Hier bitte den Titel des Beitrags eingeben

Werbung
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
Zugehörige Unterlagen
Herunterladen