mpgn/beast-poc💪 Prova di concetto dell'attacco BEAST contro SSL/TLS CVE-2011-3389 💪
Questa prova di concetto è incentrata sulla crittografia alla base dell'attacco BEAST (Browser Exploit Against SSL/TLS) presentato da Thai Duong e Juliano Rizzo il 23 settembre 2011. Si tratta di un attacco a testo scelto e consente di recuperare informazioni sensibili se la Transport Layer Security utilizzata è TLS1.0 o SSLv3. La prova di concetto originale può essere trovata qui: Here come the Ninjas
Nota: Questa è anche un'implementazione della vulnerabilità scoperta originariamente da Phillip Rogaway. Scoperta nel 2002, non è stato rilasciato alcun exploit fino a BEAST nel 2011. OpenSSL conosceva già il problema ed è per questo che hanno aggiornato TLS1.0 a TLS1.1 nell'aprile 2006.
2 L'IV CBC per ogni record tranne il primo è l'ultimo blocco di ciphertext del record precedente. Pertanto la crittografia non è sicura contro avversari che possono scegliere adattivamente i plaintext;
SSLv3/TLS1.0 sono protocolli per cifrare/decifrare e proteggere i tuoi dati. Nel nostro caso, entrambi usano 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 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 sono io) https://www.youtube.com/watch?v=0D7OwYp6ZEc.
Introdurrò l'IV nel prossimo punto. Ricorda che tutte queste proprietà ci aiuteranno a condurre il nostro attacco.
Quando si usa il CBC serve un vettore di inizializzazione chiamato IV. Questo IV è casuale (o fisso) ma in ogni caso non deve essere predicibile da nessuno. In TLS1.0 e SSLv3 il primo IV della richiesta è casuale, ok. Ma per guadagnare tempo e non generare ogni volta un nuovo IV casuale, l'implementazione di TLS1.0 e SSLv3 usa l'ultimo blocco del ciphertext precedente come IV. In altre parole, l'IV ora è indovinabile. Assumeremo che la lunghezza di ciascun blocco sia 8 (DES) e che l'attaccante abbia un MiTM per recuperare tutto il ciphertext.
Esempio :
C0 | C... | Ci-1 | Ci | Ci+1 |Cn
Ora la parte interessante, questi sono i diversi passaggi crittografici dell'attacco per recuperare un byte :
bbbbbbbTHIS_IS_A_SECRET_COOKIE attraverso la vittima.Puoi notare i sette b prima del cookie segreto. Se la lunghezza di un blocco è 8, dobbiamo inserire 7 byte noti. Questa informazione è molto importante: l'attaccante conosce i primi 7 byte del primo blocco.
Ma perché? Questo ci consente di avere solo 256 possibilità per trovare un byte e non 256^8 per trovare 8 byte !
Ora la vittima invia la richiesta e verrà cifrata così :
C0 | C1 | C2 | C3 | C4
Dove C0 = Ek(IV ⊕ bbbbbbbT) = Ek(C²n ⊕ bbbbbbbT)
P'0 = C²n ⊕ C4 ⊕ bbbbbbbX
L'unico elemento sconosciuto è X, ci sono 256 possibilità, quindi proverà al massimo 256 caratteri.
La richiesta viene inviata e cifrata così :
C'0 = Ek(P'0 ⊕ IV')
C'0 = Ek(C²n ⊕ C4 ⊕ bbbbbbbX ⊕ IV') o C4 ⊕ IV' = 0
C'0 = Ek(C²n ⊕ bbbbbbbX)
C'0 = Ek(IV ⊕ bbbbbbbX)
Ora confronta: C'0 e C0, se sono uguali, allora ha appena trovato il byte X in posizione 8. Se non corrisponde, riprova con un altro carattere e confronta di nuovo, ecc.
Ora che abbiamo un byte, possiamo ottenerne un altro spostando la richiesta precedente di uno a sinistra: bbbbbbTHIS_IS_A_SECRET_COOKIE. Ora ha sei b e conosciamo anche la T, quindi abbiamo un carattere sconosciuto. Costruiamo un nuovo P'0 = C0 ⊕ C4 ⊕ bbbbbbTX, ecc...
Nota: un altro modo con solo due richieste è impostare il primo blocco del plaintext e usare questa informazione per i tre XOR. Non abbiamo più bisogno dell'ultimo blocco C². C1 = Ek(C0 ⊕ bbbbbbbT) e poi P'0 = C0 ⊕ C4 ⊕ bbbbbbbX. Deve anche confrontare C'0 e C1. Questo è un altro modo per farlo, puoi notare che nel PoC codifico entrambe le possibilità :)
Ora possiamo recuperare tutti i caratteri !
python BEAST-poc.py
Un attaccante non può usare il protocollo HTTP perché il primo blocco sarà riempito con GET / HTTP/1.1\r\n.
... non può controllare i primi byte di ogni richiesta perché sono sempre impostati come una stringa fissa come GET /, POST /, ecc. Invece può usare il socket.
Deve anche iniettare del javascript in una pagina dannosa. La vittima deve essere connessa a questa pagina e rimanerci finché l'attacco non è completato. Trattandosi di un attacco a testo scelto, l'attaccante può inviare tramite il codice javascript qualsiasi plaintext desideri e intercettare il risultato con un Man in The Middle. Questo è il diagramma dell'attacco :
Questo attacco richiede condizioni importanti per avere successo (TLS1.0 o inferiore, modalità di cifratura CBC, MiTM, javascript dannoso). Ma Thai Duong e Juliano Rizzo hanno dimostrato che è possibile e hanno mostrato il loro exploit rubando cookie sul sito di Paypal.
Ora tutto è stato corretto e questo attacco ha poche probabilità di essere realizzato.
| Cifratura | Decifratura |
|---|
| Ci = Ek(Pi ⊕ Ci-1), e C0 = IV | Pi = Dk(Ci) ⊕ Ci-1, e C0 = IV |