Verschlüsselte Befehle lassen sich mit Padding Oracle generieren

Die Lücke in Primefaces ermöglicht ein sogenanntes Padding Oracle, eine kryptographische Schwäche, bei der ein Server unterschiedliche Antworten bei der Entschlüsselung einer Blockverschlüsselung gibt und somit dem Angreifer Informationen liefert, die dieser nutzen kann.

Bei Primefaces können verschlüsselte Befehle an ein Interface geschickt werden. Doch die Verschlüsselung hat eine ganze Reihe von Problemen. Zunächst einmal nutzt sie, wenn nicht anders angegeben, ein Standardpasswort. Doch auch wenn man das Passwort ändert, hilft das nichts. Denn die Verschlüsselung nutzt keine Authentifizierung.

Uralte Verschlüsselung, Standardpasswort, fehlende Authentifizierung

Hier kommt das Padding Oracle ins Spiel. Der Server antwortet mit unterschiedlichen HTTP-Codes, je nachdem ob die entschlüsselte Nachricht ein korrektes Padding enthält oder nicht. Damit lassen sich Daten entschlüsseln. Die Grundidee dieses Angriffs hatte 2002 der Kryptograph Sergey Vaudenay erstmals beschrieben.

Zudem nutzt das Ganze eine Verschlüsselung mit dem DES-Algorithmus. Dieser stammt aus den 70ern und lässt sich allein aufgrund der kurzen Schlüssellänge von 56 bit mit einem simplen Brute-Force-Angriff, also dem Ausprobieren aller Schlüssel, knacken. Das ist mit entsprechender Rechenpower in einigen Stunden machbar.

Doch ein Angriff auf DES ist im Fall von Primefaces gar nicht nötig, denn das Padding Oracle bietet einen schnelleren Weg. Damit lassen sich nicht nur Daten entschlüsseln, sondern auch neue Daten verschlüsseln. Mit einigen Hundert Anfragen an den Server kann man somit einen entsprechend verschlüsselten Befehl vorbereiten.

Angriff mit öffentlich verfügbaren Tools durchführbar

Mit einem öffentlich verfügbaren Tool namens Padbuster kann man den Angriff durchführen. Im Blogpost der Firma Minded Security gibt es dazu eine detaillierte Anleitung.

Der Angriff funktioniert nicht immer, da man den Inhalt des ersten Datenblocks nicht kontrollieren kann. Doch nach einigen Versuchen gelang es uns, einen harmlosen Testcode auszuführen, der einen HTTP-Header einfügt. Da der Server den entsprechenden HTTP-Header in seiner Antwort mit ausgab, konnten wir uns sicher sein, dass die Sicherheitslücke tatsächlich vorhanden und praktisch ausnutzbar ist.