In den offenen Paketen IWD (Intel inet Wireless Daemon) und wpa_supplicant, die verwendet werden, um die Verbindung von Client-Linux-Systemen zu drahtlosen Netzwerken zu organisieren, wurden Schwachstellen entdeckt, die zur Umgehung von Authentifizierungsmechanismen f\u00fchren: <\/p>\n
Die Schwachstelle wird durch fehlende \u00dcberpr\u00fcfung der Reihenfolge aller Schritte bei der vierstufigen Aushandlung des Kommunikationskanals verursacht, die beim ersten Anschluss an ein sicheres drahtloses Netzwerk verwendet wird. Da IWD Nachrichten f\u00fcr alle Aushandlungsphasen akzeptiert, ohne zu \u00fcberpr\u00fcfen, ob die vorherige Phase erfolgreich war, kann ein Angreifer, ohne die Nachricht der zweiten Phase zu senden, direkt die Nachricht der vierten Phase senden und Zugriff auf das Netzwerk erhalten, w\u00e4hrend er die Phase \u00fcberspringt, in der die Authentifizierung \u00fcberpr\u00fcft wird. <\/p>\n
Dabei versucht IWD, den MIC (Message Integrity Code) f\u00fcr die empfangene Nachricht der vierten Phase zu verifizieren. Da die Nachricht der zweiten Phase mit Authentifizierungsparametern nicht empfangen wurde, wird bei der Verarbeitung der Nachricht der vierten Phase der PTK (Pairwise Transient Key) auf null gesetzt. Dementsprechend kann der Angreifer den MIC unter Verwendung des nullen PTK berechnen, und dieser Pr\u00fcfcode wird von IWD als korrekt akzeptiert. Nach Abschluss einer solchen unvollst\u00e4ndigen Aushandlung des Anschlusses erh\u00e4lt der Angreifer vollst\u00e4ndigen Zugriff auf das drahtlose Netzwerk, da der Access Point die von ihm gesendeten Frames akzeptiert, die mit dem nullen PTK-Schl\u00fcssel verschl\u00fcsselt sind. <\/p>\n
Aufgrund eines Fehlers in der Implementierung des PEAP-Protokolls (Protected Extensible Authentication Protocol) kann ein Angreifer die zweite Authentifizierungsstufe beim Anschluss eines falsch konfigurierten Endger\u00e4ts eines Nutzers umgehen. Das Umgehen der zweiten Authentifizierungsstufe erm\u00f6glicht es dem Angreifer, ein betr\u00fcgerisches Klon einer vertrauensw\u00fcrdigen Wi-Fi-Netzwerk zu erstellen und den Benutzer ohne Passwort\u00fcberpr\u00fcfung mit einem gef\u00e4lschten Netzwerk zu verbinden. <\/p>\n
Um einen Angriff erfolgreich durchzuf\u00fchren, muss auf der Benutzerseite die \u00dcberpr\u00fcfung im wpa_supplicant deaktiviert sein. TLS-Zertifikat<\/a> des Servers, und der Angreifer muss die Identifikation des drahtlosen Netzwerks (SSID, Service Set Identifier) kennen. Dabei muss der Angreifer sich in Reichweite des drahtlosen Adapters des Opfers, aber au\u00dferhalb der Reichweite des Access Points des geklonten drahtlosen Netzwerks befinden. Ein Angriff ist m\u00f6glich auf Netzwerke mit WPA2-Enterprise oder WPA3-Enterprise, in denen das PEAP-Protokoll verwendet wird. <\/p>\n Die Entwickler von wpa_supplicant haben erkl\u00e4rt, dass sie das Problem nicht als Sicherheitsanf\u00e4lligkeit betrachten, da es nur in schlecht konfigurierten drahtlosen Netzwerken auftritt, in denen EAP-Authentifizierung zusammen mit dem PEAP-Protokoll (EAP-TTLS) ohne \u00dcberpr\u00fcfung des TLS-Zertifikats verwendet wird. Server<\/a>. Konfigurationen ohne Zertifikats\u00fcberpr\u00fcfung bieten keinen Schutz vor aktiven Angriffen. Die Entdecker der Sicherheitsanf\u00e4lligkeit behaupten, dass solche unsachgem\u00e4\u00dfen Konfigurationen typisch und weit verbreitet sind, was viele Verbraucherger\u00e4te auf Linux-, Android- und Chrome OS-Basis, die wpa_supplicant verwenden, gef\u00e4hrdet. <\/p>\n Um das Problem im wpa_supplicant zu beheben, wurde ein Patch ver\u00f6ffentlicht, der einen obligatorischen Modus f\u00fcr die zweite Authentifizierungsstufe hinzuf\u00fcgt, zus\u00e4tzlich zur \u00dcberpr\u00fcfung des TLS-Zertifikats. Laut den Entwicklern ist die vorgeschlagene \u00c4nderung jedoch nur eine Umgehung, die das Durchf\u00fchren von Angriffen bei Verwendung manueller Authentifizierung erschwert, aber nutzlos ist bei Verwendung solcher Optionen wie EAP-GTC. Um das Problem tats\u00e4chlich zu l\u00f6sen, sollten Netzwerkadministratoren ihre Konfigurationen in den richtigen Zustand versetzen, d.h. eine Vertrauenskette zur \u00dcberpr\u00fcfung des Serverzertifikats mit dem Parameter ca_cert einrichten. <\/ul>\n