ubuntuusers.de

Hallo zusammen!

Unter http://www.heise.de/newsticker/meldung/104228 wird angedeutet, daß das automatische Verbinden mit AccessPoints unter XP problematisch ist:

Rechner ist mit AP(SSID: abc + WPA) verbunden.
Angreifer stellt einen AP mit gleicher SSID bereit. Dieser AP ist unverschlüsselt. Angreifer schickt "Deauthentification".
Rechner versucht, die Verbindung wiederherzustellen, findet anhand der SSID das ungeschützte Netz und verbindet ⇒ der Angreifer kann den Datenverkehr abgreifen...
Das Problem ist doch, daß Windows nicht überprüft, ob der AP die gleiche Verschlüsselung nutzt.

(Habe ich das alles richtig verstanden?)

Nun die wichtige Frage: Der NetworkManager stellt auch die Verbindung zu "bekannten APs" automatisch her. Ist er auch für dieses Szenario anfällig?

EDIT: Bugreport: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/210459

Hallo, DrScott!

Also erstens - oder besser eigentlich BTW 😀 - mal ist der Artikel auf heise eine Frechheit, was Irreführung anbelangt.

Ich habe das ganze so verstanden:

- Rechner ist mit AP (SSID: abc + WPA) verbunden.
- Angreifer stellt einen AP mit gleicher SSID bereit und verschickt "Deauthentification", womit die Verbinung des anzugreifenden Clients vom original AP gekapt wird.
- Nun fängt der Client an - aus der in der WLAN-Managment-Software gespeicherten Liste an bekannten APs - diese APs der Reihe nach durchzuprobieren, womit diese SSIDs nach außen ablesbar bekannt gegeben werden.
- Befinden sich dabei in der Liste des Clients bekannte offne APs, so gibt sich der Angreifer nun als einer dieser offenen (unverschlüsselten) APs aus und der Client verbindet. Damit läuft der Netzwerkverkehr nun über den Angreifer.

Es wird also genau genommen nicht in das WPA gesicherte WLAN eingebrochen, sondern eine Trennung von diesem wird provoziert und stattdessen wird ein AP aus der Liste der bekannten APs angeboten und zu diesem wird dann verbunden.

Ich bin auf Linux noch neu und hab' den NetworkManager bezüglich WLAN noch nicht angeschaut, aber vom Szenario her ist das kein Windows-Problem, sondern ein Problem der WLAN-Konfiguration. Damit kann ein OS betroffen sein, sofern auf ihm eine WLAN-Managment-Software läuft, die SSIDs von offenen APs speichert und bei Wiederfinden der gespeicherten SSID ohne nachfragen automatisch verbindet.

So hab' ich das verstanden und so kenne ich es von Windows - wobei man das auch bei Windows anders konfigurieren kann.

Was das ganze allerdings mit WPA zu tun hat, weiß ich auch nicht. Klingt halt schön reißerisch.

Im übrigen dürften davon eh nur Notebooks betroffen sein. Und mal ehrlich, wer wickelt denn mit einem Notebook, dass er auch hin und wieder in offenen WLANs nutzt sensible Dinge ab?

Gruß,
Martin

Newubunti hat geschrieben:

Ich habe das ganze so verstanden: [...]

Nun, so in etwa habe ich das ja auch...

Newubunti hat geschrieben:

Es wird also genau genommen nicht in das WPA gesicherte WLAN eingebrochen, sondern eine Trennung von diesem wird provoziert und stattdessen wird ein AP aus der Liste der bekannten APs angeboten und zu diesem wird dann verbunden.

Und ich finde, das geht auch klar aus dem Heise-Artikel hervor. Klar betrifft es nicht nur gesicherte Netzwerke, auch ungesicherte, aber da ist das ja absurd.

Newubunti hat geschrieben:

Ich bin auf Linux noch neu und hab' den NetworkManager bezüglich WLAN noch nicht angeschaut, aber vom Szenario her ist das kein Windows-Problem, sondern ein Problem der WLAN-Konfiguration. Damit kann ein OS betroffen sein, sofern auf ihm eine WLAN-Managment-Software läuft, die SSIDs von offenen APs speichert und bei Wiederfinden der gespeicherten SSID ohne nachfragen automatisch verbindet.

Wie stellst Du Dir das mit dem Nachfragen vor? "Wollen Sie sich mit den Neztwerk 'SSID: abc' verbinden?" Da wird jeder auf "ja" klicken, schließlich ist es ja die korrekte SSID.

Das korrekte Verhalten wäre doch - vorausgesetzt ich habe das Problem überhaupt so richtig verstanden - daß die Software erkennt, daß das alte Netzwerk verschlüsselt war, das neue jedoch plötzlich nicht mehr. Dann müßte eine entsprechende Warnung kommen. Und keine Verbindung natürlich.

Newubunti hat geschrieben:

Was das ganze allerdings mit WPA zu tun hat, weiß ich auch nicht. Klingt halt schön reißerisch.

Naja, wie gesagt: Bei Netzen ohne WPA braucht man diesen Trick ja gar nicht. Da ist alles ganz einfach...

Newubunti hat geschrieben:

Im übrigen dürften davon eh nur Notebooks betroffen sein. Und mal ehrlich, wer wickelt denn mit einem Notebook, dass er auch hin und wieder in offenen WLANs nutzt sensible Dinge ab?

Du meinst also, daß man bei Notebooks getrost auf jede Verschlüsselung des Datenverkehrs verzichten kann? 😉

DrScott hat geschrieben:

Newubunti hat geschrieben:

Ich bin auf Linux noch neu und hab' den NetworkManager bezüglich WLAN noch nicht angeschaut, aber vom Szenario her ist das kein Windows-Problem, sondern ein Problem der WLAN-Konfiguration. Damit kann ein OS betroffen sein, sofern auf ihm eine WLAN-Managment-Software läuft, die SSIDs von offenen APs speichert und bei Wiederfinden der gespeicherten SSID ohne nachfragen automatisch verbindet.

Wie stellst Du Dir das mit dem Nachfragen vor? "Wollen Sie sich mit den Neztwerk 'SSID: abc' verbinden?" Da wird jeder auf "ja" klicken, schließlich ist es ja die korrekte SSID.

Das korrekte Verhalten wäre doch - vorausgesetzt ich habe das Problem überhaupt so richtig verstanden - daß die Software erkennt, daß das alte Netzwerk verschlüsselt war, das neue jedoch plötzlich nicht mehr. Dann müßte eine entsprechende Warnung kommen. Und keine Verbindung natürlich.

Naja, das sehe ich anders. Die richtige SSID ist die des WPA-WLAN.

Wenn ich z.B. zu hause über meinen WPA verschlüsselten AP verbinde (SSID: Furtzkiste) und nun wird die Verbindung gekappt und in meiner Client-Liste steht jetzt z.B. noch SSID: CafeSorglos - das aber ja momentan eigentlich nicht in Reichweite liegt - dann langt mir eigentlich schon die Frage, ob ich mit CafeSorglos verbinden wolle. Also ich würde da nicht auf OK klicken. 😀

Das hatte ich ursprünglich bei meiner Aussage mit der Nachfrage vor Augen. Wobei ich immer skeptisch wäre, wenn ein WLAN-Wechsel angezeigt würde. Also auch dann, wenn offenes und verschlüsseltes WLAN gleichzeitig in Reichweite wären.

Entscheidend ist doch hier, dass nicht unnachgefragt in ein anderes WLAN geswitcht wird. Der Hinweis, dass das neue WLAN nicht verschlüsselt ist, nutzt mir doch in dem Moment, wo ich in dessen Reichweite bin nichts, da ich ja das offene WLAN zuvor schon einmal genutzt habe. Andernfalls wäre es ja nicht in der Client-Liste. Also bringt m.E, der Hinweis auf den Wechsel in ein unverschlüsseltes WLAN in diesem Zusammenhang nicht mehr Sicherheit, als der Hinweis, dass ganz generell mit einem anderen WLAN aus der Client-Liste verbunden werden soll.

Oder hab' ich da einen Denkfehler?

Ich würd' einfach - OS unabhängig - so konfigurieren, dass nicht unnachgefragt in offene WLANs verbunden wird. Dann kann der Angreifer mich auch nicht umleiten. Das sollte eigentlich bei allen OSen - oder besser bei allen darauf laufenden WLAN-Konfiguratoren - möglich sein.

DrScott hat geschrieben:

Newubunti hat geschrieben:

Was das ganze allerdings mit WPA zu tun hat, weiß ich auch nicht. Klingt halt schön reißerisch.

Naja, wie gesagt: Bei Netzen ohne WPA braucht man diesen Trick ja gar nicht. Da ist alles ganz einfach...

Naja... aber das soll neu sein? Das ganze funktioniert auch mit WEP. Letztendlich steht es in dem Artikel ja schon richtig beschrieben - wobei ich auf heise schon verständlichere Artikel gelesen habe - die Überschrift hätte ich aber trotzdem sachlicher formuliert. Ist aber wirklich nur BTW.

Ok, ich hatte bisher nicht so ganz wahrgenommen, daß in dem Artikel irgendein Netz aus der "PNL" gemeint war. Da hast Du dann recht: Es sollte den Anwender verwundern, wenn plötzlich ein anderes Netz genommen wird, welches vielleicht auch normalerweise an der entsprechenden Örtlichkeit gar nicht existiert...

Ich dachte bisher aber folgenden Sonderfall:
Gut, Du bist mit AP:Furzkiste verbunden.
Nun biete ich - als böser Angreifer - einen weiteren AP in deiner Umgebung an, und zwar - Überraschung - auch mit der SSID:Furzkiste, allerdings unverschlüsselt. Ich habe keine Ahnung, ob das möglich ist, und ob ich es erreichen kann, daß mein AP vor deinem "gefunden" wird. Nach einem "deauth" würdest Du dich dann wieder mit "Furzkiste" verbinden... Wie immer... (Hierauf bezog sich meine Äußerung, daß eigentlich geprüft werden müßte, ob das Netz plötzlich unverschlüsselt sei).

Die Frage ist also: Was passiert, wenn im Umkreis zwei Netze mit der selben SSID liegen. Da gibt es ja noch verschiedene Varianten: anderer Kanal, gleicher Kanal. Und wenn man den Aufwand erhöht: Vieleicht auch mit Richtantenne durchs Fenster direkt auf deinen Rechner, so daß mein Signal stärker ist als das deines wahren APs.

EDIT: Bin jetzt zu dem Schluß gekommen, daß ich den besagten Angriff wohl falsch verstanden habe und mein Szenario so nicht klappt. Bei gleicher SSID wird wohl eine plötzlich andere Verschlüsselungsart - nämlich keine - nicht akzeptiert, oder? Nun, daß ist zumindest ein Fall, den ich selber mal austesten kann...

Hallo, DrScott!

DrScott hat geschrieben:

EDIT: Bin jetzt zu dem Schluß gekommen, daß ich den besagten Angriff wohl falsch verstanden habe und mein Szenario so nicht klappt. Bei gleicher SSID wird wohl eine plötzlich andere Verschlüsselungsart - nämlich keine - nicht akzeptiert, oder? Nun, daß ist zumindest ein Fall, den ich selber mal austesten kann...

Ich hab' zwar gerade kein WLAN zum testen zur Verfügung, ich bin mir aber ziemlich sicher, dass bei gleicher SSID ohne Verschlüsselung nicht automatisch verbunden wird. Wenn es so wäre, dann wäre das auch fatal, weil dann müßte der Angreifer ja immer nur bessere Signalqualität liefern.

Ich wundere mich nicht, dass Du das falsch verstanden hast, denn der Artikle ist einfach schlecht geschrieben. Ich halte das mehr für Werbung für die eigene Veranstaltung, als für Aufklärung über eine "Sicherheitslücke". Wenn man Leute ernsthaft aufklären will, dann sollte man das Szenario schon detailiert darstellen, damit es auch jeder nachvollziehen kann. Wie man aber an den Kommentaren zu dem Artikel ablesen kann, herrscht fast Einstimmigkeit, dass der Artikel zur wirklichen Aufklärung ungeeignet ist.

Gruß,
Martin

Newubunti hat geschrieben:

Wenn es so wäre, dann wäre das auch fatal, weil dann müßte der Angreifer ja immer nur bessere Signalqualität liefern.

So, ich habe das nun mal mit "knetworkmanager" getestet: Leider positiv. Folgendes vorgehen:

* AP mit WPA2 eingerichtet.
* Verbindung mit knetworkmanager hergestellt. (PSK wurde abgefragt).

* WPA2 abgeschaltet, SSID unverändert.
* Rechner neugestartet, Am System angemeldet, Verbindung wurde von knetworkmanager ohne Nachfrage/Warnung automatisch hergestellt...

Hallo, DrScott!

Das ist zwar ein Stück weit beunruhigend trifft aber nicht genau das Szenario. Man müßte es schon so testen:

- AP mit WPA2 eingerichtet und verbunden
- Nun zweiten AP mit gleicher SSID aber offen anbieten
- Nun vom AP mit WPA2 trennen und sehen, zu welchem AP wieder verbunden wird

Denn normalerweise schaltest Du Deinen AP ja auch nicht aus. Interesseant wird es also erst, wenn beide APs aktiv sind.

Du hast ja jetzt nur bewiesen, dass sich der Networkmanger ungefragt in ein offenes WLAN verbindet. Damit wäre noch nicht bewiesen, dass er das auch tut, wenn das WPA-WLAN mit gleicher SSID auch gleichzeitig sendet.

Nicht dass Dein Ergebnis auch ein wenig beunruhigt, aber es bildet nicht vollständig das beschriebene Angriffsszenario wieder.

Newubunti hat geschrieben:

Denn normalerweise schaltest Du Deinen AP ja auch nicht aus.

Das ist schon richtig. Aber zumindest auf Seiten des Computers sind somit schon mal alle Voraussetzungen für den Angriff gegeben. Mehr kann ich mangels Hardware (und tieferem Wissen) nicht testen.

Allerdings ist mein Fall auch schon ein kleiner Hammer: Jemand (z.B. der Nachbar) muß in einem nur sehr kurzen, unbemerkten Zeitpunkt den AP einfach auschalten... Klar "lokale Sicherheit" und "physikalischer Zugriff"... Aber schön ist es nicht.

Ja, ganz harmlos ist es nicht wobei das für mich eher eine Fehlkonfiguration ist, als eine wirkliche Sicherheitslücke. Kann man nicht unter dem KNetwork-Manager die SSID des Nachbars auf "untrusted" setzen? Dann verbindet er doch nicht automatisch?

Newubunti hat geschrieben:

Ja, ganz harmlos ist es nicht wobei das für mich eher eine Fehlkonfiguration ist, als eine wirkliche Sicherheitslücke.

Sehr viele Sicherheitslücken bestehen einfach aus Fehlkonfiguration... 😉 Und in diesem Fall ist die Fehlkonfiguration eben leider "Default".

Es wäre noch zu klären, ob sich nm-applet genauso verhält...

Newubunti hat geschrieben:

Kann man nicht unter dem KNetwork-Manager die SSID des Nachbars auf "untrusted" setzen? Dann verbindet er doch nicht automatisch?

Äh, da waren wir doch schon: Der Nachbar wählt doch "Deine" SSID...

(Würde er seinen AP weiterhin auf seiner bisherigen SSID unverschlüsselt laufen lassen, dann würde selbst knetworkmanager nicht automatisch verbinden. Denn erst wenn man ein ein Netzwerk erstmalig manuell aktiviert, so wird dies als "trusted" markiert. Erst ab dann würde es automatisch aktiviert werden....)

So, ich hab' das jetzt mal mit einem Laptop und zwei APs nachgestellt - allerdings unter Windows, da ich auf die schnelle kein WLAN über Linux zum Laufen bekommen habe.

Zur Einordung der Sicherheitslück mag es aber vielleicht dennoch interessant sein. Da ich kein absoluter WLAN- oder Sicherheits-Experte bin, ist das Szenario nicht 1:1 nachgebildet. Es erfolgt daher kein wirklicher Angriff, sondern es wird einfach nur der mit WPA verschlüsselte AP ausgeschaltet:

OS:
Windows XP Home SP 2

Geräte:
AP1: Sinus 154 DSL Basic SE
AP2: Speedport W 500 V
WLAN-Adapter: Linksys WPC54G ver.2

Versuch 1: Unterschiedliche SSID

a. Verwendung des Linksys-WLAN-Managers

- Beide APs sind anfangs noch unverschlüsselt.
- Zunächst wird eine Verbindung zum unverschlüsselten AP2 mit Hilfe des Linksys-Managers hergestellt (SSID: OpenUni)
- Das ganze wird im Linksys-Tool als Default Profil gespeichert
- Die Verbindung zu OpenUni wird getrennt und AP2 ausgeschaltet
- AP1 wird eingeschaltet.
- Mit Hilfe des Linksys Profil Assistenten wird ein ein weiteres Profil WLAN erstellt. SSID: WLAN, keine Verschlüsselung. Mit diesem Profil wird zu AP1 verbunden.
- Die SSID von AP1 wird auf Home geändert und WPA Verschüsselung wird eingeschaltet.
- Es wird ein weiteres Profil im Linksys Assitenten erstellt. SSID: Home, Verschlüsselung WPA und dann mit diesem zu AP1 verbunden.
- AP2 wird zugeschaltet und solange gewartet bis das Linksys Tool diesen sehen kann.
- AP1 wird abgeschaltet.

Beobachtung:
Es passiert nichts! Trotz bestehenden Profils OpenUni wird nicht automatisch mit OpenUni verbunden. Auch dann nicht, wenn man noch einen Neustart des Systems macht.
Das Linksys-Tool verbindet standardmäßig also nicht mit einem offenen WLAN aus der Profil-Liste.

b. Der Windows interne WLAN-Manager
- Beide APs sind anfangs noch unverschlüsselt.
- Zunächst wird eine Verbindung zum unverschlüsselten AP2 hergestellt. Dazu Rechtsklick auf das Symbol für Drahtlose Netzwerke in der Stausleiste → Verfügbare Drahtlose Verbindungen anzeigen → SSID aus der Liste auswählen → auf Verbinden klicken.
- Windows warnt daraufhin, dass man sich mit einem unverschlüsselten Netzwerk verbinden kann und das andere den Verkehr mitlesen könnten.
- Das Profil für OpenUni ist damit automatisch im Windows-WLAN-Manager gespeichert und die Verbindun wird auch standardmäßig automatisch hergestellt.
- Die Verbindung zu OpenUni wird getrennt und AP2 ausgeschaltet
- AP1 wird eingeschaltet.
- Wieder geht der Weg über den Rechtsklick auf das Sysmbol für Drahtlose Verbindungen usw. und es wird zu SSID WLAN, keine Verschlüsselung verbunden.
- Diese mal erfolgt keine Warnung mehr
- Die SSID von AP1 wird auf Home geändert und WPA Verschüsselung wird eingeschaltet.
- Erneut wird mittels Rechtsklick der Verbindungsdialog aufgerufen und es wird zu WPA verbunden, dabei fragt Windows den Key ab.
- AP2 wird zugeschaltet und solange gewartet bis er sichtbar ist.
- AP1 wird abgeschaltet.

Beobachtung:
Nach dem Ausschalten des AP1 sieht man, das kurzzeitig keine Verbindung besteht, dann wird automatisch zu AP2 OpenUni verbunden, was allerdings auch durch einen Hinweis angezeigt wird. Wenn man allerdings von einem Default Windows XP ausgeht, dann wäre es zumindest denkbar, dass der Angreifer diesen Hinweis vielleicht unterdrücken könnte.

Außderdem ist mir noch aufgefallen, dass der Hinweis nach einschalten des Bildschirmschoners verschwunden ist. Erfolgt das ganze in einem unbeobachteten Augenblick des Notebooks, dann bekommt zunächst mal wirklich nichts davon mit.

Die Automatik läßt sich im Profil des betroffenen offenen WLANs jedoch abschalten. Per Standard wird jedoch automatisch verbunden.

Versuch 2: Gleiche SSID

a. Linksys-Tool
Der Aufbau ist genauso wie unter Versuch 1, nur dass halt der AP2 mit verschlüsselung die gleiche SSID erhält. AP1 und AP2 haben beide als SSID die Standard Kennung bei T-Com Routern "WLAN".

Beobachtung:
Das Linksys-Tool zeigt bei SSID mit Kanal und Hinweis ob verschlüsselt oder unverschlüsselt an, verbindet aber wiederum nicht automatisch zum unverschlüsselten WLAN nachdem das verschlüsselte ausgeschaltet wurde.

b. Windows-Tool
Hier wird ziemlicher Murks angezeigt: Es taucht nur einmal der Eintrag WLAN in der Liste verfügbarer drahtlos Verbindungen auf. Dieser Eintrag wird als unverschlüsselt angezeigt, auch wenn man eigentlich noch mit dem verschlüsselten WLAN verbunden ist. Das ist äußerst verwirrend. 😬
Allerdings: Auch hier erfolgt keine automatische Verbindung zu dem ungesicherten WLAN - auch wenn das fälschlicherweise angezeigt wird oder man versucht manuell das unverschlüsselte WLAN anzuwählen.

Eine Verbindung zu dem unverschlüsselten WLAN ist nur dann möglich, wenn man das Profil für WLAN im WLAN-Manager von Windows absichtlich löscht.

Ok... bringt jetzt alles nicht sooo viel für Linux aber es zeigt doch, dass das keine OS-Sicherheits-Lücke ist, sondern eine (eventuelle) der WLAN-Software.

Richtig kritisch wird das ganze dann, wenn man das automatische Verbinden für offene WLANs nicht abschalten kann.

Gruß,
Martin

Im Launchpad gibt es hierzu jetzt ein Ticket: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/210459

Ich habe eine "Idea" erstellt. Unter http://brainstorm.ubuntu.com/idea/10454/ kann man dafür/dagegen stimmen...

Neues Futter:

http://www.heise.de/newsticker/WLAN-wirklich-verschluesselt--/meldung/135021

Dort wird ein weiteres Szenario für das Problem beschrieben.

Allerdings hat sich die Situation für Ubuntu-Nutzer seit NetworkManager 0.7 etwas verbessert: http://bugzilla.gnome.org/show_bug.cgi?id=541257

Anders als im Heise-Artikel derzeit noch geschildert, verbindet der NetworkManager (ab Version 0.7) nicht mit einem "bekannten" AP bei veränderter (oder abgeschalteter) Verschlüsselung. Es ist ein erneuter Klick notwendig. Allerdings wäre hier eine deutliche Warnung wünschenswert...