-
-Die CA Trustwave hat ein Zertifikat
-verkauft,
-dass Man-in-the-Middle-Angriffe erlaubt. Wie die funktionieren und warum
-es so schlimm ist, wenn ein offizielles Zertifikat zum Einsatz kommt,
-erfahren Sie hier.
-
-
-
HTTPS im Einsatz
-
-
-
-
-
-Bevor wir zum Man-in-the-Middle-Angriff kommen, muss erst mal HTTPS
-allgemein erklärt werden. Das ist eigentlich ganz einfach: Wenn Sie
-im Webbrowser durch den Aufruf eines https://-Links eine sichere Verbindung
-z.B. zu Ihrer Bank aufbauen, stellt Ihr Browser eine Verbindung zum
-angegebenen Server her, prüft dessen Identität und teilt ihm
-einen Schlüssel mit, mit dem die nachfolgende Kommunikation
-verschlüsselt werden soll.
-
-
-
-Dabei kommen mehrere Kryptographische Verfahren zum Einsatz: Eine
-Public-Key-Infrastruktur,
-um die Identität des Servers zu prüfen und dessen öffentlichen Schlüssel
-zu erhalten, ein
-asymmetrisches Kryptosystem,
-mit dem der vom Webbrowser erzeugte Sitzungsschlüssel sicher an den Server
-gesendet wird, und ein
-symmetrisches Kryptosystem,
-mit dem danach alle übertragenen Daten verschlüsselt werden.
-Aufgeteilt in die einzelnen Schritte sieht das so aus, siehe auch Abb. 1:
-
-
-
- - Sie geben im Browser
https://www.ihre-bank.example
ein.
- - Ihr Browser baut eine Verbindung zum Webserver
-
www.ihre-bank.example
auf.
- - Der Webserver sendet sein Zertifikat mit seinem öffentlichen
- Schlüssel an Ihren Browser.
-
- Ihr Browser prüft das Zertifikat. Dazu enthält er ab Werk
- eine Liste von aus Sicht des jeweiligen Browserherstellers
- vertrauenswürdigen CAs. Wurde das Zertifikat nicht von einer dieser
- CAs ausgestellt oder ist die Signatur nicht korrekt, gibt er eine Warnung
- aus und beendet den Verbindungsaufbau.
-
- Verläuft die Prüfung erfolgreich, weiß der Browser,
- dass er wirklich mit dem Server
www.ihre-bank.example
- verbunden ist und kennt dessen öffentlichen Schlüssel. Nun
- erzeugt er einen symmetrischen Schlüssel, der nur für die
- aktuelle Sitzung verwendet wird, den sog. Sitzungsschlüssel oder
- Session Key.
- - Der Sitzungsschlüssel wird mit dem öffentlichen
- Schlüssel des Webservers verschlüsselt und an den Webserver
- übertragen.
-
- Der Webserver entschlüsselt den Sitzungsschlüssel mit seinem
- privaten Schlüssel.
-
- Jetzt besitzen sowohl Webbrowser als auch Webserver einen gemeinsamen
- Schlüssel für das symmetrische Kryptosystem, mit dem sie alle
- weiteren zu übertragenen Daten verschlüsseln können.
-
- Der Webserver baut seine Startseite auf, verschlüsselt sie mit
- dem Sitzungsschlüssel und sendet sie an den Browser.
-
- Der Browser entschlüsselt die verschlüsselte Startseite und
- stellt sie dar.
-
- Auch alle weiteren zu übertragenen Daten werden mit dem
- Sitzungsschlüssel verschlüsselt.
-
-
-
-
-
-Abb. 1: HTTPS (Klick öffnet ein größeres Bild in einem
-neuen Fenster)
-
-
-
Man-in-the-Middle-Angriff auf HTTPS, allgemein
-
-
-Betrachten wir nun einen MitM-Angriff auf obiges Beispiel, z.B. durch ein
-Data Loss Prevention System (DLP-System) wie dass, für das Trustwaves
-"MitM-Zertifikat" verwendet wurde. Zuerst aber ohne das
-"MitM-Zertifikat". Damit der Man-in-the-Middle eine HTTPS-Verbindung
-aufbauen kann, braucht er aber ein passendes Zertifikat, in diesem Fall
-für www.ihre-bank.example
. Das kann er sich selbst erstellen
-und auch selbst signieren, so dass es formal korrekt ist.
-
-
-
- - Sie geben im Browser
https://www.ihre-bank.example
ein
- - Ihr Browser baut eine Verbindung zum Webserver
-
www.ihre-bank.example
auf.
- - Der Man-in-the-Middle nimmt die Verbindungsanfrage entgegen. Er sendet
- sein gefälschtes Zertifikat für
-
https://www.ihre-bank.example
mit seinem öffentlichen
- Schlüssel an Ihren Browser.
- Parallel baut er eine HTTPS-Verbindung zu
- https://www.ihre-bank.example
auf, wie es oben beschrieben
- wurde.
- - Ihr Browser prüft das Zertifikat. Da es zwar zu
-
www.ihre-bank.example
gehört, aber von einer unbekannten
- CA unterzeichnet wurde, gibt er eine Warnung aus. Sie bemerken den Angriff
- und hören mit dem Surfen auf.
- Oder sie fallen auf das gefälschte Zertifikat herein, halten es
- für echt und surfen weiter. Dann haben Sie Pech gehabt, denn der MitM
- kann alle übertragenen Daten ausspähen und/oder manipulieren,
- s.u..
-
-
-
-Im Fall eines DLP-Systems ist es üblich, eine eigene PKI aufzubauen und das
-zugehörige Root-Zertifikat, mit dem die ausgestellten Zertifikate geprüft
-werden, in den internen Webbrowsern zu installieren. Parallel werden die
-Benutzer über das Aufbrechen der geschützten Verbindung informiert. Dann
-würde der MitM-Angriff so ablaufen:
-
-
-
- - Sie geben im Browser
https://www.ihre-bank.example
ein
- - Ihr Browser baut eine Verbindung zum Webserver
-
www.ihre-bank.example
auf.
- - Das DLP-System nimmt die Verbindungsanfrage entgegen. Es erstellt ein
- Zertifikat für
www.ihre-bank.example
mit seinem
- öffentlichen Schlüssel, signiert es mit dem Root-Schlüssel
- der internen PKI und sendet es an Ihren Browser.
- Parallel baut es eine HTTPS-Verbindung zu
- https://www.ihre-bank.example
auf, wie es oben beschrieben
- wurde.
- - Ihr Browser prüft das Zertifikat. Da es zu
-
www.ihre-bank.example
gehört und von der ihm bekannten
- internen Zertifizierungsstelle ausgestellt wurde, gibt er keine Warnung
- aus, sondern baut die Verbindung weiter auf.
- - Ihr Browser tauscht mit dem DLP-System, den er für den
- Bank-Server hält, einen Sitzungsschlüssel aus.
-
- Jetzt besitzen sowohl Webbrowser und DLP-System als auch DLP-System
- und Webserver jeweils einen gemeinsamen Schlüssel für das
- symmetrische Kryptosystem, mit dem sie alle weiteren zu übertragenen
- Daten verschlüsseln können.
-
- Der Webserver baut seine Startseite auf, verschlüsselt sie mit
- dem mit dem DLP-System vereinbarten Sitzungsschlüssel und sendet sie
- an das DLP-System (das er für Ihren Browser hält).
-
- Das DLP-System entschlüsselt die Daten und kann sie nun
- prüfen und ggf. manipulieren. Sollen die Daten das DLP-System
- passieren, werden sie mit dem zwischen DLP-System und Webbrowser
- ausgetauschten Schlüssel verschlüsselt und an den Browser
- gesendet. Der denkt, sie stammen von
www.ihre-bank.example
- und sind unverändert!
- - Der Browser entschlüsselt die verschlüsselte Startseite und
- stellt sie dar.
-
- Auch alle weiteren zu übertragenen Daten werden entsprechend
- verschlüsselt, vom DLP-System entschlüsselt und nach der
- Prüfung erneut verschlüsselt.
-
-
-
-Nehmen wir mal an, ein Gast benutzt Ihr lokales Netz und surft seine Bank
-an. Da sein Browser natürlich nicht das Root-Zertifikat der internen
-PKI kennt, passiert das gleiche wie im ersten Angriffs-Beispiel: Der
-Browser bemängelt die unbekannte Zertifizierungsstelle und die
-Verbindung wird abgebrochen.
-
-
-
MitM-Angriff mit "MitM-Zertifikat"
-
-
-Kommen wir nun zu einem MitM-Angriff mit einem "MitM-Zertifikat" einer
-"offiziellen" Zertifizierungsstelle, deren Root-Zertifikat in allen
-Webbrowern enthalten ist, siehe auch Abb. 2:
-
-
-
-
- - Sie geben im Browser
https://www.ihre-bank.example
ein
- - Ihr Browser baut eine Verbindung zum Webserver
-
www.ihre-bank.example
auf.
- - Der MitM nimmt die Verbindungsanfrage entgegen. Es erstellt ein
- Zertifikat für
www.ihre-bank.example
mit seinem
- öffentlichen Schlüssel, signiert es mit dem Root-Schlüssel
- zum "MitM-Zertifikat" und sendet es an Ihren Browser.
- Parallel baut es eine HTTPS-Verbindung zu
- https://www.ihre-bank.example
auf, wie es oben beschrieben
- wurde.
- - Ihr Browser prüft das Zertifikat. Da es zu
-
www.ihre-bank.example
gehört und von einer ihm bekannten
- "offiziellen" Zertifizierungsstelle ausgestellt wurde, gibt er keine
- Warnung aus, sondern baut die Verbindung weiter auf.
- - Ihr Browser tauscht mit dem MitM einen Sitzungsschlüssel aus.
-
- Jetzt besitzen sowohl Webbrowser und MitM als auch MitM und Webserver
- jeweils einen gemeinsamen Schlüssel für das symmetrische
- Kryptosystem, mit dem sie alle weiteren zu übertragenen Daten
- verschlüsseln können.
-
- Der Webserver baut seine Startseite auf, verschlüsselt sie mit
- dem mit dem MitM vereinbarten Sitzungsschlüssel und sendet sie an den
- MitM (den er für Ihren Browser hält).
-
- Der MitM entschlüsselt die Daten und kann sie nun lesen und ggf.
- manipulieren. Sollen die Daten an den Browser weitergeleitet werden,
- werden sie mit dem zwischen MitM und Webbrowser ausgetauschten
- Schlüssel verschlüsselt und an den Browser gesendet. Der denkt,
- sie stammen von
www.ihre-bank.example
und sind
- unverändert!
- - Der Browser entschlüsselt die verschlüsselte Startseite und
- stellt sie dar.
-
- Auch alle weiteren zu übertragenen Daten werden entsprechend
- verschlüsselt, vom MitM entschlüsselt und nach der Prüfung
- erneut verschlüsselt.
-
-
-
-
-
-Abb. 2: MitM-Angriff auf HTTPS mit "MitM-Zertifikat" (Klick öffnet ein
-größeres Bild in einem neuen Fenster)
-
-
-
-Der angenommene Gast würde von diesem MitM-Angriff nichts bemerken, da das
-gefälschte Zertifikat von einer "offiziellen" Zertifizierungsstelle
-ausgestellt wurde, deren Root-Zertifikat in seinem Webbrowser gespeichert
-ist.
-
-
-
MitM-Angriff mit "MitM-Zertifikat" "in the wild"
-
-
-Betrachten wir den MitM-Angriff mit "MitM-Zertifikat" mal außerhalb
-geschlossener lokaler Netze, also "in the wild". Was wäre, wenn ein
-Cyberkrimineller so ein "MitM-Zertifikat" besäße? Er
-könnte jede beliebige HTTPS-Verbindung, die über einen von ihm
-kontrollierten Server läuft, aufbrechen, ohne dass der Benutzer es
-merkt. Und gerade das ist der entscheidende Punkt: Das
-"MitM-Zertifikat" erlaubt es dem Inhaber, gültige Zertifikate für
-beliebige Domains zu erstellen, die von den Webbrowsern problemlos
-anerkannt werden. Er ist also quasi seine eigene, offiziell anerkannte
-Zertifizierungsstelle. Denn für genau diesen Zweck ist diese Sorte
-von Zertifikaten, die eigentlich als "Intermediate Zertifikat" bezeichnet
-wird, normalerweise vorgesehen: Eine Zertifizierungsstelle kann damit einer
-weiteren, untergeordneten Zertifizierungsstelle das selbständige
-Ausstellen von Zertifikaten ermöglichen. Um so schlimmer ist ein
-Missbrauch wie im Fall von Trustwave.
-
-
-
-Und nun betrachten Sie das Problem mal mit anderen Inhabern von
-"MitM-Zertifikaten", z.B. Strafverfolgungsbehörden oder Regierungen
-bestimmter Länder...
-
-
-
MitM-Angriff mit "MitM-Zertifikat" erkennen
-
-
-Die einzige zuverlässige Möglichkeit, so einen Angriff zu
-bemerken, ist der Vergleich des Zertifikats-Fingerprints mit dem korrekten
-Fingerprint - sofern man ihn denn kennt. Banken teilen den Fingerprint
-ihren Kunden teilweise mit, aber die wenigsten prüfen ihn, erst recht
-nicht bei jedem Verbindungsaufbau. Und die Fingerprints der Zertifikate
-von z.B. Google oder Microsoft kennt außerhalb der Unternehmen wohl
-kein Mensch.
-
-
-
-Ansonsten ist das einzig Auffällige an dem Angriff der "falsche" Aussteller
-z.B. des Bank-Zertifikats. Wenn der Benutzer weiß, dass die Bank ein
-Zertifikat von Zertifizierungsstelle A hat und sie nun plötzlich angeblich
-eines von Zertifizierungsstelle B verwendet, könnte ein Angriff
-vorliegen. Oder die Bank die Zertifizierungsstelle gewechselt haben.
-
-
-
Wichtig ist die Identitätsprüfung
-
-
-Nur noch mal zur Verdeutlichung: Wichtig ist beim HTTPS-Protokoll die
-Identitätsprüfung des Servers. Ist die nicht zuverlässig,
-könnten Webbrowser und Webserver auch einfach einen Schlüssel mit
-Hilfe des
-Diffie-Hellman- Schlüsselaustausch
-vereinbaren und sich den Aufwand der Zertifikatsprüfung und des
-Zertifizierungssystems sparen. Der Schlüsselaustausch und das
-Verschlüsseln sind keine Kunst, die Identitätsprüfung ist
-das entscheidende Kriterium. Wenn man nicht sicher weiß, dass man
-wirklich z.B. mit dem Server der eigenen Bank verbunden ist, ist es im
-Grunde sogar egal, ob die Verbindung verschlüsselt ist oder nicht -
-dann kann wirklich alles passieren.
-
-
-
-In der nächsten Woche findet die CeBIT statt, auf der ich einige
-Termine habe. Wenn ich es zeitlich schaffe, gibt es daher nächste
-Woche einen Bericht von der CeBIT.
-
-
-
-
-Carsten Eilers
-
-
-
-
-
-