WPA2 gehackt Android und Linux besonders gefährdet

[Emess]

https://9to5mac.com/2017/10/16/wifi-wpa2-hacked/
Ist da was drann? Wenn ja was?
Für wpasuplicant kam ja heut ein Update für Jessie.

[BenutzerGa4gooPh]

Einschätzung: https://www.heise.de/security/meldung/D ... 63943.html
Stellungnahmen Hersteller: https://www.heise.de/security/meldung/K ... 63455.html
Router, Accesspoints, Repeater und WLAN-Clients müssen gepatcht werden (Protokoll WPA2). Viele Androiden werden wohl warten müssen oder schauen ganz in die Röhre. Wuergaround: internes VPN zwischen WLAN-Router/Accesspoint und WLAN-Client oder ausschließlich verschlüsselte Protokolle (https, TLS, SSL) nutzen. Oder Kabel für wichtige Dinge. Es können wohl "nur" unverschlüsselte Protokolle mitgehört werden, keine "Teilnahme" als WLAN-Client. 5-GHz-WLAN ist im allgemeinen max. durch 2 Ziegelwaende zu "hören". Also ohne spezielle Technik.

Allgemeine Sicherheitshinweise unabhängig von obiger Geschichte:

Man könnte durchaus mal seinen Router/Accesspoint prüfen und WLAN-Passwort (PSK) sicherer/längerer machen
https://wiki.ubuntuusers.de/WLAN/Sonderzeichen/ und Authentifizierung auf WPA2-PSK (AES) only einstellen. (TKIP und WPA sind leicht angreifbar.)

Des Weiteren irgendein Addon für HTTPS only installieren und mal den Thunderbird prüfen, ob Verschlüsselung für SMTP- und IMAP- bzw. Pop3-Server eingestellt ist. Ende-zu-Ende verschluesselnde Messenger haben klare Vorteile. Metadaten ausgeschlossen.

Irgendwelche Administrationen (Root-Passworte) per Smartphone sind aus vielen Gründen ungut ... Ich hätte auch kein Vertrauen zu SSL-Apps. Quellen-TKÜ von Google und App-Hersteller?

Edit: Rechtschreibung

[Nice]

Jana66:

Es können wohl "nur" unverschlüsselte Protokolle mitgehört werden,

So isses. Banking über https ist zum Beispiel nach den Meldungen gefahrlos.
Und einem Android-Smartphone würde ich keine sensiblen Daten anvertrauen.
Das Wlan habe ich als privater Single-User sowieso deaktiviert.

Und vor Allem - Entwarnung, wenn der Rechner auf dem aktuellen Stand ist:

For the oldstable distribution (jessie), these problems have been fixed in version 2.3-1+deb8u5.
For the stable distribution (stretch), these problems have been fixed in version 2:2.4-1+deb9u1.
For the testing distribution (buster), these problems have been fixed in version 2:2.4-1.1.
For the unstable distribution (sid), these problems have been fixed in version 2:2.4-1.1.

Aus: https://www.debian.org/security/2017/dsa-3999

[BenutzerGa4gooPh]

Und vor Allem - Entwarnung, wenn der Rechner auf dem aktuellen Stand ist:

Nö. Erst wenn der WLAN-Router auch gepatcht wurde.

[Emess]

Man könnte bei der Gelegenheit durchaus mal seinen Router/Accesspoint prüfen und WLAN-Passwort (PSK) sicherer/längerer machen
https://wiki.ubuntuusers.de/WLAN/Sonderzeichen/ und Authentifizierung auf WPA2-PSK (AES) only einstellen. (TKIP und WPA sind leicht angreifbar.)

Ich sag mal mein WPA Password ist lange und enhält Groß/Klein, Zahlen und Sonderzeichen.
Bin ich jetzt sicher?
Achja Update für Fritzbox gab es ja heute auch.
Nur hab ich keine Ahnung was bei wpasuplicant und bei der Fritzbox gepatcht wurde.

[BenutzerGa4gooPh]

Ich sag mal mein WPA Password ist lange und enhält Groß/Klein, Zahlen und Sonderzeichen.
Bin ich jetzt sicher?

Im Rahmen der aktuellen Authentifizierung relativ sicher.
Das komplexe Passwort hilft aber nicht gegen "Krack", also Angriffe auf das Authentifizierungsprotokoll WPA2, da helfen nur Patches für das Protokoll WPA2 an sich, d. h. Patches für WLAN-Router und WLAN-Client. Oder Verschlüsselung oder Kabel.

Debian hat gepatcht, AVM weiß ich nicht.

[Nice]

Was Patches von Routern betrifft:
Die Telekom hat informiert, welche ihrer Router möglicherweise verwundbar sind und Firmware-Updates bereitgestellt.
https://www.telekom.de/hilfe/geraete-zu ... 23-v-typ-b

[Emess]

Debian hat gepatcht, AVM weiß ich nicht.

Dann finde ich es ganz schön Keck in der Tagesschau zu behaupten Linux wäre besonders gefährdet.

[mat6937]

..., AVM weiß ich nicht.

AVM wird wegen Repeater und Client auch patchen. Wenn die FritzBox nur als WLAN-Router verwendet wird, muss nicht gepatcht werden, denn:

Eine FRITZ!Box am Breitbandanschluss ist nach aktuellem Stand nicht von der "Krack" genannten WLAN-Sicherheitslücke betroffen, da sie als Access Point die betroffene Norm 802.11r nicht verwendet.

Quelle: https://avm.de/aktuelles/kurz-notiert/2 ... st-sicher/

Wenn der wpa_supplicant/hostapd nicht mit:

Code: Alles auswählen

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

kompiliert ist, ist er auch nicht gefährdet.

Patches für den wpa_supplicant gibt es schon seit dem 2.10.17: https://w1.fi/security/2017-1/

[63slippy]

Heute sind aber wieder updates für wpa _supplicant gekommen und das nicht nur bei debian. Ist sicher kein Zufall.

Gesendet von meinem SM-A700FD mit Tapatalk

[dufty2]

Und vor Allem - Entwarnung, wenn der Rechner auf dem aktuellen Stand ist:

For the oldstable distribution (jessie), these problems have been fixed in version 2.3-1+deb8u5.
For the stable distribution (stretch), these problems have been fixed in version 2:2.4-1+deb9u1.
For the testing distribution (buster), these problems have been fixed in version 2:2.4-1.1.
For the unstable distribution (sid), these problems have been fixed in version 2:2.4-1.1.

Aus: https://www.debian.org/security/2017/dsa-3999

Ja, nur dumm, dass das halt nicht stimmt
Zumindest bei testing (buster) nicht:

Code: Alles auswählen

# apt-get install wpasupplicant 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
wpasupplicant is already the newest version (2:2.4-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

testing's 2:2.4-1 ist vom Februar, benötigt wird aber sid's 2:2.4-1.1 von Montag (siehe unten).
Das ist allgemein ein bekannter Nachteil von testing, dass security-updates erst einige Tage später eintrudeln als bei stable oder auch sid

Code: Alles auswählen

wpa (2:2.4-1.1) unstable; urgency=high

  * Non-maintainer upload by the Security Team.
  * Fix multiple issues in WPA protocol (CVE-2017-13077, CVE-2017-13078,
    CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082,
    CVE-2017-13086, CVE-2017-13087, CVE-2017-13088):
    - hostapd: Avoid key reinstallation in FT handshake
    - Prevent reinstallation of an already in-use group key
    - Extend protection of GTK/IGTK reinstallation of
    - Fix TK configuration to the driver in EAPOL-Key 3/4
    - Prevent installation of an all-zero TK
    - Fix PTK rekeying to generate a new ANonce
    - TDLS: Reject TPK-TK reconfiguration
    - WNM: Ignore WNM-Sleep Mode Response if WNM-Sleep Mode
    - WNM: Ignore WNM-Sleep Mode Response without pending
    - FT: Do not allow multiple Reassociation Response frames
    - TDLS: Ignore incoming TDLS Setup Response retries

 -- Yves-Alexis Perez <corsac@debian.org>  Mon, 16 Oct 2017 10:28:41 +0200

[dufty2]

Patches für den wpa_supplicant gibt es schon seit dem 2.10.17: https://w1.fi/security/2017-1/

Sorry, da bin ich anderer Meinung:
Wichtig ist nicht, wann ein Hersteller Patches auf seinen Web-Server hochlädt,
sondern ab wann sie tatsächlich verfügbar sind.

AVM und wohl auch Debian haben von den Patches erst am 16.10 (also Montag) Kenntnis erhalten.
Und das Teil hat immerhin 9 CVEs generiert

[mat6937]

...
sondern ab wann sie tatsächlich verfügbar sind.

Verfügbar für wen? Für den einzelnen User, für den package-maintainer, für die Router-Hersteller/Firmware-Programmierer, für die User die den wpa_supplicant bzw. hostapd selber kompilieren/patchen, ...?

Wenn das so ist, dann denke ich, dass es an AVM und an Debian liegt, dass diese erst am 16.10 (also Montag) Kenntnis erhalten haben.

Betr. AVM, siehe z. B. auch diesen Beitrag aus dem IPPF: https://www.ip-phone-forum.de/threads/n ... st-2246306

EDIT:

(Although OpenBSD has already released a patch, in July, after being informed of the vulnerability by Vanhoef before he made this public disclosure.)

Quelle: https://techcrunch.com/2017/10/16/wpa2- ... n-attacks/

[dufty2]

Wenn das so ist, dann denke ich, dass es an AVM und an Debian liegt, dass diese erst am 16.10 (also Montag) Kenntnis erhalten haben.

Nö.

Wenn man in den Ordner schaut, sieht man, dass die letzte Datei
16-Oct-2017 09:17 (UTC)
als Zeitstempel ausgibt
=> Das ist der Zeitpunkt der Veröffentlich des gesamten Folders
Das Debian Security Team war sehr schnell und hat ein neues Paket gebaut wenige Stunden danach.

Aber die eigentliche Security-Vorgehensweise, welche auch AVM anmahnt, ist, dass der Hersteller der Software die (großen) Distributionen vorher informiert, die ca. 2 Wochen Zeit haben, Pakete zu bauen
und bei der Veröffentlichung der Schwachstelle haben die (großen) Distributionen die Fixes schon parat.

Das ist hier wohl nicht geschehen.
So habe ich das ganze verstanden.

[mat6937]

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?

[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.