Gitbaritalian
developer
podcast
30

Hacker, twitter e le responsabilita degli sviluppatori

Serie 1
Episodio 30
Durata 25 minuti

Hanno hackerato twitter, hanno preso il controllo di più di 300000 account (tra cui quelli di Obama, Biden, Musk e Uber) per mettere in piedi una maxi truffa. Quali sono le responsabilità dei programmatori, quali sono i piccoli accorgimenti da mettere in piedi.

Links

Contatti

@brainrepo su twitter o via mail a info@gitbar.it

Crediti

Le sigle sono state prodotte da MondoComputazionale Le musiche da Blan Kytt - RSPN e Broke For Free - Something Elated

Trascrizione

Trascrizione automatica realizzata con servizi Amazon AWS Transcribe

benvenuti su Bar i podcast dedicato al mondo dei full stack developer di mezzo artigiani mezzo artisti che ogni giorno infilavano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.
Bene, benvenuti in questo nuovo episodio di Suits Bar.
Oggi una puntata un po' particolare avevo preparato per voi un episodio dove parlavo di Doku E' di breve, quindi del deploy delle nostre applicazioni o su una singola macchina, utilizzando appunto in modo da direttamente da repository e kit, oppure utilizzando appunto la tecnologia è il paradigma perde direttamente l'applicazione.
In questo caso su le manda via Amazon su Amazon fatti e naturalmente avevo preparato la puntata era già programmata, ma ho deciso di sospenderla perché questa notte è successo qualcosa di veramente interessante.
Ma prima di introdurvi l'argon e di raccontarvi un po' cos'e' successo e perche' cosa mi ha spinto a portarlo qua? In un episodio del podcast vi devo ricordare i nostri contatti.
Potete scrivermi a Heat, su Twitter oppure ai tweet.
Inoltre tutte le puntate reale con relative nota dell'episodio e trascrizioni automatiche le trovate su www bar punto eat.
Bene, ricordati i nostri contatti al momento di partire mentre proviamo a capire cos'e' successo stanotte perché ho cambiato idea per non pubblicare l'episodio che avevo già preparato stanotte è successa una cosa molto molto particolare.
Infatti avvenuto il più catastrofico attacco su Twitter L'attacco consisteva in una semplice truffa con tutta una serie di tweet che venivano da profili di personaggi famosi e che dicevano in poche parole versate mi un Totti in bitcoin il doppio giusto in modo da ringraziare e la mia comunità che mi segue.
Insomma mi sta accanto.
Più o meno era questo il messaggio.
Naturalmente ho visto tanti e Twitter Hilary e simpatici.
Per esempio quello di Jeff Bezos che scriveva appunto in mezzo sei un po' visto come il tirchio tra gli ultra milionari dice sei già da qualcosa indietro.
È sicuramente una truffa, però in tweet simpatici a parte.
In realtà questo tipo di truffa mette le basi tu su una serie di attacchi che risalgono al duemila diciotto, quando dei gruppi di truffatori hanno creato tutta una serie di account fake di Elon, maschio vittima anche della truffa di ieri sera e utilizzavano tutta una serie di tecniche per amplificare la Rice.
Quindi il diciamo il numero di persone che potevano vedere il tweet, appunto, e tecniche che poi non erano altro che l'utilizzo, che ne so di botnet per amplificare appunto la Rice, oppure di replay.
Quindi risposte fatte a tweet dell'account ufficiale che in qualche modo permetteva l'acquisizione di legittimità.
Naturalmente da questa esperienza, da questi fatti del Duemila diciotto una cosa si è notata chiara che le persone che scavano perché comunque questo tipo di tweet bastava andare a vedere le transazioni su quell'indirizzo Bitcoin per vedere che comunque ce l'ha del flusso.
Quindi che ci sono delle persone che versavano dei Bitcoin è emersa anche la lentezza nell'intervento di Twitter e ed è emerso anche un certo una certa grinta nel reagire.
Perché alle misure più repressive messe in atto da Twitter è succedevano, diciamo, delle azioni ancora più forti da parte degli hacker.
Quindi era un po' come fare il gioco del gatto e del topo.
Non rincorrersi.
E con un obiettivo da parte degli hacker che oltre a naturalmente racimolare piu' soldi possibili, volevano generare il piu' caos possibile.
Caos che dopo due anni sono riusciti a fare.
Perché? Perché pare che in realtà siano stati presi tutta una serie di account verificati si parla di trecentocinquanta nove mila account verificati, che sono quelli che poi Twitter ha bloccato per creare un problema in scala mastodontica.
Tra questi account ci sono quelli di Obama, quelli di quelli di Bezos, persino quelli de pole e Uber e naturalmente e Lomas che era in mezzo a questi.
Pensate che con la con la stessa tecnica che vi ho raccontato prima, quindi una truffa e per la quale si chiedeva di versare un certo ammontare di bitcoin in cambio appunto del doppio, e sono stati raccolti nella prima ora circa cento diciotto mila dollari.
Naturalmente stiamo parlando di una cifra grandissima.
Qualcuno faceva la battuta e dice in un'ora sono stati raccolti quasi più, più, più più denari del profitto di Twitter.
Una cosa simpatica, visto che comunque Twitter ha dei grossi problemi di profittabilità pero'.
Diciamo che la il problema e' la portata del problema è un problema.
È una portata di scala gigantesca.
Perché comunque tutti questi account verificati che non sono due, sono trecentocinquanta mila hanno inciso comunque in una percezione di sicurezza.
È stando alle dichiarazioni di Joss, spero si Lega è un reporter esperto di sicurezza informatica.
A vais pare che per la sia stato usato un di Twitter che appunto permette di gestire e gli account e che attraverso questo tool sia stata cambiata di questi account verificabili, quindi la proprietà di questi account verificabili.
Naturalmente Twitter ha rimosso gli screenshot che erano stati pubblicati sulla stessa piattaforma è e ha bloccato gli account che condividevano questi screenshot.
Quindi ad oggi non sono disponibili degli screenshot di questo fantomatico pannello che risulta d'accatto, sempre stando alle indiscrezioni di cozze vox.
E pare che non si sia trattato di un caso di ingegneria sociale o di password non sicuro passo riutilizzate, ma dipenda da un dipendente interno a Twitter che abbia in qualche modo e divulgato è permesso l'accesso per effettuare questo tipo di di truffa.
E se così fosse, diciamo che la seconda volta quest'anno.
Quindi in realtà il problema, probabilmente due o tre domande.
Jack Dorsey, zio di Twitter, dovrà pur farsela.
Una cosa interessante è stato e il fatto che Twitter ha in qualche modo è stata abbastanza fredda nel seguire questo tipo di fenomeno con appunto dei tweet, infatti, ha fatto due tweet durante il lasso di tempo in questa ma succedendo questa truffa, il primo dove annunciava che ci era stato questo Brice di sicurezza.
Questo questo problema e' il secondo due ore dopo, dove ha bloccato trecentocinquanta nove mila account verificati.
Tra questi account verificati, come vi dicevo, ce la di Jeff Bezos, account che non potevano né twittare ne ne resettare la password.
Adesso qua ed è uno dei motivi per cui vi sto parlando di questo mi sorge una domanda abbastanza sponda Tanya.
Buona parte dei messaggi e delle informative che passano, specie nel mondo statunitense, passano attraverso Twitter anche informazioni di tipo critico? No, per esempio, la lasciano al Werder Service con dalle informazioni tornato nel momento in cui vengono bloccati trecentocinquanta nove mila account.
Questo tipo di servizi che possono essere inquadrati come servizi critici non possono twittare.
Basti pensare che appunto la National stava twittando un avviso di tornado e poi è sparita.
Quindi in realtà e' la domanda che mi pongo è oggi come oggi questo tipo di servizi vengono utilizzati anche in condizioni critiche e possono essere un servizio che viene utilizzato in condizioni critiche puo' essere vulnerabile ad attacchi di questa scala? Oppure possiamo utilizzare stiamo facendo bene ad utilizzare i servizi di comunicazione? General Paul Puss per informazioni tipo critiche.
Basti pensare che il presidente americano Donald Trump passa non passa più comunicati stampa, quasi, perché buona parte delle informazioni passano attraverso Twitter, ma in un momento in cui degli hacker possono entrare su Twitter e far uscire dei messaggi a nome di personaggi famosi, tra cui può esserci anche quello del presidente americano Roma Qualche domanda me la metto la sicurezza nazionale e se legata una piattaforma come Twitter qualche dubbio me lo e lo stesso dubbio che mi sono messo quando all'attuale presidente del Consiglio italiano, durante il periodo di faceva i suoi comunicati e attraverso Facebook lo faceva sotto forma di video.
E va bene, ma può essere quello il canale istituzionale per comunicare e questo canale istituzionale a parte, che appartiene a una società, ma non voglio addentrarmi in discorsi di questo tipo.
Per questo vi suggerisco magari il podcast data che mettono nelle note dell'episodio, che tratta l'argomento in modo molto più profondo di come posso farlo io.
Però nel momento in cui questo tipo di persone, questo tipo di strumenti, vengono utilizzati per passare delle comunicazioni istituzionali, non è permesso che abbiano questo tipo di vulnerabilita'.
Ma allora il problema quindi non è più solo un problema di minaccia della privacy, ma è qualcosa anche di più vasto e di piu' grande portata, come appunto la sicurezza nazionale.
Riflettendo sull'accaduto mi sono reso conto che comunque tutti i prodotti che noi andiamo a realizzare come sviluppatori devono comunque garantire un'unità minima di sicurezza.
Dove Perlini.
Ma intendo essenziale anche perché, come ben sappiamo, la sicurezza assoluta non esiste e non possiamo delegare la responsabilità della sicurezza solo ai framework che usiamo, ma dobbiamo esserne in qualche modo pienamente consapevoli.
Allora facevo una riflessione sulla sicurezza dei pannelli di amministrazione.
Solitamente le nostre applicazioni, in buona parte dei casi, sono dotate di pannelli di amministrazione.
Questi pannelli di amministrazione sono come la chiave magica che permette l'accesso ai dati della nostra applicazione, quindi sono uno degli elementi più vulnerabili della nostra stessa applicazione.
Allora cosa ho pensato riflettendo su come mettere in sicurezza i pannelli l'amministrazione? Bene, il primo ragionamento che ho fatto è quello di dividere il pane nella nostra applicazione in due parti, la parte e la parte amministrazione.
A rendere isolate le due parti questa azione si contrappone una cosa che vedo spesso, che sono dei software dove non si riesce a percepire la differenza sostanziale troppa nell'amministrazione del software stesso, spesso appunto la gestione dei diritti e' delegata ad aree specifiche faccia o a funzionalità all'interno di una maschera generale l'idea di dividere il pannello di amministrazione dall'applicazione ci permette comunque di isolare completamente i due ambiti operativi, isolando completamente quindi a livello di codice, i due ambiti operativi.
Abbiamo la certezza matematica che all'interno dell'applicazione in leland non ci sarà nessun caso in cui l'utente possa scavalcare assumere delle il controllo di funzionalità d'amministrazione un'altra cosa molto interessante è quello di nascondere il rl per l'accesso ai pannelli di amministrazione, cosa che con gli attuali framework e' abbastanza facile.
Basta semplicemente impostare o una configurazione i parametri di configurazione oppure una rotta è il consiglio che mi sento di dare o comunque la tecnica che io utilizzo è quello di non usare uno slasher per accedere all'area amministrativa, ma magari mettere dei nomi che possono essere fuorvianti.
Per esempio che nessuno rl di un titolo di un contenuto il vostro sito piuttosto che qualcosa di veramente mio.
Per esempio metto diabetica o che ne so css esserle quindi slasher, css le persone pensano a tutto tranne che a un pannello di amministrazione, facendo in qualche modo si limitano tantissimo quelle azioni di scanning automatico che precedono l'utilizzo di un brutto, forse per tentare l'accesso un'altra, cosa molto interessante che secondo me possiamo fare per limitare anche nelle nostre, per quanto piccole applicazioni, tentativi di hacking per esempio limitare i tentativi di log-in, infatti molti framework che ci sono in circolazione oggi permettono spero si dica quindi una funzione che non permette di provare un in più di un certo numero di volte in un lasso di tempo.
Questo magari puo' essere legato alla o puo' essere legato per esempio al braccio surfing fingerprint che è un'impronta che in qualche modo possiamo generare dalla configurazione del che sta eseguendo, perché si sa che le configurazioni del sono ha talmente particolare.
Una volta che installiamo dei mettiamo degli elementi da essere quasi un'impronta digitale per il navigante facendo così riusciamo a limitare tantissimo le operazioni eletti.
I tentativi di brutto forcing un'altra, cosa interessante da per limitare questo tipo di tentativi è per esempio non usare l'utente era admin per l'accesso nel pannello di amministrazione, ma ammettere non solo la password ma anche il nome utente.
Questo limita ancora di gran lunga in un tentativo aumenta naturalmente numero di tentativi di accesso falliti.
In certo può generare un po' di confusione nel primo periodo col nostro cliente nostro utente, ma ci dà un grosso vantaggio.
Ci dà il vantaggio che in realtà le operazioni di brutto forse debbano essere fatte non solo per la password, ma anche per il nome utente.
Naturalmente non sto a dirvi che buona parte dei moderni utilizzano sistemi di tuo factor authentication, basti pensare ad Avda.
Google, ora Macron Microsoft.
Tutte queste tecniche però sono inutili.
Se poi andiamo a salvare le password in chiaro nel database, quindi mi raccomando, la parte importante è quello di andare a salvare le password criptate e alcune cose che vi sto dicendo vi potranno sembrare banali, ma credetemi, ad oggi, in buona parte delle consulenze che faccio, continuo a vedere password salvate in chiaro, sistemi nei quali è possibile entrare inserendo utente oppure accedervi con una.
Quindi, anche se vi sembrano banali, questo vuole essere un memorandum, un memo non solo per chi sta sviluppando l'applicazione, ma anche per me stesso, perché comunque nel la guerra mettere insieme queste piccole buone pratiche sono degli accorgimenti e spesso si rivelano a livello pratico, come qualche configurazione in più da fare e poco più.
Ci permettono però di aumentare in modo significativo la sicurezza dell'applicazione che stiamo realizzando un'altra cosa per esempio, che molti trascurano ci pensano me in primis e quello di per il pannello d'amministrazione evitare per esempio di mettere la funzione di password.
Quindi il resto della password dimenticata per l'utente amministratore che solitamente non serve e soprattutto la cui funzionalità un cambio ad aprire una breccia, una possibilità appunto, di attacco perche'.
Il password è una delle aree più sensibili nella sicurezza dei nostri pannelli di amministrazione.
Alcune cose che possiamo fare, per esempio permettere l'accesso al pannello d'amministrazione qua naturalmente emerge la necessità di dividere il pane all'amministrazione dell'applicazione che stiamo facendo proprio livello.
Anche è operativo spesso anche di macchina virtuale.
Ha solo ad alcuni tipi che possono essere o i p pubblici, per esempio lei ci due di Amazon.
Quindi le macchine virtuali di Amazon permettono appunto attraverso il loro farmaco fa il ruolo di abilitare alcuni oppure può essere un che sta dietro la Cup in non vi sto a dire perché lo sapete benissimo che è indispensabile installare un certificato all'interno della macchina, quindi per permettere la navigazione sotto forma di https, in modo che tutto il traffico che noi facciamo verso questo pannello d'amministrazione o che i nostri utenti fanno sia criptato, così come un'altra.
Cosa interessante che ho trovato utile negli anni è stata quella di bloccare l'accesso al database solo ad alcuni picchi.
Sono le macchine in realtà che ci accedono quindi le macchine nelle quali gira la nostra applicazione.
Ci sarebbero tantissime cose da dire, per esempio il fatto di bloccare types negli apple hod oppure di aggiornare il framework o di verificare i permessi di file dei file.
Però questo tipo di azioni sono indispensabili quando noi andiamo a sviluppare un'applicazione che non gira solo nella localhost, ma che poi mettiamo in produzione.
Come vi dicevo spesso sono accorgimenti anche marginali anche che ci rubano pochi pochi minuti, ma che in realtà rendono la nostra applicazione sicure.
Quindi rendono i dati dei nostri utenti sicuri a loro volta che da una parte a essere un po' piu' per ci rendono consapevoli della responsabilità che abbiamo nel trattare i dati degli utenti perché noi non sappiamo o comunque possiamo solo immaginare la tipologia di dati che i nostri utenti andranno a salvare nella nostra applicazione, ma l'importanza di questi dati in realtà nella vita di tutti i giorni del nostro utente, questa la possiamo solo appunto immaginare, per cui abbiamo la necessità periodicamente di farci questo tipo di domande e di darci delle risposte per cui sarebbe opportuno fermarsi.
Magari ogni tanto.
Ed è una cosa che io sto facendo da qualche tempo a questa parte.
Per tanti anni non l'ho fatta e mi sono reso conto solo poi a chiedermi il valore che io sto dando al mio cliente attraverso l'applicazione che sto sviluppando è un valore che in qualche modo lo mette anche al riparo da certi rischi o per dare questo valore al mio cliente lo espongo una quantità di dischi che spesso rischia di superare, appunto il valore che io voglio fornire.
Sono sicuro che questa puntata potrebbe entrare nella serie le seghe mentali dello sviluppato.
Abbiate pazienza, ma avevo proprio l'esigenza di condividere con voi questo tipo di riflessione.
Quindi questa questa sede appunto, di passaggi che mi spingono quotidianamente a cercare di fare dei prodotti non solo migliori in termini di valore, ma anche quelli più sicuri.
Vi anticipo che sto preparando una puntata con un esperto di sicurezza informatica di cui non vi dirò il nove fino all'uscita.
Dell'episodio è un'altra dove andremo a parlare di lui con un altro ospite abbastanza e' importante ha detto questo e prima di lasciarvi vi ricordo i nostri contatti.
Potete scrivermi a in oppure su Twitter a heat Brian Repo tutte le informazioni degli episodi col file audio la trascrizione le note appunto della puntata le trovate su bar punto Vi ricordo che potete iscrivervi al vostro cliente di podcast per ricevere settimanalmente la nuova puntata.
Solitamente usciamo il e' solitamente usciamo attorno alle otto e mezza parte questa settimana che come vi dicevo ho preferito uscire un pochino più tardi per registrare questa affrontata all'ultimo minuto un saluto da ponte Allie Spero si dica scontente eh ci sentiamo la prossima settimana con donne il circolo dei fusti Ekberg.
Una volta a settimana ci troviamo davanti a due birre e comprerebbe Parliamo di linguaggi e tecniche di sviluppo web, metodologie e degli strumenti immancabili nella cassetta degli attrezzi dei Foster
Ho bisogno di una mano. Aiutami a rendere più conosciuto il nostro podcast. Parlane con gli amici o con i colleghi e iscriviti usando Apple Podast o Google Podcast. Questa tua azione ci aiuterà a salire nella classifica dei podcast di tecnologia ed essere utili anche a qualcun’altro. Se non ti va, amici come prima😄