Dipl.-Inform. Carsten Eilers

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:

1. Sie geben im Browser https://www.ihre-bank.example ein.
2. Ihr Browser baut eine Verbindung zum Webserver www.ihre-bank.example auf.
3. Der Webserver sendet sein Zertifikat mit seinem öffentlichen Schlüssel an Ihren Browser.
4. 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.
5. 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.
6. Der Sitzungsschlüssel wird mit dem öffentlichen Schlüssel des Webservers verschlüsselt und an den Webserver übertragen.
7. Der Webserver entschlüsselt den Sitzungsschlüssel mit seinem privaten Schlüssel.
8. 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.
9. Der Webserver baut seine Startseite auf, verschlüsselt sie mit dem Sitzungsschlüssel und sendet sie an den Browser.
10. Der Browser entschlüsselt die verschlüsselte Startseite und stellt sie dar.
11. 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.

1. Sie geben im Browser https://www.ihre-bank.example ein
2. Ihr Browser baut eine Verbindung zum Webserver www.ihre-bank.example auf.
3. 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.
4. 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:

1. Sie geben im Browser https://www.ihre-bank.example ein
2. Ihr Browser baut eine Verbindung zum Webserver www.ihre-bank.example auf.
3. 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.
4. 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.
5. Ihr Browser tauscht mit dem DLP-System, den er für den Bank-Server hält, einen Sitzungsschlüssel aus.
6. 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.
7. 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).
8. 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!
9. Der Browser entschlüsselt die verschlüsselte Startseite und stellt sie dar.
10. 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:

1. Sie geben im Browser https://www.ihre-bank.example ein
2. Ihr Browser baut eine Verbindung zum Webserver www.ihre-bank.example auf.
3. 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.
4. 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.
5. Ihr Browser tauscht mit dem MitM einen Sitzungsschlüssel aus.
6. 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.
7. 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).
8. 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!
9. Der Browser entschlüsselt die verschlüsselte Startseite und stellt sie dar.
10. 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