WPA2 gehackt Android und Linux besonders gefährdet

[dufty2]

So habe ich das ganze verstanden.

Warum wurde OpenBSD _direkt_ vom Entdecker (der Schwachstelle) informiert und konnte deshalb schon im Juli die betroffene Software patchen und warum ist Debian erst vom Softwarehersteller (wpa_supplicant/hostapd) am 16. Oktober informiert worden?

OpenBSD ist - wie w1.fi für hostapd/wpasupplicant - Hersteller von WPA2-Software und wurde am 14./15. Juli informiert.
OpenBSD hat - eigenmächtig - Patches am 30. August veröffentlich.
vgl. auch https://www.krackattacks.com/ ganz unten:
"When did you first notify vendors about the vulnerability?" sowie
"Why did OpenBSD silently release a patch before the embargo?"

Debian - als Distributor - wurde am 28. August informiert vom CERT:
http://www.kb.cert.org/vuls/id/228519

Dass der Folder https://w1.fi/security/2017-1/ erst zum 16. Oktober und nicht schon zum 2. Oktober sichtbar - für die Öffentlichkeit - war, ist meine Interpretation, die nicht stimmen muss.
Im git-repository von w1.fi tauchen die Patches jedenfalls erst ab ca. 23:00 Uhr 15. Oktober auf:
https://w1.fi/cgit/hostap/commit/?id=0e ... 54ad6a9449 und ff.

Kann gut sein, dass AVM sich übers OpenBSD "Vorpreschen" aufgeregt hat.

[hikaru]

Mal eine praktische Frage am Rande:
An meinem Plastik-Router hängt per Ethernet mein HTPC/Fileserver-Notebook das 24/7 läuft und dessen WLAN-Karte sich wohl dazu eignet, per hostapd einen eigenen WLAN-Host aufzumachen, was angesichts der Update-Situation insgesamt sicherer sein dürfte, als das WLAN des Plastik-Routers. Die Reichweite sei hier erstmal zweitrangig.

Anleitungen zu hostapd gibt es ja genügend. Ich habe sie bisher nicht bis in's letzte Detail durchschaut, aber ich glaube die Idee verstanden zu haben.
Bisher ist mir allerdings nicht klar, mit welchen zusätzlichen Diensten ich mich beschäftigen müsste, um tatsächlich ein eigenes WLAN aufzumachen über das andere Geräte in's Internet kommen. Ich brauche ja eine Bridge vom Ethernet- zum WLAN-Chip und einen dhcp-Server hätte ich auch gern. Übernimmt das hostapd? Und brauche ich dann noch einen dns-Server?
Gibt es dafür vielleicht irgendwo eine "rundum-sorglos"-Anleitung?

[MSfree]

Bisher ist mir allerdings nicht klar, mit welchen zusätzlichen Diensten ich mich beschäftigen müsste

Um es kurz zu machen, ausser hostapd brauchst du nichts zusätzliches.

Ich brauche ja eine Bridge vom Ethernet- zum WLAN-Chip

Das läßt sich relativ einfach über /ets/network/interfaces konfigurieren.

und einen dhcp-Server hätte ich auch gern.

Du hast doch einen auf deinem Plastikrouter. Wenn du kein zusätzliches Subnetz für dein WLAN einrichten willst, kann DHCP weiterhin von deinem Plastikrouter bedient werden.

Übernimmt das hostapd?

Nein.

Und brauche ich dann noch einen dns-Server?

Hier gilt das gleich wie für DHCP. Wenn du kein zusätzliches Subnetz für dein WLAN einrichten willst, kann das dein Plastikrouter weiterhin übernehmen.

Gibt es dafür vielleicht irgendwo eine "rundum-sorglos"-Anleitung?

Google mal nach Raspberry als Access Point.

[mat6937]

Gibt es dafür vielleicht irgendwo eine "rundum-sorglos"-Anleitung?

Siehe z. B.: https://wiki.ubuntuusers.de/WLAN_Router/

[BenutzerGa4gooPh]

Ich brauche ja eine Bridge vom Ethernet- zum WLAN-Chip und einen dhcp-Server hätte ich auch gern. Übernimmt das hostapd? Und brauche ich dann noch einen dns-Server?

Das kann man machen. Bei DHCP-Server-Umzug wäre zu beachten, dass dann ohne Umstände nur das direkt angeschlossene Netzsegment (beide Ports, WLAN und Ethernet)) bedient werden kann. Zentraler DHCP-Server auf dem Router (für alle Netze) ist eleganter. DNS-Server wiederum bietet sich an, könnte man gegenüber Plastikrouter dann "aufbohren" - um DNS-Blocker a la Pihole oder/und unbound als rekursiven Resolver mit DNSSEC. Dieser DNS-Server ist im ganzen Netzwerk erreichbar, einfach dessen IP-Adresse allen Clients "verklickern" (fix oder per DHCP). Evtl. noch dem Router.

Aber bis zum Erfolg der Selbsterstellung eines WLAN-Accespoints lasse erst mal alles auf Router. Der Accesspoint ist nur eine Bridge (Layer 2), ändert am IP-Netz (OSI-Layer 3) gar nichts. Um den AP/NAS zu erreichen, muss dieser fix adressiert oder DHCP-Client und zur Bequemlichkeit DNS-Client und NTP-Client sein. Ist ein normaler Host/Client bezüglich IP.

[hikaru]

Danke euch Dreien!
Alles was irgendwie mit Routing zu tun hat soll weiter vom Plastikrouter kommen, nur den WLAN-Host hätte ich da gern runter. Insofern reicht sicher eine einfache Bridge auf dem Notebook.

[BenutzerGa4gooPh]

Bevor du groß zu basteln anfänbgst, schaue mal, ob deine Karte überhaupt Accesppoint spielen kann. Die meisten Karten können das eh nur auf 2,4 GHz.

Code: Alles auswählen

iw list
oder
iw phy

Links zur Auswertung: viewtopic.php?f=30&t=166520#p1143875

Edit: Korrektur.

[hikaru]

Bevor du groß zu basteln anfänbgst, schaue mal, ob deine Karte überhaupt Accesppoint spielen kann.

Ja, kann sie laut iw list und den Aussagen diverser hostapd-Tutorials zur Ausgabe.

[scientific]

Hab mal in der Firma Alam geschlagen.

Und ich bekam als Antwort:
Nicht besonders gefährlich. Warum machst du so einen Hallo? Aber dein Linux ist besonders gefährdet...

Hab gesagt, die Geschichte ist ca. so sicher wie eine mit Draht überbrückte Sicherung...

Bei uns sind ausschließlich Windowsrechner im Einsatz, mit teilweise sensiblen Patientendaten...

[Lord_Carlos]

Windows ist schon gepatched.
Die Patientendaten sind nur gefährdet wenn man die unverschluesselt via Wlan versendet.

[MSfree]

Windows ist schon gepatched.

wpa_supplicant und hostapd sind für Linux auch schon gepatcht.

Wenn aber der billige Pastikrouter noch nicht gepatcht wurde, wovon man in kleinen Betrieben zu fast 100% ausgehen kann, kannst du Windows soviel patchen wie du willst, dann greife ich halt den WLAN-Router an.

Die Patientendaten sind nur gefährdet wenn man die unverschluesselt via Wlan versendet.

Die Patientendaten werden vermutlich ganz einfach mittels SMB übertragen, Verschlüsselung = Fehlanzeige.

[TRex]

Wenn man der heise-Erklärung folgt, sind Router nur angreifbar, wenn sie als Client agieren (repeater).

[mat6937]

... folgt, sind Router nur angreifbar, wenn sie als Client agieren (repeater).

Sie sind auch als WLAN-Router angreifbar, wenn sie:

Code: Alles auswählen

# IEEE Std 802.11r-2008 (Fast BSS Transition)
CONFIG_IEEE80211R=y

implementiert haben.

[MSfree]

Wenn man der heise-Erklärung folgt, sind Router nur angreifbar, wenn sie als Client agieren (repeater).

Nein, denn sonst hätte man für Linux den hostapd nicht gepatcht. Die größte Gefahr geht mal wieder vov ungepatchten WLAN-Routern aus. Aber ich gebe zu, daß keine einzige Erklärung, die ich im Internet gelesen habe, wirklich eindeutig sagt, was Sache ist. Es wird sensationsheischend dieser Bug verbreitet, aber nicht klar gesagt, was denn wirklich kaputt ist.

Ich gehe sogar davon aus, daß man auf die Art und Weise, wie der Angriff durchgeführt wird, auch der WPA-Key auslesbar ist, obwohl überall vehement das Gegenteil behauptet wird. Das Geeiere um die echten Auswirkungen dieses Bugs bestätigt mich eigentlich nur in meiner Annahme, daß wohl auch die Patches, die jetzt veröffentlicht wurden, nur ein notdürftiges Pflaster sein werden. Vermutlich brauchen wir WPA3, um der Lage Herr zu werden.

[guennid]

Da ich z.Z. noch andere Software-Sorgen habe, würde ich dem Verwirrspiel auch gerne verweigern, solange man nicht weiß, was Sache ist.

Ich lese hier immer "Router". Meine Router sind lediglich per Kabel, bzw. DSL ans Internet angeschlossen. Aber was ist mit Plastik-AP, über den ein paar Rechner an die Router angeschlossen sind?

Grüße, Günther

[MSfree]

Ich lese hier immer "Router".

Ein WLAN-Router ist ein Router mit integriertem WLAN Accesspoint. Wenn du also auf deinen "nur" per Kabel" angeschlossenen Router das WLAN nicht abgeschaltet hast, ist es prinzipiell verwundbar.

Aber was ist mit Plastik-AP

Der Plastik-AP ist selbstverständlich genau der verwundbare Teil, um den du dir Gedanken machen mußt.

Alles, was irgendwie über WLAN funkt (Laptops, Tabletts, APs, WLAN-Router, Smartphones, IoT-Devices, TV-Geräte, Überwachungskameras, Amazon Alexa...) ist angreifbar.

[guennid]

Wenn du also auf deinen "nur" per Kabel" angeschlossenen Router das WLAN nicht abgeschaltet hast,

Ist abgeschaltet.

Der Plastik-AP ist selbstverständlich genau der verwundbare Teil, um den du dir Gedanken machen mußt.

Dachte ich mir schon. Daher liebäugele ich mit hikarus Idee. Ob die WLAN-NIC auf einem eeepc 4g hostapd-tauglich ist, muss ich noch rausfinden.

Grüße, Günther

[hikaru]

Ob die WLAN-NIC auf einem eeepc 4g hostapd-tauglich ist, muss ich noch rausfinden.

Soweit ich weiß steckt da ein Atheros-Modul drin, mit dem es gehen sollte. Aufschluss gibt die Ausgabe von iw list, wobei das Entscheidende dann diese beiden Punkte wären:

Code: Alles auswählen

Supported interface modes:
		 * AP
		 * AP/VLAN

[scientific]

Unser IT-Dienstleister gibt für die Remote-Desktopverbindung ein Zertifikat heraus, das von einer in den Browsern bekannten CA signiert ist, heraus, das auf "*.domain.example" ausgestellt ist. Der Gateway für die RDP-Verbindung passt. Der Sessionhost endet dann auf *.LOCAL

Der Rdp-Client bemängelt zurecht ein unkorrektes Zertifikat. Der Workaround ist "Klicken sie bitte die Warnmeldung weg"
Meine Bitte nach einem korrekten Zertifikat wird "nicht einmal ignoriert"...

Dieser Dienstleister meint nun, dass vom WPA-Crack keine Gefahr ausgeht. Die Geschäftsführung glaubt den Experten und meint belustigt "DEIN Linux ust ja viel gefährdeter"...

Angenommen, ein Bösewicht nutzt den Wpa-Bug aus und lenkt die Rdp-verbindung über einen Man-in-the-middle-Rechner um und greift sich Logindaten ab. Dann meckert natürlich der RDP-Client ein fehlerhaftes Zertifikat. Die User lernten diese Warnung wegzuklicken... Und schon ist der Angreifer im Netz bei uns.
Klingt das realistisch (wenn auch unwahrscheinlich)? Könnte man dann so auch eine ssl-verschlüsselte Verbindung öffnen?

Lg scientific

[MSfree]

Soweit ich weiß steckt da ein Atheros-Modul drin

Richtig, im 70x-Modell steckt Atheros. Es kann aber nur 54MBIt/s brutto, ist also entsprechend lahm.

Mein Ansatz wäre eher, über WLAN nur noch OpenVPN zuzulassen, entsprechende Firewallregeln kann man relativ einfach einrichten. Ich hatte so etwas mal vor langer Zeit, als ich noch einen AP hatte, der nur WEP konnte.

Fremde können mit so einem WLAN nichts anfangen, weil das nichts durchrouten würde außer OpenVPN-Pakete, und für OpenVPN gibt es für jeden Rechner ein eigenes Zertifikat.

[MSfree]

Angenommen, ein Bösewicht nutzt den Wpa-Bug aus und lenkt die Rdp-verbindung über einen Man-in-the-middle-Rechner um und greift sich Logindaten ab.

Angeblich ist MiM im Moment nicht möglich. Man kann nur den unverschlüsselten WLAN-Verkehr mitlesen aber nichts selbst einstreuen. Es wird auch versichert, daß man durch mitlesen (angeblich) nicht an den WPA-Key kommt.

Wer also im Moment seine Netzwerkverbindungen zusätzlich über Verschlüsselung absichert, hat erstmal kein großes Problem. Im Moment kann man dann nur evrschlüsselte Pakete mitlesen.

Aber, wie gesagt, ob man nicht doch noch an den WPA-Key kommt, kann ich nicht ausschließen.

[hikaru]

Mein Ansatz wäre eher, über WLAN nur noch OpenVPN zuzulassen,

Das Konzept durcblicke ich nicht auf Anhieb. Was passiert dann mit den OpenVPN-Paketen im Plastikrouter? Ich habe mich hostseitig nie mit VPN beschäftigt.

[TomL]

Was passiert dann mit den OpenVPN-Paketen im Plastikrouter?.

Nix, weil es die da nicht gibt. Die Vpn-Verbindung befindet sich zwischen Client und wlan-AP. Zwischen AP und dem DSL-Router ist ne normale Leitung mit normalen TCP/UDP-Paketen. Das heisst, im wlan-Router kommen auf dem tun-Interface vpn-Pakete rein und gehen via eth0-Interface unverschlüsselt an den DSL-Router.

Technisch könnten sich alle Clients mit dem AP verbinden , aber via Iptables werden nur VPN-Pakete geroutet, alles andere hingegen gedropt. Damit ist der AP für Nicht-VPN-Clients quasi unbenutzbar. Und die VPN-Clients haben 'personifizierte' Zertifikate. Ich hoffe, ich habe msfree' Idee richtig verstanden

[MSfree]

Mein Ansatz wäre eher, über WLAN nur noch OpenVPN zuzulassen,

Das Konzept durcblicke ich nicht auf Anhieb.

Ich hatte, wie geasgt, mal einen WEP-only Accesspoint. Den habe ich per Ethernetkabel an einer zweiten Netzwerkschnittstelle eines Linuxrechners angeschlossen und darüber ein eigenes Subnetz aufgespannt. Der Linuxrechner hat per iptables nur UDP 1194 durchgelassen, ebenso die WLAN-Clients.

Der OpenVPN-Server lief auf dem Linuxrechner, an dem die WLAN-Kiste angeschlossen war. OpenVPN habe ich so konfiguriert, daß man die virtuelle tun/tap-Schnittstelle, mit dem lokalen LAN bridgen konnte.

Über das VPN waren dann alle WLAN-Clients auch Mitglied im lokalen LAN, so daß keine weiteren Konfigurationen auf den Clients nötig war, ausser dort OpenVPN einzurichten.

Was passiert dann mit den OpenVPN-Paketen im Plastikrouter?

Gar nichts, die Plastikbüchse sieht die Pakete nicht einmal. Das WLAN im Plastikrouter muß allerdings ausgeschaltet werden, du brauchst ein zweites Gerät oder hast sowieso noch einen alten AP oder nimmst einen USB-WLAN-Stick und steckst ihn an einen Linuxrechner, der immer läuft.

[dufty2]

Mmmh, wird mal Zeit, sich mit WLAN genauer zu beschäftigen.
Ohne irgendwas gelesen zu haben - denke ich - ist bei WLAN:
Den (4-Wege)-Handshake initiiert stets der "wlan-client" => sind also "im Netz" nur zwei WLAN-AccessPoints (AP) - sprich zwei "wlan-server" - passiert gar nichts.
Das ändert sich für den "wlan-server" dann, wenn er a) im repeater- b) mesh- c) roaming(802.11r-2008)-mode sich befindet.

Und da Debian's hostapd die Confg
CONFIG_IEEE80211R=y
hat, muss er auch gepatcht werden.

Die 3 Modi sind bei hikaru - wenn ich seinen Netzaufbau richtig interpretiere - nicht vorhanden.
Daher weiss ich nicht, ob sein Projekt einen großen Sicherheitsgewinn bringt.

Aber wie gesagt, von WLAN keine Ahnung, lasse ich mich gerne belehren