Netzsicherheit 4: Layer 2-Sicherheit – Das Point-to-PointProtokoll und seine Erweiterungen Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Das TCP/IP-Schichtenmodell Anwendungsschicht (FTP, HTTP, SMTP, ...) Transportschicht (TCP, UDP) Internetschicht (IP) Netzwerkschicht (z.B. Ethernet, TokenRing, ...) PPP (PPTP, L2TP, L2F) Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Gliederung Layer 2: Ethernet, ... PPP: Point-to-Point protocol PAP und CHAP AAA: Authentication, Autorisation and Accounting (RADIUS, SecureID) PPP-Extensions: L2F, PPTP, L2TP Der PPTP-Angriff von Schneier und Mudge Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Layer 2: Ethernet & Co Übertragungsprotokolle für Teilnetze mit gleicher Technologie Ethernet: ursprünglich Broadcast-Netz PPP: Punkt-zu-Punkt-Verbindung WLAN: Broadcast-Netz DVB: Broadcast-Netz mit Fehlerkorrektur Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Point-to-Point Protocol (PPP) RFC 1661: The Point to Point Protocol (PPP). W. Simpson, Juy 1994 Benötigt: Voll-Duplex, simultane, bidirektionale Verbindung zwischen zwei Hosts (z.B. ISDN) Encapsulation: Verpackt beliebige Protokolle Link Control Protocol: Aushandlung von PPP-Optionen, auch Authentisierung Network Control Protocol: Parameter für höhere Protokolle, z.B. für die Zuweisung von IP-Adressen Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Point-to-Point Protocol (2) Ablauf eines PPP-Verbindungsaufbaus +------+ +-----------+ +--------------+ | | UP | | OPENED | | SUCCESS/NONE | Dead |------->| Establish |---------->| Authenticate |--+ | | | | | | | +------+ +-----------+ +--------------+ | ^ | | | | FAIL | FAIL | | +<--------------+ +----------+ | | | | | +-----------+ | +---------+ | | DOWN | | | CLOSING | | | +------------| Terminate |<---+<----------| Network |<-+ | | | | +-----------+ +---------+ Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Point-to-Point Protocol (4) Ablauf eines PPP-Verbindungsaufbaus 1. PPP-Pakete mit protocol=c021 LCP 2. PPP-Pakete mit protocol=c023 PAP/c223 CHAP 3. PPP-Pakete mit protocol=8*** NCP 4. PPP-Pakete mit protocol=???? IP Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit RFC 1334: PPP Authentication Protocols Password Authentication Protocol (PAP) Voraussetzung: PPP-Verbindung steht Client sendet wiederholt (im Klartext) das Paar (ID, Passwort) Network Access Server (NAS) überprüft das Passwort gegen den zur ID gespeicherten Wert (besser: den Hashwert des Passworts) Überprüfung erfolgreich: ACK Überprüfung nicht erfolgreich: NACK Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Wörterbuch-Attacken commonpasswords.txt http://www.openwall.com/wordlists/ • ca. 40 Millionen Passwörter • entspricht einer Komplexität von 225 - 226 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Wörterbuch-Attacken Annahme: Passwörter werden gehasht, oder immer mit dem gleichen Schlüssel verschlüsselt. Angreifer bildet den Hashwert aller Worte in einem Wörterbuch. Die Paare (Wort, Hashwert) werden nach Hashwert sortiert. Ein gehashtes Passwort kann in dieser Liste leicht gefunden werden. Funktioniert, weil nur wenige Zeichenkombinationen als Passwörter verwendet werden (kleines Wörterbuch) Gegenmaßnahme: Für jeden Benutzer ein öffentlich bekanntes „Salt“ einführen. Das hat zur Konsequenz, dass für jeden Benutzer ein eigenes Wörterbuch angelegt werden muss. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit RFC 1994: PPP Authentication Protocols (2) Challenge Handshake Authentication Protocol (CHAP) Voraussetzung: PPP-Verbindung steht Network Access Server (NAS) sendet „challenge“-Nachricht Client antwortet mit res = hash(secret, challenge) NAS überprüft, ob res = hash(secret, challenge) ist Überprüfung erfolgreich: ACK Überprüfung nicht erfolgreich: NACK Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit PPP-Erweiterungen Viele neue Vorschläge zu PPP findet man unter http://ietf.org/html.charters/pppext-charter.html The PPP Encryption Control Protocol (ECP) (RFC 1968) PPP Extensible Authentication Protocol (EAP) (RFC 2284) The PPP DES Encryption Protocol, Version 2 (DESE-bis) (RFC 2419) The PPP Triple-DES Encryption Protocol (3DESE) (RFC 2420) Microsoft PPP CHAP Extensions (RFC 2433) PPP EAP TLS Authentication Protocol (RFC 2716) Microsoft PPP CHAP Extensions, Version 2 (RFC 2759) Microsoft Point-To-Point Encryption (MPPE) Protocol (RFC 3078) EAP-Protokolle werden auch im Bereich WLAN intensiv untersucht Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit AAA: Authentication, Authorization and Accounting AAA wird vor allem von Internet Service Providern (ISP, z.B. T-Online) benötigt, um gegenüber Kunden abrechnen zu können. Architektur: RADIUS (RFC 2058) AAA-Protokolle: PAP (meistens) CHAP SecureID Kerberos Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Remote Authentication Dial-In User Service (RADIUS) RFC 2058: RADIUS (Lucent Technologies) Client-Server-Lösung zur Authentisierung von Kunden ID, Passwort Kunde OK, Dienst EK(ID, Passwort) RADIUSNAS: RADIUS- OK, Konfiguration Server Client Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit SecureID Produktlinie von RSA Inc. Alle 10 Sekunden wird im Client-Token und im Server eine neue Zufallszahl generiert Server überprüft, ob eine gesendete Zufallszahl im zulässigen Zeitfenster liegt. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Kerberos (MIT) Kerberos wurde 1987 am MIT entwickelt Ta, Ts: Timestamps L: Lifetime Kxy: Gemeinsamer Schlüssel von X und Y S 1: A, B 2: {Ts, L, Kab, B,{Ts, L, Kab, A}Kbs} Kas A 3:{Ts, L, Kab, A}Kbs , {A,Ta}Kab B 4: {Ta+1} Kab Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit PPP-Verlängerung Problem: Wie wähle ich mich ins Intranet meiner Firma ein? CRYPTO 2011 Santa Barbara PPP-NAS meine Firma 1. Per Mobilfunk (am bequemsten) 2. Per Festnetz über das Hotel 3. Über das Internet mit lokaler Einwahl (am günstigsten) Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit PPP-Verlängerung PPP bietet heute die besten AAA-Features Viele Außendienst-Mitarbeiter wählen sich über eine direkte Modem-Verbindung und PPP ins Firmennetz ein Idee zur Kostensenkung: Einwahl der Mitarbeiter lokal bei einem ISP Verlängere PPP über ein IP Backbone-Netz Authentifizierung am NAS der Firma Problem: Verschlüsselung! PAP über PPP übers Internet ist nicht sicher. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit PPP-Verlängerung (2) Client-initiierter Tunnel 1. Client stellt IP-Verbindung zum NAS der Firma her 2. Client sendet PPP-Pakete über diese Verbindung Remote User IP2 ISP NAS PPP GRE/UDP IP1 PPP ISDN IP2 Internet PPP GRE/UDP IP1 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit HomeNAS IP2 Intranet PPP-Verlängerung (3) NAS-initiierter Tunnel 1. Client stellt PPP-Verbindung zum NAS des ISP her 2. NAS sendet PPP-Pakete über IP-Verbindung an den NAS der Firma Remote User IP2 PPP ISDN ISP NAS IP2 Internet PPP GRE/UDP IP1 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit HomeNAS IP2 Intranet Layer 2: PPTP, NCP Einbettung in das TCP/IP-Schichtenmodell: PPTP verlängert PPP mit Hilfe von GRE (Generic Routing Encapsulation) PPTP-Kontrollnachrichten mit TCP Transportnetzwerk: IP Verschlüsselung und Authentikation auf PPP-Ebene („link encryption“): Optionales Schlüsselmanagement: Microsoft EAP-TLS Sicherheitsprobleme bei PPTP v1 (Mudge, Schneier, 1998) IP Header GREHeader PPPHeader PPP Payload (verschlüsselt) Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Layer 2: L2TP „Best of“ PPTP (Microsoft) und L2F (Cisco) Einbettung in das TCP/IP-Schichtenmodell: Verlängert PPP-Tunnel mit UDP (auch Kontrollnachrichten) Transportnetzwerk: IP (fertig), X.25, Frame Relay, ATM (geplant) Authentikation auf PPP-Ebene (PAP, CHAP, ...) Verschlüsselung mit IPSec ESP http://ietf.org/html.charters/l2tpext-charter.html IP Header ESP Header UDP Header L2TPHeader PPPHeader PPP Payload Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Padding ESP-Auth Kryptoanalyse von MS-PPTPv1 B. Schneier and Mudge, "Cryptanalysis of Microsoft's Point-to-Point Tunneling Protocol (PPTP)," Proceedings of the 5th ACM Conference on Communications and Computer Security, ACM Press, pp. 132-141. http://www.counterpane.com/pptp.html. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Kryptoanalyse von MS-PPTPv1(2) Authentisierung/Verschlüsselung bei MS-PPTPv1: 1. 2. 3. Passwort im Klartext senden/keine Verschlüsselung möglich Hashwert des Passworts senden/ keine Verschlüsselung möglich MS-CHAP: Hashwert des Passworts wird zum Verschlüsseln der Challenge benutzt/ Verschlüsselung möglich Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Kryptoanalyse von MS-PPTPv1(3) Berechnung von zwei Hashwerten aus dem Passwort: Windows NT Hash (sicherere Variante, wird hier nicht betrachtet). LAN Manager Hash: 1. Wandle das Passwort in einen 14-Byte-String um, entweder durch Kürzen längerer Passworte, oder durch Anfügen von Nullen an kürzere Passworte 2. Wandle alle Klein- in Grossbuchstaben um. Zahlen und andere Zeichen werden nicht verändert. 3. Teile den String in zwei 7-Byte-Hälften. 4. Verwende jede der beiden Hälften als 56-Bit DES-Schlüssel und verschlüssele damit jeweils eine feste Konstante. 5. Füge die beiden Ergebnisse zu einem 16-Byte-Wert zusammen. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Kryptoanalyse (4) MS-CHAP: Berechnung des LMH Beispiel ! Passwort Umwandlung in 14-Byte-String: Abschneiden nach Byte 14 oder Anfügen von Nullen Umwandlung Klein- in Großbuchstaben Splitten in zwei 7-Byte-Hälften KONSTANTE DES HASHWER1 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit DES HASHWER2 Passwort Kryptoanalyse (4) MS-CHAP: Berechnung des LMH Umwandlung in 14-Byte-String: Abschneiden nach Byte 14 oder Anfügen von Nullen Passwort000000 Umwandlung Klein- in Großbuchstaben Splitten in zwei 7-Byte-Hälften KONSTANTE DES HASHWER1 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit DES HASHWER2 Passwort Kryptoanalyse (4) MS-CHAP: Berechnung des LMH Umwandlung in 14-Byte-String: Abschneiden nach Byte 14 oder Anfügen von Nullen Passwort000000 Umwandlung Klein- in Großbuchstaben PASSWORT000000 Splitten in zwei 7-Byte-Hälften KONSTANTE DES HASHWER1 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit DES HASHWER2 Passwort Kryptoanalyse (4) MS-CHAP: Berechnung des LMH Umwandlung in 14-Byte-String: Abschneiden nach Byte 14 oder Anfügen von Nullen Passwort000000 Umwandlung Klein- in Großbuchstaben PASSWORT000000 Splitten in zwei 7-Byte-Hälften PASSWOR T000000 KONSTANTE DES HASHWER1 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit DES HASHWER2 Kryptoanalyse von MS-PPTPv1(5) Angriff auf Authentisierungs-Variante 2: Berechnung des Passworts aus den beiden Hashwerten. Windows NT Hash und LAN Manager Hash werden immer beide gesendet Greife zuerst den LAN Manager Hash an: Wörterbuch-Attacke gegen die beiden 8-Byte Hälften des Hashs. Längere Passwörter sind nicht sicherer als 7-Byte Passwörter Größe des benötigten Wörterbuchs wird durch die Umwandlung von Klein- in Grossbuchstaben weiter reduziert Es gibt kein Salt, also kann das gleiche Wörterbuch für alle Benutzer verwendet werden Aus dem so gefundenen Passwort kann man das Originalpasswort durch Variation der Groß-Kleinschreibung und Anwendung des Windows NT Hash berechnen. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Passwort Passwort Kryptoanalyse (4) Umwandlung in 14-Byte-String: Abschneiden nach Byte 14 oder Anfügen von Nullen Umwandlung in 14-Byte-String: Abschneiden nach Byte 14 oder Anfügen von Nullen MS-CHAP: Berechnung Passwort000000 des LMH Passwort000000 Umwandlung Klein- in Großbuchstaben Umwandlung Klein- in Großbuchstaben PASSWORT000000 PASSWORT000000 Splitten in zwei 7-Byte-Hälften PASSWOR Splitten in zwei 7-Byte-Hälften T000000 PASSWOR T000000 KONSTANTE DES DES HASHWER1 HASHWER2 KONSTANTE DES DES HASHWER1 HASHWER2 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Kryptoanalyse von MS-PPTPv1(7) Berechnung der Response in MS-CHAP: Server sendet 8 Byte (=64 Bit) Challenge Client verschlüsselt Challenge mit LAN Manager Hash: 1. Füge 5 Null-Bytes an den LMH an, um 21 Bytes zu erhalten. 2. Splitte die 21 Byte in drei DES-Schlüssel, und verschlüssele die Challenge mit jedem dieser Schlüssel separat unter DES. 3. Sende die Ergebnisse als RES1, RES2, RES3 an den Server zurück. Client verfährt analog mit dem WNT-Hash; das Ergebnis sei RES4, RES5, RES6. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Kryptoanalyse von MS-PPTPv1(8) MS-CHAP: Berechnung der Response Passwort LMH-Funktion WNTH-Funktion LMH-Wert||00000 WNTH-Wert||00000 Challenge DES DES DES RES1 RES2 RES3 DES DES DES RES4 RES5 RES6 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Kryptoanalyse von MS-PPTPv1(9) MS-CHAP: Berechnung des Passworts P0,...,P13 LMH-Funktion WNTH-Funktion H0,...,H15||00000 WNTH-Wert||00000 Challenge DES DES DES R0 ... R23 DES DES DES RES4 RES5 RES6 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Kryptoanalyse von MS-PPTPv1(9) MS-CHAP: Berechnung des Passworts P0,...,P13 LMH-Funktion WNTH-Funktion H0,...,H15||00000 WNTH-Wert||00000 Challenge DES DES DES R0 ... R23 DES DES DES RES4 RES5 RES6 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Kryptoanalyse von MS-PPTPv1(10) MS-CHAP: Berechnung des Passworts 1. Teste alle möglichen Werte (216) für H14 und H15. Die richtigen Werte sind gefunden, wenn die Verschlüsselung der Challenge mit DES und dem Schlüssel H14H1500000 den Wert R16…R23 ergibt. H0H1H2H3H4H5H6∣H7H8H9H10H11H12H13∣H14H1500000 Challenge DES R0R1...R6R7 DES DES R8R9...R14R15 R16R17...R22R23 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Kryptoanalyse von MS-PPTPv1(11) 2. Teste alle wahrscheinlichen Möglichkeiten (die 7 letzten Byte von möglichen Passwörtern, ggf. mit vielen Nullen) für P7, …, P13. Die meisten falschen Werte können aussortiert werden, indem man den LM-Hash von P7, …, P13 bildet und überprüft, ob die letzten beiden Bytes gleich H14 und H15 sind. P0P1P2P3P4P5P6 ∣ P7P8P9P10P11P12P13 LMH-Funktion aus geeignetem Wörterbuch H0H1H2H3H4H5H6H7 ∣H8H9H10H11H12H13H14H15 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Kryptoanalyse von MS-PPTPv1(12) 3. Teste die Kandidaten P7, …, P13 wie folgt Berechne für die Kandidaten P7, …, P13 die Werte H8, …, H13. (H14 und H15 sind bereits bekannt.) P0P1P2P3P4P5P6 ∣ P7P8P9P10P11P12P13 LMH-Funktion aus geeignetem Wörterbuch H0H1H2H3H4H5H6H7 ∣H8H9H10H11H12H13H14H15 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Kryptoanalyse von MS-PPTPv1(13) Für jeden der 28 möglichen Werte von H7, verschlüssele die Challenge mit H7H8…H13. Wenn das Ergebnis gleich R8…R15 ist, so sind H7 und damit auch P7, …, P13 mit an Sicherheit grenzender Wahrscheinlichkeit die korrekten Werte. Liefert kein möglicher Wert für H7 das gewünschte Resultat, so war der Kandidat falsch. H0H1H2H3H4H5H6∣H7H8H9H10H11H12H13∣H14H1500000 Challenge DES R0R1...R6R7 DES DES R8R9...R14R15 R16R17...R22R23 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Kryptoanalyse von MS-PPTPv1(14) 4. 5. Wähle aus dem Wörterbuch für die linke Hälfte des Passworts die Kandidaten P0 … P6 aus, die den bekannten Wert H7 liefern. Teste diese Kandidaten dahingehend, ob der Schlüssel H0H1H2H3H4H5H6 die Challenge zu R0 … R7 verschlüsselt . P0P1P2P3P4P5P6 ∣ P7P8P9P10P11P12P13 LMH-Funktion aus geeignetem Wörterbuch H0H1H2H3H4H5H6H7 ∣H8H9H10H11H12H13H14H15 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Kryptoanalyse von MS-PPTPv1(15) Alternative zu 4. und 5. Wenn P7, …, P13 bekannt sind, so kann man P0, …, P6 durch eine Wörterbuchattacke ermitteln, indem man zu jedem möglichen Wert die LMH-Response berechnet und mit dem tatsächlichen Wert vergleicht. Da kein Salt verwendet wird, kann dieses Wörterbuch für alle PPTPClients verwendet werden. Der beschriebene Angriff wurde im Tool L0phtcrack implementiert. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit MS-CHAP v2 Sicherheitsupdate als Antwort auf Mudge/Schneier LMN-Hash wird nicht mehr verwendet; NT-Hash=MD4(PW) Zusätzlich: Server authentifiziert sich gegenüber dem Client Fazit Schneier (http://www.schneier.com/paper-pptpv2.html): „Microsoft has improved PPTP to correct the major security weaknesses described in [SM98]. However, the fundamental weakness of the authentication and encryption protocol is that it is only as secure as the password chosen by the user. As computers get faster and distributed attacks against password files become more feasible, …“ Deshalb glaubten einige Firmen, dass MS-CHAP v2 bei Wahl starker Passwörter sicher sei (z.B. riseup.net mit 21 zufällig gewählten Zeichen aus einem Alphabet der Größe 96, ungefähr ein 138-BitSchlüssel). https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/ zeigt, dass die Komplexität maximal bei 256 liegt Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit MS-CHAP v2 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit https://www.cloudcracker.com/blog/2012/07 /29/cracking-ms-chap-v2/ MS-CHAP v2 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit https://www.cloudcracker.com/blog/2012/07 /29/cracking-ms-chap-v2/ MS-CHAP v2 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit https://www.cloudcracker.com/blog/2012/07 /29/cracking-ms-chap-v2/ MS-CHAP v2 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit https://www.cloudcracker.com/blog/2012/07 /29/cracking-ms-chap-v2/ MS-CHAP v2 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit https://www.cloudcracker.com/blog/2012/07 /29/cracking-ms-chap-v2/ MS-CHAP v2 Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit https://www.cloudcracker.com/blog/2012/07 /29/cracking-ms-chap-v2/ MS-CHAP v2 DES-56 kann mit Tools wie COPACOBANA (LS Paar) oder http://picocomputing.com/ innerhalb von einem Tag geknackt werden. Wird als Service für 200 $ angeboten (nur legale Anwendungen). MS-CHAP v2 wird in PPTP VPNs (auch Piratebay) und WPA2 Enterprise-Umgebungen eingesetzt, und sollte ab sofort nicht mehr genutzt werden: „Microsoft ist bekannt, dass im Internet ausführlicher Angreifercode bezüglich bekannter Schwachstellen im Challenge Handshake Authentication-Protokoll Version 2 (MS-CHAP v2) veröffentlicht wurde. Das MS-CHAP v2-Protokoll wird großflächig als Authentifizierungsmethode in Point-to-Point Tunneling-Protokoll-(PPTP-) basierten VPNs verwendet. Soweit Microsoft bekannt, ist es noch zu keinen Angriffen unter Ausnutzung dieses Angreifercodes gekommen, und wir verfügen zurzeit über keine Meldungen über etwaige Auswirkungen auf unsere Kunden. Microsoft beobachtet die Lage jedoch sehr genau, um seine Kunden auf dem Laufenden zu halten und ggf. entsprechende Anleitungen anzubieten.“ Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit