8. März 2016

Let SSL DROWN…

…oder: warum Dienste mit nur noch mit TLS- statt mit SSL-Transportverchlüsselung arbeiten sollten.

In Penetrationstests findet man häufig noch Dienste, die zur Verschlüsselung der Daten auf dem Transportweg noch SSL (in Protokollversion 2 oder Protokollversion 3) anbieten – sowohl intern, als auch (wenn auch immer seltener) extern. Letzte Woche hat ein Team von Forschern eine weitere Schwäche des veralteten SSL-Protokolls in Version 2 mit Namen „DROWN“ veröffentlicht. Da sich die Anfragen bei mir mehren scheint es doch eine gewisse Unsicherheit über die Konfigurationen von Diensten zu geben. Daher an dieser Stelle eine kleine Hilfestellung:

Bin ich gegenüber DROWN verwundbar?

Fragen, die man sich stellen sollte:

  • Habe ich einen Serverdienst, der noch das angestaubte Protokoll in Version 2 verwendet?
  • Teile ich mir einen privaten Schlüssel mit einem anderen Server, der noch SSL-Protokollversion 2 verwendet?
  • Setze ich OpenSSL ein und wenn ja, auch die aktuellste Version?

Wenn man eine der Fragen mit „ja“ beantworten muss, dann sieht es leider (immer noch) düster aus.

Wer sich dennoch unsicher ist, sollte sich nicht vor technischen Prüfungen scheuen:

Wie finde ich technisch heraus, ob ich gegenüber DROWN verwundbar bin?

Es gibt eine eigene Seite der Forscher, auf der man seine Domainnamen eingeben kann. Es findet dann ein Abgleich mit deren Datenbank statt. Wenn dort angezeigt wird, dass man nicht verwundbar ist, heißt das aber nicht, dass man nicht durch deren Scanning erfasst wurde.

Um selbst herauszufinden, ob man verwundbar ist, nehme man beispielsweise OpenSSL (wichtig: es muss der Support für SSL Protokollversion 2 noch aktiviert sein, sonst kann man nicht testen 🙂 )

openssl s_client -ssl2 -connect $servername:$port

Wenn dann im Ergebnis zu lesen ist, dass das verwendete Protokoll nich tunterstützt wird (siehe nächste Ausgabe), kann man fast aufatmen.

CONNECTED(00000003)
458:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:

Nur fast, weil man jetzt noch sicherstellen muss, dass der betreffende Dienst noch die aktuellste OpenSSL-Bibliothek einsetzt (sofern OpenSSL zum Einsatz kommt), damit man nicht gegen CVE-2015-3197 (erlaubt das Verbinden mittels SSLv2, obwohl man dafür alle Cipher-Suites deaktiviert hat) oder CVE-2016-0703 (macht die DROWN-Attacke effektiver/schneller ausnutzbar) verwundbar ist.

openssl version

Es sind aber auch andere Tools wie beispielsweise das SSL/TLS-Audit-Tool „o-saft“ des Open Web Application Security Projects für die Überprüfung verwendbar.

Was kann ich dagegen tun?

Erst sollte ich die OpenSSL-Bibliothek aktualisieren, sofern nicht schon geschehen. Danach sollte ich mir gedanken machen, wie ich (alle) Dienste so konfiguriere, dass

eingesetzt werden. Dabei kann man auch noch auf Aspekte wie Perfect-Forward-Secrecy oder Kompatibilität mit Browsern achten.

Ich hab das nicht verstanden oder brauche Hilfe!

Keine Angst, das ist kein Hexenwerk und bisher wurde noch kein Exploit veröffentlicht. Wir helfen gerne bei der Überprüfung. Im Rahmen von Penetrationstests wird dies z. B. mit überprüft. Ob ein solcher Penetrationstest für Sie sinnvoll ist, können wir gemeinsam in einem Gespräch herausfinden. Sprechen Sie uns einfach über das Kontaktformular an.