Schnellerer Drown-Angriff durch OpenSSL-Bugs

Der Drown-Angriff ist zwar durchaus praktikabel, aber der Aufwand ist relativ hoch. Doch den Forschern gelang es, eine deutlich optimierte Variante des Drown-Angriffs zu entwickeln. Ein Bug in der SSLv2-Implementierung OpenSSL, der in allen Versionen vor März 2015 zu finden ist, erlaubt es, den Angriff mit etwa 10.000 Verbindungen durchzuführen, die Berechnung des Angriffs ist innerhalb von Sekunden auf einem modernen PC möglich. Dieser Angriff ist damit schnell genug, um direkt eine TLS-Verbindung mittels eines Man-in-the-Middle-Angriffs zu übernehmen.

Der Bug wurde im vergangenen Jahr eher zufällig behoben, als die Entwickler von OpenSSL eine davon unabhängige, weniger kritische Sicherheitslücke schlossen. Dass dabei nebenher diese kritische Lücke ebenfalls gefixt wurde, hat damals niemand bemerkt.

Ein weiterer Bug in OpenSSL, der im Januar behoben wurde, erleichtert den Angriff ebenfalls unter bestimmten Umständen. Wie oben bereits erwähnt, nutzt der Drown-Angriff die alten Export-Ciphersuiten mit 40-Bit-Schlüsseln. Theoretisch ist auch ein Angriff gegen das DES-Verfahren (56 Bit) möglich, doch dann erhöht sich der Aufwand deutlich. Doch wie sich herausstellte, erlaubte OpenSSL auch Verbindungen mit Export-Ciphersuiten, wenn diese überhaupt nicht aktiviert sind.

Variante des Angriffs gegen QUIC

Eine weitere Variante des Angriffs betrifft das von Google entwickelte QUIC-Protokoll. QUIC ist ein Ersatz für TCP und TLS und wird von Google teilweise für seine eigenen Webseiten eingesetzt. Gelingt es einem Angreifer, eine einzige korrekte Signatur von einem privaten Schlüssel zu erhalten, kann er mittels QUIC einem Anwender die Identität des entsprechenden Servers vorgaukeln. Da eine RSA-Signatur und eine RSA-Entschlüsselung technisch praktisch identisch sind, lässt sich der Bleichenbacher-Angriff auch hier anwenden. Der Angriff gegen QUIC ist jedoch deutlich aufwändiger als der gewöhnliche Drown-Angriff. Die Autoren schätzen die Kosten für die Berechnungen auf über neun Millionen Dollar.

Bemerkenswert an dieser Angriffsvariante ist, dass der Server QUIC überhaupt nicht unterstützen muss. Ein Angreifer kann mittels einer HTTP-Verbindung eine QUIC-Verbindung initialisieren und dann dem Opfer eine falsche Webseite vorsetzen. Als Reaktion hat Google die Implementierung von QUIC in Chrome so abgeändert, dass nur noch Verbindungen zu einer Whitelist von bestimmten Webseiten möglich ist. Änderungen im Protokoll sollen künftig derartige Angriffe verhindern.

SSLv2 muss überall abgeschaltet werden

Sämtliche Varianten des Drown-Angriffs richten sich gegen das uralte SSLv2-Protokoll. Eigentlich sollte das längst überall abgeschaltet sein. In RFC 6176 heißt es eindeutig, dass sowohl Server als auch Clients keine SSLv2-Verbindungen zulassen dürfen. Hätten sich alle Serverbetreiber daran gehalten, wäre Drown nur ein theoretisches Problem.

Doch SSLv2 ist noch weit verbreitet. Für den Drown-Angriff genügt es bereits, wenn derselbe RSA-Schlüssel für verschiedene Hosts genutzt wird. So könnte beispielsweise ein HTTPS-Server zwar SSLv2-Verbindungen verbieten, wenn aber gleichzeitig ein Mailserver dasselbe Zertifikat nutzt und über SMTP auch SSLv2-Verbindungen zulässt, lassen sich die Verbindungen trotzdem angreifen. Einzige Voraussetzung ist, dass der HTTPS-Server in diesem Fall die RSA-Verschlüsselung nutzt. Idealerweise sollte das auch nicht der Fall sein, denn Verbindungen mit Forward Secrecy nutzen RSA nur noch für Signaturen.

22 Prozent der HTTPS-Server mit gültigem Zertifikat sind laut internetweiten Scans verwundbar - entweder weil sie direkt SSLv2 anbieten oder weil auf einem anderen Server oder auf einem anderen Port das alte Protokoll mit demselben Key unterstützt wird. Betrachtet man alle HTTPS-Server - inklusive solcher mit ungültigem Zertifikat - sind 33 Prozent verwundbar. Gescannt haben die Drown-Autoren die Ports für HTTPS (443), IMAP (143, 993), SMTP (25, 465, 587) und POP3 (110, 995). Doch selbst diese Daten sind möglicherweise unvollständig, denn andere Protokolle wie FTP oder XMPP, die ebenfalls SSL unterstützen können, wurden nicht getestet.

Insbesondere bei Mailservern werden gerne Konfigurationen genutzt, die möglichst viele Protokolle und Cipher unterstützen. Die Idee dabei: Wenn keine Verschlüsselung zustande kommt, werden Mails unverschlüsselt verschickt. "Eine schlechte Verschlüsselung ist besser als keine", denken sich daher viele. Der Drown-Angriff zeigt, dass diese Haltung gefährlich sein kann.

Die Schlussfolgerung aus dem Drown-Angriff ist klar: SSLv2 muss ohne Ausnahme überall abgeschaltet werden.

Risiken von alten Protokollen

Wie viele andere Angriffe vorher - man denke nur an FREAK, Logjam, POODLE oder SLOTH - nutzt auch Drown veraltete Verschlüsselungsmodi, um TLS anzugreifen. Das Überraschendste an Drown ist jedoch, dass ein Protokoll, das in der Praxis überhaupt nicht mehr nutzbar ist, da es in Browsern längst deaktiviert wurde, weiterhin ein Problem darstellen kann. Es zeigt auch, welche Probleme auftreten können, wenn derselbe kryptographische Key in verschiedenen Protokollen zum Einsatz kommt. Idealerweise sollte ein Key immer nur für einen Zweck eingesetzt werden, in TLS ist das allerdings oft schwer umsetzbar.

An der Entdeckung von Drown haben Forscher der Ruhr-Universität Bochum und der Fachhochschule Münster mitgewirkt. Ende April werden sie den Angriff auf der Ruhrsec-Konferenz in Bochum vorstellen.