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

Skype4Linux unter Fedora Updaten

Das Skype-RPM für Fedora hat eine unsaubere Abhängigkeit drin, die leider seit Wochen nicht behoben wird. Trotzdessen kann man ein Update hinbekommen.

Skype4Linux unter Fedora Updaten

Wer kennt das nicht .. ok,ok, alle die kein Skype nutzen ist schon klar ….  Skype nervt mit einem Hinweis „Update mich. Update mich.“ und wenn man das dann tun will, dann geht das nicht:

# dnf update skypeforlinux
Letzte Prüfung auf abgelaufene Metadaten: vor 4:07:00 am Do 08 Apr 2021 13:48:32 CEST.
Abhängigkeiten sind aufgelöst.

Problem: cannot install the best update candidate for package skypeforlinux-8.68.0.100-1.x86_64
– nothing provides libatomic1 needed by skypeforlinux-8.69.0.77-1.x86_64
==================================================================================
Package Architecture Version Repository Size
==================================================================================
Pakete mit nicht auflösbaren Abhängigkeiten werden übersprungen:
skypeforlinux x86_64 8.69.0.77-1 skype-stable 112 M

Transaktionsübersicht
==================================================================================
Überspringen 1 Paket

Nichts zu tun.
Fertig.

Schuld daran ist die Abhängigkeit auf das Paket „libatomic1“, welches es bei Fedora gar nicht gibt, weil das Paket der libatomic hier .. tada… „libatomic“ heißt 🙂

Jetzt dürft Ihr zwei Dinge tun: Root werden, und die Sache manuell durchziehen 😉

sudo dnf -y install libatomic
sudo rpm -U –nodeps https://repo.skype.com/rpm/stable/skypeforlinux_8.69.0.77-1.x86_64.rpm

Für den Fall, daß die Lib noch nicht drauf sein sollte, installieren wir die mal pauschal, damit Skype dann auch noch funktioniert. Im nächsten Schritt kommt die (heute) neueste Version drauf. Ich bin mal gespannt, ob das beim Umstieg auf Fedora 33 nicht zu Fehlern führen wird. Falls es zu einem „unauflösbaren“ Fehler beim Upgrade auf Fedora 33 kommt, hier schon einmal die Lösung:

vi  /etc/dnf/dnf.conf

exclude=skype*

Dann Updaten und wieder einkommentieren. Falls die nächste Version von dem RPM den Bug immernoch drin hat, dann muß man die wohl auch von Hand updaten.

Linux am Dienstag: Linuxsensorik – Beschleunigungssensoren lesen

Hallo Linuxfans,

eine kleine Ankündigung für alle die an den Online Meetings „Linux am Dienstag“ teilnehmen wollen. Der Termin liegt ab jetzt Dienstag, ab 19 Uhr auf dem bereits bekannten Jitsi Meet Portal.

Linux am Dienstag: Linuxsensorik – Beschleunigungssensoren lesen

Da im Rahmen dieser Meetings Linux Vorträge entstehen, habe ich da mal die Unterseite im Blog Linux am Dienstag erstellt. Diese ist im Linux Menü zu finden, falls Ihr den Link verlegt habt 😉

Der Erste dort downloadbare Vortrag dreht sich um die Beschleunigungssensoren einer Handies mit Linux. Grundsätzlich kann man damit aber jeden Sensor auslesen. Da Tablets und Laptops auch solche Sensoren haben können, lohnt sich ein Blick in diesen Vortrag auch, wenn man kein Linux Smartphone hat.