Poodle PoC 🐩 🐩 🐩

Una prova di concetto dell'attacco Poodle (Padding Oracle On Downgraded Legacy Encryption) :

un exploit man-in-the-middle che sfrutta il fallback a SSL 3.0 dei client di software Internet e di sicurezza

L'attacco Poodle consente di recuperare i dati cifrati inviati da un client a un server se il Transport Layer Security utilizzato è SSLv3. Non consente di recuperare la chiave privata usata per cifrare la richiesta.

1. 🐩 Concetto dell'attacco 🐩

SSLv3 e modalità di cifratura CBC

SSLv3 è un protocollo per cifrare/decifrare e proteggere i tuoi dati. Nel nostro caso, utilizza la modalità di cifratura a blocchi CBC. 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 un padding alla fine per completare lo spazio mancante. Ti consiglio vivamente di aprire queste immagini di cifratura e decifratura per leggere questo readme.

In pratica è solo un semplice XOR, puoi anche guardare questo video (non il mio) https://www.youtube.com/watch?v=0D7OwYp6ZEc.

Una richiesta inviata su HTTPS utilizzando SSLv3 verrà cifrata con AES/DES e la 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 blocco intero di padding, il che significa che l'ultimo blocco può essere pieno di byte casuali, tranne l'ultimo byte.

T|E|X|T|E|0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 dove |0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 è il padding; solo il 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.

Influenzare il padding

Un attaccante deve essere in grado di far inviare richieste alla vittima (usando javascript, ad esempio sfruttando una XSS). Poi può controllare il percorso (path) 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.

HMAC

SSLv3 usa anche HMAC per verificare l'integrità e autenticare il plaintext.

keyed-hash message authentication code (HMAC) è un tipo specifico di message authentication code (MAC) che coinvolge una funzione di hash crittografica (da qui la 'H') in combinazione con una chiave crittografica segreta

Con questo, un attaccante non può intercettare e alterare la richiesta per poi rinviarla. Se il server incontra un problema, invierà un errore HMAC.

MAC-then-encrypt

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 era effettivamente autentico o spoofato. Integrità del plaintext. Se lo schema di cifratura è malleabile, potrebbe essere possibile alterare il messaggio per farlo sembrare valido e avere un MAC valido. Questo è un punto teorico, ovviamente, poiché in pratica il segreto del MAC dovrebbe fornire protezione. Qui, il MAC non può fornire alcuna informazione sul plaintext, poiché anche questo è cifrato.

https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac

Questo significa che possiamo alterare il testo cifrato senza che il server lo sappia. È fantastico, davvero :)

2. 🔑 Crittografia 🔑

Prima di tutto, l'ultimo blocco deve essere pieno di padding; come visto in precedenza, l'attaccante usa il percorso della richiesta e controlla la lunghezza della richiesta.

• Salva la lunghezza del cipher originale
• Aggiunge un byte nel percorso e controlla la lunghezza.
  • Se la lunghezza non cambia, aggiunge un altro byte, ecc.
  • Altrimenti: la lunghezza della richiesta cifrata cambia, sa che l'ultimo blocco è pieno di padding.

Poiché l'ultimo blocco, tranne l'ultimo byte, è pieno di byte casuali, può sostituire quest'ultimo blocco C_n con il blocco che vuole decifrare C_i. La richiesta alterata viene inviata al server.

Il server:

• rimuove il padding in base alla lunghezza dell'ultimo byte
• ottiene l'hmac dalla richiesta = HMAC
• ottiene il plaintext
• confronta hmac(plaintext) e HMAC
  • se uguali => padding corretto
  • altrimenti => padding errato

Sostituendo l'ultimo blocco, l'attaccante cambia 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 lo stesso dell'originale; in questo caso non ci sarà alcun errore di padding e l'attaccante può usare questa operazione XOR per recuperare l'ultimo byte del blocco C_i seguendo questa operazione:

P_n = D_k(C_n) ⊕ C_n-1
P_n = D_k(C_i) ⊕ C_n-1
P_n = D_k(C_i) ⊕ C_n-1
xxxxxxx7 = D_k(C_i) ⊕ C_n-1
D_k(C_i) = xxxxxxx7 ⊕ C_n-1
P_i ⊕ C_i-1 = xxxxxxx7 ⊕ C_n-1
P_i = C_i-1 ⊕ xxxxxxx7 ⊕ C_n-1

(xxxxxxx7 o xxxxxxx15, dove x è un byte casuale)

L'ultimo byte del blocco può essere recuperato: P_i[7] = C_i-1[7] ⊕ xxxxxxx7 ⊕ C_n-1[7] In caso di errore di padding, l'attaccante deve chiudere la sessione SSL per effettuare un'altra handshake (nuova chiave AES) e ottenere un nuovo cipher, quindi sostituire l'ultimo blocco, ecc. (in genere sono necessarie +300 handshake)

Una volta recuperato un byte, otterrà tutti gli altri byte del blocco aggiungendo un byte nel percorso e rimuovendo un byte dai dati:

A proposito di TLS1.0

Anche se le specifiche TLS richiedono che i server controllino il padding, alcune implementazioni non lo validano 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.

3. 💥 Avvia l'attacco 💥

Ci sono tre file in questo repository:

• poodle-poc.py -> Una proof of concept che non richiede alcun prerequisito
• parallelization-poodle.py -> Un'altra proof of concept ma che usa la parallelizzazione (davvero veloce)
• poodle-exploit.py -> Un exploit per scenari reali

1. Il file poodle-poc.py

Questa PoC esplora la crittografia dietro l'attacco. Questo file ci permette di capire in modo semplice come funziona l'attacco.

python3 poodle-poc.py

2. Il file poodle-poc.py

Il file parallelization-poodle.py è un progetto, un'idea :) controlla https://github.com/mpgn/poodle-PoC/issues/1

python3 parallelization-poodle.py

3. Il file poodle-exploit.py

Questo è il vero exploit. Molto utile se vuoi fare una prova di concetto sull'attacco Poodle per un cliente durante un pentest, se usa server e browser vecchi. Basta inserire l'IP del tuo proxy malintenzionato nella configurazione del browser con la porta corretta, il proxy si occuperà del resto.

Requisiti:

• assicurati che client e browser possano comunicare solo con il protocollo SSLv3, forza solo SSLv3 in Firefox usando ad esempio security.tls.version.min: 0. In alternativa, se il client usa anche TLS, puoi forzare il downgrade
• assicurati che il server sia vulnerabile, usa lo strumento testssl.sh
• assicurati di poter iniettare Javascript lato client (XSS)
• assicurati di poter intercettare la connessione tra client e server

💀 Se hai questi prerequisiti puoi iniziare l'attacco 💀:

Due opzioni sono disponibili per questo exploit:

1. Configura l'indirizzo IP e la porta del proxy direttamente lato client ed esegui l'exploit (vai alla parte 3)
2. Configura un attacco ARP spoofing per reindirizzare tutto il traffico tra il client e il server sulla tua macchina

• Abilita il forwarding e imposta una regola Iptable per reindirizzare il traffico dal client al tuo proxy

$> echo 1 > /proc/sys/net/ipv4/ip_forward
$> iptables -i vmnet1 -t nat -A PREROUTING -p tcp --dport 1337 -j REDIRECT --to-ports 1337

• Usa lo strumento arpspoof, ettercap o bettercap per eseguire un attacco ARP spoofing

$> bettercap -iface vmnet1
net.show
set arp.spoof.internal true
arp.spoof on

3. Esegui il proxy

⋊> ~/T/poodle-Poc on master ⨯ python3 poodle-exploit.py -h              13:10:24
usage: poodle-exploit.py [-h] [--start-block START_BLOCK]
                         [--stop-block STOP_BLOCK] [--simpleProxy SIMPLEPROXY]
                         proxy port server rport

Poodle Exploit by @mpgn_x64

positional arguments:
  proxy                 ip of the proxy
  port                  port of the proxy
  server                ip of the remote server
  rport                 port of the remote server

optional arguments:
  -h, --help            show this help message and exit
  --start-block START_BLOCK
                        start the attack at this block
  --stop-block STOP_BLOCK
                        stop the attack at this block
  --simpleProxy SIMPLEPROXY
                        Direct proxy, no ARP spoofing attack

$> python3 poodle-exploit.py 192.168.13.1 4443 192.168.13.133 443 --start-block 46 --stop-block 50

Scegliere un blocco: se non specifichi l'opzione del blocco, tutti i blocchi verranno decifrati, ma può richiedere molto tempo. Ti consiglio vivamente di 'sapere' come sarà formattata la richiesta e di usare lo script request-splitter.py per conoscere il blocco che vuoi decifrare (idealmente il blocco del cookie! :)

Poi inserisci il codice javascript dannoso (poodle.js) nel sito web vulnerabile usando, ad esempio, una XSS. Avvia lo script python e digita help, poi search e infine active. Durante questo periodo, saranno necessarie solo due interazioni con il javascript (i comandi search e active).

Aggiornamento 01/04/2018: è stata aggiunta l'opzione di downgrade all'exploit. Quando l'exploit rileva il protocollo TLS, inserisci il comando downgrade per effettuare il downgrade a SSLv3.0.

Come funziona? durante l'handshake (dopo l'hello client), l'exploit invia una handshake_failure 15030000020228, poi il browser dovrebbe rinviare un hello client con SSLv3.0 come protocollo predefinito. Testato su Chrome versione 15 ma non funziona su Firefox (penso che non supporti la rinegoziazione del protocollo), vedi #4

Video completo dell'exploit:

Asciinema:

Collaboratore

mpgn

Licenza

licenza MIT

Riferimenti

• https://en.wikipedia.org/wiki/POODLE
• https://www.openssl.org/~bodo/ssl-poodle.pdf