WIFI: Die FRAGATTACK Apokalypse

Ja, der Titel wäre Click-Bait, wenn es nicht wirklich so schlimm wäre, wie es ist: praktisch jeder Wifi-Stack der bis heute produziert wurde, ist für die FragAttack anfällig.

WIFI: Die FRAGATTACK Apokalypse

Der Name FragAttack ist hier nicht wie sonst üblich ein Akronym für irgendwas langes, sondern bezieht sich ausnahmsweise mal auf die Grundlage des Angriffs: Fehler bei Zusammenfügen von Paketfragmenten.

„Fragmentierung“ meint, daß einzelne große Datenpakete, die nicht durch das Netz/Kanal passen, in kleinere Pakete aufgeteilt und beim Empfänger wieder zusammen gesetzt werden. Das passiert bei IP-Datenpaketen im normalen Netz auch laufend, ist an sich nicht besonderes.

Die Schwachstellen sind in praktisch jeder Implementierung von WEP bis WPA3 enthalten, wobei nicht jede davon überall sein muß.

12 Fehler sollt Ihr sein

Insgesamt wurden 12 Schwachstellen in verschiedenen Implementierungen bzw. dem Wifi-Protokoll an sich gefunden;

CVE-2020-24588: Akzeptieren von nicht-SPP A-MSDU-Frames
CVE-2020-24587: Wiederzusammensetzen von Fragmenten, die unter verschiedenen Schlüsseln verschlüsselt wurden
CVE-2020-24586: Fragmente werden nicht aus dem Speicher gelöscht, wenn eine (erneute) Verbindung zu einem Netzwerk hergestellt wird
CVE-2020-26145: Akzeptieren von Klartext-Broadcast-Fragmenten als vollständige Frames (in einem verschlüsselten Netzwerk)
CVE-2020-26144: Akzeptieren von Klartext-A-MSDU-Frames, die mit einem RFC1042-Header mit EtherType EAPOL beginnen (in einem verschlüsselten Netzwerk)
CVE-2020-26140: Akzeptieren von Klartext-Datenframes in einem geschützten Netzwerk
CVE-2020-26143: Akzeptieren von fragmentierten Klartext-Datenframes in einem geschützten Netzwerk
CVE-2020-26139: Weiterleitung von EAPOL-Frames, obwohl der Absender noch nicht authentifiziert ist
CVE-2020-26146: Wiederzusammensetzen von verschlüsselten Fragmenten mit nicht-fortlaufenden Paketnummern
CVE-2020-26147: Wiederzusammensetzen von gemischten verschlüsselten/Klartext-Fragmenten
CVE-2020-26142: Verarbeitung von fragmentierten Frames als vollständige Frames
CVE-2020-26141: Keine Verifizierung des TKIP-MIC von fragmentierten Frames

„CVE-2020-24587: Wiederzusammensetzen von Fragmenten, die unter verschiedenen Schlüsseln verschlüsselt wurden“ Ist ein Paradebeispiel dafür, daß ganz schlicht jemand einfach mal eine kleine „if ( oldkey == actualkey)“ Abfrage im Code vergessen hat. Wenn man den Testfall nicht dabei hat, weil man nur ein Netz mit nur einem Schlüssel hat, dann kann das schon einmal passieren.

Die Hacker News schreiben dazu, daß Mathy Vanhoef, ein Sicherheitsforscher der New York University Abu Dhabi, die Probleme auf weit verbreitete Programmierfehler zurückführt.

„Ein böser Akteur kann diese Schwachstellen ausnutzen, um beliebige Netzwerkpakete zu injizieren, Benutzerdaten abzufangen und zu exfiltrieren, Denial-of-Service-Angriffe zu starten und möglicherweise sogar Pakete in WPA- oder WPA2-Netzwerken zu entschlüsseln.“

Es sind sogar Angriffe denkbar bei denen  in das Netz oder am Netz beteiligte Rechner eingebrochen werden kann. Dabei wären dann Geräte interessant die keine Updates mehr bekommen haben, wie z.B. so ziemlich jedes Androidgerät älter als 2 Jahre, Windows XP/7 oder Macs.

Die Wifi-Allianz hat in einer mehr als neunmonatigen konspirativen Aktion sukzessive die Gerätehersteller kontaktiert und Updates verteilen lassen. Wohl dem, der die noch bekommt.

Für Windows wurden die Updates schon eingespielt, bei Linux sind auch bereits Patche in den Kernel eingeflossen, müssen aber noch etwas reifen. Da die Lücken nicht ganz so leicht auszunutzen sind, wie das vielleicht klingen mag, ist das „erst einmal“ kein Problem… bis es dann zum Problem wird 😉

Exploits sind nicht auszuschließen, also kümmert Euch am besten auch um Eure ganzen IoT Geräte, DSL-Router, Access-Points und Uralt-Androids.. wenn Ihr noch könnt.

Quelle: https://thehackernews.com/2021/05/nearly-all-wifi-devices-are-vulnerable.html

Pinephone: DANKE ModemManager!

Liebe Linuxphone Fans, es ist passiert! Ich habe mich geirrt und freue mich darüber 😀

Pinephone: DANKE ModemManager!

Die ModemManagerelease 1.16.x kommt mit einer Option daher, die das Pinephone aus dem Winterschlaf holt bzw. es gar nicht erst schlafen lässt. Die Konsequenz ist, das Pinephone verpennt im Tiefschlaf keine Anrufe oder SMS mehr.

Zusammen mit dem aktuellen Fedora Megi-Kernel läuft das Pinephone jetzt wie ein „normales“ Smartphone stundenlang, weil es nicht mehr läuft, wenn es nicht mehr gebraucht wird.

Dabei kann Euch dieses kleine Projekt helfen:

https://github.com/Cyborgscode/pinephone/tree/main/suspendguardian

Das schickt das PinePhone nämlich nach 30 Sekunden Bildschirm aus in den Suspend. Mit dem neuen ModemManager bleibt das Modem wach und kann das System wecken, wenn ein Anruf kommt. SuspendGuardian macht noch mehr und dann genügend präzise konfiguriert werden.

Damit das problemlos funktioniert, macht Ihr folgendes:

cp ModemManager.service /etc/systemd/system/
vi /etc/systemd/system/Modemmanager.service

Die Zeile ExecStart= wird wie folgt geändert:

ExecStart=/usr/sbin/ModemManager –test-no-suspend-resume

Dann  „systemctl daemon-restart; systemctl restart ModemManager“ oder einen kurzen Reboot, falls das nicht klappt 😉

Da ich den neuen Kernel schon testen konnte, weiß ich, daß das Gerät (mit Modem im Tiefschlaf / also vor der Anpassung oben) in 8h knapp 4% Akkuladung verbraucht hat.

Ich habe dies bei meinem Pinephone natürlich schon gemacht und bin mal gespannt , wie viel Strom das Pine so in der Nacht verbrauchen wird. Das ist ein Game-Changer Feature fürs Pinephone!  Weil ab jetzt ist der Verbrauch quasi nur noch von der echten Nutzungsdauer von Apps abhängig.

 

Pinephone: 200mW – neuer Rekord

Wie sagte Prof. Farnsworth immer „Good News Everyone!“ und dann mußte die Mannschaft auf irgendeine tödliche Mission gehen 😀 Ich schwöre, das ist hier nicht der Fall 😉

Pinephone: 200mW – neuer Rekord

Mit dem aktuellen Megi-Fedora-Kernel 12.0.7 verbraucht das System im Deep-Sleep nur noch 200 mW und kann so 6,5 Tage in Bereitschaft bleiben. Yoda von der Fedora SIG Mobility brachte heute gute Nachricht raus. Wie er sich so lange zurückhalten konnte es zu starten ist mir aber schleierhaft 😉

Im Deep-Sleep reagiert das Modem auf Anrufe und SMS ( der Teil muß noch etwas verbessert werden ) und weckt dann den Rest vom System auf, so daß der Anruf angenommen werden kann. Mit der neuen Modemfirmware soll das noch viel besser klappen, als mit der Herstellerfirmware

Im Normalbetrieb, also erreichbar per SSH, kommt der neue Kernel auf 0.88-0.92W . Das sind 0.5 W weniger als noch vor einer Woche. Das Telefon kann mit der Leistung fast schon in den täglichen Betrieb wechseln, wenn man es zwischenzeitlich nicht zu hart ran nimmt 😉 Tagesbetrieb.. WIR KOMMEN \o/