it-swarm.com.de

Was ist DROWN und wie funktioniert es?

Es gibt einen neuen letzter Angriff"auf TLS"benannt"DROWN" . Ich verstehe, dass es anscheinend schlechte SSLv2-Anforderungen verwendet, um statische (Zertifikat-) Schlüssel wiederherzustellen.

Meine Frage ist: Wie ?

Wie können Sie statische Verschlüsselungs- oder Signaturschlüssel mit SSLv2 wiederherstellen?

Bonusfragen: Wie kann ich verhindern, dass der Angriff auf mich als Serveradministrator angewendet wird? Wie konnte der Angriff überhaupt entstehen?

162
SEJPM

Um den Angriff zu verstehen, muss man sich an Bleichenbachers Angriff aus dem späten 20. Jahrhundert erinnern. Bei diesem Angriff verwendet der Angreifer den Zielserver als Oracle. Bei Verwendung des RSA-basierten Schlüsselaustauschs soll der Client einen geheimen Wert (das "Pre-Master-Geheimnis") senden, der mit dem öffentlichen Schlüssel des Servers verschlüsselt ist, wobei PKCS # 1 v1.5 padding (aufgerufen) verwendet wird "Typ 2"). Bleichenbachers Angriff beruhte darauf, sorgfältig gestaltete Werte anstelle einer ordnungsgemäß verschlüsselten Nachricht zu senden und die Reaktion des Servers zu beobachten. Der Server antwortet möglicherweise (meistens) mit dem Fehler "Ich habe das verarbeitet, aber es wurde keine ordnungsgemäße Auffüllung von PKCS # 1 v1.5 Typ 2 erzielt". aber manchmal scheint die Entschlüsselung zu funktionieren und der Server fährt mit dem fort, was er erhalten hat. Der Angreifer sieht diesen Unterschied im Verhalten und gewinnt so ein kleines bisschen an Informationen über den privaten Schlüssel. Nach ungefähr einer Million Verbindungen weiß der Angreifer genug, um eine willkürliche Entschlüsselung durchzuführen und damit eine zuvor aufgezeichnete Sitzung zu unterbrechen.

Dieser Angriff ist von der gleichen Art, jedoch mit einer neuen Technik, die auf den Besonderheiten von SSL 2.0 beruht. SSL 2.0 ist eine alte Protokollversion, die mehrere schwerwiegende Mängel aufweist und nicht verwendet werden sollte. Es ist seit mehr als 15 Jahren veraltet. Es wurde sogar offiziell verboten im Jahr 2011. Trotzdem unterstützen einige Leute immer noch SSL 2.0. Schlimmer noch, sie unterstützen es mit sogenannten "Export" -Cipher-Suites, bei denen die Verschlüsselungsstärke auf etwa 40 Bit reduziert ist.

Der Angriff funktioniert also ein bisschen wie folgt:

  1. Der Angreifer beobachtet eine verschlüsselte SSL/TLS-Sitzung (eine moderne, robuste, z. B. TLS 1.2), die den RSA-Schlüsselaustausch verwendet, und möchte diese entschlüsseln. Nicht alle SSL/TLS-Sitzungen können wie beschrieben angegriffen werden. Es besteht eine Wahrscheinlichkeit von ungefähr 1/1000, dass der Angriff funktioniert. Der Angreifer muss also ungefähr tausend verschlüsselte Sitzungen sammeln und wird letztendlich eine davon durchbrechen. Die Autoren argumentieren, dass in einem Setup, das dem für CRIME und BEAST (feindliches Javascript, das unsichtbare Verbindungen im Hintergrund auslöst) ähnelt, diese Sammlung automatisiert werden kann.

  2. Der Server verwendet unachtsam denselben privaten RSA-Schlüssel für ein SSL 2.0-System (möglicherweise denselben Server, möglicherweise ein anderes Softwaresystem, das möglicherweise ein anderes Protokoll implementiert, z. B. einen Mailserver). Der Angreifer hat die Möglichkeit, zu versuchen, mit diesem anderen System zu sprechen.

  3. Der Angreifer startet einen SSL 2.0-Handshake mit diesem System und verwendet als ClientMasterKey Nachricht einen Wert, der von dem Wert abgeleitet ist, den der Angreifer entschlüsseln möchte. Er bittet auch um die Verwendung einer 40-Bit-Exportverschlüsselungssuite.

  4. Der Angreifer beobachtet die Antwort des Servers und erzwingt brutal den 40-Bit-Wert, den der Server beim Entschlüsseln des vom Angreifer gesendeten Werts ermittelt hat. Zu diesem Zeitpunkt kennt der Angreifer einen Teil des Ergebnisses der Verarbeitung seines gestalteten Werts durch den Server mit seinem privaten Schlüssel. Dies liefert indirekt einige Informationen zu der verschlüsselten Nachricht, an der der Angreifer wirklich interessiert ist.

  5. Der Angreifer muss die Schritte 3 und 4 ungefähr einige tausend Mal ausführen, um das verschlüsselte Pre-Master-Geheimnis aus der Zielsitzung wiederherzustellen.

Für die mathematischen Details lesen Sie der Artikel .

Bewerbungsbedingungen:

  • Die Verbindung muss den RSA-Schlüsselaustausch verwenden. Der Angriff kann, wie beschrieben, nicht viel gegen eine Verbindung tun, die DHE- oder ECDHE-Schlüsselaustausch verwendet (die ohnehin für Vorwärtsgeheimnis empfohlen werden).

  • Derselbe private Schlüssel muss in einem System verwendet werden, das SSL 2.0 implementiert, auf das der Angreifer zugreifen kann, und das außerdem die Aushandlung einer "Export" -Verschlüsselungssuite akzeptiert.
    Hinweis : Wenn OpenSSL verwendet wird und nicht gepatcht für CVE-2015-3197 , auch wenn "exportieren" "Cipher Suites sind deaktiviert. Ein böswilliger Client kann weiterhin einen Handshake mit diesen deaktivierten Cipher Suites aushandeln und ausführen.

  • Der Angreifer muss in der Lage sein, einige Tausend Verbindungen zu diesem SSL 2.0-System herzustellen und dann für jedes System eine 40-Bit-Brute-Force auszuführen. Die Gesamtkosten für die Berechnung betragen ca. 250 Operationen.

Es muss gut verstanden werden, dass die 250 Der Aufwand gilt für jede Verbindung, die der Angreifer zu entschlüsseln versucht. Wenn er beispielsweise Kreditkartennummern von Verbindungen lesen möchte, die er beobachtet, muss er für jede Kreditkartennummer einen nicht zu vernachlässigenden Arbeitsaufwand leisten. Obwohl der Angriff sehr schwerwiegend ist, ist er in diesem CCN-Grabbing-Setup nicht wirklich praktisch.


Die Lösung: Verwenden Sie kein SSL 2.0. Verdammt. Sie sollten SSL 2.0 im letzten Jahrtausend nicht mehr verwenden. Als wir sagten "benutze es nicht, es ist schwach", meinten wir es wirklich so. Es ist höchste Zeit aufzuwachen und Ihren Job zu machen.

Die Unterstützung schwacher ("Export") Cipher Suites war ebenfalls kein kluger Schachzug. Erraten Sie, was ? Schwache Krypto ist schwach.

Das Deaktivieren von SSL 2.0 ist der einzig richtige Weg, um das Problem zu beheben. Deaktivieren Sie währenddessen auch SSL 3. .

(Und diese Art, Akronyme in Großbuchstaben für Angriffe zu verwenden, ist wirklich lächerlich.)

239
Thomas Pornin

Die Antwort von Thomas ist wunderbar. Es gibt nur eine Sache, die untertrieben zu sein scheint: E-Mail-Server sind sicherheitsbedingt defekt ... standardmäßig und beabsichtigt.

  • Standard: Schauen Sie sich zum Beispiel die Standardkonfiguration postfix an (Hinweis: SSLv2 und 40-56-Bit-Chiffren sind immer noch eine Sache, und "keine Verschlüsselung" auch).
  • by design: Hast du jemals von dem StartSSL Wunder gehört? Nun, es ist der einzige nicht veraltete Weg, um eine Verschlüsselung mit SMTP (dem "E-Mail" -Protokoll) zu erreichen. Was bei StartSSL wunderbar ist, ist, dass es normalerweise stark ist, wenn niemand zuhört, aber leicht auf Klartext eingestellt werden kann, wenn jemand lesen möchte ... oder SSLv2 wenn jemand möchte stattdessen HTTPS lesen ...

    ¯\_ (ツ) _/¯

Siehe dort für ein Beispiel sowohl des Geisteszustands von Menschen im Bereich SMTP als auch einiger Einblicke in die Konfiguration. Bitte beachten Sie, dass es in postfix kein einziges Flag gibt, um SSLv2 zu deaktivieren (nun, es gibt eines, aber wundern Sie sich nicht, wenn der Server SSLv2 danach noch akzeptiert und darauf reagiert).

Wie hängt das überhaupt mit der Frage zusammen?

Sie können Ihren Webserver so stark härten, wie Sie möchten. Wenn auf einem SMTP Server ein gültiges Zertifikat ausgeführt wird, ist die Wahrscheinlichkeit hoch, dass Sie für denselben "DROWN" -Angriff anfällig sind. Schlimmer noch, Ihr Webserver wird zu ... normalerweise: Sie wären überrascht, wie viele SMTP Server ihre gemeinsam nutzen Zertifikate mit dem Server HTTP. Sie werden auch von der Gültigkeitsdomäne einiger "eigenständiger" SMTP -Zertifikate überrascht sein.

Lösungen?

  1. Konfigurieren Sie Ihren SMTP Server ordnungsgemäß (und überprüfen Sie die Konfiguration mit externen Tools wie sslyze ).
  2. Oder deaktivieren Sie SMTP insgesamt.
  3. Oder verwenden Sie ein selbstsigniertes/subdomänenspezifisches Zertifikat mit SMTP.
44
JPatta