mpgn/poodle-poc🐩 Attacco Poodle (Padding Oracle On Downgraded Legacy Encryption) CVE-2014-3566 🐩
Una prova di concetto dell'attacco POODLE (Padding Oracle On Downgraded Legacy Encryption):
un exploit man-in-the-middle che sfrutta il fallback dei client Internet e dei software di sicurezza a SSL 3.0
L'attacco POODLE consente di recuperare i dati cifrati inviati da un client a un server se il protocollo Transport Layer Security utilizzato è SSLv3. Non consente di recuperare la chiave privata usata per cifrare la richiesta.
SSLv3 è un protocollo per cifrare/decifrare e proteggere i tuoi dati. Nel nostro caso, utilizza la modalità di cifratura CBC (cipher block chaining). Il plaintext viene diviso in blocchi in base all'algoritmo di cifratura (AES, DES, 3DES) e la lunghezza è un multiplo di 8 o 16. Se il plaintext non riempie la lunghezza, viene aggiunto alla fine un padding per completare lo spazio mancante. Ti consiglio vivamente di aprire queste immagini di cifratura e decifratura prima di leggere questo readme.
| Cifratura | Decifratura |
|---|---|
| Ci = Ek(Pi ⊕ Ci-1), and C0 = IV | Pi = Dk(Ci) ⊕ Ci-1, and C0 = IV |
In pratica si tratta solo di un semplice XOR; puoi anche guardare questo video (non il mio) https://www.youtube.com/watch?v=0D7OwYp6ZEc.
Una richiesta inviata via HTTPS utilizzando SSLv3 verrà cifrata con AES/DES in modalità CBC. La particolarità di SSLv3 rispetto a TLS1.x è il padding. In SSLv3 il padding è riempito con byte casuali, tranne l'ultimo byte che è uguale alla lunghezza del padding.
Esempio:
T|E|X|T|0xab|0x10|0x02 dove 0xab|0x10|0x02 è il padding.
T|E|X|T|E|0x5c|0x01 dove 0x5c|0x01 è il padding.
Inoltre, l'ultimo blocco può essere riempito con un intero blocco di padding, il che significa che l'ultimo blocco può essere composto interamente da byte casuali tranne l'ultimo.
T|E|X|T|E|0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 dove |0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 è il padding e solo 0x07 è noto all'attaccante. Quindi se un attaccante è in grado di influenzare il blocco di padding, potrà sapere che l'ultimo byte dell'ultimo blocco è uguale alla lunghezza di un blocco.
Un attaccante deve essere in grado di far inviare richieste alla vittima (usando JavaScript, ad esempio sfruttando una XSS). Poi può controllare il percorso e i dati di ogni richiesta:
Esempio: aggiungendo un byte "A" al percorso della richiesta
GET / HTTP/1.1\r\nSECRET COOKIE\r\n\r\n
GET /AAA HTTP/1.1\r\nSECRET COOKIE\r\n\r\nDATA
Con questa tecnica può influenzare il padding.
SSLv3 usa anche HMAC per verificare l'integrità e autenticare il plaintext.
keyed-hash message authentication code (HMAC) è un tipo specifico di codice di autenticazione del messaggio (MAC) che coinvolge una funzione hash crittografica (da cui la 'H') in combinazione con una chiave crittografica segreta
Con questo un attaccante non può intercettare e modificare la richiesta per poi rinviarla. Se il server incontra un problema, invierà un errore HMAC.
Il protocollo SSLv3 usa la seguente routine: riceve i dati dal client, decifra i dati, verifica l'integrità con l'HMAC.
MAC-then-Encrypt: Non fornisce alcuna integrità sul ciphertext, poiché non abbiamo modo di sapere, finché non decifriamo il messaggio, se sia effettivamente autentico o contraffatto. Integrità del plaintext. Se lo schema di cifratura è malleabile, potrebbe essere possibile alterare il messaggio per farlo apparire valido e avere un MAC valido. Questo è ovviamente un punto teorico, dato che in pratica il segreto MAC > dovrebbe fornire protezione. Qui il MAC non può fornire alcuna informazione sul plaintext, poiché è cifrato.
https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac
Questo significa che possiamo modificare il testo cifrato senza che il server se ne accorga. È fantastico, davvero :)
Per prima cosa l'ultimo blocco deve essere interamente di padding; come abbiamo visto in precedenza, l'attaccante usa il percorso della richiesta e controlla la lunghezza della richiesta.
Poiché l'ultimo blocco, tranne l'ultimo byte, è pieno di byte casuali, può sostituire quest'ultimo blocco Cn con il blocco che vuole decifrare Ci. La richiesta modificata viene inviata al server.
Il server:
Sostituendo l'ultimo blocco, l'attaccante modifica anche l'ultimo byte dell'ultimo blocco (la lunghezza del padding). C'è 1/256 di probabilità che l'ultimo byte sostituito nel blocco di padding sia uguale a quello originale; in questo caso non ci sarà un errore di padding e l'attaccante può usare questa operazione XOR per recuperare l'ultimo byte del blocco Ci seguendo questa operazione:
Pn = Dk(Cn) ⊕ Cn-1
Pn = Dk(Ci) ⊕ Cn-1
Pn = Dk(Ci) ⊕ Cn-1
xxxxxxx7 = Dk(Ci) ⊕ Cn-1
Dk(Ci) = xxxxxxx7 ⊕ Cn-1
Pi ⊕ Ci-1 = xxxxxxx7 ⊕ Cn-1
Pi = Ci-1 ⊕ xxxxxxx7 ⊕ Cn-1
(xxxxxxx7 o xxxxxxx15 dove x è un byte casuale)
L'ultimo byte del blocco può essere recuperato con Pi[7] = Ci-1[7] ⊕ xxxxxxx7 ⊕ Cn-1[7] In caso di errore di padding, l'attaccante deve chiudere la sessione SSL per effettuare un altro handshake (nuova chiave AES) e ottenere un nuovo cifrato, quindi sostituire di nuovo l'ultimo blocco, ecc. (in generale sono necessari +300 handshake)
Una volta recuperato un byte, otterrà tutti gli altri byte del blocco aggiungendo un byte nel percorso e rimuovendo un byte nei dati:
| Richiesta per recuperare il byte E,I,K,O |
|---|
| GET /a SECRET_COOKIE dataazerty PADDING_7 |
| GET /aa SECRET_COOKIE dataazert PADDING_7 |
| GET /aaa SECRET_COOKIE dataazer PADDING_7 |
| GET /aaaa SECRET_COOKIE dataaze PADDING_7 |
Anche se le specifiche TLS richiedono che i server controllino il padding, alcune implementazioni non lo convalidano correttamente, il che rende alcuni server vulnerabili a POODLE anche se disabilitano SSL 3.0
TLS è normalmente sicuro contro POODLE, ma alcune implementazioni non controllano il padding: è come se si usasse SSLv3, ed è per questo che alcune versioni di TLS sono vulnerabili.