PEAP-MSCHAPv2: Warum es immer noch verbreitet ist, warum es riskant ist und wie man den Übergang schafft

Hallo und herzlich willkommen zu diesem technischen Briefing von Purple. Ich bin Ihr Moderator, und heute widmen wir uns einem Thema, das an der Schnittstelle von Netzwerkarchitektur, Sicherheits-Compliance und, offen gesagt, veralteten technischen Altlasten liegt. Wir sprechen über PEAP-MSCHAPv2. Konkret schauen wir uns an, warum dies immer noch die am weitesten verbreitete Authentifizierungsmethode im Enterprise-WiFi ist, warum sie in der heutigen Bedrohungslandschaft grundlegend riskant ist und – was am wichtigsten ist – wie Sie Ihr Unternehmen praktisch auf eine bessere Lösung umstellen können. Beginnen wir mit dem Kontext. Wenn Sie IT-Leiter oder Netzwerkarchitekt in einem Hotel, einer Einzelhandelskette oder einem großen öffentlichen Veranstaltungsort sind, ist die Wahrscheinlichkeit sehr hoch, dass sich Ihr Mitarbeiter-WiFi-Netzwerk – und vielleicht auch Ihre Unternehmensgeräte – über PEAP-MSCHAPv2 authentifizieren. Es ist seit fast zwei Jahrzehnten der Standard für WPA2-Enterprise-Netzwerke. Warum? Weil es unglaublich einfach bereitzustellen ist. Es lässt sich über einen RADIUS-Server direkt in das Active Directory einbinden, und die Benutzer geben einfach ihren standardmäßigen Windows-Benutzernamen und ihr Passwort ein. Keine Zertifikate, die verwaltet werden müssen, keine komplexe Public-Key-Infrastruktur, die aufgebaut werden muss. Es funktioniert einfach. Aber „einfach funktionieren“ reicht nicht mehr aus. Die Sicherheitsarchitektur, die PEAP-MSCHAPv2 zugrunde liegt, ist, um es unverblümt auszudrücken, veraltet. Werfen wir einen Blick auf die technischen Fakten. MSCHAPv2 basiert auf dem MD4-Hashing-Algorithmus und der DES-Verschlüsselung. Beide kryptografischen Standards wurden in den 1990er Jahren entwickelt und gelten seit über einem Jahrzehnt als schwach. Bereits 2012 demonstrierte der Forscher Moxie Marlinspike auf der Sicherheitskonferenz DEF CON, dass der MSCHAPv2-Handshake deterministisch geknackt werden kann. Er veröffentlichte ein Tool, das den Knackprozess auf das Knacken eines einzigen DES-Schlüssels reduzierte. Das bedeutet, dass ein Angreifer mit mäßiger Rechenleistung – oder Zugriff auf einen Cloud-Knackdienst – das Klartext-Active-Directory-Passwort eines Benutzers aus einem abgefangenen Handshake in wenigen Stunden, wenn nicht sogar Minuten, wiederherstellen kann. Wie fängt ein Angreifer diesen Handshake in der Praxis also tatsächlich ab? Dies bringt uns zum „Evil Twin“-Angriff. Stellen Sie sich ein Firmenbüro oder den Back-of-House-Bereich eines Hotels vor. Ein Angreifer betritt den Raum mit einem gefälschten Access Point – oft nicht größer als eine Wi-Fi Pineapple im Rucksack. Er konfiguriert diesen gefälschten AP so, dass er genau dieselbe SSID wie Ihr Unternehmensnetzwerk ausstrahlt, sagen wir „Staff-WiFi“. Er erhöht die Signalstärke, sodass die Geräte in der Nähe diesen natürlich gegenüber Ihren legitimen Access Points bevorzugen. Wenn sich der Laptop oder das Telefon eines Mitarbeiters zu verbinden versucht, fungiert der Rogue AP als Authentifikator und verweist auf einen gefälschten RADIUS-Server, der vom Angreifer kontrolliert wird. Das Gerät des Mitarbeiters initiiert den PEAP-Tunnel. Hier liegt nun der kritische Schwachpunkt: PEAP verlässt sich darauf, dass das Client-Gerät das digitale Zertifikat des Servers überprüft, um sicherzustellen, dass es mit dem echten RADIUS-Server des Unternehmens kommuniziert. In der überwiegenden Mehrheit der Implementierungen sind die Client-Geräte jedoch entweder falsch konfiguriert oder die Benutzer erhalten lediglich ein Pop-up mit der Frage "Vertrauen Sie diesem Zertifikat?" und klicken auf "Ja", nur um online zu gehen. Sobald dieses gefälschte Zertifikat akzeptiert wird, sendet das Gerät die MSCHAPv2-Challenge-Response durch den Tunnel. Der Angreifer fängt diese ab, zieht ab und knackt den Hash offline. Damit verfügt er über gültige Active Directory-Anmeldedaten, mit denen er sich bei Ihrem VPN, Ihrem E-Mail-System oder jedem anderen Unternehmensdienst anmelden kann. Dies ist kein theoretisches Risiko. Es ist ein Standardverfahren für Penetrationstester und böswillige Akteure gleichermaßen. Und wenn Sie Compliance-Frameworks wie PCI DSS oder GDPR unterliegen, ist die Nutzung eines kompromittierten Authentifizierungsprotokolls ein erhebliches Haftungsrisiko. Wenn die Risiken also so hoch sind, warum sind wir nicht alle schon einen Schritt weitergegangen? Die Antwort liegt meist in einer Mischung aus gefühlter Komplexität und veralteter Hardware. Der Abschied von PEAP bedeutet den Übergang zur zertifikatsbasierten Authentifizierung, genauer gesagt zu EAP-TLS. EAP-TLS ist der Goldstandard. Es erfordert, dass sowohl der Server als auch das Client-Gerät ein gültiges digitales Zertifikat vorlegen. Es werden keine Passwörter übertragen, weder gehasht noch auf andere Weise. Es ist völlig immun gegen Offline-Wörterbuchangriffe und äußerst resistent gegen Evil-Twin-Angriffe, da der Client jeden gefälschten RADIUS-Server, der kein von Ihrer vertrauenswürdigen Zertifizierungsstelle signiertes Zertifikat besitzt, geräuschlos abweist. Die Bereitstellung von EAP-TLS bedeutet jedoch, dass Sie eine Public-Key-Infrastruktur (PKI) benötigen. Sie benötigen eine Möglichkeit, Zertifikate zu generieren und diese sicher auf jedem Laptop, Telefon und Tablet in Ihrer Flotte zu verteilen. Vor fünf Jahren war der Aufbau einer Microsoft Active Directory Certificate Services-Infrastruktur noch ein entmutigendes, teures Projekt. Heute hat sich die Landschaft jedoch verändert. Der Implementierungspfad ist viel klarer. Wenn Sie eine Migration planen, empfehlen wir unseren Kunden bei Purple den folgenden pragmatischen Ansatz. Erstens müssen Sie keinen harten Schnitt machen. Moderne RADIUS-Server – ob Cisco ISE, Aruba ClearPass oder Cloud-native Lösungen – ermöglichen es Ihnen, PEAP-MSCHAPv2 und EAP-TLS gleichzeitig auf derselben SSID auszuführen. Schritt eins ist die Bereitstellung Ihrer PKI. Sie müssen diese heute nicht mehr zwingend On-Premise aufbauen. Cloud-PKI-Lösungen lassen sich direkt in Ihren Identity Provider – wie Entra ID oder Google Workspace – und Ihre Mobile Device Management-Plattformen wie Intune oder Jamf integrieren. Schritt zwei besteht darin, Ihr MDM zu nutzen, um Client-Zertifikate geräuschlos auf Ihre verwalteten Geräte zu übertragen. Sie können das WiFi-Profil über das MDM so konfigurieren, dass EAP-TLS bevorzugt wird. Das bedeutet, dass Ihre Unternehmens-Laptops automatisch und ohne Benutzerinteraktion auf die sichere, zertifikatsbasierte Methode umsteigen. Schritt drei ist die Übergangsphase. Sie überwachen Ihre RADIUS-Protokolle. Sie werden sehen, dass sich Ihre verwalteten Geräte über EAP-TLS authentifizieren, während nicht verwaltete oder ältere Geräte weiterhin PEAP verwenden. Dies bringt uns zu der typischen Stolperfalle: Legacy-Geräte. Was machen Sie mit den zehn Jahre alten Barcodescannern in Ihrem Lager oder den älteren Point-of-Sale-Terminals, die EAP-TLS schlichtweg nicht unterstützen? Die Lösung ist Segmentierung. Sie sollten niemals die Sicherheit Ihres primären Mitarbeiternetzwerks herabsetzen, um dem kleinsten gemeinsamen Nenner gerecht zu werden. Isolieren Sie diese Legacy-Geräte stattdessen in einem dedizierten VLAN. Sie können eine MAC-basierte Authentifizierung in Kombination mit strengen Netzwerkzugriffskontrollen verwenden, um sicherzustellen, dass diese Geräte nur mit den spezifischen internen Servern kommunizieren können, die sie benötigen, und mit absolut nichts anderem. Sobald Ihre verwaltete Flotte vollständig auf EAP-TLS migriert ist, können Sie PEAP-MSCHAPv2 auf Ihrer Haupt-Unternehmens-SSID endgültig deaktivieren und das Sicherheitsrisiko für immer schließen. Lassen Sie uns eine kurze Fragerunde basierend auf den häufigsten Fragen von IT-Leitern durchgehen. Frage eins: "Löst WPA3 das PEAP-MSCHAPv2-Problem?" Antwort: Nein. WPA3 verbessert die Verschlüsselung über die Luft, aber die zugrunde liegende EAP-Authentifizierungsmethode bleibt dieselbe. Wenn Sie WPA3-Enterprise mit PEAP-MSCHAPv2 verwenden, sind Sie immer noch anfällig für den Diebstahl von Anmeldedaten über einen Evil Twin, wenn der Client das Serverzertifikat nicht streng validiert. Frage zwei: "Was ist mit EAP-TTLS?" Antwort: EAP-TTLS ist besser als PEAP, da es die Authentifizierung tunnelt und oft PAP anstelle von MSCHAPv2 verwendet, wodurch die spezifischen kryptografischen Schwachstellen von MSCHAPv2 vermieden werden. Es basiert jedoch immer noch auf Passwörtern und ist weiterhin anfällig, wenn das Serverzertifikat nicht validiert wird. Es ist ein Zwischenschritt, aber EAP-TLS sollte das Endziel sein. Frage drei: "Wie wirkt sich das auf unser Purple Gäste-WiFi aus?" Antwort: Es hat keine direkten Auswirkungen. Gäste-WiFi nutzt in der Regel offene Netzwerke mit Captive Portals oder WPA2/3-Personal, die von Ihrer 802.1X-Unternehmensauthentifizierung getrennt sind. Die Absicherung Ihres Back-of-House-Netzwerks ist jedoch von entscheidender Bedeutung, um die Infrastruktur zu schützen, die alle Ihre Betriebsabläufe vor Ort unterstützt, einschließlich Ihrer Gästeservices und Analyseplattformen. Zusammenfassend lässt sich sagen: PEAP-MSCHAPv2 hat uns gute Dienste geleistet, aber seine Zeit ist vorbei. Die kryptografischen Schwachstellen sind öffentlich und die Angriffswerkzeuge automatisiert. Die Migration zu EAP-TLS ist kein experimentelles Projekt mehr; sie ist ein standardmäßiges, realisierbares Upgrade, das durch moderne MDM- und Cloud-PKI-Lösungen erheblich erleichtert wird. Das Risiko, untätig zu bleiben – ein kompromittiertes Active Directory-Passwort, das zu einer weitreichenden Netzwerkverletzung führt –, überwiegt den betrieblichen Aufwand der Migration bei Weitem. Beginnen Sie noch heute mit einer Überprüfung Ihrer RADIUS-Protokolle, identifizieren Sie Ihre Legacy-Geräte und planen Sie Ihren Übergang zur zertifikatsbasierten Authentifizierung. Vielen Dank, dass Sie sich dieses technische Briefing von Purple angehört haben. Ausführlichere Bereitstellungshandbücher und Architekturdiagramme finden Sie im vollständigen technischen Referenzhandbuch, das diesen Podcast begleitet.