16.10.2014

POODLE / SSL 3.0 / CVE-2014-3566

Erst vor kurzem haben wir an dieser Stelle über den sogenannten „Shellshock“ berichtet, eine kritische Sicherheitslücke in der weit verbreiteten GNU Bash. Nun macht erneut eine als kritisch zu bewertende Sicherheitslücke von sich reden, die in einer Schwäche des als veraltet angesehenen Protokolls SSL 3.0 besteht (siehe hierzu Heise Security Online am 15.10.2014: Poodle: Experten warnen vor Angriff auf Internet-Verschlüsselung).

Informationen zur Ausnutzung dieser Schwachstelle wurden in dieser Woche von Forschern von Google veröffentlicht und aufgrund des möglichen Angriffsmechanismus "POODLE" (Padding Oracle On Downgraded Legacy Encryption) genannt. Um die Sicherheitslücke CVE-2014-3566 ausnutzen zu können, muss sich ein Angreifer in einer Man-in-the-Middle-Position im Netzwerk befinden, dazu reicht es aber bereits aus, mit demselben offenen WLAN verbunden zu sein.

Die DFN-Anwender wurden von uns umgehend durch das Advisory DFN-CERT-2014-1354 über die Sicherheitslücke und die jeweils verfügbaren Sicherheitsupdates informiert.

Betroffene Systeme und Auswirkungen

Von der Schwachstelle betroffen sind grundsätzlich alle Systeme, welche das Secure Sockets Layer Version 3 (SSLv3)-Protokoll unterstützen, wie u. a. alle Implementierungen, die auf OpenSSL bis Version 1.0.1i aufsetzen.

Dies betrifft derzeit u. a. noch fast alle Webserver und auch fast alle Browser. Lediglich der Google Chrome Browser ist bereits ab Version 33, die im Februar 2014 veröffentlicht wurde, in den meisten Umgebungen – falls serverseitig TLS 1.0 oder höher überhaupt unterstützt wird – nicht mehr gegen TLS-Protokoll-Downgrade-Angriffe verwundbar.

Gelingt es einem Angreifer durch zusätzliche Maßnahmen zu erreichen, dass Client und Server für eine verschlüsselte Internet-Verbindung tatsächlich das angreifbare und gegenüber dem Nachfolger Transport Layer Security (TLS) als veraltet geltende Protokoll SSL 3.0 für die Verschlüsselung verwenden, kann er diese gezielt manipulieren und sich dadurch in die Lage versetzen, Teile von verschlüsselten Nachrichten, zu denen auch sensible Anmeldedaten gehören können, im Klartext auszulesen.

Technische Details

Das Secure Sockets Layer Version 3 (SSLv3) Protokoll ist ein mittlerweile fast 18 Jahr altes, inzwischen unsicheres Protokoll für den Aufbau verschlüsselter Verbindungen über das Internet, welches durch seine Nachfolger TLS 1.0, TLS 1.1 und TLS 1.2 abgelöst wurde. Dennoch werden viele HTTPS-Server aus Rückwärtskompatibilitätsgründen noch mit Unterstützung von SSL 3.0 zusätzlich zum moderneren TLS 1.0, 1.1 und 1.2 betrieben; auch die meisten Browser unterstützen es noch. TLS-Implementierungen sind zur Beibehaltung der Abwärtskompatibilität meist in der Lage, bei der initialen Verhandlung zwischen Client und Server die zu benutzende Version des Protokolls miteinander auszuhandeln, indem sie sukzessive weitere Vorgängerversionen vorschlagen, bis letztlich eine Übereinstimmung auf beiden Seiten erreicht ist

Weitere Informationen:

Um allerdings Information ausspähen zu können, muss der Angreifer weitere Maßnahmen ergreifen, welche direkt die Verschlüsselung angreifen, d. h. die eigentliche Schwachstelle CVE-2014-3566 ausnutzen. Das SSL 3.0 Protokoll, so wie es u. a. von OpenSSL bis Version 1.0.1i implementiert ist, benutzt nämlich nicht deterministisches „Padding“. Unter Padding versteht man das Auffüllen der Nachricht mit Bytes bis zur nächsten vollen Blockgrenze für Kryptoalgorithmen im CBC-Modus (Cipher-Block-Chaining). Dieses Padding kann durch den MAC (Message Authentication Code), eine kryptografische Prüfsumme, nicht überprüft werden, da der MAC-Wert das Padding nicht mit einbezieht. Dieses Problem ist unter dem Namen „MAC-then-encrypt“ bekannt.

Weitere Informationen:

Der Empfänger von verschlüsselten Nachrichten kann also die Integrität des Paddings nicht vollständig überprüfen. Dies ermöglicht es dem Man-in-the-Middle das Padding entsprechend zu modifizieren (Padding-Oracle-Angriff), so dass er Teile der Nachricht im Klartext auslesen kann. Indem er dieses Vorgehen mit leichten Veränderungen häufiger wiederholt, kann ein Angreifer beispielsweise auch das von einem Server übermittelte Sitzungs-Cookie für eine verschlüsselte Verbindung, z. B. zu einem Online-Banking-Portal, stückweise auslesen, welches Anmeldeinformationen enthalten kann.

Zur Zeit wird an einem Mechanismus gearbeitet, welcher TLS_FALLBACK_SCSV genannt wird und das Problem des Herunterstufens der Protokollversion in der Verhandlungsphase entschärfen soll. Von den Entwicklern von OpenSSL wurde dieser Mechanismus bereits implementiert und ist in den Versionen OpenSSL 1.0.1j, 1.0.0o und 0.9.8zc enthalten. Hersteller, deren Software-Produkte auf OpenSSL basieren, sind im Augenblick dabei, für diese Sicherheitsupdates bereitzustellen, welche die verbesserten Versionen von OpenSSL beinhalten.

Maßnahmen für Betreiber

Wie sollen Betreiber von Serversystemen sich richtig verhalten? Wenn möglich sollten Sie für Ihre Server verfügbare Sicherheitsupdates installieren. Im Übrigen empfehlen wir allen Betreibern von Webservern als Sofortmaßnahme die Unterstützung von SSL 3.0 vollständig zu deaktivieren. Zwar kann dies Auswirkungen auf die Erreichbarkeit der Webseite für ältere Browser haben, dies betrifft nach derzeitigem Kenntnisstand jedoch nur Internet Explorer 6 unter Windows XP.

Apache HTTP-Server

Um die Unterstützung für SSL 3.0 (und SSL 2.0) für den Apache HTTP-Server zu deaktivierten, müssen Sie die folgende SSL-Direktive in jeder SSL/TLS-Sektion hinzufügen:

SSLProtocol all -SSLv2 -SSLv3

Danach muss der Apache HTTP-Server neu gestartet werden.

Nginx HTTP-Server

Um die Unterstützung für SSL 3.0 (und SSL 2.0) für den Nginx HTTP-Server zu deaktivierten, müssen Sie lediglich die erlaubten Protokolle auflisten:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2

Danach muss der Nginx HTTP-Server neu gestartet werden.

Microsoft IIS Internet Information Server

Um SSL 3.0 für Microsoft IIS zu deaktivieren müssen Sie die Registry editieren:

HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server

und den folgenden Key

Enabled

auf den Wert „0“ setzen.

Alternativ können Sie das folgende PowerShell-Skript ausführen:

md 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server' -Force
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server' -name Enabled -value 0 -PropertyType 'DWord' -Force

Danach müssen Sie das System neu starten; ein Neustart des IIS alleine reichte in unseren Tests nicht aus (getestet mit Windows Server 2012R2).

Test auf Unterstützung von SSL 3.0

Um zu testen, ob ein Server SSL 3.0 anbietet, können Sie folgenden openssl-Befehl verwenden:

openssl s_client -connect <FQDN>:443 -ssl3

Wenn SSL 3.0 erfolgreich abgeschaltet wurde, sollten Sie folgende Ausgabe erhalten:

CONNECTED(00000003)
140185900164752:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1275:SSL alert number 40
140185900164752:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598:
[...]
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
[...]
    Verify return code: 0 (ok)

Maßnahmen für Benutzer

Ebenso sollten Benutzer, falls möglich, ihre Clients dahingehend konfigurieren, dass SSL 3.0 nicht akzeptiert wird, wenn sie sich mit geschützten Diensten verbinden wollen.

Mozilla Firefox

Um SSL 3.0 für Firefox manuell zu deaktivieren, müssen Sie folgende Schritte durchführen:

  1. Öffnen Sie „about:config“ in Ihrem Browser

  2. Suchen sie nach „security.tls.version.min“

  3. Rechts-Klick → „Bearbeiten“

  4. Setzen Sie den Wert auf „1“

Auf diese Weise wird nur noch TLSv1, TLSv1.1 and TLSv1.2 akzeptiert. In Firefox Release 34, das für den 25. November 2014 angekündigt wurde, wird SSL 3.0 per Voreinstellung deaktiviert sein.

Mozilla Thunderbird

Um SSL 3.0 für Thunderbird manuell zu deaktivieren, müssen Sie folgende Schritte durchführen:

  1. Öffnen Sie das Menü „Einstellungen“

  2. Klicken Sie auf „Erweitert“

  3. Gehen Sie auf den Tab „Allgemein“

  4. Klicken Sie auf „Konfiguration bearbeiten“

  5. Suchen Sie nach „security.tls.version.min“

  6. Rechts-Klick → „Bearbeiten“

  7. Setzen Sie den Wert auf „1“

Microsoft Internet Explorer

Um SSL 3.0 für Internet Explorer manuell zu deaktivieren, müssen Sie folgende Schritte durchführen:

  1. Öffnen Sie das Konfigurationsmenü

  2. Gehen Sie zu Internet-Optionen

  3. Klicken Sie auf „Erweitert“

  4. Suchen Sie nach „SSLv3“ und deaktivieren Sie das Häkchen

Google Chrome

Um SSL 3.0 für Chrome zu deaktivieren müssen Sie den Browser mit der Kommandozeilen-Option

--ssl-version-min=tls1

starten.

Weitere Maßnahmen

Grundsätzlich sollten Benutzer einige Vorsichtsmaßnahmen beachten, die auch unabhängig von der hier geschilderten Angriffsmöglichkeit gelten. Kritische Webverbindungen, z. B. für das Online-Banking, sollten generell nicht über offene WLANs und möglichst immer durch den direkten Aufruf einer durch HTTPS abgesicherten Einstiegsseite aufgebaut werden. Während dieser Sitzung sollten keine parallelen Tabs im Browser geöffnet werden. Und nach der SSL-Sitzung sollten alle kritischen Webanwendungen explizit geschlossen werden, um Sitzungs-Cookies zu deaktivieren.

Weitere Informationen:

Fazit und Ausblick

„Heartbleed“, „ShellShock“ und jetzt „POODLE“ – es scheint so, als ob die Einschläge in immer kürzerer Folge kommen, und es drängt sich dabei unwillkürlich dem Benutzer wie dem Experten gleichermaßen der Eindruck auf, dass das Internet irgendwie Stück für Stück „kaputt geht“.

Tatsächlich sollte man darüber nachdenken, wie lange manche Schwachstellen schon in den Systemen enthalten sind und es als ein positives Zeichen für die erhöhte Sensibilität und daraus folgende detailliertere Überprüfungen von Software nehmen, dass diese Schwächen jetzt entdeckt werden. Betrachtet man zusätzlich die ständig wachsende Anzahl immer komplexer werdender Anwendungen, so ist es nur natürlich, dass auch die Angriffsmöglichkeiten steigen.

Man muss akzeptieren, dass Sicherheitsvorfälle im Internet ein alltäglicher Teil unserer Arbeit sind, auf die wir uns einstellen und auf die wir reagieren müssen. Das Etablieren von Strategien zum Umgang mit IT-Sicherheitsproblemen ist schon lange nichts mehr für ein „paar paranoide Freaks“, sondern für uns alle notwendig und wichtig.

Laufen wir also nicht vor den Gefahren des Internets davon – wir würden wohl ohnehin nicht weit kommen, sondern stellen wir uns den Tatsachen und denken wir (gemeinsam) über die Maßnahmen nach, die uns helfen können, den Risiken auch in Zukunft zu begegnen.