È di queste ore la notizia del caricamento di alcuni video truffaldini su un noto canale YouTube: gli aggressori si sono improvvisamente impossessati di un canale YouTube da oltre 15 milioni di iscritti e hanno iniziato a pubblicare contenuti pericolosi legati al mondo delle criptovalute.
Ma com’è potuta accadere una cosa del genere? Nel caso dell’incidente in questione, gli aggressori hanno 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.
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.
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 e le responsabilità di Google
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?
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.