Der Todesstoß für PPTP

PPTP ist ein viel genutzter Standard für sichere und verschlüsselte Internet-Nutzung. Doch das Projekt Cloudcracker verspicht, jeden PPTP-Zugang zu knacken -- für 200 US-Dollar und innerhalb eines Tages. Wir haben das mit einem echten Zugang ausprobiert.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 9 Min.

Das VPN bildet einen verschlüsselten Tunnel, der Lauschern am WLAN-Hotspot keine Chance lässt - eigentlich...

Firmen nutzen Virtual Private Networks (VPN) primär, um externen Mitarbeitern übers Internet sicheren Zugriff auf das Firmennetz zu gewähren. Oft sollen VPNs auch die Netzwerkverbindung von mobilen Geräten und Smartphones etwa an öffentlichen Hotspots absichern und dabei neugierige Schnüffler aussperren. Und egal ob Windows, Mac, Linux, Smartphone oder Tablet – alle unterstützen Microsofts Point to Point Tunneling Protocol (PPTP) von Haus aus; und weil es so einfach einzurichten ist, erfreut es sich nach wie vor großer Beliebtheit.

Dass es dabei um die Sicherheit nicht allzu gut bestellt ist, ist eigentlich bekannt. Trotzdem kam es für viele überraschend, als Moxie Marlinspike Ende Juli einen Dienst präsentierte, der das Geheimnis für Authentifizierung und Verschlüsselung innerhalb eines Tages knacken soll. Die Theorie liest sich plausibel und ziemlich erschreckend. Das eingesetzte Authentifizierungsverfahren MSCHAPv2 setzt auf das angestaubte DES und lässt sich demnach mit Spezial-Hardware einfach knacken. Konkret kann angeblich CloudCracker aus aufgezeichneten Netzwerk-Paketen den NT-Hash ermitteln, der die Basis für Authentifizierung und Verschlüsselung von PPTP und übrigens auch von WLANs mit WPA2 und EAP/MS-CHAPv2 bildet.

Aus dem NT-Hash bildet MS-CHAPv2 drei DES-Schlüssel, mit denen es die Challenge des Servers dreimal verschlüsselt, um die Response zu erstellen. Die grünen Blöcke gehen als Klartext über die Leitung.

(Bild: CloudCracker)

Da der Angreifer Challenge und Response belauschen kann, muss Cloudcracker also nur alle möglichen 256 DES-Schlüssel durchprobieren, um die richtigen zu finden und wieder zum NT-Hash zusammen zu setzen. Einem Einbruch ins Firmennetz durch die Hintertür VPN steht nicht mehr viel im Weg. Doch die Theorie ist grau, wir wollten das Ganze wirklich duchspielen und stießen bei unserem Selbstversuch auch prompt auf einige unerwartete Hürden.

Um es dem Cracker nicht unnötig leicht zu machen, erstellten wir einen Testzugang zu einem PPTP-Server, der mit einem richtig guten Passwort gesichert war. Das von einem Generator erzeugte 16-stellige Nao;hi2chie)toh1 sollte auch gehobenen Anforderungen an Passwortsicherheit genügen. Anschließend schnitten wir den PPTP-Anmeldevorgang eines iPhones in einem (verschlüsselten) WLAN mit. Dazu leitete das Tool arpspoof den kompletten Netzwerkverkehr des iPhones über einen Linux-Rechner um, der sich im gleichen Netz befand und die Pakete mit tcpdump in eine PCAP-Datei speicherte. Das könnte im Prinzip jedem ganz unbemerkt an einem WLAN-Hotspot widerfahren.

Ein kurzer Check belegte, dass wirklich der komplette Anmeldevorgang aufgezeichnet wurde:

$ tcpdump -n -r my-pptp-chap.cap
...
IP 193.99.XX.XX > 192.168.69.169: GREv1, call 45515, seq 5, ack 4, length 60: CHAP, Challenge (0x01), id 111,Value e5df... , Name pptpXY.heise.de
IP 192.168.69.169 > 193.99.XX.XX: GREv1, call 39936, seq 6, ack 6, length 80: CHAP, Response (0x02), id 111, Value d4528..., Name jutest
IP 193.99.XX.XX > 192.168.69.169: GREv1, call 45515, seq 7, ack 6, length 83: CHAP, Success (0x03), id 111, Msg S=6E9...406 M=Access granted

Aus dieser PCAP-Datei sollte eigentlich das Open-Source-Tool chapcrack die drei DES-verschlüsselten Hashes extrahieren und daraus ein Token für den CloudCracker erstellen. Doch das Python-Skript verweigerte zunächst den Dienst. Selbst mit der mitgelieferten Demo-Datei kamen nur Fehlermeldungen. Ein Bug-Report und einige Mails später gab es einen Fix, um die Unverträglichkeit mit der bei Ubuntu 10.04 LTS eingesetzten Python-Version zu kompensieren, aber leider – immer noch keine Hashes. Denn das Programm beendete sich nun ohne jegliche Ausgabe. Nach erneuten Bug-Reports lokalisierte Moxie einen Fehler in dem Modul "dpkt" und lieferte einen weiteren Patch, mit dem chapcrack dann schließlich auch tatsächlich aktiv wurde. Innerhalb weniger Sekunden spuckte das Skript die extrahierten Daten aus:

$ ./chapcrack.py parse -i ./my-pptp-chap.cap 
Got completed handshake [192.168.69.169 --> 193.99.XXX.YYY]
Cracking K3..............
User = jutest
C1 = 4de9d262a222e617
C2 = d5e0d1eb316886a6
C3 = 9a441fe1dc7001fe
P = 36b29bb9b0140fc0
K3 = d9c50000000000
CloudCracker Submission = $99$NrKbubAUD8BN6dJioiLmF9Xg0esxaIam2cU=

Das Knacken von MS-CHAPv2 ist nur eine der CloudCracker-Optionen.

Dabei wurde der mit Nullen aufgefüllte Schlüssel K3 sofort geknackt. Aus den Hashes der Challenge erzeugte das Python-Skript das Submission-Token, das ich dann auch an den CloudCracker verfütterte, um den Rest des NT-Hashes zu ermitteln.

Den Preis von $200 für das Durchprobieren der Schlüssel entrichtete ich per Kreditkarte, was über einen externen Zahlungsdienstleister reibungslos funktionierte. Allerdings stellte sich da ein weiteres Problem: Eine Rechnung war offenbar nicht vorgesehen; auch E-Mail-Nachfragen dazu stießen auf tauber Ohren. Nach der Eingabe der Kreditkartendaten versprach der Cloud-Dienst lediglich, sich via E-Mail wieder zu melden.

Knapp zwei Tage später erreichte mich dann auch eine E-Mail mit den "CloudCracker Results" und lieferte die zunächst wenig spektakulär wirkende Zeichenkette 0bb65a54df3cfee1e65da6c91c53d9c5

Knapp zwei Tage dauerte es, bis das Ergebnis kam.

Offenbar waren die Vorab-Schätzungen etwas optimistisch; der erfolgreiche Angriff hatte immerhin 135062 Sekunden -- also knapp 38 Stunden gebraucht.

Es führt übrigens kein praktikabler Weg von diesem Hash-Wert zurück zum ursprünglichen Passwort. Selbst bei den eigentlich als geknackt geltenden kryptografischen Hash-Funktionen wie MD4, MD5 oder SHA-1 gibt es keine Angriffe, die es ermöglichten, in endlicher Zeit einen passenden Datensatz zu einem vorgegebenen Hashwert wie diesem zu erstellen – also einen sogenannten Pre-Image-Angriff durchzuführen. Alle bekannten Angriffe beziehen sich auf Kollisionen. Also darauf, dass man zwei Datensätze einander so annähern kann, dass sie irgendwann den gleichen Hash-Wert ergeben – aber irgendeinen wohlgemerkt.

Doch das Passwort selbst ist laut Theorie ja auch gar nicht erforderlich. Das einzig relevante Geheimnis beim Aufbau einer Verbindung via MS-CHAPv2 ist demnach der NT-Hash, und den habe ich ja jetzt. Der Gegencheck mit nthash.py bestätigte, dass es sich tatsächlich um den korrekten MD4-Hash des oben abgedruckten PPTP-Passworts handelt.

Der naive Versuch, damit wie in der Dokumentation versprochen den aufgezeichneten PPTP-Verkehr zu dekodieren, scheiterte erneut: "Wrote 0 packets" meldete das Skript ohne weitere Begründung. Ein erneuter Eintrag im Bug-Tracking-System wartet derzeit noch auf einen Bearbeiter.

Als machte ich mich daran, den NT-Hash direkt zum Login in das Virtual Private Network zu nutzen. Nach einem "apt-get -b source pppd" fand sich der Quellcode des PPP-Daemon auf der Platte, der die MS-CHAPv2-Authentifizierung für PPTP abwickelt. Dort fand ich sehr schnell die Stelle, an der das Passwort gehasht wurde, unterband diesen nun unnötig gewordenen Vorgang durch ein paar beherzte Eingriffe in den Quell-Code und kopierte statt dessen den als Verbindungspasswort eingetragenen Hash-Wert direkt in den Puffer. Ein "make" lieferte eine gepatchte Version des pppd. Den folgenden Aufruf des manipulierten PPP-Daemons mit

./pppd debug call pptptest updetach pty "pptp 193.99.X.Y --nolaunchpppd"

beantwortete der Server dann auch prompt mit

CHAP Success id=0x95 "S=941C... M=Access granted"

Doch was war das?

MS-CHAPv2 mutual authentication failed.

Irgendwie klappte der Verbindungsaufbau offenbar doch nicht. Kurzes Nachdenken brachte des Rätsels Lösung: Der Server weist sich gegenüber dem Client mit einem Hash aus, den er über die Challenge und das PPTP-Passwort gebildet hat – und kommt dabei natürlich zu einem anderen Ergebnis als der Client, dem ich ja nur den NT-Hash des Passworts verfüttert hatte. Ein weiterer kleiner Hack, der die Server-Authentifizierung abschaltete, und ich war endlich drin:

local IP address 172.16.10.134
remote IP address 172.16.10.1

Der VPN-Zugang war erfolgreich geknackt; ich konnte ohne Einschränkung auf das Heise-LAN zugreifen.

Das alles war keine Hexerei; letztlich kostete es nur ein paar Tage Warten, ein wenig Bastelei, insgesamt drei Bug-Reports und 200 Dollar. Für eine echte Dienstleistung ist Moxies CloudCracker zwar noch reichlich ungeschliffen. Jemandem 200 Dollar von der Kreditkarte abzubuchen, ohne ihm dafür eine Rechnung auszustellen, zeigt, dass die Hacker eigentlich nicht wirklich mit Kunden rechnen.

Aber als Demo, die den Tod von PPTP und MSCHAPv2 besiegelt, ist CloudCracker ein voller Erfolg. Das erforderliche Knowhow ist vergleichsweise gering. Die größte Herausforderung dieses Tests dürfte jetzt sein, die 200 Dollar ohne Rechnung irgendwie durch das Controlling zu bekommen...

Wer noch PPTP einsetzt, sollte sich schleunigst Gedanken machen, wie er davon weg kommt. Alternativen sind L2TP/IPSec, IPSec mit IKEv2 oder OpenVPN. Ähnliches gilt Übrigens für Firmen-WLANs mit WPA2 und EAP via MSCHAPv2, die sich analog knacken lassen. Die verschlüsselte Variante PEAP packt das ganze in einen SSL-Tunnel, dessen Sicherheit davon abhängt, dass die Anwender nie ein gefälschtes Zertifikat akzeptieren. Bei Firmen, die dabei selbst signierte Zertifikate einsetzen, dürfte das allerdings schwer zu gewährleisten sein.

Siehe dazu auch:

(ju)