DROWN: Angriff auf verschiedene Protokolle auf TLS mittels SSLv2 (CVE-2016-0800)

Die Red Hat Product Security wurde auf eine Sicherheitslücke im SSLv2 Protokoll hingewiesen, die zugewiesen wurde CVE-2016-0800 und bei einem protokollübergreifenden Angriff unter der Bezeichnung DROWN - DROWN - Decrypting RSA using Obsolete and Weakened eNcryption verwendet wird.

Überblick

Eine Gruppe von Sicherheitsexperten hat festgestellt, dass SSLv2 (Secure Sockets Layer protocol version 2.0) für den Bleichenbacher RSA Padding Oracle Angriff anfällig ist, der benutzt werden kann um einen RSA-verschlüsselten Text ohne Kenntnis über den passenden privaten RSA-Schlüssel zu entschlüsseln. Dies kann erreicht werden, indem Antworten von einem Server observiert werden, der den privaten Schlüssel hat und damit verschlüsselte Texte der Angreifer entschlüsselt. Die Experten haben zudem auf einen neuen protokollübergreifenden Angriff hingewiesen, der die Entschlüsselung von SSL/TLS Sessions mit neueren Protokollversionen ermöglicht - SSLv3 oder andere aktuelle TLS (Transport Layer Security) Versionen (1.0 - 1.2) - mittels dieser SSLv2 Schwachstelle. Dieser Fehler ist ein Problem des SSLv2 Protokolls und betrifft alle Implementierungen des Protokolls. Experten bezeichnen diesen Angriff als general DROWN.

Darüber hinaus wurden Fehler in der SSLv2 Protokoll-Implementierung in OpenSSL Kryptographie und SSL/TLS Library gefunden, welche die Durchführung einer effektiveren Variante des DROWN Angriffs ermöglichen, den special DROWN. Diese Probleme wurden zugewiesen CVE-2016-0703 und CVE-2016-0704, und wurden vor Kurzem im Rahmen der Korrektur von CVE-2015-0293 behoben.

Weitere Details zu diesem Angriff finden Sie im Expertenbericht namens DROWN: Breaking TLS using SSLv2.

Hintergrund

Das SSLv2 Protokoll hat bekannte Sicherheitsschwachstellen und wird als unsicher angesehen, seit es 1996 durch SSLv3 ersetzt wurde. Seit 2011 ist es offiziell veraltet RFC 6176. Heute wird es im Internet nur beschränkt eingesetzt, da moderne SSL/TLS Clients diese Protokollversion entweder überhaupt nicht unterstützen, oder nach Möglichkeit eine neuere Version verwenden. Dennoch ist es noch immer auf vielen SSL/TLS Servern aktiv. Dies ermöglicht, dass selbst sehr alte Clients verbinden können und vor der Bekanntgabe des DROWN Angriffs war keine Sicherheitsbedrohung ausgehend von Verbindungen mit alten Clients bekannt, die neuere Protokollversionen unterstützen.

Konfigurationen, die vom DROWN Angriff betroffen sind

Ein Server ist anfällig für den DROWN Angriff, wenn er das SSLv2 Protokoll zusätzlich zum SSLv3 oder TLSv1.x aktiviert, und wenn er Cipher Suites zum RSA-Schlüsselaustausch verwendet. Ein Server, der SSLv2 nicht aktiviert, kann ebenfalls anfällig sein, wenn er seinen privaten RSA-Schlüssel mit einem anderen Server oder Dienst mit aktiviertem SSLv2 teilt. Der DROWN Angriff kann zum Beispiel immer noch verwendet werden um HTTPS Sessions auf einen Web-Server zu entschlüsseln, der SSLv2 nicht aktiviert, wenn er seinen RSA-Schlüssel beispielsweise mit einem IMAP Server teilt, der möglicherweise auf demselben Host läuft, der SSLv2 aktiviert. Um den Angriff durchzuführen ist die Verwendung einer schwachen oder Export SSLv2-Cipher erforderlich.

SSL/TLS Verbindungen, die non-RSA-Schlüsselaustausch verwenden, wie Diffie-Hellman oder Elliptic Curve Diffie-Hellman, können nicht mit dem DROWN Angriff entschlüsseln.

Beschreibung und Auswirkung des Angriffs

Der von den Experten beschriebene DROWN Angriff besteht aus folgenden Schritten:

• Zuerst muss ein Angreifer eine gewisse Anzahl von SSL/TLS Sessions zwischen Client und Server mit einer beliebigen Version des Protokolls und unter Verwendung von Cipher-Suites aufzeichnen. Eine dieses aufgezeichneten Sessions wird verschlüsselt sein. Die Experten geben an, dass für den Angriff etwa 1000 Sessions ausreichen.

• Daraufhin öffnet der Angreifer viele SSLv2 Verbindungen zum Server. Für einige dieser Verbindungen muss der Angreifer die Verwendung eines 40-bit (wenn eine der SSLv2 EXPORT Ciphers benutzt werden kann) oder eines 56-bit (für Cipher Suites, die DES verwenden) Session Schlüssels erzwingen. Die Experten schätzen, dass dafür etwa 40000 Verbindungen benötigt werden.

• Jetzt kann der Angreifer "Premaster Secret" Daten von einer der originalen Handshakes entschlüsseln. Die Daten werden verwendet um symmetrische Session-Schlüssel zu erstellen und somit die gesamte aufgezeichnete SSL/TLS Session zu entschlüsseln. Auch andere sensible Daten wie Anmeldedaten zur Authentifizierung oder Cookies können aus der entschlüsselten Session bezogen werden.

Die Experten geben an, dass sie einen TLS 1.2 Handshake mit einem Server entschlüsseln konnten, der 2048 bit RSA-Schlüssel mit 1000 aufgezeichneten Handshakes, 40000 SSLv2 Verbindungen und 2⁵⁰ Offline Berechnungen verwendet. Ihr Angriff dauerte weniger als 8 Stunden und verwendete die Ressourcen eines öffentlichen Cloud-Anbieters zu entstandenen Kosten von 440 USD.

Sie geben außerdem an, dass die Verwendung des special DROWN Angriffs die Anzahl der SSLv2 Verbindungen auf 14000 reduziert und mit einem einzigen Arbeitsplatzrechner in weniger als 3 Minuten durchgeführt werden kann. Das ermöglicht, dass mit diesem Fehler ein aktiver Man-In-The-Middle (MITM) Angriff durchgeführt werden kann und dass ein TLS Server die Identität eines TLS Client annehmen kann.

SSL und TLS Libraries mit SSLv2 Support

Red Hat Produkte umfassen die folgenden Komponenten, die Support für das SSLv2 Protokoll implementieren. Dieser Support kann aktiviert werden, basierend darauf, wie Anwendungen diese SSL/TLS Libraries verwenden.

SSLv2 in OpenSSL

Anwendungen, die OpenSSL verwenden, müssen eine Verbindungsmethode auswählen um die Library zu informieren, welche Versionen des SSL/TLS Protokolls sie verwenden wollen. OpenSSL Verbindungsmethoden aktivieren entweder eine einzelne Protokollversion, oder verwenden die besondere Methode SSLv23 um alle Protokollversionen, die von der Library unterstützt werden, zu aktivieren. Dies ist die am häufigsten gebrauchte Verbindungsmethode. Das SSLv2 Protokoll ist automatisch aktiviert, wenn diese Methode ausgewählt ist. Anwendungen müssen die SSL_OP_NO_SSLv2 Option explizit in den relevanten SSL_CTX oder SSL Objekten einstellen um SSLv2 zu deaktivieren. Während viele Anwendungen das bedingungslos oder aufgrund ihrer Konfiguration tun, verwenden andere Anwendungen die aktivierten Standardprotokolle. Anwendungen, die die OpenSSL Library verwenden, laufen daher wahrscheinlich mit aktiviertem SSLv2.

Die folgenden Änderungen wurden auf die in Red Hat Produkten enthaltene OpenSSL angewendet um dieses Problem anzugehen:

• Das SSLv2 Protokoll ist nicht mehr standardmäßig aktiviert, wenn die SSLv23 Verbindungsmethode verwendet wird.
• Alle SSLv2 Cipher Suites, die 40 bit (EXPORT) oder 56 bit (single DES) symmetrische Verschlüsselungs-Codes verwenden, sind jetzt deaktiviert und können nicht mehr verwendet werden. Die folgenden Cipher Suites sind nicht mehr verfügbar:
  • EXP-RC2-CBC-MD5 / SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
  • EXP-RC4-MD5 / SSL_CK_RC4_128_EXPORT40_WITH_MD5
  • DES-CBC-MD5 / SSL_CK_DES_64_CBC_WITH_MD5
• OpenSSL Versionen in openssl Paketen überprüfen bei allen Updates für Red Hat Enterprise Linux 4 und 5 die OPENSSL_ENABLE_SSL2 Umgebungsvariable. Ist sie definiert, so ist SSLv2 bei der Verwendung der SSLv23Verbindungsmethode standardmäßig aktiviert. Mit dieser Umgebungsvariable kann SSLv2 bei Bedarf wieder aktiviert werden.

Die SSLv2 Verbindungsmethode ist nicht von der Änderung zur SSLv23 Verbindungsmethode betroffen und kann immer noch verwendet werden um Verbindungen über das SSLv2 Protokoll herzustellen.

Beachten Sie außerdem, während die DEFAULT Cipher-Liste in OpenSSL Versionen, wie sie in Red Hat Enterprise Linux 6 und 7 geliefert wird, alle SSLv2 Cipher Suites ausschließt, dass dieser Standard die Server nicht davor bewahrt SSLv2 Verbindungen von Clients anzunehmen, die den Gebrauch einer deaktivierten Cipher Suite erzwingen. Dieses Problem wurde zugewiesen CVE-2015-3197 und ist auch in Updates, die das DROWN Problem behandeln, behoben.

SSLv2 in NSS (Network Security Services)

Die NSS Cryptography-Library implementiert das SSLv2 Protokoll, aktiviert sie jedoch nicht automatisch. Anwendungen müssen die Library explizit auffordern SSLv2 zu aktivieren um es benutzen zu können. Die NSS Versionen, die mit Red Hat Enterprise Linux 7 geliefert werden, lassen die Aktivierung des SSLv2 Protokolls überhaupt nicht zu. Anwendungen, die die NSS-Library verwenden, können mit aktiviertem SSLv2 wahrscheinlich nicht laufen.

Da die NSS-Library SSLv2 nicht standardmäßig aktiviert, sind keine direkten Updates geplant um das DROWN Problem zu behandeln. Zukünftige Updates in Red Hat Enterprise Linux 6 sollen das Protokoll auf ähnliche Weise deaktivieren, wie sie es in Red Hat Enterprise Linux 7 deaktiviert haben.

SSL und TLS-Libraries ohne SSLv2 Support

Red Hat Produkte umfassen die folgenden Komponenten, die manche TLS oder SSL Versionen implementieren, jedoch nicht Support für SSLv2. Daher sind diese Komponenten von dem Problem nicht betroffen. Beachten Sie, dass Anwendungen, die diese nicht betroffenen Libraries verwenden, dennoch vom DROWN Angriff betroffen sein können, wenn sie ihren privaten RSA-Schlüssel mit einer anderen Anwendung teilen, die eine SSL/TLS Library verwendet, die SSLv2 unterstützt.

• GnuTLS
• OpenJDK (Pakete java-1.6.0-openjdk, java-1.7.0-openjdk, java-1.8.0-openjdk)
• Oracle JDK (Pakete java-1.6.0-sun, java-1.7.0-oracle, java-1.8.0-oracle)
• IBM JDK (Pakete java-1.6.0-ibm, java-1.7.0-ibm, java-1.7.1-ibm, java-1.8.0-ibm)

Auflösung

Red Hat empfiehlt, dass Kunden eine riskobasierte Priorisierungsanalyse Ihrer betroffenen Systeme durchführen und verfügbare Patches unverzüglich anwenden um das Problem zu beseitigen. Nach der Aktualisierung ist ein Neustart Ihres Systems der sicherste Weg um sicherzustellen, dass alle betroffenen Dienste die aktualisierte OpenSSL Library verwenden. Wenn ein System-Neustart nicht möglich ist, ist es dennoch erforderlich, dass alle Netzwerkdienste, von OpenSSL abhängen, nach der Anwendung der Patches neu gestartet werden.

Danksagung

Red Hat möchte dem OpenSSL Projekt für die Meldung dieser Probleme danken. Upstream erkennt Nimrod Aviram und Sebastian Schinzel als ursprüngliche Berichterstatter an.

Häufig gestellte Fragen

Wie deaktiviert man SSLv2 in Anwendung X?

Im Knowledgebase-Artikel Securing Application 'X' in RHEL 'Y' ? finden Sie Informationen zur Änderung von SSL/TLS Einstellungen, wie aktivierte Protokollversionen, in den zahlreichen Anwendungen der verschiedenen Red Hat Enterprise Linux Versionen.

Müssen Serverschlüssel oder Zertifikate aufgrund dieses Problems neu generiert werden?

Nein. DROWN kann ihre privaten RSA-Schlüssel nicht direkt offenlegen, zielt aber auf individuellen Sessionschlüssel, die während SSL/TLS Verbindungs-Handshakes generiert und für symmetrische Verschlüsselung verwendet werden. Die Kompromittierung solcher Schlüssel ermöglicht eine Entschlüsselung bestimmter SSL/TLS Sessions. Daher müssen Serviceschlüssel und Zertifikate selbst dann nicht erneuert werden, wenn festgestellt wurde, dass ein Dienst für einen DROWN Angriff anfällig ist.

Ist SSLv2 in den Versionen des Apache httpd Web Servers, die mit Red Hat Produkten geliefert werden, aktiviert?

Der Apache httpd Web Server kann eines der folgenden Module verwenden um HTTPS Service bereitzustellen:

• mod_ssl - Dieses Modul verwendet die OpenSSL kryptographische Library und ist als Teil der Apache httpd Web Server Distribution enthalten.
• mod_nss - Dieses Modul verwendet die NSS kryptographische Library und wurde separat vom Apache httpd Projekt entwickelt und verteilt.

Diese beiden Module sind in Red Hat Produkten enthalten.

Die Standardeinstellungen für httpd im mod_ssl sind:

• Die httpd Versionen, die mit Red Hat Enterprise Linux 7, in der httpd24 Sammlung in Red Hat Software-Collections und mit Red Hat JBoss Web Server 3 geliefert werden, basieren auf Upstream httpd Version 2.4 und können nicht konfiguriert werden das SSLv2 Protokoll zu aktivieren.

• Die httpd Versionen, die mit Red Hat Enterprise Linux 5 und 6, mit dem Red Hat JBoss Web Server 1 und 2, und mit Red Hat JBoss Enterprise Application Platform 6 geliefert werden, basieren auf Upstream httpd Versionen 2.2. Diese Versionen können konfiguriert werden SSLv2 zu verwenden, jedoch ist dieses Protokoll in der Standardkonfiguration deaktiviert. Die /etc/httpd/conf.d/ssl.conf Konfigurationsdatei beinhaltet die folgende Konfigurationsdirektive, die SSLv2 deaktiviert:

SSLProtocol all -SSLv2

• Die mit Red Hat Enterprise Linux 4 gelieferten httpd Versionen basieren auf Upstream httpd Versionen 2.0. Die Standardkonfiguration aktiviert SSLv2, es kann jedoch deaktiviert werden, indem dieselbe SSLProtocol Direktive zur /etc/httpd/conf.d/ssl.conf Konfigurationsdatei hinzugefügt wird, die oben angegeben ist und der httpdDienst neu gestartet wird.

Die Standardeinstellungen für httpd im mod_nss sind:

• Die mit Red Hat Enterprise Linux 5, 6 und 7 gelieferten mod_nss Versionen aktivieren SSLv2 nicht standardmäßig. Die /etc/httpd/conf.d/nss.conf Konfigurationsdatei enthält, je nach mod_nss Paketversion, eine der folgenden Konfigurationsdirektiven, die nur SSLv3 oder höher, oder TLSv1.0 oder höher aktiviert:

NSSProtocol SSLv3,TLSv1
NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2

HINWEIS: Aufgrund bekannter Probleme mit dem SSLv3 Protokoll werden wir weiterhin die Deaktivierung dieser Version empfehlen. Im entsprechenden Artikel POODLE: SSLv3 vulnerability (CVE-2014-3566) finden Sie Details und Anweisungen zur Deaktivierung des SSLv3 Protokolls in verschiedenen Komponenten der Red Hat Produkte.

Ist SSLv2 in den Mail SMTP Servern, die mit Red Hat Enterprise Linux geliefert werden, aktiviert?

Standardkonfigurationen von Postfix und Sendmail Mail-Servern in Red Hat Enterprise Linux 5, 6 und 7 aktivieren nicht SSL/TLS Verschlüsselung.

Wenn ein Systemadministrator SSL/TLS in Postfix aktiviert, ist SSLv2 standardmäßig mit opportunistischer Verschlüsselung aktiviert und mit obligatorischer Verschlüsselung deaktiviert. In Red Hat Enterprise Linux 6 und 7 ist es möglich SSLv2 mit opportunistischer Verschlüsselung über die Konfigurationsoption smtpd_tls_protocols zu deaktivieren.

Wenn ein Systemadministrator SSL/TLS in Sendmail aktiviert, ist SSLv2 standardmäßig aktiviert. In Red Hat Enterprise Linux 5, 6 und 7 ist es möglich SSLv2 mit der Konfigurationsoption ServerSSLOptionszu deaktivieren.

In der Frage "Wie deaktiviert man SSLv2 in Anwendung X?" oben finden Sie Links zu weiteren Ressourcen zur Konfiguration von SSL/TLS in Postfix und Sendmail.

Muss ich meine EAP 6.4 Installation aktualisieren?
EAP kann konfiguriert werden den Java Cryptography Provider (JSSE) oder den systemeigenen Provider (APR/OpenSSL) zu verwenden. Wenn Sie den Apr/OpenSSL Provider verwenden, sollten Sie folgende Schritte befolgen:

• Red Hat Enterprise Linux
  OpenSSL-Upgrade für Ihre Version.
• Windows oder Solaris
  Ein Update für die OpenSSL-Libraries wird auf der Kundendienst-Plattform verfügbar gemacht. Dieses Update wird die libssl, die libeay Libraries und OpenSSL Anwendung ersetzen.

EAP 6.4 wurde auf Windows mittels APR/OpenSSL getestet und obwohl die OpenSSL Library technisch gesehen ein Update erfordert, wird die EAP 6.4 standardmäßig TLSv1 verwenden und Verschlüsselungsanfragen für SSLv2 und SSLv3 ablehnen. Von der EAP wird derzeit nicht angenommen, dass sie für diesen Fehler anfällig ist.

Muss ich meine EAP 5.2 Installation aktualisieren?
EAP kann konfiguriert werden den Java Cryptography Provider (JSSE) oder den systemeigenen Provider (APR/OpenSSL) zu verwenden. Wenn Sie den Apr/OpenSSL Provider verwenden, sollten Sie folgende Schritte befolgen:

• Red Hat Enterprise Linux
  OpenSSL-Upgrade für Ihre Version.
• Windows oder Solaris
  Ein Update für die OpenSSL Libraries wird auf der Kundendienst-Plattform verfügbar gemacht. Dieses Update wird die libssl, die libeay Libraries und OpenSSL Anwendung ersetzen.

Die EAP 5.2 wird auf Windows getestet um die Anfälligkeit für diesen Fehler zu bewerten.

Muss ich meine EWS 2.1 Installation aktualisieren?
Dieser Fehler betrifft nur Windows und Solaris Installationen, bei denen APR/OpenSSL als Sicherheitsprovider konfiguriert wurde. EWS 2.1 unterstützt derzeit SSLv2 und SSLv3.
Wenn Sie den Apr/OpenSSL Provider verwenden, sollten Sie folgende Schritte befolgen:

• Red Hat Enterprise Linux
  OpenSSL-Upgrade für Ihre Version.
• Windows oder Solaris
  Ein Update für die OpenSSL Libraries wird auf der Kundendienst-Plattform verfügbar gemacht. Dieses Update wird die libssl, die libeay Libraries und OpenSSL Anwendung ersetzen.

A: Ja, EWS 2.1 ist betroffen und Updates werden im Kundenportal verfügbar gemacht. Dieser Fehler betrifft nur Windows und Solaris Installationen, bei denen APR/OpenSSL als Sicherheitsprovider konfiguriert wurde. Die standardmäßige JSSE Konfiguration ist nicht betroffen. Updates werden im Kundenportal verfügbar gemacht.

Muss ich meine EWS 3.0.2 Installation aktualisieren?
Dieser Fehler betrifft nur Windows und Solaris Installationen, bei denen APR/OpenSSL als Sicherheitsprovider konfiguriert wurde. EWS 3.0.2 unterstützt derzeit SSLv2 und SSLv3. Wenn EWS 3.0.3 veröffentlicht ist, wird es SSLv2 oder SSLv3 nicht mehr anbieten.

Wenn Sie den Apr/OpenSSL Provider verwenden, sollten Sie folgende Schritte befolgen:

• Red Hat Enterprise Linux
  OpenSSL-Upgrade für Ihre Version.
• Windows oder Solaris
  Ein Update für die OpenSSL Libraries wird auf der Kundendienst-Plattform verfügbar gemacht. Dieses Update wird die libssl, die libeay Libraries und OpenSSL Anwendung ersetzen.

Was ist der Status des Tomcat Native Pakets?

Das Tomcat Native Paket ist von diesem Fehler nicht betroffen. Es ist auf die vom System zur Verfügung gestellten OpenSSL Libraries angewiesen.