Vor Kurzem wurde über eine “neue” Sicherheitslücke des TLS-Protokolls SSLv2 berichtet. Dabei ist es gelungen, eine verschlüsselte SSL/TLS-Verbindungen (HTTPS) zu knacken und den aufgezeichneten, grundsätzlich verschlüsselten Datenverkehr rückwirkend zu entschlüsseln und somit den Inhalt zugänglich zu machen. Das “neue” steht in Hochkommas, weil es sich um ein grundsätzlich älteres und bei modernen Webbrowsern nicht mehr eingesetztes TLS-Protokoll handelt - dieses existiert bereits seit über 18 Jahren.
Bei nine.ch wird der Sicherheit, neben der Verfügbarkeit, die höchste Priorität zugeordnet. Aus diesem Grund haben wir uns entschieden einen Blogbeitrag zu schreiben, welcher aufzeigt welche Schwäche ausgenützt wird und wie wir unsere Managed Kunden, aber auch Sie sich als Root-Serverbetreiber schützen können.
Worum geht es bei DROWN?
DROWN (engl. für “ertrinken”, to drown) setzt sich aus der Abkürzung “Decrypting RSA with Obsolete and Weakend eNcryption” zusammen. Dies bedeutet wörtlich übersetzt “Entschlüsseln von RSA mit obsoleten und schwachen Verschlüsselungen”. Die Attacke richtet sich gegen das ältere SSLv2-Protokoll. Wie bereits erwähnt, unterstützen heutige moderne Webbrowser dieses Protokoll nicht mehr. Die letzten Webbrowser, die dieses noch aktiv unterstützten, gehen ungefähr mit der Version 6 des Internet Explorers einher. Sie werden vielleicht jetzt einwerfen, dass diese Lücke entsprechend unkritisch ist. Leider ist dem nicht so, den viele Server bieten aus Kompatibilitätsgründen nach wie vor einen Austausch über das SSLv2-Protokoll an. Das besondere an dieser Attacke ist, dass dadurch auch Verbindungen, welche auf anderen Protokollen beruhen, dennoch gefährdet sind.
Das SSLv2-Protokoll ist übrigens das erste überhaupt flächendeckend eingesetzte Verschlüsselungsprotokoll im Internet.
Wie wird DROWN eingesetzt?
Bereits 1998 wurde durch Daniel Bleichenbacher mittels einem sogenannten “Chosen-Ciphertext-Angriff” (umgangssprachlich auch als “Bleichenbacher-Angriff” bekannt) diese Art der Verletzlichkeit aufgezeigt.Dabei werden mehrere tausend Verbindungen (Handshakes) durchgeführt und akribisch analysiert. Hierbei werden durch den Angreifer manipulierte und teilweise absichtlich fehlerhaft verschlüsselte Nachrichten an einen Server gesendet. Der Server verhält sich so, dass er diese Anfragen quittiert - auch beispielsweise mit Fehlermeldungen (anstelle die Verbindung einfach nicht mehr zu beantworten). Anhand dieser Informationen kann ein Angreifer mit entsprechender Berechnung Rückschlüsse auf den “Pre-Master-Secret”-Wert ziehen. Dieser Wert ist essentiell und besteht aus einer aus 46 Bytes bestehenden Zufallszahl, die für die Generierung der symmetrischen Chiffrierschlüssel und des Authentifizierungscodes zuständig ist - dieser wird wiederum mit dem öffentlichen Schlüssel des Servers verschlüsselt.
Das bedeutet eben auch, dass sobald dieser Wert bekannt ist, auch moderne SSL/TLS-Verbindungen entschlüsselt werden können, da auch neue Verfahren mit diesem Wert arbeiten. Dies macht diese Attacke so gefährlich und viele Server verwundbar.
Forscher haben diese Attacke leicht modifiziert und dadurch ist es Ihnen gelungen, verschlüsselte Verbindungen zu knacken. Dies läuft ungefähr so ab:
Ein Angreifer zeichnet den gesamten TLS-Verkehr auf. Innerhalb dieser verschlüsselten Verbindungen können sich beispielsweise Login-Informationen, Kreditkarten-Daten oder andere sensitive Daten befinden. Das Aufzeichnen geschieht zum Beispiel mit einer klassischen “Man-in-the-Middle”-Attacke (jemand, der zwischen dem Client und dem Server den Verkehr sehen kann, beispielsweise auch der Provider). Danach attackiert er den Webserver mit der neuen, modifizierten Bleichenbacher-Attacke, um den Pre-Master-Secret-Wert zu erhalten. Ist dies gelungen, kann er sämtlich aufgezeichneten TLS-Verkehr entschlüsseln, da er nun im Besitz des Keys ist. Es spielt hierbei keine Rolle wann der Verkehr aufgezeichnet wurde, beispielsweise ist damit auch möglich rückwirkenden TLS-Verkehr zu entschlüsseln, was bei “sammelwütigen” Diensten eine erhebliche Gefahr darstellt.
Ich bin ein “Managed Server”-Kunde bei nine.ch, gibt es für mich etwas zu tun?
Nein, unsere Engineers verfolgen solche Entwicklungen ständig, planen und ergreifen innert kürzester Zeit Massnahmen. Manchmal sind diese Massnahmen öffentlich nachvollziehbar, weil es beispielsweise einen Neustart der Services (z.B. Anfälligkeiten auf Protokolle/Dienste wie SSH, Postfix etc.) oder des Servers (z.B. Anfälligkeit des Kernels) benötigt [2]. Vielfach reicht es aber aus, wenn wir die entsprechenden Pakete deployen - dies geschieht für Sie fast unsichtbar.
Selbstverständlich weisen wir auch darauf hin, dass dies immer ein “Katze-und-Maus”-Spiel ist - die Angreifer sind hierbei immer einen Schritt voraus, aber wir setzen alles daran diesen das Leben so schwer als möglich zu machen.
Ich bin Root-Kunde bei nine.ch, gibt es für mich etwas zu tun?
Ja, als Serveradministrator mit einem Root Zugang sind Sie eigenständig dafür verantwortlich Sicherheitslücken zu schliessen. Nachfolgend erklären wir, worauf zu achten ist.
Wie kann ich mich gegen DROWN schützen?
Als reiner Client-Benutzer können Sie hierbei nichts tun, ausser auf moderne Browser zu setzen. Leider reicht dies nicht aus, da die Anfälligkeit “nur” die Server betrifft. Deswegen sind die - oder Ihre - Serveradministratoren gefordert.
Die Anfälligkeit auf dem Server ist über zwei wichtige Eckdaten definiert:
- Erlauben von SSLv2-Verbindungen auf dem Server
- Ausgetauschte Private Keys zwischen Servern, bei dem einer der Server SSLv2 noch unterstützt.
Gerade das zweite Risiko wird hierbei schnell unterschätzt oder geht vergessen: Wenn beispielsweise Ihr Mailserver SSLv2 unterstützt und dabei mit demselben SSL-Zertifikat auch Ihr Webserver schützt, kann durch das knacken via Mailserver ebenfalls der Verkehr des Webservers ausgelesen werden (da hier dann auch der Masterkey von RSA geknackt ist). Entsprechend muss dadurch auch überprüft werden, ob jeder Server in einem Unternehmen gegen SSLv2 geschützt ist bzw. dieses Protokoll nicht mehr erlaubt ist.
Als erstes sollten Sie prüfen ob Ihre Website bzw. Ihre Server dieses Protokoll noch unterstützen. Das Entdecker-Team dieser Lücke stellt dazu eine Datenbank zur Verfügung [1], mittels der Sie überprüfen können ob Ihr Server zum Zeitpunkt der Entdeckung anfällig gewesen ist. Dazu muss erwähnt werden, dass es keine “Live”-Überprüfung ist (dies aus Schutzgründen, damit nicht jeder Laie kurz Ihren Stand zum Server überprüfen kann - die Betonung liegt hier auf “Laie”. Ein potenzieller Angreifer findet selbstverständlich genug andere Wege.).
Welche Dienste anfällig sind:
- Apache (ab mind. 2.4 keine Gefahr, offizielles Apache-Developer Statement steht noch aus) [3]
- Nginx (Versionen vor 0.7.64, 0.8.18 und früher unterstützen SSLv2 per default - diese sollten deaktiviert werden, offizielles Nginx-Developer Statement steht noch aus - Anleitung zur Deaktivierung im unten stehenden Link) [4]
- Postfix (ab 2.9.14 bzw. Release nach 20. Juli 2015 keine Gefahr) [5]
Der vermutlich wichtigste Schritt ist das Deaktivieren des SSLv2-Protokolls. Wie mehrfach erwähnt, ist dieses veraltet und wird heute nicht mehr eingesetzt; es kann entsprechend bedenkenlos deaktiviert werden. Aufgrund der verschiedenen und komplexen Serverkonfigurationen gibt es diesbezüglich leider keine pauschale Anleitung zur Umsetzung. Nachfolgend zählen wir jedoch die wichtigsten Punkte auf, die beachtet werden sollten:
- Sicherstellen, dass SSLv2 deaktiviert ist.
- Moderne und aktuelle Versionen des Webservers nutzen (beispielsweise lässt Apache sich nich dazu bringen über SSLv2 zu kommunizieren)
- Aktualisieren Sie OpenSSL: Die Anfälligkeit kann durch vorgehende Bugs [6] noch schneller ausgenützt werden (schneller in Form des Zeitaufwandes zum Knacken des Master-Werts). OpenSSL 1.0.2 sollte auf 1.0.2g, OpenSSL 1.01 auf 1.0.1s aktualisiert werden. [7]
Diese Schritte sind dringend zu empfehlen. Weiterführende Informationen zu DROWN finden Sie in der unten stehenden Link-Liste bzw. auf der offiziellen Seite der DROWN-Entdecker [8].
- [1] https://test.drownattack.com/
- [2] https://status.nine.ch/de/messages/498
- [3] https://drownattack.com/apache.html
- [4] http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols
- [5] https://drownattack.com/postfix.html
- [6] https://status.nine.ch/de/messages/409
- [7] https://www.openssl.org/blog/blog/2016/03/01/an-openssl-users-guide-to-drown/
- [8] https://drownattack.com/
