mpgn/poodle-poc🐩 Poodle (Padding Oracle On Downgraded Legacy Encryption) Angriff CVE-2014-3566 🐩
Ein Proof of Concept des Poodle-Angriffs (Padding Oracle On Downgraded Legacy Encryption) :
ein Man-in-the-Middle-Exploit, der das Zurückfallen von Internet- und Sicherheitssoftware-Clients auf SSL 3.0 ausnutzt
Der Poodle-Angriff ermöglicht es Ihnen, verschlüsselte Daten abzurufen, die ein Client an einen Server sendet, wenn die verwendete Transport Layer Security SSLv3 ist. Er ermöglicht es Ihnen nicht, den privaten Schlüssel abzurufen, der zum Verschlüsseln der Anfrage verwendet wurde.
SSLv3 ist ein Protokoll zum Ver- und Entschlüsseln und Sichern Ihrer Daten. In unserem Fall verwendet es die CBC-Verschlüsselungsmodus-Verkettung . Der Klartext wird abhängig vom Verschlüsselungsalgorithmus (AES, DES, 3DES) in Blöcke aufgeteilt, und 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 Raum zu vervollständigen. Ich empfehle Ihnen dringend, diese Bilder der Verschlüsselung und Entschlüsselung zu öffnen, um diese README zu lesen.
| Verschlüsselung | Entschlüsselung |
|---|---|
| Ci = Ek(Pi ⊕ Ci-1), and C0 = IV | Pi = Dk(Ci) ⊕ Ci-1, and C0 = IV |
Grundsätzlich ist das nur ein einfaches XOR. Sie können sich auch dieses Video ansehen (nicht von mir) https://www.youtube.com/watch?v=0D7OwYp6ZEc.
Eine über HTTPS mit SSLv3 gesendete Anfrage wird mit AES/DES im CBC-Modus verschlüsselt. Die Besonderheit von SSLv3 gegenüber TLS1.x ist das Padding. Bei SSLv3 wird das Padding mit Zufallsbytes gefüllt, außer dem letzten Byte, das der Länge des Paddings entspricht.
Beispiel:
T|E|X|T|0xab|0x10|0x02 wobei 0xab|0x10|0x02 das Padding ist.
T|E|X|T|E|0x5c|0x01 wobei 0x5c|0x01 das Padding ist.
Außerdem kann der letzte Block mit einem vollständigen Padding-Block gefüllt sein, das heißt, der letzte Block kann voller Zufallsbytes sein, außer dem letzten Byte.
T|E|X|T|E|0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 wobei |0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 das Padding ist und nur das 0x07 dem Angreifer bekannt ist. Wenn ein Angreifer also in der Lage ist, den Padding-Block zu beeinflussen, kann er wissen, dass das letzte Byte des letzten Blocks gleich der Länge eines Blocks ist.
Ein Angreifer muss das Opfer dazu bringen können, Anfragen zu senden (z. B. mithilfe von JavaScript durch Ausnutzen einer XSS). Dann kann er den Pfad und die Daten jeder Anfrage kontrollieren:
Beispiel: Hinzufügen eines "A"-Bytes zum Pfad der Anfrage
GET / HTTP/1.1\r\nSECRET COOKIE\r\n\r\n
GET /AAA HTTP/1.1\r\nSECRET COOKIE\r\n\r\nDATA
Mit dieser Technik kann er das Padding beeinflussen.
SSLv3 verwendet außerdem HMAC, um die Integrität und Authentifizierung des Klartexts zu prüfen.
Der keyed-hash message authentication code (HMAC) ist ein spezifischer Typ eines Message Authentication Code (MAC), der eine kryptografische Hash-Funktion (daher das 'H') in Kombination mit einem geheimen kryptografischen Schlüssel verwendet
Dadurch kann ein Angreifer die Anfrage nicht abfangen, verändern und dann zurücksenden. Wenn der Server ein Problem feststellt, sendet er einen HMAC-Fehler.
Das Protokoll SSLv3 verwendet die folgende Routine: Es empfängt die Daten vom Client, entschlüsselt die Daten und prüft die Integrität mit dem HMAC.
MAC-then-Encrypt: Bietet keinerlei Integrität für den Chiffretext, da wir bis zur Entschlüsselung der Nachricht keine Möglichkeit haben zu wissen, ob sie tatsächlich authentisch oder gefälscht ist. Klartext-Integrität. Wenn das Verschlüsselungsschema malleable ist, könnte es möglich sein, die Nachricht so zu verändern, dass sie gültig erscheint und einen gültigen MAC besitzt. Dies ist natürlich ein theoretischer Punkt, da das MAC-Geheimnis praktisch gesehen Schutz bieten sollte. Auch hier kann der MAC keine Informationen über den Klartext liefern, da dieser verschlüsselt ist.
https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac
Das bedeutet, dass wir den Chiffretext verändern können, ohne dass der Server es merkt. Das ist großartig, wirklich :)
Zuerst muss der letzte Block vollständig mit Padding gefüllt sein. Wie wir zuvor gesehen haben, nutzt der Angreifer den Pfad der Anfrage und prüft die Länge der Anfrage.
Da der letzte Block mit Ausnahme des letzten Bytes voller Zufallsbytes ist, kann er diesen letzten Block Cn durch den Block Ci ersetzen, den er entschlüsseln möchte. Die veränderte Anfrage wird an den Server gesendet.
Der Server :
Durch das Ersetzen des letzten Blocks ändert der Angreifer auch das letzte Byte des letzten Blocks (die Länge des Paddings). Es gibt eine Wahrscheinlichkeit von 1/256, dass das letzte Byte im Padding-Block mit dem ursprünglichen übereinstimmt. In diesem Fall gibt es keinen Padding-Fehler, und der Angreifer kann diese XOR-Operation nutzen, um das letzte Byte des Blocks Ci mit der folgenden Operation abzurufen:
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 oder xxxxxxx15 und x Zufallsbyte)
Das letzte Byte des Blocks kann abgerufen werden: Pi[7] = Ci-1[7] ⊕ xxxxxxx7 ⊕ Cn-1[7] Im Falle eines Padding-Fehlers muss der Angreifer die SSL-Sitzung schließen, um einen weiteren Handshake durchzuführen (neuer AES-Schlüssel), neuen Chiffretext erhalten und dann den letzten Block ersetzen usw. (in der Regel sind +300 Handshakes erforderlich)
Sobald ein Byte abgerufen ist, erhält er alle anderen Bytes des Blocks, indem er ein Byte im Pfad hinzufügt und ein Byte in den Daten entfernt:
| Anfrage zum Abrufen der Bytes 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 |
Obwohl die TLS-Spezifikationen von den Servern verlangen, das Padding zu prüfen, validieren einige Implementierungen es nicht ordnungsgemäß, was einige Server selbst dann verwundbar für POODLE macht, wenn sie SSL 3.0 deaktivieren.