Discussion:
heise: gewollt fragliche WLAN-Sicherheit bei Android (und iOS)
(zu alt für eine Antwort)
Helmut Springer
2013-05-28 06:11:33 UTC
Permalink
Es geht um <http://heise.de/-1868258>
geschaetzt 80% der anwesenden Smartphones hatten sich auch brav in das
Netz eingebucht, egal ob iPhone oder Android. Es wurde mittels eines
Smartphones einer der Referenten gezeigt das a. das Passwort
auszulesen war...
Was f?r ein Passwort?
Das Zugangspasswort fuer das Netzwerk.
Die Passphrase f?r ein WPA oder WPA2 verschl?sseltes Netz?
Genau dieses.
WPA oder WPA2 senden aber keine Passwoerter, die man auslesen
koennte.
In diesem Fall wurde z.B. das Zugangspasswort fuer den Telekom Hotspot
ausgespaeht.
Die Telekom macht WPA?
Da aber auch angezeigt wurde welche anderen Netze der Besitzer des
Smartphones nutzt waere es ein leichtes dann auch einen "Zugang"
mit dieser SSID aufzubauen um so z.B. an Zugangsdaten fuer ein
Firmennetzwerk zu kommen.
Der Artikel hebt allerdings auf Radius-Authentication ab, liefert
dann aber keine Details.

Followup-To: de.comp.security.misc
--
Best regards
helmut springer panta rhei
Juergen Ilse
2013-05-28 07:10:48 UTC
Permalink
Hallo,
Post by Helmut Springer
Es geht um <http://heise.de/-1868258>
[...]
Post by Helmut Springer
Der Artikel hebt allerdings auf Radius-Authentication ab, liefert
dann aber keine Details.
Der Artikel spricht keineswegs davon, dass das Problem nur fuer (oder vor
allem fuer) Radius-Authentifizierung gelten wuerde (im Gegenteil), sondern
dass man bei Radius-Authentifizierung ggfds. erst eine "Zertifikatswarunung"
bestaetigen muesste, bevor wirklich eine Verbindung zu einem "Fakr-Netzwerk"
aufzubauen versucht wird. Der Grund dafuer ist, dass in dem Fall das Netzwerk
nicht nur durch die ESSID sondern zusaetzlich durch das passende Zertifikat
identifiziert wird.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Helmut Springer
2013-05-28 08:00:48 UTC
Permalink
Post by Juergen Ilse
Der Artikel spricht keineswegs davon, dass das Problem nur fuer
(oder vor allem fuer) Radius-Authentifizierung gelten wuerde (im
Gegenteil), sondern dass man bei Radius-Authentifizierung ggfds.
erst eine "Zertifikatswarunung" bestaetigen muesste, bevor
wirklich eine Verbindung zu einem "Fakr-Netzwerk" aufzubauen
versucht wird. Der Grund dafuer ist, dass in dem Fall das Netzwerk
nicht nur durch die ESSID sondern zusaetzlich durch das passende
Zertifikat identifiziert wird.
Zertifikat heisst fuer mich x509 aka HTTPS. Das waere vom WLAN-Teil
voellig letztlich unabhaengig.

Ist der Artikel wirklich so schlecht?
--
Best regards
helmut springer panta rhei
Juergen P. Meier
2013-05-28 07:55:34 UTC
Permalink
Post by Juergen Ilse
Der Artikel spricht keineswegs davon, dass das Problem nur fuer (oder vor
allem fuer) Radius-Authentifizierung gelten wuerde (im Gegenteil), sondern
dass man bei Radius-Authentifizierung ggfds. erst eine "Zertifikatswarunung"
bestaetigen muesste, bevor wirklich eine Verbindung zu einem "Fakr-Netzwerk"
aufzubauen versucht wird. Der Grund dafuer ist, dass in dem Fall das Netzwerk
nicht nur durch die ESSID sondern zusaetzlich durch das passende Zertifikat
identifiziert wird.
Das ist nur bei WPA2 + EAP-TLS der Fall. Andere EAP-Methoden liefern
entweder gar kein Serverzertifikat (weil kein TLS) oder bauen nur
einen Transporttunnel ohne Zertifikatsverifikation (EAP-TTLS) auf.

Bei Microsofts proprietaeren Varianten mit gegenseitiger Kerberos-basierter
Domainauthentifikation (ich weis grad nicht auswenendig wie das EAP- dazu
heisst) werden auch Client und Server gegenseitig authentifiziert -
man ist jedoch auf Microsoft Server und Clients (=Windows) beschraenkt.

Das Problem, dass der Artikel anspricht, und das in der Tat schon
viele Jahre alt und wohl bekannt ist (und fuer das es seit eben so
vielen Jahren eine perfekt funktionierende Massnahme gibt), ist jedoch
eines, bei dem man um eine Ecke denken muss: Nicht die WPA2-"Enterprisse"
gesicherte SSID wird angegriffen, sondern der Client, der einer
solchen vertraut und - weil das ja hoechsten Sicherheitsstandards
entspricht und sogar sicherer als LAN ist (gegen Angriffe von aussen
auf die Infrastruktur!), dieser SSID vollstes Vertrauen schenken und
sobald sie glauben in diesem Netz eingebucht zu sein, die virtuellen
Hosen herunter lassen und keine weiteren Schutzvorkehrungen treffen -
eben genau weil sie sich in einem vermeintlich sicheren Netzwerk
woehnen.

Bei den im Artikel genannten Geraeten wurde jedoch die Schutzmassnahme
gegen diesen Angriff *bewusst* weggelassen, genau wegen der
Bequemlichkeit...

Die Schutzmassnahme (die z.B. in Microsoft Windows 7 clients per GPO
erzwungen werden kann) lautet dann auch ganz einfach:
Eine bekannte SSID mit WPA2+EAP-TLS muss zwingend immer EAP-TLS
mit verifiziertem (u.U. vorgegebener Root-CA) Server-Zertifikat
bieten, sonst verbindet sich der Client nicht mit dieser SSID.
Nur so kann der Angriff der "fake SSID" ohne Authentifizierung
durch Fallback verhindert werden.

Jetzt ist auch klar, warum das unbequem ist und einige Hersteller
es deswegen weglassen. Zwei Szenarien fuer Unbequemlichkeit:
1.) Die sichere SSID wurde so generisch gewaehlt, dass der User
unterwegs oder im Hotel ein WLAN mit der gleichen SSID nutzen will,
aber nicht kann, weil der Client das als Angriff erkennt und
verhindert (diese SSID muss authentfiziert sein!).
2.) Ein Problem bei der Zertifikatspruefung - z.B. weil die Uhr des
Clients aufgrund eines BIOS-Fehlers auf das Jahr 1970 zurueck gestellt
wurde und er erst nach Anmeldung am WLAN die Uhr synchronisieren
kann, oder weil die CRL nicht mehr gecacht ist und ohne WLAN auch
nicht abgerufen werden kann (henne-ei-probleme).

Um beide Szenarien zu vermeiden (und damit die Supportkosten
durch verwirrte Anwender) implementiert man einfach die
Schutzmassnahme nicht. Ganz einfach.

Jetzt darf sich jeder selbst ueberlegen, ob er den Hersteller seines
Vertrauens deswegen vors Schienbein treten moechte oder nicht.
Fuer iOS Geraete ist die Anlaufstelle der Support von Apple.
Bei Androiden hat man verloren. Google wird die Verantwortung auf die
Device-hersteller schieben, welche widerum mit ihren Fingern auf
Google zeigen werden (Business as usual bei Android).

Zumindest auf der Notebook-Front sieht es besser aus: Sowohl Microsoft
Windows als auch Apple Mac OS X machen es richtig - sofern vom Admin
(bzw. dem Domaenen-Admin bei Win) des Geraetes richtig voreingestellt.
(Die jetzt aktuellen sowie die jeweilige vorherigen OS-Versionen
zumindest)

HTH,
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Helmut Springer
2013-05-28 08:30:41 UTC
Permalink
Post by Juergen P. Meier
Das ist nur bei WPA2 + EAP-TLS der Fall. Andere EAP-Methoden
liefern entweder gar kein Serverzertifikat (weil kein TLS) oder
bauen nur einen Transporttunnel ohne Zertifikatsverifikation
(EAP-TTLS) auf.
Mit etwas Nachlesen: EAP-TLS erfordert idR server und client
certificates, EAP-TTLS erfordert ein server certificate. Beide
sollten also Zertifikatsverifikation durchfuehren...
Post by Juergen P. Meier
Bei den im Artikel genannten Geraeten wurde jedoch die
Schutzmassnahme gegen diesen Angriff *bewusst* weggelassen, genau
wegen der Bequemlichkeit...
Klartextpasswortbasierte Authentication ueber nicht verifizierte
TLS-Verbindungen sind natuerlich trivial anzugreifen, ok.
--
Best regards
helmut springer panta rhei
Florian Weimer
2013-05-28 19:43:05 UTC
Permalink
Post by Helmut Springer
Mit etwas Nachlesen: EAP-TLS erfordert idR server und client
certificates, EAP-TTLS erfordert ein server certificate. Beide
sollten also Zertifikatsverifikation durchfuehren...
Aber gegen welche CA, wenn das ganze mehr oder weniger ad hoc ist?
Juergen P. Meier
2013-05-29 05:04:13 UTC
Permalink
Post by Florian Weimer
Post by Helmut Springer
Mit etwas Nachlesen: EAP-TLS erfordert idR server und client
certificates, EAP-TTLS erfordert ein server certificate. Beide
sollten also Zertifikatsverifikation durchfuehren...
Aber gegen welche CA, wenn das ganze mehr oder weniger ad hoc ist?
Garkeine. Ad-hoc stellt man ein offenes WLAN mit gleicher SSID zur
verfuegung und freut sich, dass sich jeder Idiot mit iPhone oder
Android dort einbucht.

Fehlt nur noch eine Infrastruktur aus einem modifizierten Honeynet,
und schon kennt man Proxy-user+passwort, Domainkennungen, E-Mail
Account, Username und Passwort (und ggf. auch Inhalte von auf dem
Geraet gecachten E-Mails inkl. unfertiger Mails aus dem
Vorlagen-Ordner sowie "geleoschte" Mails aus dem Papierkorb) etc.pp.

Frueher, also vor Windows Vis^W7, hat sich diese Form des Angriffs
vorwiegend gegen die Noteobooks von Geschaeftsreisenden in Hotel-WLANs
oder andern von Reisenden haeufig benutzten Hotspots gerichtet, und
wurde wohl vorwiegend zum Zwecke der Industriespionage (zumindest in
der westlichen und ost-asiatischen Hemisphaere) verwendet. Diese Klasse
von Angreifer verfuegt auch oft genug ueber die Moeglichkeit,
gefaelschte Zertifikate von vertrauten CAs signieren zu lassen.

Mittlerweile hat sich das Primaerziel geaendert, sowohl weil die
Mobilen Geraete mit WLAN-immer-an so verbreitet haben, als auch weil
die urspruengliche Zielplattform so nicht laenger Angreifbar ist.

Als DAU mit privatem Smartphone, auf dem die wertvollsten Daten
irgendwelche hoechstens im Bekanntenkreis peinliche Photos darstellen,
und die Mailkommunikation sich vorwiegend aus werbemuell und
Verabredungen zum Kinobesuch zusammensetzt, ist das Risiko dieses
Angriffs vernachlaessigbar - nicht wegen der Chance, sondern wegen
dem Schadensumfang. Darum scheisst sich auch ausserhalb eines kleinen
Kreises niemand um diese Sicherheitsluecke in Consumer-Geraeten.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Arno Garrels
2013-05-29 18:43:33 UTC
Permalink
Post by Helmut Springer
Klartextpasswortbasierte Authentication ueber nicht verifizierte
TLS-Verbindungen sind natuerlich trivial anzugreifen, ok.
Ach ja? Erzähl mal, oder zählst du den "Mann in der Mitte" als
triviale Angriffsmöglichkeit?
--
Arno
Hendrik Weimer
2013-05-28 18:58:44 UTC
Permalink
Nicht die WPA2-"Enterprisse" gesicherte SSID wird angegriffen, sondern
der Client, der einer solchen vertraut und - weil das ja hoechsten
Sicherheitsstandards entspricht und sogar sicherer als LAN ist (gegen
Angriffe von aussen auf die Infrastruktur!), dieser SSID vollstes
Vertrauen schenken und sobald sie glauben in diesem Netz eingebucht zu
sein, die virtuellen Hosen herunter lassen und keine weiteren
Schutzvorkehrungen treffen - eben genau weil sie sich in einem
vermeintlich sicheren Netzwerk woehnen.
Nein. Mit als verschluesselt gespeicherte Netze kann man nur verbunden
werden, wenn der Hotspot die Passphrase kennt, bzw. ein korrekt
signiertes Zertifikat vorliegt. Der aktuell diskutierte Angriff sieht
vor, dass die Internet-Verbindung ueber ein Netzwerk mit bekannter SSID
umgeleitet wird, nur weil man sich beispielsweise in der Vergangenheit
mal einen T-Mobile-Hotspot genutzt hat, der unverschluesselt ist. Zudem
wird bemaengelt, dass die Liste der bekannten SSIDs auf Android und iOS
auch noch herausposaunt wird, das ist aber fuer das eigentliche Problem
aber irrelevant.

Hendrik
Juergen P. Meier
2013-05-29 04:29:56 UTC
Permalink
Post by Hendrik Weimer
Nicht die WPA2-"Enterprisse" gesicherte SSID wird angegriffen, sondern
der Client, der einer solchen vertraut und - weil das ja hoechsten
Sicherheitsstandards entspricht und sogar sicherer als LAN ist (gegen
Angriffe von aussen auf die Infrastruktur!), dieser SSID vollstes
Vertrauen schenken und sobald sie glauben in diesem Netz eingebucht zu
sein, die virtuellen Hosen herunter lassen und keine weiteren
Schutzvorkehrungen treffen - eben genau weil sie sich in einem
vermeintlich sicheren Netzwerk woehnen.
Nein. Mit als verschluesselt gespeicherte Netze kann man nur verbunden
werden, wenn der Hotspot die Passphrase kennt, bzw. ein korrekt
signiertes Zertifikat vorliegt. Der aktuell diskutierte Angriff sieht
Aeh, darum genau ging es, dass bei Android und iOS *keine* feste
Bindung des bekannten WLAN-Profils an die SIcherheitseinstellungen
desselben vorhanden ist.

Der Angreifer muss eben genau *NICHT* die gleiche
Sicherheitseinstellunge verwenden. Der selbe SSID-Name genuegt.
Post by Hendrik Weimer
vor, dass die Internet-Verbindung ueber ein Netzwerk mit bekannter SSID
umgeleitet wird, nur weil man sich beispielsweise in der Vergangenheit
mal einen T-Mobile-Hotspot genutzt hat, der unverschluesselt ist. Zudem
wird bemaengelt, dass die Liste der bekannten SSIDs auf Android und iOS
auch noch herausposaunt wird, das ist aber fuer das eigentliche Problem
aber irrelevant.
Du hast das Angriffszenario nicht verstanden. Es geht hier um einen
Angriff gegen Trustbeziehungen innerhalb eines vermeindlich sicheren
WLANs, nicht das WLAN selbst.

Der Angreifer stellt on-the-fly ein offenes WLAN mit dem selben Namen
bereit wie das Geraet erwartet (was es ja hinausposaunt), das Geraet
bucht sich dort /ohne Nachzufragen/ ein - wegen Fallback auch wenn die
Sicherheitseinstellungen bei der SSID des Angreifers voellig andere
sind (=offnen). Dieser Fallback existiert in den Angesprochenen Geraeten
aus Grunden der Bequemlichkeit *DAS IST DER KERNPUNKT DER KRITIK*.

Der Angreifer stellt jetzt dem Opfer eine scheinbar vollstaendige
Infrastruktur (DNS, proxy, fileserver, ein im NTLM-fallback operierender
degradierter Domaincontroller, proxy-pac autoconfigruator (u.A. um den
Proxy vertrauenswuerdig bezueglich automatischer Proxy-Auth zu machen),
Mail-Server (der IMAP/POP3/SMTP Auth leider nur mit ungehashten
klartext-passwoertern erlaubt - dafuer aber TLS gesichert, dafuer jede
Username/Passowort-kombination zulaesst und den Mailclient erstmal
alle lokal gecachte Mail mit dem Server synchronisiert (=Hochlaedt))
zur Verfuegung, und zwar aehnlich genug wie der Client sie erwartet.
Man kann das selbst bauen: einfach ein Honeynet entsprechend modifizieren.

So kommt der Angreifer ohne dass der Smartphonebenutzer was merkt an:
1) Proxy-Auth Username und Passwort (oft identisch mit Login-credentials)
2) E-Mail Kennung, username und Passwort, und bei IMAP sogar an alle
lokal am Geraet gespeicherten e-Mails - sofern der Mailclient den
Sever nicht ausreichend* authentifiziert.
3) Ein Mapping der internen Infrastruktur aufgrund von DNS-Anfragen
und connect-attempts des Clients - ohne darauf zugriff haben zu muessen.
etc.

Bei Notebooks ist der Hauptvorteil fuer den Angreifer: etwaitige
installilerte Endpoint-Protection Produkte meinen ein sicheres WLAN
zu erkennen und fahren ein "ich bin in der sicheren Domaene!!1"-Profil.


* TLS erzwungen mit Zertifikatsverifikation und Integritaetspruefung
des Zertikfates (CN muss korrekt sein, Signing CA muss die richtige
sein) - Das leistet *kein* Mailclient auf irgend einer Mobilen
Smartphone-Plattform. JEDER Mailclient dort erlaubt ein von
irgendeiner systemweit vertrauenswuerdig deklarierter CA signiertes
Zertifikat - darum ist es ja z.B. auch erlaubt, solche Geraete mit
Verschluesseltem E-Mailzugriff u.A. nach Indien einzufuehren...
Die Signatur muss jedoch stimmen (d.h. so ein Angriff setzt voraus,
dass der Angreifer Zertifikate ausstellen kann, z.B. von einer
kompromittierten CA oder Sub-CA, oder weil es eine Behoerde eines
Staates ist, dessen CAs vertraut werden...

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Hendrik Weimer
2013-05-29 17:29:38 UTC
Permalink
Post by Juergen P. Meier
Der Angreifer muss eben genau *NICHT* die gleiche
Sicherheitseinstellunge verwenden. Der selbe SSID-Name genuegt.
Kannst Du diese Behauptung auch irgendwie belegen?

Hendrik
Bastian Blank
2013-05-29 07:18:10 UTC
Permalink
Post by Hendrik Weimer
Nein. Mit als verschluesselt gespeicherte Netze kann man nur verbunden
werden, wenn ein korrekt
signiertes Zertifikat vorliegt.
Was ist in diesem Fall ein "korrekt signiertes Zertifikat"? Wie prüfte
der EAP-Client, das es für das konkrete Netz valid ist?

Bastian
Juergen P. Meier
2013-05-29 09:09:37 UTC
Permalink
Post by Bastian Blank
Post by Hendrik Weimer
Nein. Mit als verschluesselt gespeicherte Netze kann man nur verbunden
werden, wenn ein korrekt
signiertes Zertifikat vorliegt.
Was ist in diesem Fall ein "korrekt signiertes Zertifikat"? Wie prüfte
der EAP-Client, das es für das konkrete Netz valid ist?
Sofern ueberhaupt: Es wird geprueft, ob eine der 'zig vorinstallierten CAs
das Zertifikat signiert hat. Es findet idR. nichtmal ein CRL-Check
statt (wie sollte das auch gehen, ohne Netz).
Jens Hektor
2013-05-29 10:30:40 UTC
Permalink
Post by Juergen P. Meier
Sofern ueberhaupt: Es wird geprueft, ob eine der 'zig vorinstallierten CAs
das Zertifikat signiert hat. Es findet idR. nichtmal ein CRL-Check
statt (wie sollte das auch gehen, ohne Netz).
Man sollte sicher überhaupt keinen Illusionen über Zertifikatsprüfungen
durch irgendwelche Apps auf Android oder iOS hingeben:

http://www.dfn-cert.de/dokumente/workshop/2013/FolienSmith.pdf
Hendrik Weimer
2013-05-29 17:30:26 UTC
Permalink
Post by Jens Hektor
Man sollte sicher überhaupt keinen Illusionen über Zertifikatsprüfungen
http://www.dfn-cert.de/dokumente/workshop/2013/FolienSmith.pdf
Mag sein, aber wir reden hier ueber das Basissystem.

Hendrik
Hendrik Weimer
2013-05-29 17:21:59 UTC
Permalink
Post by Bastian Blank
Post by Hendrik Weimer
Nein. Mit als verschluesselt gespeicherte Netze kann man nur verbunden
werden, wenn ein korrekt
signiertes Zertifikat vorliegt.
Was ist in diesem Fall ein "korrekt signiertes Zertifikat"? Wie prüfte
der EAP-Client, das es für das konkrete Netz valid ist?
Ich kann nur fuer Android sprechen: da muss die Root-CA manuell
installiert werden selbst wenn diese bereits in den Browser integriert
ist.

Hendrik
Lesen Sie weiter auf narkive:
Loading...