Beast Attack SSLOggi cercherò di spiegarvi come funziona l’attacco che ha messo in ginocchio l’ultima barriera della sicurezza web. La vulnerabilità è riportata ufficialmente CVE-2011-3389 ed è datata 2011.

L’attacco BEAST (Browser Exploit Again SSL TSL ) è stato sviluppato da Thai Duong e Juliano Rizzo e può essere portato su TLS v1.0. La versione TLS v2.0 invece non risulta vulnerabile.

Ogni qualvolta vi connettete ad un sito web che usa SSL e fate l’autenticazione, vedrete che nella URL della pagina successiva cioè quella autenticata una stringa particolare. Una volta autenticati troveremo nella URL del browser l’ ID di Sessione che è un numero alfanumerico randomico che mantiene lo stato della pagina, rendendo unica la connessione tra il client e il server. Questo ID viene dato dal web server al browser del client. L’ID di sessione è possible trovarlo anche nei Cookies che rilascia il sito. Di solito questo ID di Sessione viene criptato per prevenire hijacking della sessione.

Per facilitare meglio la comprensione dividerò l’attacco in 3 fasi.

Fase 1. L’attaccante invia del codice javascript maligno al target attraverso varie tipologie di attacco ( CSRF, Social Engineering, Pagina di ritorno con Javascript etc). Questo codice maligno viene eseguito sulla macchina della vittima ed ha lo scopo di catturare gli Header e i cookie criptati che vengono assegnati dal web server (TLS v1) e inviare il tutto all’attaccante.

Prima di procedere alla seconda fase dobbiamo chiarire la differenza tra cifratura a Blocchi e cifratura Stream.

La cifratura a blocchi è un tipo di cifratura che utilizza blocchi da 64bit per l’encrypting dei dati ed è utilizzato perlopiù in modalità embedded.

La cifratura a stream invece viene utilizzata una XOR dei dati bit a bit quindi il dato viene codificato. Per decodificarlo invece si riapplica la stessa XOR che riporta i bit all’origine.

Fase 2.  SSL e TLS possono essere criptate attraverso due tipologie di cifrature: cifratura a Blocchi come AES e DES e cifratura Stream come RC4. Il TLS v1 da la precedenza alla cifratura a blocchi anzichè a  Stream. La vulnerabilità consiste proprio nella precedenza data dal protocollo TLS v1. Immaginiamo di avere 2 messaggi di testo in chiaro identici, dopo averli criptati entrambi avremo lo stesso testo cifrato nel quale viene riflesso il pattern del testo in chiaro. Male.

Spiegazione: TLSv1 utilizza la modalità CBC per criptare i blocchi, questo però viene utilizzato “male”. Infatti anzichè utilizzare un VI (vettore di inizializzazione) random per ogni messaggio TLS, viene usato il messaggio cifrato dell’ultimo blocco inviato per criptare il successivo messaggio.

Fase 3. Ora l’attaccante non deve fare altro che una comparazione tra la sessione criptata e i dati inviati dal javascript maligno iniettato nel computer della vittima per trovare il vettore di inizializzazione. Per fare questo non deve far altro che applicare la formula C’ xor P dove  P è l’ultimo testo in chiaro (inviato dal javascript sulla vittima) e C’ è l’ultimo blocco criptato inviato prima del testo P. Se l’attaccante ha ragione avrà come output lo stesso testo cifrato che ha avuto prima di fare l’encrypt del blocco. Una volta ricavata l’informazione, l’attaccante avrà la possibilità decriptare ogni dato inviato dal web server.

Per correggere questa vulnerabilità su windows server basterà correggere l’ordine di priorità dei cifrari.

  1. At a command prompt, enter “gpedit.msc”. The Group Policy Object Editor appears.
  2. Expand Computer Configuration, Administrative Templates, and Network, and then click SSL Configuration Settings.
  3. Under SSL Configuration Settings, double click the SSL Cipher Suite Order setting.
  1. Aprire un prompt, digitare “gpedit.msc”. Vi apparirà l’editor delle policy di gruppo.
  2. Espandere Computer Configuration, Administrative Templates, Network, e poi click su  SSL Configuration Settings.
  3. Sotto SSL Configuration Settings doppio click su Cifrari SSL Cipher Suite Order setting.
  4. Inserite questa sequenza TLS_RSA_WITH_RC4_128_SHA e TLS_RSA_WITH_RC4_128_MD5

 

Nel prossimo post, parleremo del CRIME attack.

Cheers! ;-)