Dopo il famigerato Heartbleed e i successivi FREAK , Shellshock e POODLE , dalla storica conferenza sulla sicurezza informatica Black Hat emerge un altro bug di sicurezza degno di un nome tutto suo: HEIST , abbreviazione di HTTP Encrypted Information can be Stolen Through TCP-Windows (“Informazioni crittografate con HTTP possono essere trafugate tramite TCP windows”). Non è direttamente questa nuova vulnerabilità a decifrare i dati sensibili nelle comunicazioni HTTPS, ma grazie ad essa due vulnerabilità scoperte tra il 2012 e il 2013 e finora solo teoriche, BREACH e CRIME , diventeranno un pericolo concreto . HEIST infatti rende molto più semplice sfruttarle, rimuovendo l’ostacolo principale: la necessità di intercettare il traffico.
Per comprendere la svolta rappresentata da HEIST è prima necessario esplorare il funzionamento di BREACH , altro bug presentato al mondo in un’edizione della Black Hat, quella 2013. BREACH è un cosiddetto oracle attack , una categoria di vulnerabilità in cui l’attaccante crea un testo in chiaro (o cifrato) e lo invia in input al sistema sotto attacco, che produrrà un output: dall’analisi dell’output e dalla sua relazione con l’input prescelto , l’attaccante è in grado di dedurre informazioni altrimenti segrete anche senza eseguire un algoritmo di decifrazione.
BREACH sfrutta le caratteristiche dell’algoritmo di compressione Deflate comunemente utilizzato nel protocollo HTTP. Deflate conserva solo la prima occorrenza di una particolare stringa : tutte le ripetizioni successive diventano un puntatore compatto alla prima, permettendo dunque di ridurre la dimensione della risposta e caricare più velocemente le pagine web. Questa operatività però comporta la possibilità per l’attaccante di dedurre la presenza di una certa stringa . È sufficiente aggiungerla e osservare la dimensione del contenuto compresso: se la variazione è minima, la stringa era già presente ed è stato semplicemente aggiunto il puntatore salvaspazio. Se invece la dimensione varia di parecchio, l’attaccante può semplicemente correggere un carattere alla volta fino a rivelare il contenuto completo . Per sfruttare BREACH, gli attaccanti avevano bisogno di due elementi: risposte HTTPS che ripetano nel loro corpo il contenuto della richiesta (cosa molto comune, per esempio nel caso di un utente posta un commento in un forum che al ricaricarsi della pagina verrà visualizzato) e soprattutto la possibilità di misurare la dimensione delle richieste HTTPS . Per farlo era necessario trovare un modo di intercettare tutto il traffico tra la vittima e il server, aspetto tutt’altro che banale.
Ora grazie a HEIST gli attaccanti possono misurare la dimensione delle risposte HTTPS inviate da qualunque sito lucchettato in verde senza la necessità di sniffare il traffico tra gli estremi della comunicazione. È sufficiente compromettere una qualsiasi pagina web visitata dall’utente con del codice javascript malevolo che convinca il browser a generare richieste verso il sito che contiene i dati sensibili della vittima. Grazie a due nuove API standard del web, Resource Timing e Fetch , è ora possibile per il codice javascript avere accesso anche a queste informazioni critiche e consegnare agli attaccanti l’ultimo pezzo mancante per sfruttare la vulnerabilità BREACH. Tutto comodamente dal browser dell’utente, a cui è sufficiente visitare una pagina web compromessa.
I ricercatori responsabili della scoperta, Tom Van Goethem e Mathy Vanhoef, hanno già condiviso le loro scoperte in anteprima con Google e Microsoft. Secondo Van Goethem “ci vorrà del tempo prima di vedere i primi exploit basati su HEIST, perché prima sarà necessario infettare i siti che faranno da vettore”. Nonostante non ci siano per ora exploit noti di BREACH, a tre anni dalla rivelazione della vulnerabilità la maggior parte dei siti vulnerabili lo sono ancora. La difficoltà sia nel difendersi che nel perpetrare praticamente l’attacco ha finora causato un sostanziale stallo , che HEIST ha tutte le carte in regola per sbloccare. A favore dei cattivi .
Una delle eventualità più temute è la possibilità per gli attaccanti di scoprire il token CSRF ( Cross Site Request Forgery ), che alcuni servizi web includono nel corpo della richiesta e dunque rendono vulnerabile ad attacchi oracolo. I token CSRF evitano che un qualsiasi sito web possa fare login e altre operazioni a nome dell’utente su qualche altro servizio (ad esempio, online banking o casella di posta). Le conseguenze esatte del furto di uno di questi token dipendono dal grado e numero di funzionalità da esso dipendenti, ma per i ricercatori la situazione potrebbe implodere presto: “La conoscenza del token CRSF è tipicamente tutto ciò che serve per compromettere un account. Sospettiamo che la combinazione tra BREACH e HEIST diventerà a breve il metodo più semplice a disposizione per farlo.”
Stefano De Carlo
Ti potrebbe interessare
4 ago 2016