Andrea Galeazzi hackerato: cosa potrebbe essere successo. Cookie hijacking o OAuth? (aggiornato)

È di queste ore la notizia del caricamento di alcuni video truffaldini su un noto canale YouTube italiano, quello amministrato da Andrea Galeazzi: gli aggressori sembra si siano impossessati delle sue credenziali per pubblicare contenuti pericolosi legati al mondo delle criptovalute. L’attacco informatico ha compromesso l’account Google di Galeazzi e tutti i servizi collegati.

A seguito dell’incidente, il canale YouTube ufficiale di Galeazzi è stato reso irraggiungibile da parte di Google, molto probabilmente per via della pubblicazione di contenuti non ammessi da parte dei criminali informatici, mentre lo stesso creator ha pubblicato messaggi sui social per avvisare la sua community di non fidarsi di eventuali email o contenuti sospetti provenienti dal suo account compromesso.

Ma com’è potuta accadere una cosa del genere? Nel caso dell’incidente in questione, gli aggressori potrebbero aver utilizzato la tecnica conosciuta come session hijacking (in italiano, dirottamento della sessione).

Abbiamo già parlato in altri nostri di questa modalità d’attacco che mette gli aggressori nelle condizioni di accedere a servizi altrui senza conoscere nome utente e password corretti.
Poiché questo tipo di attacchi sono in continua crescita, non soltanto su YouTube, vale la pena soffermarci sul modus operandi utilizzato dai criminali informatici.

Partiamo dal concetto di sessione

Conosciamo il concetto di sessione: è il periodo di tempo durante il quale l’utente interagisce con un’applicazione. Ogni volta che si visita un sito Web, inizia una nuova sessione. Per impostazione predefinita, la durata delle sessioni per le applicazioni PHP è 1440 secondi ovvero 24 minuti. Il valore può essere ovviamente personalizzato lato server e può variare da un’applicazione all’altra.

Utilizzando un apposito cookie tecnico, generato dall’applicazione lato client, la durata della sessione può essere estesa: in altre parole, grazie alla presenza del cookie di sessione, il client conferma di essere ancora collegato e l’applicazione Web non richiede nuovamente l’accesso con username e password. D’altra parte sarebbe davvero scomodo ritrovarsi disconnessi da un’applicazione dopo pochi minuti.
Fastidiosissimo, ad esempio, quando si riceve il messaggio sessione scaduta su Facebook: nell’articolo abbiamo spiegato da cosa può dipendere e come risolvere ma i principi sono identici per qualunque applicazione Web con cui si ha a che fare.

La stragrande maggioranza delle applicazioni Web, come Facebook, Twitter o YouTube, usano cookie persistenti che vengono generati sul client una volta conclusa con successo la procedura di autenticazione sull’applicazione Web. La loro memorizzazione da parte del browser Web fa sì che l’utente non debba effettuare di nuovo il login neppure nelle successive sessioni di lavoro (ad esempio quando spegne e riaccende il dispositivo). I cookie persistenti scadono a una data specifica o trascorso un determinato periodo di tempo: a quel punto deve obbligatoriamente essere effettuato di nuovo il login sull’applicazione Web.

Rubando il contenuto del cookie persistente, un aggressore può utilizzarlo sui suoi dispositivi per sottrarre l’identità altrui e autenticarsi come un altro individuo.

Come funziona l’attacco cookie o session hijacking

Con l’attacco chiamato cookie hijacking un malintenzionato riesce a ottenere l’accesso ai cookie di un utente, salvati dal browser Web in uso, e ad utilizzarli per assumere il controllo dell’account altrui.

Una volta, quando la maggior parte dei siti Web non usava HTTPS, utenti collegati alla stessa rete usata dalla vittima potevano analizzare il traffico dati in transito, individuare cookie di sessione e cookie persistenti quindi rubare il loro contenuto.

Oggi questo tipo di attacco è diventato più complesso e gli aggressori sfruttano altre metodologie. Generalmente, come accaduto nel caso del canale amministrato dallo youtuber Linus Sebastian, inviano – spesso tramite email – file malevoli che all’apparenza sembrano legittimi ma che in realtà caricano ed eseguono codice dannoso sul sistema della vittima.

Cosa è successo in un caso simile a quello di Andrea Galeazzi

Sebastian racconta che uno dei membri del suo team ha aperto un file PDF nocivo presentato, tramite email, come un’offerta proveniente da un potenziale inserzionista. Una volta aperto, il codice malevolo contenuto nel file è andato in esecuzione e il cookie persistente del canale YouTube è stato trasferito agli aggressori remoti che a loro volta si sono subito attivati per utilizzarlo.

Perché rubare i cookie di sessione e persistenti? Non basta recuperare username e password per l’accesso a YouTube o a qualunque altro servizio? No.

Questi servizi possono essere protetti con meccanismi basati sull’autenticazione a due fattori: una conferma dell’accesso viene sempre richiesta al momento del login con nome utente e password corretti, specie se la procedura viene avviata da un dispositivo precedentemente sconosciuto. Inoltre, le stesse procedure di verifica svolte dall’applicazione Web all’atto del login possono rendere impossibile l’accesso da parte di utenti non autorizzati, anche se in possesso delle credenziali corrette.

Riutilizzando su un altro sistema lo stesso cookie di un altro utente, rubato mentre la vittima era “loggata” sull’applicazione Web, l’aggressore ha gioco facile e può presentarsi al server remoto facendo le veci altrui, senza dover superare l’autenticazione a due fattori.

Cosa fare per difendersi? Le colpe dell’utente

Inutile dire che nel caso di un attacco di tipo cookie o session hijacking la responsabilità è in primis della vittima.

Si prenda il caso di specie: quel file PDF era davvero tale oppure si trattava di un eseguibile mascherato da PDF usando ad esempio il meccanismo della doppia estensione in Windows? Noi consigliamo sempre di attivare la visualizzazione delle estensioni dei file conosciuti in Windows in modo da smascherare subito chi usa pericolosi trucchetti.

Se il file malevolo fosse stato davvero un PDF, gli aggressori potrebbero aver sfruttato le vulnerabilità di un visualizzatore come quello integrato nel browser, di Acrobat Reader o di qualunque altro programma similare. Ma anche in questo caso… l’esecuzione del codice malevolo può avvenire solo se non si fosse aggiornato il software per la visualizzazione dei PDF con le ultime patch di sicurezza.

Ancora, a meno che non si sia trattato di un attacco di elevato profilo con lo sfruttamento di uno zero-day sconosciuto, possibile che il tentativo di apertura del file malevolo non abbia fatto battere ciglio all’antimalware?

Google potrebbe migliorare il monitoraggio degli account

Sebastian si è dichiarato fortunato di essere riuscito a risolvere il problema in brevissimo tempo, con la collaborazione di Google. D’altra parte, tuttavia, anche YouTube potrebbe richiedere agli utenti di reinserire la loro password o autenticarsi nuovamente quando si modificano elementi importanti come il nome del canale o si eliminano più video contemporaneamente.

Inoltre, quando si verifica un attacco di tipo cookie hijacking, l’indirizzo IP del client cambia radicalmente perché gli aggressori spesso si collegano dall’altra parte del mondo. La geolocalizzazione del client autenticato è quindi completamente diversa: ecco, in questi frangenti YouTube dovrebbe richiedere agli utenti di autenticarsi nuovamente. In altre parole, l’improvviso cambio di posizione per un utente che pochi minuti prima era collegato da un altro Paese dovrebbe insospettire e provocare l’immediata chiusura di tutte le sessioni in corso.

La tecnica del cookie hijacking è comunemente utilizzata da molteplici malware e trojan bancari: Xenomorph attacca le app Android di tante banche italiane e usa proprio questo meccanismo.

Ancora una volta, quindi, le misure di sicurezza implementate sui singoli dispositivi e a livello di infrastruttura sono essenziali per proteggersi da attacchi come quello descritto. Quando un oggetto dannoso dovesse andare in esecuzione anche su uno solo dei propri dispositivi, le conseguenze possono rivelarsi nefaste.

Aggiornamento sul caso Galeazzi: lo youtuber parla di phishing

Nel racconto di quanto accaduto, emerge che l’attacco subìto da Andrea Galeazzi non è stato il risultato di una falla tecnica, ma di una manipolazione psicologica costruita con estrema precisione.

Gli aggressori hanno sfruttato una dinamica lavorativa del tutto ordinaria per un creator professionale: i contatti con i brand. Galeazzi racconta di aver ricevuto una mail phishing che non presentava alcun elemento grossolano o sospetto, anzi riproduceva fedelmente modalità, tempistiche e linguaggio tipici delle collaborazioni reali, inserendosi in un flusso quotidiano.

Il passaggio decisivo è avvenuto quando, per completare una presunta procedura operativa, è stata richiesta una verifica del canale YouTube: un’azione apparentemente neutra, ma che in realtà ha aperto l’accesso all’intero account Google.

In quel momento l’attacco si è trasformato da potenziale a irreversibile, con la rapidissima sostituzione delle credenziali di recupero e la presa di controllo totale dell’ecosistema digitale collegato alla stessa email. Le modifiche al canale, l’avvio di live truffaldine sulle criptovalute e la compromissione di tutti i servizi associati sono state solo le conseguenze visibili di un’operazione iniziata su un sistema personale di Galeazzi.

È proprio questo l’aspetto più critico dell’ingegneria sociale moderna: non forza i sistemi, ma induce la vittima a legittimare l’accesso, rendendo il danno immediato e, almeno inizialmente, impossibile da fermare.

Sfruttamento dei permessi accordati via OAuth

Galeazzi afferma: “ho schiacciato sì per verificare il canale YouTube”. E non dice esplicitamente “ho inserito email e password”.

La domanda che resta sullo sfondo è la seguente: come gli aggressori hanno ottenuto i diritti di accesso all’account di Galeazzi? L’autorizzazione di un’app di terze parti via OAuth non permette di accordare l’autorizzazione per la modifica delle credenziali. Tra i permessi che possono essere concessi, tuttavia, c’è il pieno controllo del contenuto dell’account Gmail, di Drive, di YouTube e così via.

Se con OAuth si concede l’autorizzazione di “Leggere, scrivere, controllare le email Gmail” (a proposito, controllate il contenuto della pagina Servizi e app di terze parti), l’aggressore può certamente leggere le mail, comprese quelle in arrivo. Tuttavia, Google non usa un “codice di conferma” via email come unico fattore per il reset della password dell’account.

L’email contiene che invia in caso di cambio password contiene un link che NON autorizza da solo il cambio password: non è un OTP risolutivo come in molti servizi minori. L’hacker può sì leggere l’email e cliccare il link. Ma non “intercetta un codice” sufficiente a cambiare password: non esiste un token OAuth che valga come conferma di identità.

Per cambiare password Google richiede ulteriore verifica, basata su device già conosciuto, cookie storici, IP / area geografica coerente, eventuale email o numero di recupero, 2FA se attiva. Un attore che non ha mai fatto login, arriva da IP nuovo, usa solo OAuth è automaticamente bloccato o messo in recovery ritardata.

Le alternative sul tavolo restano tre:

1) Lo youtuber ha condiviso username e password (ma allora desumiamo che non avesse attiva neppure l’autenticazione a due fattori).

2) Manca un pezzo della vicenda ossia l’avvenuta installazione di qualche componente dannoso (i.e. un’estensione malevola, un eseguibile dannoso, un documento capace di sfruttare una vulnerabilità). In questo caso, però, si tornerebbe a un attacco di tipo session hijacking, con l’esfiltrazione del cookie di autenticazione Google.

3) La vittima ha concesso anche l’autorizzazione al cambio password (con un secondo passaggio in più tramite lo smartphone collegato all’account Google), forse ritenendo l’operazione correlata alla richiesta di verifica (fraudolenta) dell’account YouTube.

In ogni caso, facciamo i nostri migliori auguri a Galeazzi affinché la situazione possa risolversi nel migliore dei modi e in tempi brevi.