Stefano De Carlo

HEIST, vulnerabilitÓ HTTPS di servizio

La nuova vulnerabilitÓ presentata alla conferenza Black Hat 2016 semplifica l'esecuzione di altri attacchi giÓ noti. I ricercatori avvertono: prepararsi all'impatto

HEIST, vulnerabilitÓ HTTPS di servizioRoma - 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.

Dimostrazione di un attacco HEIST

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

Fonte immagine
Notizie collegate
5 Commenti alla Notizia HEIST, vulnerabilitÓ HTTPS di servizio
Ordina
  • "grazie a HEIST gli attaccanti possono misurare la dimensione delle risposte HTTPS inviate da qualunque sito lucchettato"

    Ma quante risposte sono necessarie affinché venga scoperto alcunché?
    Voglio dire:
    -da un lato abbiamo la necessità di inviare stringhe con testi sempre diversi in modo seriale al fine di scoprire qualcosa
    -dall'altro abbiamo il comune utonto che usa il sito infettato, quindi si presume qualche visita al giorno (se non infettano siti tipo Fessbuck, ovviamente)

    Mi pare che l'ordine di grandezza dtra ciò che serve e ciò che sarà a disposizione sia molto diverso.
    E nel frattempo anche gli antivirus credo che faranno qualcosa.

    Personalmente credo che la soluzione potrebbe essere nei browser, che potrebbero compattare i testi aggiungendo un po' di entropia.
    non+autenticato
  • Bravo, spiegazione dettagliata e chiara.
    non+autenticato
  • - Scritto da: ciao
    > Bravo, spiegazione dettagliata e chiara.
    si non malaccio. beh, a parte la fine. CSRF (attack) e' una tecnica d'attacco... quindi volendo lasciare il testo com'e', andrebbe scritto "token ANTI-csrf" ...
    non+autenticato
  • Ciao! e grazie mille del tuo feedback

    ╚ vero che "token anti-CSRF" sarebbe un nome decisamente migliore per rendere l'idea, ma il nome di gran lunga più accettato nella letteratura tecnica è proprio "CSRF token", inteso come "CRSF (protection) token". Pertanto è stato utilizzato quest'ultimo nell'articolo.
  • - Scritto da: Stefano De Carlo
    > Ciao! e grazie mille del tuo feedback
    figuratiSorride

    > ╚ vero che "token anti-CSRF" sarebbe un nome
    > decisamente migliore per rendere l'idea, ma il
    > nome di gran lunga più accettato nella
    > letteratura tecnica è proprio "CSRF token",
    > inteso come "CRSF (protection) token". Pertanto è
    > stato utilizzato quest'ultimo
    > nell'articolo.
    ... per me ti sei risposto da solo ... "token per la protezione da CSRF" pero' e' piu' lungo, quindi meglio i miei 5 caratteriSorride Cmq uno alla fine scrive come je pareSorride


    Cmq volendo far il pignolo (e farmi una chiacchierataCon la lingua fuori), si puo' dire che, in un forum di sicurezza o in una chattata ha senso abbreviare in 'token csrf' perche' "si e' gia sul pezzo"... in articoli divulgativi imho no... perche' stravolge il senso... scritto cosi' sembra una tipologia di token (tipo 'token otp' e simile) ma il senso e' tutt'altro. CSRF (attack) e' un tipo (anzi quasi una categoria) di attacchi, e questo "token" non e' che un num random (o qualcosa di simile = a volte e' semplicemente l'hash di qualcosa) buttato dentro nella sessione html e validato server-side, per tentare di evitare il forgery (questo detto rozzamente).
    Tra l'altro, -di per se-, il token NON salva da un CSRF attack... nel senso che, se per es il sito ne fa uso, MA e' vulnerabile ad XSS, l'attacker potrebbe iniettare codice atto a recuperare il token, rendendo vana la protezione.
    non+autenticato