Security: Angriff auf WPA2 möglich, wenn Broadcom&Cypress Chips im Spiel sind

Eine Meldung der Hacker News erfreut die Gemütslage von allen Admins weltweit: WPA2 + Broadcomships sind eine schlechte Kombination 🙁

Angriff auf WPA2 möglich, wenn Broadcom & Cypress Chips im Spiel sind

Die mit CVE-2019-15126 registrierte Schwachstelle mit dem Namen „Kr00k“ erlaubt es in Kombination mit dafür anfälligen Chips von Broadcom &  Crypress, die WLAN Verschlüsselung teilweise zu verhindern.

Das funktioiert so, daß ein Angreifer ohne überhaupt im Funktnetz zu sein, ständig Disassoziationen auszulöst, indem er Deauthentifizierungspakete an alle sendet. Das führt dazu, daß sich die Chips aus dem WLAN lösen und den WLAN Schlüssel intern auf NULL setzen. So weit wärs noch ok, aber nun senden anfällig Broadcom und Crypress Chips die Restpufferinhalt im Chipspeicher ohne die Verschlüsselung ans Ziel. Streng genommen verschlüsseln die die Daten mit 000000000000000000, was dann keine Verschlüsselung mehr ist. Ist also ein Bug in der Chipfirmware, weil die müßte den Puffer auch leeren, statt den Inhalt denn zu senden.

„Unsere Tests bestätigten, dass einige Client-Geräte von Amazon (Echo, Kindle), Apple (iPhone, iPad, MacBook), Google (Nexus), Samsung (Galaxy), Raspberry (Pi 3), Xiaomi (RedMi) sowie einige Zugangspunkte von Asus und Huawei für Kr00k anfällig sind“, so die ESET-Forscher.“ schreiben die Hacker News.

Diese Lücke hackt also nicht Eurer WLAN Passwort, weswegen ein Wechsel des Passworts nichts bringt. Da Broadcom Chips in allen möglichen Geräten zu finden sind und damit in allem was IoT, Accesspoints, alte Handies etc. ist ungepatcht laufen, wird das ein schöner Mitschmatsch werden.

Wie könnt Ihr euch schützen?

Das schlimmste was mit dem Angriff passiert ist, daß einige eurer Pakete im WLAN so übertragen werden, als wenn es ein OFFENES-WLAN wäre. Damit sind alle die Datenübertragungen betroffen, die Klartextverbindungen beinhalten, z.b. HTTP:// Traffic, FTP, SMTP, POP, IMAP, DNS und jede Menge IoT Geraffel. Wer seine Dienste alle mit TLS Verbindungen wie HTTPS, FTPS, SFTP, SCP, SSH, STARTTLS für SMTP, POP und IMAP schützt, muß sich keine Sorgen machen. Aber wer zu Hause intern von einem PC per Samba auf einen anderen PC zugreift, dessen Daten könnten damit abgelauscht werden.

Ein gezielter Angriff auf bestimmte Daten ist mit dem Angriff nicht möglich, der Angreifer weiß also nie was er da so bekommt, aber je mehr er mitschneidet, desto schlechter für Euch.

Wie bekomme ich raus, daß ich betroffen bin?

Für Eurer Linux braucht Ihr erstmal eine Version von „lshw„, also für Fedorabenutzer eingeben: „sudo dnf install -y lshw

Ihr werdet Rootrechte brauchen, also „sudo su“ eingeben. Mit „ip l“ bekommt Ihr Eure Interfacenamen heraus, „ifconfig“ würde es auch tun:

# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether f0:76:1c:be:39:c8 brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
link/ether 34:e6:ad:5d:18:ee brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:e7:5f:07 brd ff:ff:ff:ff:ff:ff

Wir brauchen das wlp3s0 WIFI Interface. Jetzt gebt Ihr „lshw | less“ ein und bekommt eine lange Liste mit Info zu Eurer Hardware. Den Befehl solltet Ihr Euch also merken, den braucht man häufiger mal. In der Ausgabe sucht Ihr nach Eurem Interfacenamen und stoßt so auf solch einen Block:

*-network
description: Wireless interface
product: Wireless 3160
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:03:00.0
logical name: wlp3s0
version: 83
serial: 34:e6:ad:5d:18:ee
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=iwlwifi driverversion=5.2.18-100.fc29.x86_64 firmware=17.3216344376.0 ip=192.168.0.103 latency=0 link=yes multicast=yes wireless=IEEE 802.11
resources: irq:54 memory:c4000000-c4001fff

Entweder verrät es euch jetzt schon die Herstellerbezeichnung, hier Intel Corporation, oder der Drivername (hier iwlwifi) gibt den Chiphersteller preis. Wenn da BC drin vorkommt, war es ein Broadcom. Den Code für Crypress Chips kenne ich jetzt leider nicht auswendig, aber das findet Ihr vermutlich im Netz auf Linux-Wifi-Infoseiten.

Wie gehts weiter?

Apple soll wohl bereits Patches für seine Benutzer veröffentlicht haben. Wann die anderen patchbaren Systeme hinterher ziehen, bleibt offen. Für alles was IoT, oder mehr als 2 Jahre alte Accesspoints, Handies etc. kommt wohl jede Hilfe zu spät, da hilft nur entsorgen. Vorher würde ich aber einen Blick auf die Webseite meines Herstellers werfen, vielleicht gabs ja doch ein Gnadenupdate.

Quelle: https://thehackernews.com/2020/02/kr00k-wifi-encryption-flaw.html

Exim: neue mögliche RCE Schwachstelle gefunden

Toller Sonntag. Überall Regen und dann weckt mich noch die Meldung, das im Exim eine neue, nicht abwehrbare Schwachstelle gefunden wurde 🙁 ( wichtiges 13 Uhr Update unten )

Elysium ist gefallen

Es gibt einen neuen Bug, der auch bereits gefixt wurde, aber leider nicht mit einem Workaround abzuwehren geht. Das bedeutet für Euch, daß Ihr Updaten müßt.

Der Fehler liegt in einem Programmierfehler der Stringverarbeitung, die dummerweise bereits beim HELO/EHLO greift. Ein Angreifer kann einen Heap-overflow auslösen, in dem er einen überlangen ELHO String sendet.

An der Stelle des Codes wurden die Rootrechte zwar schon gedroppt, aber das hilft nur wenig, falls der Angreifer tatsächlich einen RCE hinbekommt, was nicht ausdrücklich ausgeschlossen ist, aber auch nicht 100% bestätigt wurde. Daher muß man davon ausgehen, daß es jemand früher oder später schafft: Worst-Case halt.

Betroffen sind alle Versionen < 4.92.3.

Also entweder Ihr patchted Euren alten Exim selbst, oder Ihr updated auf die neue Version. Eure Entscheidung.

Aktuelle CVE Nummer zu dem Exim RCE : CVE-2019-16928 .
(Passage geändert, vorher keine bekannt gewesen.)

13 Uhr Update

Fedora kompilierte Versionen sind nicht angreifbar. Der Exploit funktioniert einfach nicht.

Getestet auf: Fedora 29 64Bit gegen 4.92.2

Andere Distros könnten angreifbar sein. Es hängt auch ein bisschen damit zusammen, wie das angegriffene System konfiguriert ist. „Eylsium ist gefallen“ ziehe ich damit teilweise zurück .. das Fedosium steht noch :DDD

Der Exploitstring ist übrigens 11k lang, nur falls Ihr das bei euch mal selbst ausprobieren wollt, nehmt gleich 12k.

Außerdem wurde mitgeteilt, daß es im Rahmen der 4.92.x eingeführt wurde und mit 4.93 auch schon wieder draußen war. Die Exploitmeldung war leider etwas hastig formuliert worden. Allerdings sehe ich da keinen Schaden drin, weil „besser safe than sorry“ wie der Denglischer sagt 😉

 

KDE-Desktop: RCE Schwachstelle durch .desktop Dateien

Wie die Hacker News heute morgen berichten, ist im KDE 4/5 Plasma Desktop eine Schwachstelle enthalten, die durch das reine Herunterladen von manipulierten Desktopdateien ( erkennbar an den Endungen .desktop und .directory)  ausgelöst werden kann.

Schwachstelle im KDE Desktop Indexer für Plasma

Die Ursache liegt im unsicheren Indexer, der neue Dateien analysiert und für die Suchfunktion des Desktops aufbereitet.

Dabei werden Umgebungsvariablen aus der analysierten Datei übernommen, was dazu führt, daß ein Angreifer seinen Schadcode ausführen kann. Auch das Auspacken von Archiven triggert den Indexer an, so daß auch dies die Schwachstelle auslöst.

Securityforscher Dominik Penner, der die Lücke direkt an die Hacker News geschickt hat, statt sie dem KDE Security Team zu senden, schreibt dazu:

„When a .desktop or .directory file is instantiated, it unsafely evaluates environment variables and shell expansions using KConfigPrivate::expandString() via the KConfigGroup::readEntry() function,“ Penner said.

„Wenn eine .desktop oder .directory Datei instanziiert wird ( A.d.R.: muß wohl gelesen heißen ), werden auf unsichere Weise Umgebungsvariablen und Shellerweiterungen ausgewertet, in dem die Funktion KConfigPrivate::expandString() via KConfigGroup::readEntry() genutzt wird“ schreibt Penner.

Diese Schwachstelle erinnert extrem stark an die kürzlich gefundenen Schwachstellen in Exim, wo auch die  Inhalte von fremdeingelieferten Strings ausgewertet werden und zu einem Root-Exploit eskalieren.

Bis auf weiteres muß man bei Downloads und dem Auspacken von aus unbekannten/unsicheren Quellen stammenden Archiven extrem vorsichtig sein. Das KDE Team hat einen Patch angekündigt, fertig ist der aber noch nicht.

Wenn ich mich recht entsinne, hatte der Gnome Index auch kürzlich erst so eine Schwachstelle.

Kleines Update: (10:24 Uhr)

Es gibt ein Youtube Video, daß das Problem zeigt. Allerdings wird man als unbedarft neugieriger erstmal unverständlich davor sitzen. Daher möchte ich dazu eine kleine Einleitung geben:

In dem Shellfenster rechts startet Penner „nc -lp 31337“  ( 31337 = „elite“ in L33T-Speak 🙂 ). nc startet also einen Dämon und wartet auf Verbindungen. Plötzlich wird nc beendet und wirft eine Fehlermeldung aus. Das liegt daran, daß das Desktopfile, daß per Firefox runtergeladen wird, sich bzw. ein dadurch gestartetes anderes Programm zu besagtem Port 31337 verbindet.

Das zusammen demonstriert das Problem. Man kann in den Desktopdateien natürlich auch „rm -rf /“ unterbringen, oder den Download von Illegalem Filmmaterial starten.

 

Exim CVE-2019-13917 – Die Katze ist aus dem Sack

Ich habe es geahnt, natürlich war die String-Expansion vom letzten Exim Exploit nicht nur dort im Einsatz, sondern auch an anderer Stelle:

CVE-2019-13917 – Root Access für lokale und entfernte Benutzer.

Betroffen sind alle aktuellen(und nicht mehr ganz so aktuellen) Exim Versionen 4.85 -> 4.92.

Laut Jeremy Harris besteht die Lücke wie schon beim letzten Exim Exploit in einer String-Expansion-Operation.

Wir erinnern uns: Ein Angreifer konnte vor einem Monat „<${run{bash}}@zieldomain.de>“ als Absender oder Empfänger einer Email setzen und hatte freien Zugang zum System.

So geht das jetzt auch wieder. Diesmal ist es die „Sort“-Funktion, die Einträge, naja, sortiert halt. Wenn ein Angreifer dort Einträge beisteueren kann, wie z.b. einen modifizierten Received-Header, oder multiple Empfängernamen und der angegriffene Server sortiert diese Einträge, für was auch immer er das bräuchte, dann würde der Text des Angreifers ausgeführt.

In PHP nennt man das die EVAL()-Falle. Ist halt immer blöd, wenn man ungeprüft Sachen von fremden Leuten ausführt 😉

Seid Ihr betroffen?

Das ist leicht festzustellen:

exim -bP config | grep -i sort

als Root ausführen und wenn da nichts kommt, dann seid ihr sicher. Da es in der Default Konfig nicht vorkommt, würde sich ein betroffener Admin jetzt direkt daran erinnern, daß er da was sortiert hat und könnte jetzt Updaten. „Könnte“ weil Fedora User nicht können, in der Rebuildversion von heute liest man leider nur das :

* Thu Jul 25 2019 Fedora Release Engineering <releng@fedoraproject.org> – 4.92-9
– Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

Von CVE liest man nichts, oder Ihr vielleicht? Das ist jetzt peinlich, weil die Exim-Devs das allen Distros rechtzeitig mitgeteilt haben.

Workaround:

Sort-Funktion auskommentieren, siehts zwar nicht mehr schön aus, ist aber sicher 😉

 

 

PHP 5.6/7.x Remote Execution Schwachstelle

Zeit zum Updaten: PHP eine Remote Code Execution Schwachstelle hat!

Risikostufe 4 – Remote Code Execution

Das BSI schreibt im Advisory:

„Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in PHP ausnutzen, um Informationen offenzulegen, einen Denial of Service herbeizuführen oder Code mit den Privilegien des angegriffenen Dienstes zur Ausführung zu bringen.“

betrifft:

Open Source PHP < 5.6.40
Ooen Source PHP < 7.1.26
Open Source PHP < 7.2.14
Open Source PHP < 7.3.1