Back to Posts

Share this post

Poodle

Posted by: voidsec

Reading Time: 7 minutes

Un’altra falla simile a Heartbleed è stata scoperta nel protocollo crittografico Secure Sockets Layer (SSL) 3.0, vulnerabilità che permette ad un attaccante di decifrare il contenuto delle connessioni crittate ai siti web.
La falla affligge tutti i prodotti che seguono le direttive del Secure layer, versione 3; inclusi Chrome, Firefox, and Internet Explorer.

I ricercatori hanno chiamato l’attacco “POODLE,” acronimo di Padding Oracle On Downgraded Legacy Encryption, che permette ad un attaccante di eseguire un attacco man-in-the-middle in grado di decifrare i cookie HTTPS. POODLE può forzare una connessione a utilizzare SSL 3.0 con la possibilità di rubare i cookie contenenti dati personali, sessioni, preferenze dei siti web e password.

Questa vulnerabilità permette di “calcolare” il testo in chiaro di una connessione sicura” scrive Bodo Möller, Google Security Team, in un post.

POODLE (PDF e CVE) è una vulnerabilità critica per siti web e web browser e rimarrà tale fintanto che non si esaurirà il supporto a SSL 3.
SSL 3.0 non è lo standard di sicurezza in uso per l’encryption web anche se i server e i browser mantengono la compatibilità con questo protocollo nel caso in cui incontrassero errori e/o problematiche nel più sicuro e meno vulnerabile layer TLS (Transport Layer Security). La parte peggiore e che in molti casi, l’attaccante, può costringere al downgrade i più moderni protocolli, proprio grazie a questa retro-compatibilità, il tutto in maniera trasparente all’utente.

SSL 3.0 utilizza l’RC4 per cifrare i flussi (stream) e CBC come cifrario a blocchi (un cifrario a blocchi, come si può dedurre dal suo nome, considera i dati raggruppati in piccoli blocchi e su ciascuno di questi applica delle operazioni di cifratura basate su una chiave k). RC4 è noto per essere vulnerabile ad attacchi statistici, ma nessun attacco a questa implementazione CBC era noto sino alla pubblicazione di POODLE.

Come funziona l’attacco?

Il messaggio HTTP, prima di essere cifrato e in seguito inviato al server, viene autenticato tramite un MAC e suddiviso in blocchi. Per far si che i dati da cifrare riempiano totalmente la struttura dei blocchi, a questi vengono aggiunti dei dati arbitrari detti di padding, cosicché la dimensione dei dati, del MAC e del padding riempia totalmente la struttura dei blocchi; è importante evidenziare che se la lunghezza dei dati e del MAC sono esattamente un multiplo della dimensione del blocco, viene aggiunto un ulteriore blocco dedicato interamente al padding. Un elemento chiave del processo di attacco è il valore assunto dall’ultimo byte del padding, il quale definisce la lunghezza del padding stesso, cosicché, in fase di decifratura il padding possa essere riconosciuto e rimosso.

Il problema risiede nel fatto che SSL 3.0 autentica, usando un MAC, solamente il messaggio (per esempio la richiesta HTTPS), mentre il padding è libero di assumere un qualsiasi valore.
Un attaccante pertanto può permettersi di modificare il valore di padding a suo piacimento per estrarre dati relativi ai blocchi precedenti.

Consideriamo una richiesta HTTPS, al suo interno possiamo individuare due parti: la request line, che contiene i dati manipolabili noti all’attaccate (es. GET /poodle.png HTTP/1.1), e i request fields, che contengono dati confidenziali ignoti all’attaccante (per esempio i cookie), manipolando il padding finale si potranno estrarre i dati contenuti nei request fields.

scheme - testo

Immaginiamo di trovarci in un ambiente in cui i dati sono cifrati usando il protocollo più forte tra quelli che si appoggiano alla cifratura CBC, nell’ambito del protocollo SSL 3.0, l’AES-CBC.
In questa situazione i blocchi sono lunghi 16 byte, quindi i possibili valori che l’ultimo byte dell’offset può assumere vanno da 0 a 15 e l’attaccante può facilmente calcolare in anticipo il valore di questi, nel seguito immaginiamo che il padding sia lungo 16 byte (un intero blocco) e che pertanto il byte di controllo assumerà il valore 15.

L’attacco utilizza questa informazione per calcolare, un byte alla volta, i dati del request field.
Grazie ad un man in the middle, il malintenzionato rimpiazzerà l’ultimo blocco dello stream cifrato (quello che contiene la cifratura del padding) con un altro blocco a sua scelta. Questo nuovo pacchetto non è detto che possa essere accettato dal server, poiché l’ultimo byte del padding, una volta decifrato, potrebbe contenere un’informazione inconsistente, in questo caso il client riceverebbe una risposta negativa e ripeterebbe la richiesta, dando la possibilità all’attaccante di riprovare la sostituzione dei blocchi; in media dopo 256 richieste (256 = sqrt(2^16)) il server riceverà una richiesta con un padding della lunghezza corretta; come già detto il valore della lunghezza del padding è calcolabile in anticipo, in questa situazione il server restituisce una informazione riguardo all’ultimo byte dell’ultimo blocco, ossia che l’ultimo byte del blocco che abbiamo inserito con l’attacco man in the middle viene decifrato nel valore 15.
In questo scenario per l’attaccante è sufficiente sostituire il blocco criptato del padding con un blocco criptato di quelli che lo precedono, per ottenere informazioni riguardo all’ultimo byte del blocco cifrato, in particolare informazioni riguardo all’ultimo blocco del request field.

Cifratura e Sostituzione CBC:
Cifratura CBC Il valore estratto, nel nostro esempio 15, non è quello del dato originale, in quanto il blocco è stato cifrato con l’algoritmo CBC; questo è un sistema di cifratura che aumenta la sicurezza dei dati effettuando lo XOR di ogni blocco da cifrare con il testo cifrato del blocco precedente. Il primo blocco, che ovviamente non può essere cifrato usando un blocco precedente, viene XORato con un vettore di 16 byte casuali detto IV (initialization vector) generato all’inizio di ogni transazione in maniera casuale, in questo modo viene assicurato che due messaggi uguali, cifrati in tempi diversi, genereranno un output differente.
Inoltre la variazione dell’IV rende possibile l’attacco sopra descritto, in quanto ogni volta che si ripete la stessa richiesta, l’ultimo byte del padding varierà nonostante la stringa di input sia rimasta invariata.

Il valore ottenuto, nel nostro esempio 15, è ottenuto da una cifratura che coinvolge il padding e l’ultimo byte del blocco precedente cifrato. Ma questo valore dipende dalla posizione in cui l’attaccante ha inserito il blocco, in particolare 15 è il risultato ottenuto dallo XOR tra l’ultimo byte del blocco cifrato precedente il padding e il risultato dell’operazione di decodifica effettuata sul blocco che vogliamo attaccare. All’attaccante non resta che reinserire tramite XOR l’ultimo byte del blocco precedente il padding, ottenendo la decodifica del testo cifrato e a questi sottrarre tramite XOR l’ultimo byte del blocco originariamente antecedente a quello attaccato.

Decodifica CBC:

A questo punto, si può passare ad attaccare tutti i byte precedenti, usando lo stesso schema; bisognerà far si che il client richieda una pagina sul webserver che sia lunga un carattere in più, ma per l’attaccante che esegue un man in the middle questa operazione è molto facile, in particolare, non è richiesto che la pagina richiesta esista. Un byte alla volta, l’attaccante può estrarre tutte le informazioni sensibili della vittima.

poodle_repeat

L’elemento manipolabile può essere, inoltre, forgiata da un attacco man in the middle tramite javascript injection su un sito che usa http (es. cURL GET).

Ricapitolando:

Un attaccante che controlla la connessione internet tra il browser e il server, in grado di forzare l’esecuzione di codice (es script) all’interno del browser, può potenzialmente decrittare i cookie di autenticazione a siti come: Google, Yahoo e ovviamente alla vostra banca.

Poiché questa vulnerabilità non è risolvibile, SSL 3.0 non è più da considerarsi sicuro e pertanto da abbandonare.

Fix:

Fix per Apache:
SSLProtocol All -SSLv2 -SSLv3

oppure: SLProtocol TLSv1

Controllo della configurazione: sudo apache2ctl configtest

Riavvio del server: sudo service apache2 restart

Fix per Nginx: ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Riavvio del server: sudo service nginx restart

Fix per HAProxy Servers: bind :443 ssl crt ciphers no-sslv3

Altri metodi per rendere sicuri I propri servizi possono essere trovati a questo link

di VoidSec e kalup

Back to Posts