Padding-Oracle-Angriffe im Detail

Im CBC-Modus (Cipher Block Chaining) wird jeder Block entschlüsselt, indem zunächst der Chiffretextblock mit der Blockchiffre entschlüsselt und das Ergebnis anschließend mit dem vorherigen Chiffretextblock per XOR verknüpft wird. Diese XOR-Operation hat eine entscheidende Eigenschaft: Durch das Ändern von Bits in einem Chiffretextblock kann ein Angreifer gezielt bestimmte Bits im entschlüsselten Klartext des folgenden Blocks beeinflussen. Diese Eigenschaft ermöglicht den Padding-Oracle-Angriff.

Blockchiffren benötigen Eingaben in Blöcken fester Größe. PKCS#7-Padding füllt den letzten Block auf: Wenn 3 Bytes Padding erforderlich sind, werden drei Bytes mit dem jeweiligen Wert 0x03 hinzugefügt. Wenn der Block bereits vollständig gefüllt ist, wird ein vollständiger Padding-Block hinzugefügt, in dem alle 16 Bytes den Wert 0x10 haben. Während der Entschlüsselung wird geprüft, ob die Padding-Bytes konsistent sind (alle N Bytes den Wert N haben), und sie werden entfernt. Bei ungültigem Padding muss die Entschlüsselung fehlschlagen.

Ein Padding-Orakel ist jedes System, das offenlegt, ob ein entschlüsselter Chiffretext über gültiges PKCS#7-Padding verfügt. Das Orakel kann Folgendes sein: eine ausdrückliche Fehlermeldung (Invalid padding), ein anderer HTTP-Statuscode (500 statt 403), ein anderer Fehlertext oder sogar ein Zeitunterschied (die Entschlüsselung bei gültigem Padding ist geringfügig schneller). Der Angreifer muss den Schlüssel nicht kennen; er benötigt lediglich dieses binäre Signal: gültiges Padding oder nicht.

Der Angreifer nimmt einen bestimmten Chiffretextblock ins Visier. Um das letzte Klartextbyte wiederherzustellen, ändert er das letzte Byte des vorherigen Chiffretextblocks und sendet den veränderten Chiffretext an das Orakel. Er probiert nacheinander 256 mögliche Werte aus, bis das Orakel gültiges Padding meldet. Bei dem Wert, der gültiges Padding erzeugt (0x01), ist der Zwischenwert der Entschlüsselung bekannt (er wird mit dem geänderten Byte per XOR verknüpft, um 0x01 zu erzeugen). Durch XOR-Verknüpfung mit dem ursprünglichen Chiffretextbyte wird das Klartextbyte offengelegt.

Sobald das letzte Byte wiederhergestellt ist, wird das vorletzte Byte ins Visier genommen. Der Zwischenwert des letzten Bytes ist bereits bekannt, sodass es auf 0x02 gesetzt werden kann. Anschließend werden 256 Werte für das vorletzte Byte ausprobiert, bis das Padding 0x02 0x02 gültig ist. Dieser Vorgang wird für jedes Byte wiederholt. So lässt sich ein vollständiger 16-Byte-Block mit durchschnittlich 256 × 16 = 4.096 Orakelabfragen pro Block wiederherstellen. Mit einem schnellen Orakel kann dies in wenigen Sekunden abgeschlossen werden.

Der Vorgang wird für jeden Chiffretextblock wiederholt, mit Ausnahme der IV, die ohne den vorherigen Block nicht wiederhergestellt werden kann. Ein 128 Byte langer Chiffretext (8 AES-Blöcke) erfordert durchschnittlich etwa 32.000 Oracle-Abfragen, um ihn vollständig zu entschlüsseln. Bei einem Webserver, der Hunderte Anfragen pro Sekunde verarbeitet, dauert dies nur wenige Minuten. Der Angreifer stellt den vollständigen Klartext wieder her, ohne jemals den Verschlüsselungsschlüssel zu erfahren.

POODLE (Padding Oracle On Downgraded Legacy Encryption) nutzte die Validierung des CBC-Paddings in SSL 3.0 aus. SSL 3.0 verwendete ein anderes Padding-Verfahren als PKCS#7, doch der Angriff passte das Konzept des Orakels daran an. Ein Angreifer, der Inhalte in eine SSL-3.0-Sitzung einschleusen und Clients zu einem Downgrade auf SSL 3.0 zwingen konnte, war in der Lage, Sitzungscookies mithilfe der Padding-Oracle-Technik wiederherzustellen. POODLE führte zur Ablösung von SSL 3.0.

Lucky Thirteen (2013) nutzte einen Timing-Seitenkanal im CBC-Schema MAC-then-Encrypt von TLS aus. Die Zeit für die MAC-Überprüfung unterschied sich um wenige Nanosekunden, je nachdem, ob das Padding gültig war, wodurch ein Timing-Orakel entstand. BEAST (2011) nutzte die vorhersehbare IV im CBC-Modus von TLS 1.0 aus, um einen Angriff mit frei wählbarem Klartext auf Sitzungscookies durchzuführen. Beide Angriffe zeigten, dass der CBC-Modus in TLS grundsätzlich nur schwer korrekt zu implementieren war.

Der zuverlässigste Schutz gegen Padding-Oracle-Angriffe besteht darin, AEAD-Modi (Authenticated Encryption with Associated Data) statt CBC zu verwenden. AEAD-Modi wie AES-256-GCM und ChaCha20-Poly1305 überprüfen die Authentifizierung, bevor eine Entschlüsselung oder Padding-Prüfung stattfindet. Ist das Authentifizierungstag ungültig, wird überhaupt nicht entschlüsselt und es werden keine Informationen über das Padding preisgegeben. TLS 1.3 schreibt AEAD vor und entfernt CBC vollständig.

Wenn AEAD nicht verfügbar ist, fügt die Konstruktion Encrypt-then-MAC einen MAC über dem Chiffretext hinzu, nicht über dem Klartext. Vor der Entschlüsselung oder der Padding-Prüfung wird der MAC überprüft. Schlägt die MAC-Prüfung fehl, wird der Vorgang sofort abgebrochen, ohne Informationen über das Padding preiszugeben. Dies muss in konstanter Zeit erfolgen, um Timing-Orakel zu verhindern. Das Fehlschlagen der MAC-Prüfung verrät nichts darüber, ob das Padding gültig gewesen wäre.

So testen Sie auf Schwachstellen durch Padding-Orakel: Verschlüsseln Sie eine bekannte Nachricht, senden Sie anschließend einen modifizierten Chiffretext an die Anwendung und beobachten Sie die Antwort. Wenn gültiges und ungültiges Padding zu erkennbar unterschiedlichen Antworten führen (Fehlermeldung, Statuscode oder Antwortzeit), ist ein Padding-Orakel vorhanden. Automatisierte Tools wie padbuster und PadBuster testen Webanwendungen gezielt auf Padding-Orakel, indem sie Chiffretexte systematisch verändern und die Antworten analysieren.

Was muss ein Zielsystem für einen Padding-Oracle-Angriff bereitstellen, damit ein Chiffretext ohne den Schlüssel entschlüsselt werden kann?

Zusammenfassung des Padding-Orakels: Die XOR-Eigenschaft der CBC-Entschlüsselung ermöglicht eine gezielte Manipulation einzelner Klartextbytes. Die Validierung des PKCS#7-Paddings liefert ein binäres Orakel. Der Angreifer probiert Bytewerte durch und beobachtet gültige oder ungültige Antworten, um den Klartext Byte für Byte wiederherzustellen. Zu den Angriffen in der Praxis gehören POODLE, Lucky Thirteen und BEAST. Als Schutz wird auf AEAD (GCM, ChaCha20-Poly1305) umgestellt, das die Authentifizierung vor der Entschlüsselung überprüft.