WLAN-Sicherheit 21 - Rogue Access Points, Teil 2: MANA
Der KARMA-Angriff eines Rogue Access Points, bei dem der AP sich gegenüber dem Client als dem bekanntes WLAN ausgibt funktioniert auch in der verbesserten Variante nur, wenn die Clients überhaupt nach Netzwerken suchen. Was wie schon erwähnt nicht mehr unbedingt der Fall ist. Wenn die Geräte dadurch aber nicht mehr verraten, mit welchen Netzwerken sie sich verbinden würden, erschwert das den KARMA-Angriff natürlich.
Aber dagegen kann man etwas machen:
Viel hilft viel
Der Rogue AP kann aber auch statt für jedes Geräte eine Liste individueller Netzwerke anzukündigen, einfach alle ihm bekannte SSIDs per Broadcast als seine eigenen anpreisen. Das können zum Beispiel die SSIDs bekannter öffentlicher Netze sein, oder auch vermutete Namen in einem Unternehmensnetz. Oder die SSIDs der Netzwerke, nach denen ältere Geräte weiterhin suchen. Oft verwenden benachbarte Geräte die gleichen WLANs, zum Beispiel weil sie in der gleichen Stadt, auf dem gleichen Flughafen, auf der gleichen Konferenz, ... waren. Oder weil sie zum gleichen Unternehmen oder zum gleichen Benutzer gehören. Oder ....
Dieser von den MANA-Entwicklern "Loud Mode" genannte Ansatz löst auch das Problem der zufällig vergebenen MAC-Adressen aktueller Clients. Indem die MAC-Adresse immer wieder geändert wird, wird ein Wiedererkennen der Geräte und damit zum Beispiel ihr Tracking erschwert. Im Fall der Rogue APs wird so auch verhindert, dass für jedes Gerät eine individuelle Preferred Network List (PNL) angelegt wird, da der AP nicht weiß, welche Anfragen vom gleichen Gerät stammen.
Ein Nachteil dieses Ansatzes: Alle oder zumindest fast alle in Reichweite befindlichen Geräte werden versuchen, sich mit dem Rogue AP zu verbinden. Möchte man das nicht, weil nur bestimmte Geräte angegriffen werden sollen, kann der Zugriff auf MAC-Basis reguliert werden. Was natürlich wieder Probleme bereitet, wenn die MAC zufällig gewählt wird und sich immer wieder ändert. Die zufällig erzeugten MAC-Adressen lassen sich zwar erkennen, da in ihnen zur Kennzeichnung einer lokal verwalteten Adresse das zweite Bit im ersten Oktett gesetzt ist, das hilft beim Angriff aber nur weiter, wenn man zumindest weiß, welche Adressbereiche interessant oder uninteressant sind.
Da MAC-basierte Zugriffslisten erst nach dem Austausch der Probe- und Response-Nachrichten greifen, haben die Entwickler in MANA die Möglichkeit vorgesehen, die MAC-ACLs auch auf Management-Frames anzuwenden. Damit ist es möglich, den Rogue AP vor allen Geräten, die für ihn uninteressant sind, zu verbergen.
Angriffe auf geschützte Netzwerke ausweiten
Der klassische KARMA-Angriff funktioniert nur mit offenen Netzen. Geschützte Netze werden nicht unterstützt, da davon ausgegangen wird, dass die Geräte sich nicht mit ihnen verbinden. Das ist aber nicht zwingend der Fall, denn die Benutzer können sich zum einen manuell mit ihnen verbinden. Zum anderen bauen einige Systeme auch automatisch eine Verbindung auf. Der Angriff wurde daher in MANA auf geschützte Netze ausgedehnt:
Der Rogue AP kann von einer einzigen BSSID aus mehrere Probe-Response für unterschiedliche Netzwerke verschicken. Das gilt auch für mehrere Probe-Responses mit unterschiedlichen Sicherheitseinstellungen. Manche Geräte verbinden sich mit einem davon, wenn es in ihrer PNL enthalten ist. Danach scheitert der Angriff an der nun nötigen Authentifizierung.
Aber nicht immer. Clients, die EAP mit SSL (PEAP, EAP-GTC, PEAL-TTLS) verwenden und das dabei präsentierte Zertifikat nicht prüfen, senden ihren EAP-Hashwert an den Rogue AP. Und bei WPA2 können die ersten beiden Handshake-Nachrichten aufgezeichnet werden. Diese Daten werden von MANA aufgezeichnet werden, so dass sie zum Beispiel mit asleap geknackt werden können. Was nur bei einfachen Credentials schnell genug gelingt, um rechtzeitig ein Fake-Netzwerk mit passenden Sicherheitseinstellungen und WPA2-PSK bzw. EAP Benutzer-Passwort-Kombination einzurichten. Denn nur damit ist es möglich, die Authentifizierung erfolgreich abzuschließen und dadurch den Rogue AP als das betreffende Netzwerk auszugeben.
Ohne MitM in SSL/TLS geht nicht mehr viel
Das alles ist aber nur die berühmte "halbe Miete": Der Client hat sich zwar mir dem Rogue AP verbunden, sobald aber HTTS oder allgemein SSL/TLS zum Einsatz kommen verhindert das einen MitM-Angriff auf die über den Rogue AP abgewickelte Kommunikation. Und das aus gleich mehreren Gründen:
- Die Clients prüfen, ob die Verbindung echt ist,
- die bekannten Tools funktionieren nicht mehr (richtig),
- HSTS verhindert SSL Stripping,
- Mobile Apps prüfen SSL-Zertifikate, und
- Cert Pinning verhindert erst recht den Einsatz eines MitM-Zertifikats.
Trotzdem kann man es aber ja mal versuchen. MANA setzt für MitM-Angriffe auf SSL/TLS-Verbindungen auf SSLsplit von Daniel Roethlisberger. Das Tool klinkt sich mit on-the-fly gefälschten oder auch bereits vorhandenen X.509-Zertifikaten in die SSL/TLS-Verbindung ein. Was natürlich nicht möglich ist, wenn der Client zum Beispiel durch Certificate Pinning geschützt ist, so dass das falsche Zertifikat zurückgewiesen wird.
Heiß begehrt: Zugangsdaten!
Haupt-Angriffsziel eines Rogue APs sind im Allgemeinen Zugangsdaten, und auch MANA ist mit entsprechenden Funktionen ausgestattet. Um die Zugangsdaten einzusammeln kommt ein Fake-Portal zum Einsatz, außerdem eine OAuth nachempfundene Authentifizierung.
MANA kann versuchen, dem Client über Konfigurationsprofile eine neue Root-CA (um MitM-Angriffe auf SSL/TLS zu erleichtern) oder ein neues offenes Wifi-Netzwerk (um KARMA-Angriffe funktionsfähig zu halten) unterzuschieben. So ein Angriff ist aber nur erfolgreich, wenn der Benutzer das untergeschobene Profil installiert. Was mit etwas Social Engineering oft gelingen dürfte.
Da Firesheep nicht mehr weiterentwickelt wird, wurde mit Firelamp eine Alternative entwickelt. Dabei handelt es sich um ein Python-Script, das ungeschützt übertragene Cookies ausspäht. Weiterentwickelt wird das allerdings auch schon seit einiger Zeit nicht mehr.
SSL Stripping ermöglichen
Der Schutz vor SSL Stripping über HSTS lässt sich teilweise
aushebeln. Eine angepasste Version von sslstrip enthält einen
"intercepting DNS Server",
dns2proxy.
Ruft der Benutzer in
seinem Browser zum Beispiel http://www.google.com/ auf, antwortet sslstrip
mit einem Redirect zu wwww.google.com.
dns2proxy spiegelt den DNS-Eintrag für www.google.com
für wwww.google.com. sslstrip ändert Links von
www.google.com zu wwww.google.com. Da der Browser
keine HSTS-Einstellungen für wwww.google.com kennt, nutzt
er weiterhin eine unverschlüsselte Verbindung. Die natürlich bei
www.google.com landen, da die DNS-Einträge ja identisch
sind.
Sie sehen also: Rogue Access Points sind und bleiben eine Gefahr.
Hiermit ist das Thema "WLAN-Sicherheit" zumindest vorerst abgeschlossen. Worum es ab der nächsten Folge geht habe ich noch nicht endgültig entschieden.
Trackbacks