WPA2 gehackt Android und Linux besonders gefährdet

[mat6937]

... habe ich eine hostapd.conf ...

Evtl. für zusätzliche Sicherheit, den hostapd mit z. B.:

Code: Alles auswählen

CFLAGS += -DDEFAULT_WPA_DISABLE_EAPOL_KEY_RETRIES=1

patchen/kompilieren/konfigurieren.

Quelle: https://w1.fi/cgit/hostap/commit/?id=6f ... 45ed8e52d3

[BenutzerGa4gooPh]

Das Entscheidende scheint das Zuweisen einer Netzwerkadresse an die Bridge in /etc/network/interfaces überhaupt zu sein. netmask und broadcast haben offenbar keinen Einfluss. Aber wenn ich eine address-Zeile zuweise (auch 192.168.1.10, was im selben Subnetz wie mein restliches Netzwerk liegt), dann funktioniert hostapd, aber nicht das restliche Netzwerk und wenn ich sie nicht zuweise, dann ist es genau andersrum. Dabei ist es für die Funktionstüchtigkeit des Netzwerks egal, ob hostapd schon läuft oder noch nicht.

Die Bridge ist auch nur ein Host im entsprechenden Netzsegment:
Router - LAN-Subnet - Ethernetport der Bridge- Bridge (IP) - WLAN-Port der Bridge - WLAN (= LAN-Subnet). Also Bridge-IP ausschließlich aus LAN-Subnet und ausserhalb DHCP-Pool des Routers! Die Bridge-IP ist eigentlich die gleiche, wie die normale IP des Rechners. DHCP-Dienste müssen gar nicht laufen (werden durchgereicht), DNS-Forwarder nur um auf dem Rechner arbeiten zu können. Auch für Host im WLAN ist der DNS des Routers zuständig. Schaue mal nach sich "kannibalisiernden" Netzwerkdiensten (network-manager, dnsmasq, systemd?). Und für Bridge gleiche IP-Konfiguration wie für Hosts im WLAN und vorgeschalteten LAN-Segment. Da fixe IP ausserhalb DHCP-Pool.

[BenutzerGa4gooPh]

"Krack" hat seinen "Weg" zu Wikipedia gefunden.

Die Sicherheitslücke betrifft die clientseitige Implementation von IEEE 802.11s und die Accesspoints bei der IEEE 802.11r beim „MESH-Roaming“ und nicht nur einzelne Implementierungen.[4]

https://de.m.wikipedia.org/wiki/WPA2#Ke ... on_Attacks
Mit Wissen um die betroffenen Standards kann man Risikoabschaetzungen für den Weiterbetrieb von WLAN-Komponenten vornehmen, die absehbar nicht (mehr) oder nicht "zeitnah" gepatcht werden.

802.11r betrifft Roaming in WLAN-Netzen mit mehreren Accesspoints. Implementierung für AP und Client notwendig.
Datenblatt suchen: Ist das in meinem Accesspoint/Router überhaupt implementiert? In meinem WLAN-Client, meinem Repeater?
In alten Android-Smartphones 802.11r eher nicht, "Roaming" durch Reaktivieren WLAN, AP mit höherem Pegel bei gleicher SSID/PSK wird gewählt. KISS.
https://en.m.wikipedia.org/wiki/IEEE_802.11r-2008

802.11s kann ich nicht abschätzen, da müsste man tiefer graben als hier: https://de.m.wikipedia.org/wiki/IEEE_802.11s

Jedenfalls wollen momentan nicht alle Hersteller von Accesspoints unverzüglich patchen. Z. B. keine Aussage von Devolo gefunden ausser diesem (unverbindlichen) Beitrag: https://www.heise.de/forum/heise-Securi ... 1501/show/
Keine neue Software auf Downloadseiten für "Bussiness"-WLAN.
https://www.devolo.de/business-solution ... 0-wifi-ac/
Eine offizielle Stellungnahme eines "Platzhirschen" wäre angebracht.

[dufty2]

Da Du im Grunde nur eine "WLAN-Bridge" aber keinen "WLAN-Router" benötigst, könnten die Zeilen

Code: Alles auswählen

address 192.168.3.1
netmask 255.255.255.0
broadcast 192.168.3.255

Nach Auskommentieren dieser Zeilen funktioniert die Netzwerkkommunikation mit anderen Rechnern wieder, allerdings scheitert dann der Handshake in hostapd:

Das kann gut sein, denn wenn ich mich dunkel erinnere, war die bridge "wlan-ethernet" etwas komplizierter als die bridge "ethernet-ethernet".
Unter
https://www.elektronik-kompendium.de/si ... 002161.htm
ist auch eine bridge-Konfiguration benannt, die ich so auch von "ethernet-ethernet"-bridges kenne:
Die IP/NM/default-gw bekommt das bridge-interface ("virtueller IP"), die unter der bridge gehängten physikalischen Interfaces bekommen selbst keine IP mehr zugewiesen.
Kannst ja nochmals so testen.

[hikaru]

Evtl. für zusätzliche Sicherheit, den hostapd mit z. B.:

Code: Alles auswählen

CFLAGS += -DDEFAULT_WPA_DISABLE_EAPOL_KEY_RETRIES=1

patchen/kompilieren/konfigurieren.

Quelle: https://w1.fi/cgit/hostap/commit/?id=6f ... 45ed8e52d3

Danke für den Hinweis!

Die Bridge ist auch nur ein Host im entsprechenden Netzsegment:
Router - LAN-Subnet - Ethernetport der Bridge- Bridge (IP) - WLAN-Port der Bridge - WLAN (= LAN-Subnet). Also Bridge-IP ausschließlich aus LAN-Subnet und ausserhalb DHCP-Pool des Routers!

Ich denke, der Teil ist mir klar.

Die Bridge-IP ist eigentlich die gleiche, wie die normale IP des Rechners.

Das ändert hier nichts. Ich habe gerade mal dem LAN-Interface und der Bridge statisch die selbe IP zugewiesen, aber auch dann lässt sich der Rechner nicht anpingen, während eine WLAN-Verbindung per hostapd funktioniert. Wenn ich die IP-Adresse der Bridge gar nicht definiere, dann habe ich wieder den umgekehrten Fall, dass zwar der Rechner selbst im LAN ereichbar ist, aber per hostapd keine WLAN-Verbindungen mehr gehen.

DHCP-Dienste müssen gar nicht laufen (werden durchgereicht), DNS-Forwarder nur um auf dem Rechner arbeiten zu können.

Keines von beiden läuft momentan auf dem Rechner.

Schaue mal nach sich "kannibalisiernden" Netzwerkdiensten (network-manager, dnsmasq, systemd?).

network--manager habe ich abgeschaltet. Das war nötig um hostapd überhaupt starten zu können.
dnsmasq ist nicht installiert, dnsmarq-base war als Abhängigkeit von network-manager vorhanden, das dnsmasq-Binary läuft aber nicht.
Bei systemd weiß ich nicht wonach ich schauen soll.

Und für Bridge gleiche IP-Konfiguration wie für Hosts im WLAN und vorgeschalteten LAN-Segment. Da fixe IP ausserhalb DHCP-Pool.

Das scheint sich mit dem Plastikrouter zu beißen. Jedenfalls kann ich dann trotz stehender Verbindung weder in's LAN noch in's Internet pingen.

802.11r betrifft Roaming in WLAN-Netzen mit mehreren Accesspoints. Implementierung für AP und Client notwendig.
Datenblatt suchen: Ist das in meinem Accesspoint/Router überhaupt implementiert? In meinem WLAN-Client, meinem Repeater?

Angenommen das sei in meinem AP implementiert, reicht das schon für Verwundbarkeit oder muss das Feature auch aktiviert sein?
Mein Bauch sagt "nein", aber wie die Zurschaustellung meiner Netzwerkkompetenz in diesem Thread zeigt, sollte ich mich darauf nicht verlassen.

Unter
https://www.elektronik-kompendium.de/si ... 002161.htm
ist auch eine bridge-Konfiguration benannt,

Danke! Die Konfiguration funktioniert.
Entscheidender Punkt könnte sein, dass da beide Enden der Bridge definiert sind (was mir logisch erscheint). Im Ubuntuusers-Wiki steht hingegen, das hostapd die Anbindung des WLAN-Interfaces an die Bridge übernimmt.

[ingo2]

Ich verfolge das hier auch mit Interesse. Zunächst nur wegen der WPA2-Geschichte, jetzt aber auch bezüglich "Brückenbau". Bin nämlich auch gerade auf meinem APU.2C die 3 Ethernet-Ports zu einer "br0" zusammengeschlossen - die laufen jetzt vorläufig als dummer Switch.

Der nächste Schritt soll dann ein minimales Routen/Firewalling auf der Bridge sein (mit iptables, ebtables und arptables muß ich mich erst noch vertraut machen).

Was mir aber schon jetzt noch völlig unklar ist - das könnte ja auch hikaru interessieren:
Was ist mit IPv6 ???

Schon in der default-Konfiguration nach der Installation von Stretch hatte ich folgende Zeile in der interfaces:

Code: Alles auswählen

# This is an autoconfigured IPv6 interface
iface enp1s0 inet6 auto

Habe das erstmal einfach kommentiert - aber dennoch funktioniert IPv6 über die Bridge, obwohl ich nur eine IPv4-Adresse statisch vergeben habe!?
Und die ganzen schönen Filter-Regeln reden nur von und konfigurieren nur IPv4. Ist das nicht irgendwo widersinnig, mit IPv6 umgeht man doch das ganze Routing-Konstrukt, oder denke ich da falsch?

Viele Grüße,
Ingo

[dufty2]

Habe das erstmal einfach kommentiert - aber dennoch funktioniert IPv6 über die Bridge, obwohl ich nur eine IPv4-Adresse statisch vergeben habe!?
Und die ganzen schönen Filter-Regeln reden nur von und konfigurieren nur IPv4. Ist das nicht irgendwo widersinnig, mit IPv6 umgeht man doch das ganze Routing-Konstrukt, oder denke ich da falsch?

Haben wir doch gelernt
Bei einer Bridge/Switch bräuchten wir gar keine IP(4/6)-Adresse,
die geht ja auf Layer-2 und so ist der übergeordnete Layer-3 (Routing) nicht von Belang.

Code: Alles auswählen

$ cat /etc/ethertype

zeigt Dir auf, dass es neben IPv4 und IPv6 'ne Menge Protokolle auf Layer-3 gibt.
Jene könnte man ggf. auch per "ebtables" blocken.

[ingo2]

Haben wir doch gelernt
Bei einer Bridge/Switch bräuchten wir gar keine IP(4/6)-Adresse,
die geht ja auf Layer-2 und so ist der übergeordnete Layer-3 (Routing) nicht von Belang.

... zeigt Dir auf, dass es neben IPv4 und IPv6 'ne Menge Protokolle auf Layer-3 gibt.
Jene könnte man ggf. auch per "ebtables" blocken.

Da fehlt mir jetzt echt das Verständnis. Wie soll dann eine Firewall auf so einer Bridge laufen, wenn eh' alle Ports wie eine "Mehrfachsteckdose" verbunden sind? Was macht dann überhaupt der Kernel noch?
Gibt's irgendwo da ein Tutorial, wo die Zusammenhänge für Anfänger auf dem gebiet erklärt sind?

Was ich mir noch vorstellen könnte, wäre eine Flußsteuerung anhand von MAC-Adressen, d.h. eth1 darf mit eth2 und eth3 kommunizieren, aber eth2 darf nicht mit eth3 kommunizieren ... usw.

Ingo

[dufty2]

Du willst doch unbedingt eine Firewall auf eine Bridge laufen lassen
Die meisten Firewall, die ich so kenne, sind eher Router als Bridges/Switche.

Aber der kernel hat schon einige Möglichkeiten, z. B. kann man ipv6 komplett abschalten.
Und was er im Fall einer bridge macht, kannst Du z. B. hier nachlesen unter "bridge processing":
https://vincent.bernat.im/en/blog/2017- ... -isolation

Recht bekannt ist auch
https://wiki.linuxfoundation.org/images ... kernel.png

Wobei ich zugebe, letzteres auch nicht verstanden habe

[ingo2]

Du willst doch unbedingt eine Firewall auf eine Bridge laufen lassen

Nachdem ich deinen Link gelesen habe, nicht mehr - Danke!
Sicherheit bringt das praktisch kaum, im Gegenteil, es wird soooo kompliziert, daß Fehler unvermeidbar sind und ich mir das nicht zutraue. Also meine 2 übrigen/ungenutzten Ports werden zum Switch - fertig. Kann man ja noch als Monitoring Port für Wireshark nutzen, da die Interfaces alle im promiscuous mode laufen.
Aber gelernt habe ich trotzdem viel: eine wirklich gute Firewall gehört nicht umsonst auf eine dezidierte Hardware mit professioneller Software. Die sollte dann aber nicht nochmal NAT machen und auch IPv6-tauglich sein.
Und - was jetzt hikaru beachten sollte: so eine WLAN-Ethernet-Bridge öffnet das ganze Heimnetz über WLAN!

Recht bekannt ist auch
https://wiki.linuxfoundation.org/images ... kernel.png

Dass das alles funktioniert - wer hat da den Überblick

[BenutzerGa4gooPh]

Angenommen das sei in meinem AP implementiert, reicht das schon für Verwundbarkeit oder muss das Feature auch aktiviert sein?

Das weiß ich nicht, kommt wohl auf die programmierte "Implementierung der Deaktivierung" an.

Und das ist ebenfalls offen:

802.11s kann ich nicht abschätzen, da müsste man tiefer graben als hier: https://de.m.wikipedia.org/wiki/IEEE_802.11s

dufty2 hat geschrieben: Sa 21. Okt 2017, 13:50
Unter
https://www.elektronik-kompendium.de/si ... 002161.htm
ist auch eine bridge-Konfiguration benannt,
Danke! Die Konfiguration funktioniert.

Freut mich auch. Haben "Mitneugierige" einen Link auf eine verifizierte Gebrauchsanleitung.
Du arbeitest nun mit fixer IP und deaktiviertem

Code: Alles auswählen

service dhcpcd stop
systemctl disable dhcpcd

?

[mat6937]

Angenommen das sei in meinem AP implementiert, reicht das schon für Verwundbarkeit oder muss das Feature auch aktiviert sein?

Der WLAN-Client (wpa_supplicant) müsste auch damit bzw. dafür kompiliert _und_ konfiguriert sein. Z. B.:

In der ".config"-Datei zwecks Kompilieren:

Code: Alles auswählen

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

in der wpa_supplicant.conf-Datei zwecks Konfigurieren:

Code: Alles auswählen

# key_mgmt: list of accepted authenticated key management protocols
# ,,,
# FT-PSK = Fast BSS Transition (IEEE 802.11r) with pre-shared key
# FT-EAP = Fast BSS Transition (IEEE 802.11r) with EAP authentication
# ...

[dufty2]

Angenommen das sei in meinem AP implementiert, reicht das schon für Verwundbarkeit oder muss das Feature auch aktiviert sein?

Der WLAN-Client (wpa_supplicant) müsste auch damit bzw. dafür kompiliert _und_ konfiguriert sein.

Man darf davon ausgehen, dass ein Angreifer "mit allen Mitteln gewaschen" ist, sprich alle WLAN-modis zur Verfügung hat.
Dies nicht zu tun, wäre IMHO etwas blauäugig

Aber um auf die Frage etwas konkreter einzugehen, z. B. wird 802.11r in
http://www.arubanetworks.com/assets/ale ... _Rev-1.pdf
erwähnt und - solange nicht konfigueriert - auch nicht als Gefährdung angesehen.
So wird's bei hostapd wohl auch sein, denke ich (sprich: sicher weiß ich es auch nicht ).

Auf der "All Systems Go 2017" gab's einen netten Vortrag von Marcel Holtmann,
ist ganz schön über wpa_supplicant hergezogen
https://media.ccc.de/v/ASG2017-132-upda ... _for_linux

[mat6937]

Angenommen das sei in meinem AP implementiert, reicht das schon für Verwundbarkeit oder muss das Feature auch aktiviert sein?

Der WLAN-Client (wpa_supplicant) müsste auch damit bzw. dafür kompiliert _und_ konfiguriert sein.

Man darf davon ausgehen, dass ein Angreifer "mit allen Mitteln gewaschen" ist, sprich alle WLAN-modis zur Verfügung hat.
Dies nicht zu tun, wäre IMHO etwas blauäugig

BTW: Im Zitat geht es aber nur um den 802.11r-FT-Angriff. In deinem 1. Link kann man z. B. Folgendes zu diesem Angriff lesen:

However, if
updating AP software is not possible immediately, an effective mitigation would be disabling 802.11r on
the Aruba infrastructure ...