mpgn/beast-poc💪 Proof of Concept des BEAST-Angriffs gegen SSL/TLS CVE-2011-3389 💪
Dieses Proof of Concept konzentriert sich auf die Kryptografie hinter dem BEAST-Angriff (Browser Exploit Against SSL/TLS), der von Thai Duong und Juliano Rizzo am 23. September 2011 vorgestellt wurde. Es handelt sich um einen Chosen-Plaintext-Angriff, mit dem Sie vertrauliche Informationen abrufen können, wenn die verwendete Transport Layer Security TLS1.0 oder SSLv3 ist. Das ursprüngliche Proof of Concept finden Sie hier: Here come the Ninjas
Hinweis: Dies ist auch eine Implementierung der Schwachstelle, die ursprünglich von Phillip Rogaway entdeckt wurde. Obwohl sie 2002 entdeckt wurde, wurde bis BEAST im Jahr 2011 kein Exploit veröffentlicht. OpenSSL kannte das Problem bereits, und deshalb wurde TLS1.0 im April 2006 auf TLS1.1 aktualisiert.
2 Der CBC-IV ist für jeden Datensatz außer dem ersten der letzte Chiffratblock des vorherigen Datensatzes. Daher ist die Verschlüsselung nicht sicher gegen Angreifer, die Klartexte adaptiv wählen können;
SSLv3/TLS1.0 sind Protokolle zum Ver- und Entschlüsseln und zum Sichern Ihrer Daten. In unserem Fall verwenden beide die CBC-Betriebsart mit Blockverkettung. Der Klartext wird abhängig vom Verschlüsselungsalgorithmus (AES, DES, 3DES) in Blöcke aufgeteilt; die Länge ist ein Vielfaches von 8 oder 16. Wenn der Klartext die Länge nicht ausfüllt, wird am Ende ein Padding hinzugefügt, um den fehlenden Platz aufzufüllen. Ich empfehle Ihnen dringend, diese Bilder der Verschlüsselung und der Entschlüsselung zu öffnen, um diese README zu lesen.
Im Grunde ist das nur eine einfache XOR-Verknüpfung; Sie können sich auch dieses Video ansehen (nicht von mir): https://www.youtube.com/watch?v=0D7OwYp6ZEc.
Ich werde den IV im nächsten Punkt einführen. Denken Sie daran, dass all diese Eigenschaften uns helfen werden, unseren Angriff voranzutreiben.
Wenn wir CBC verwenden, benötigen wir einen Initialisierungsvektor namens IV. Dieser IV ist zufällig (oder fest), aber auf jeden Fall sollte er für niemanden vorhersagbar sein. In TLS1.0 und SSLv3 ist der erste IV der Anfrage zufällig, gut. Aber um Zeit zu sparen und nicht jedes Mal einen neuen zufälligen IV zu erzeugen, verwendet die Implementierung von TLS1.0 und SSLv3 den letzten Block des vorherigen Chiffrats als IV. Mit anderen Worten: Der IV ist nun vorhersagbar. Wir nehmen an, dass die Länge jedes Blocks 8 (DES) beträgt und der Angreifer einen MiTM hat, um das gesamte Chiffrat zu erhalten.
Beispiel:
C0 | C... | Ci-1 | Ci | Ci+1 |Cn
Jetzt zum interessanten Teil: Dies sind die verschiedenen kryptografischen Schritte des Angriffs, um ein Byte zu ermitteln:
bbbbbbbTHIS_IS_A_SECRET_COOKIE über das Opfer senden.Sie können die sieben b vor dem geheimen Cookie bemerken. Wenn die Länge eines Blocks 8 beträgt, müssen wir 7 bekannte Bytes einfügen. Diese Information ist sehr wichtig: Der Angreifer kennt die ersten 7 Bytes des ersten Blocks.
Warum? Dadurch haben wir nur 256 Möglichkeiten, ein Byte zu finden, und nicht 256^8, um 8 Bytes zu finden!
Nun sendet das Opfer die Anfrage, und sie wird wie folgt verschlüsselt:
C0 | C1 | C2 | C3 | C4
Wobei C0 = Ek(IV ⊕ bbbbbbbT) = Ek(C²n ⊕ bbbbbbbT)
P'0 = C²n ⊕ C4 ⊕ bbbbbbbX
Das einzige unbekannte Element ist X; es gibt 256 Möglichkeiten, also wird er maximal 256 Zeichen versuchen.
Die Anfrage wird gesendet und wie folgt verschlüsselt:
C'0 = Ek(P'0 ⊕ IV')
C'0 = Ek(C²n ⊕ C4 ⊕ bbbbbbbX ⊕ IV') oder C4 ⊕ IV' = 0
C'0 = Ek(C²n ⊕ bbbbbbbX)
C'0 = Ek(IV ⊕ bbbbbbbX)
Nun vergleicht er: C'0 und C0. Wenn sie gleich sind, hat er gerade das Byte X an Position 8 gefunden. Wenn es nicht übereinstimmt, versucht er es mit einem anderen Zeichen und vergleicht erneut usw.
Jetzt haben wir ein Byte; wir können ein weiteres erhalten, indem wir die vorherige Anfrage um eins nach links verschieben: bbbbbbTHIS_IS_A_SECRET_COOKIE. Er hat jetzt sechs b, und wir kennen auch das T, also haben wir ein unbekanntes Zeichen. Wir bauen ein neues P'0 = C0 ⊕ C4 ⊕ bbbbbbTX usw.
Hinweis: Ein anderer Weg mit nur zwei Anfragen besteht darin, den ersten Block des Klartexts zu setzen und diese Information für die drei XOR-Verknüpfungen zu verwenden. Wir benötigen den letzten Block von C² nicht mehr. C1 = Ek(C0 ⊕ bbbbbbbT) und dann P'0 = C0 ⊕ C4 ⊕ bbbbbbbX. Er muss auch C'0 und C1 vergleichen. Dies ist ein anderer Weg; Sie können im PoC sehen, dass ich die beiden Möglichkeiten kodiert habe :)
Wir können nun alle Zeichen abrufen!
python BEAST-poc.py
Ein Angreifer kann das HTTP-Protokoll nicht verwenden, weil der erste Block mit GET / HTTP/1.1\r\n gefüllt wird.
... er die ersten Bytes jeder Anfrage nicht kontrollieren kann, weil sie immer als feste Zeichenfolge wie GET /, POST / usw. gesetzt sind. Stattdessen kann er einen Socket verwenden.
Er muss außerdem etwas JavaScript in eine bösartige Seite einschleusen. Das Opfer muss mit dieser Seite verbunden sein und dort bleiben, bis der Angriff abgeschlossen ist. Da dies ein Chosen-Plaintext-Angriff ist, kann der Angreifer über den JavaScript-Code jeden beliebigen Klartext senden und das Ergebnis mit einem Man-in-the-Middle abfangen. Dies ist ein Diagramm des Angriffs:
Dieser Angriff benötigt wichtige Bedingungen, um erfolgreich zu sein (TLS1.0 oder niedriger, CBC-Verschlüsselungsmodus, MiTM, bösartiges JavaScript). Aber Thai Duong und Juliano Rizzo haben bewiesen, dass er möglich ist, und demonstrierten ihren Exploit, indem sie Cookies auf der Paypal-Website stahlen.
Inzwischen ist alles behoben, und dieser Angriff hat nur eine geringe Wahrscheinlichkeit, realisiert zu werden.
| Verschlüsselung | Entschlüsselung |
|---|
| Ci = Ek(Pi ⊕ Ci-1), und C0 = IV | Pi = Dk(Ci) ⊕ Ci-1, und C0 = IV |