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

Programmerweiterung: Linux Presentation Day 2021.1 am 15.5.

Aus aktuellem Anlass gibt es eine Programmerweiterung für den LPD. Wir konnten Eximentwickler Heiko Schlittermann für ein Interview zur Lage der neuesten Sicherheitsfixe im Eximprojekt gewinnen, das ab 13 Uhr ausgestrahlt wird.

Linux Presentation Day 2021.1 am 15.5.

Der Beitrag von Linux am Dienstag zum LPD 2021.1 wird live aus Braunschweig gestreamt. Der Livestream ist ab Samstag auf der gleichnamingen Webseite https://linux-am-Dienstag.de erreichbar.

Unser Programm

13:00 Special-Event: 21Nails – Interview mit Eximentwickler Heiko Schlittermann
14:00 „Willkommen beim Pinguin“ – Der Einführungsevent
14:30 „Keine Angst vor Gnome“ – Einführung in Linux Desktops
15:30 „Daten sicher in der Cloud ablegen“ – Ein bisschen Linux Magie und es geht auf Kopfdruck.
16:00 „Wieso ich Linux möchte“ – Eine Reflektion der Sehnsucht
16:30 „Wieso Spamfilter schlecht sind?“ – Sind sie es wirklich?
17:00 „Wie tickt eigentlich mein Desktop“ – Technikbeitrag wie Programme gestartet werden.
17:30 „Ein Tag im Leben eines PinePhones“ – Das Linux Smartphone stellt sich vor.

Selbstverständlich sind wir am Samstag den 15.5. nun auch schon ab 13 Uhr im Live-Chat erreichbar.

 

21Nails: Interview mit Eximentwickler Heiko Schlittermann

Liebe Linuxfans,

ein kleines Interview als Teaser für Euch, denn Heiko hat eingewilligt nächste Woche bei Linux am Dienstag aus dem Eximnähkästchen zu plaudern. Er steht allen Interessierten gern Rede und Antwort. Ich rate Euch dringend diesen Termin wahrzunehmen, denn in unserem Vorgespräch offenbarten sich wahre Schätze an Wissen, das ganz dringend in den Tux in Euch rein muß 😉

21Nails: Interview mit Eximentwickler Heiko Schlittermann

Die Firma Qualys hat Ihre Entdeckung 21Nails genannt, aber Sargnägel waren es mit Sicherheit nicht. Eximmitentwickler Heiko Schlittermann stand uns heute morgen dankenswerterweise für ein kurzes Interview zur Verfügung.

„21 Lücken, 7 Monate bis zur Behebung, wieviele schlaflose Nächte waren das?“

Die meiste Zeit nicht mehr als sonst auch, aber die letzten zwei Wochen
vor dem public release waren etwas anstrengend, da einige Bugs erst in
letzter Minute auftraten – wir konnten ja nicht großflächig testen.

„Was hat Euch(Devs) so lange Zeit gekostet? War es die Qualität des Fixes an sich, oder die Kommunikation mit Qualys?“

Das ist eine längere Geschichte. Anfangs hatten wir nur die Bugreports
von Qualys. In diesem Zusammenhang muss ich noch mal deren sehr
professionelles und freundliches Verhalten bei der Zusammenarbeit
hervorheben.

Wir hatten zeitnah begonnen, uns um die Probleme zu kümmern. Eigentlich
hatte ich das Taintwarn-Feature in der Pipeline, denn ich wollte das
noch vor Debian11 rausbringen und ein 4.95-Release wäre eigentlich im
November dran gewesen.

Leider wurde einer der Entwickler vom Burnout aus der Kurve geschossen.

Qualys unterstützte uns dann mit Ressourcen: Sie haben uns die Patches
geliefert, die wir *eigentlich* nur noch importieren mussten. Es gab
aber intern einige Diskussion über die technische Umsetzung: es ist
wieder seteuid()* dabei, das eigentlich nicht mehr im Exim-Code
auftauchen sollte
*) Seteuid => setzt die effektive UserID eines Prozesses auf einen bestimmten User, damit der Prozess nur noch mit dessen Rechten läuft und falls dieser Prozess exploitet wird, ist der Schaden minimiert. Hier vom User „Root“, mit dem der Prozess startet, zu User „Exim“.

Wir suchten nach anderen Lösungen, aber das funktionierte alles nicht,
und das hat Zeit gekostet.

Einige Patches mussten geringfügig umgebaut werden. Und dann blieben bei
der Testsuite einige Tests auf der Strecke, da mussten die Ursachen
gefunden werden und gefixt werden. Exim hat eine Regression-Testsuite, mit gut
1000 Testsscripts, die jeweils im Schnitt 2…6 Einzeltests enthalten.
(Anm.d.R. insgesamt knapp 4000 Tests)

Qualys hat uns die ganze Zeit wertvoll unterstützt.

Mein Fazit: Wir hätten die Patches importieren sollen, Testsuite anpassen, shippen.
Und uns dann anschließend um Verschönerungsmaßnahmen kümmern. Auf der
anderen Seite wurde uns von Qualys kommuniziert, dass ja noch nichts brennt
und es keine Anzeichen gibt, dass eine der gefundenen Vulnerabilites aktiv genutzt wird.

„Wie kam es dazu, daß die Deadline so knapp war? Die Distros hatten ja kaum Zeit die neuen Versionen zu testen, geschweige denn zu shippen. Bei Fedora fiel die Testversion mit dem Releasedate des Advisories zusammen.“

Soweit ich den Prozess bei oss-security* verstehe, ist 1 Woche Vorlauf für die Distros schon gut bemessen. 3 Tage werden angestrebt.
(* Anm.d.R. OSS-Security ist eine öffentliche Mailingliste zu Securitymeldungen auf der u.a. die großen Distributionen und andere Organisationen vertreten sind )

„Da bleibt nicht viel Zeit für Test. Hat sich im Ablauf des Teams etwas geändert durch die Herkulische Aufgabe? Seit Ihr jetzt für die Zukunft besser bewappnet?“

Lesson learned. See above 🙂

„In der Mailing sieht man jetzt wieder sehr viele Hilferufe wegen „Tainting“. Erklärst Du mal, wie es dazu gekommen ist.“

Nun. Wir haben das Konzept von „tainted data“ mit 4.94 eingeführt. Da
werden Daten, die „von außen“ kommen als nicht vertrauenswürdig
betrachtet, und können z.B. nicht verwendet werden, um Dateien zu
öffnen. Der Klassiker

data = ${lookup{$local_part}lsearch{/etc/exim/virtual/$domain}}

geht dann plötzlich nicht mehr. Die „$domain“ ist „tainted“.

Wer jetzt beim Update von < 4.94 auf 4.94.2 aktualisiert hat, stand
plötzlich vor einer Herausforderung. Die Konfig ist nicht mehr sicher
und Exim arbeitet nicht mehr wie gewohnt.

Auch darüber hatten wir intern viele Diskussionen. (Das ist auch ein
Grund, warum wir 4.95 noch nicht released hatten: weil ich der Meinung
war, dass das mit dem Tainted so nicht bleiben kann.) Bisher waren
Updates des Exim immer möglich, ohne die Konfiguration ändern zu müssen.

(Der einzige „breaking Change“ war das aus Sicherheitsgründen
vorgenommene Bereinigen der Umgebungsvariablen für Kindprozesse. Da
hatten wir keine Wahl.)

Zurück zur Frage: Ja, wer jetzt plötzlich von < 4.94 auf >= 4.94
aktualisiert hat, hat möglicherweise ein Problem. Um das zu mildern, haben
wir eine Main-Config-Option eingeführt: „allow_insecure_tainted_data“.
Diese Option ist aber *nicht* Bestandteil von 4.94.2. Es gibt die
Meinung, dass wir alte Versionen vor 4.94 eh nicht unterstützen, und die
die sich den Exim selber bauen, sind schon bei 4.94, haben also mit dem
Update kein Problem. Ist sicher diskutierbar…

Wer über seine Distro aktualisiert, hat kein Problem, wir haben Debian
beim Backport der Patches auf 4.92 unterstützt. Von den anderen Distros
wissen wir nichts, aber es sieht so aus, als hätten die das auch
irgendwie gelöst.

Wer von Debian 10 auf Debian 11 aktualisiert, hat auch kein Problem, weil
Debian freundlicherweise den oben erwähnten „taintwarn“ Patch mit
übernommen hat.

Hm. Zu viel Antwort für die kurze Frage…:)

„Letzte Frage: Wird es jetzt aus Deiner Sicht Zeit, die Beispiele in der Eximdoku zu überarbeiten und Tainting-sichere Beispiele anzuführen?“

Ja, definitiv ist da noch etwas dokumentarische Arbeit nötig. Jeder
ist eingeladen, sich daran zu beteiligen.

Die Beispiel-Config ist „tainting sicher“.