Alert: CVE-2024-3094 backdoor in xz Library

[tstimper]

Hallo Forum,

kennt Ihr die CVE-2024-3094 schon?

https://nvd.nist.gov/vuln/detail/CVE-2024-3094

In der aktuellen xz Library ist eine Backdoor eingebaut.

Die kann genutzt werden, um beim SSH connect die Authentifizierung zu umgehen und lokale root Rechte zu erlangen.

Stable Linux Distributionen scheinen aber nicht betroffen zu sein.
Auch Router Firmware und das Firewall OS der UF wird vermutlich nicht betroffen sein,
da die wenn überhaupt genutzen xz Versionen vermutlich älter als Februar 2024 sind.

Ich habe auch einen Case aufgemacht und auch an security@lancom.de gemailt.

Bislang (30.03.2024 11:15 Uhr) keine Antwort und es ist auch nichts bei den Sicherheitshinweisen auf der Lancom Webseite zu sehen.

Weiß da jemand mehr?

Log4j ist harmlos gegen das was da grad passiert ist...


Klare Empfehlung: SSH von Extern dringend ausschalten bis wir ein klares Bild haben.

Und die Fälle einzeln bewerten.


Viele Grüße

ts


PS: eine gute Zusammenfassung der Ereignisse gibt es in diesem LinkedIn Post https://www.linkedin.com/posts/dev-feli ... 05345-g5Ih

[plumpsack]

Klare Empfehlung: SSH von Extern dringend ausschalten bis wir ein klares Bild haben.

Eigentlich sollte man seinen Router niemals von außen "direkt" zugänglich machen.

siehe hierzu u.A Lancom und "Showdown*-Server" ...

*Shodan

... ist schon gruselig was man da alles findet, wenn man nach lancom sucht ...

[GrandDixence]

Eigentlich sollte man seinen Router niemals von außen "direkt" zugänglich machen.

Gemäss Shodan:
https://www.shodan.io/search/facet?quer ... facet=port

sind weltweit 34934 LANCOM-Geräte vom Internet per SSH erreichbar (Serverport TCP 22) und 14377 LANCOM-Geräte sind über verschlüsseltes Telnet erreichbar (Serverport TCP 992). Soviel zur Einhaltung grundlegender IT-Security-Empfehlungen. Gähn...

Interessanter finde ich diese Shodan-Webseite:
https://www.shodan.io/search/facet?quer ... facet=vuln

Weshalb werden für LANCOM-Geräte die Sicherheitslücken CVE-2023-52322 und CVE-2024-23659 aufgeführt? Fehlalarm!?
https://nvd.nist.gov/vuln/detail/CVE-2024-23659

https://nvd.nist.gov/vuln/detail/CVE-2023-52322

[5624]

Interessant, alle meine Router sind in der Liste nicht sichtbar, scheinbar hab ich einen guten Port erwischt.

Ja, man sollte dies nicht und jenes nicht und überhaupt nicht ...

Aber jeder kennt die Differenzen zwischen Theorie und Praxis. In der Theorie funktionieren LANCOM-Router problemlos, in der Praxis nicht. Ich hab keine Ahnung, wie oft mir die VPN-Verbindung einseitig zusammenklappt. Soll ich jedes mal, wenn ein Router wieder son Furz quersitzen hat, 400km in irgendeine Himmelrichtung fahren? Nein, da bleibt bei mir SSH aktiv.

Und die Welle, die daraus jetzt wieder entsteht, weil Leute, die keinerlei Ahnung haben, absolut nicht verstehen, was überhaupt los ist, wird wieder riesig sein, für nichts am Ende. Zum Glück ist ts nicht so einer, der in der Erstmeldung einfach blind rumgeschossen hat, wie es an anderen Stellen im Internet war. Da wurde z.B. daraus eine Kernel-Lücke gemacht und was nicht alles.
Am Ende wird es aktuell nur sehr wenige betreffen, da die Sache sehr früh gefunden wurde, ehe die betroffene Version im Mainstream angekommen ist.

[tstimper]

Hi Forum,

Der Angriff auf die betroffene Library wurde seit 2022 vorbereitet.

Es kann also schon sein, das sich noch vorbereitender Code in dem LCOS-FX oder in LCOS-LX versteckt
Genau wissen wir das erst, wenn das Review der xz Library
vollständig abgeschlossen ist.

Ich halte die Wahrscheinlichkeit, das LCOS betroffen ist
eher für Null.

Bei LCOS-FX (Debian)und LCOS-LX (OpenWRT) und LCOS-SX ( diverse embeded Linux Derivate)
kann es durchaus sein, wenn sich noch herausstellen sollte, das auch die xz Versionen vor Februar 2024 betroffen sind.


Ich zitiere mal was Felix Becker auf LinkedIn zusammengefasst hat:

Bösartige Akteure haben seit 2022 Stück für Stück das liblzma-Projekt übernommen und sich das Vertrauen der Maintainer erschlichen. Die Angreifer haben ein Source-Tar veröffentlicht, das Malware enthält, die auf SSHD abzielt, und in verschiedenen Distributionen angekommen ist.

Betroffen:
Debian Testing / Unstable
Kali Linux
Fedora Rawhide/40
OpenSUSE Tumbleweed

Malware-Version installiert, aber Exploit wohl nicht aktiviert:
Gentoo Stable
Archlinux
Homebrew

Nicht betroffen:
 Alpine 3.19
RedHat <= 9
Ubuntu <= 24.04
Rock Linux 9
Suse Enterprise Linux / OpenSUSE Leap

Hier die originalen Links:

https://www.linkedin.com/posts/dev-feli ... 05345-g5Ih

https://www.linkedin.com/posts/dev-feli ... 39264-hs4T


Viele Grüße

ts

[tstimper]

Nachtrag:

Hier noch die Heise Meldungen dazu:

https://www.heise.de/news/Hintertuer-in ... 71317.html

https://www.linkedin.com/posts/christop ... 19072-9Z3z

https://www.heise.de/news/xz-Attacke-Hi ... 71588.html

Was ich interessant finde ist das es durch erhöhte CPU Last bei der SSH Anmeldung aufgefallen ist.

Wir haben seit einigen Monaten auch beobachtet,
das SSH Connects auf LCOS Geräte länger brauchen als früher.

Das muss nichts damit zu tun haben.

Viele Grüße und gute Nacht

ts

[Hagen2000]

Super, dass Du dir die Mühe gemacht hast, hier alles zusammenzutragen!

[fildercom]

Vielen Dank auch von mir! Ich denke, dass nur sehr wenige Geräte tatsächlich betroffen sein werden, weil die Lücke früh erkannt wurde und daher ihren Weg in die "stabilen" Betriebssysteme noch nicht gefunden hat.

[tstimper]

Das war echt knapp..

Und jeder, der betoffene Systeme hat,
weis das er handeln musste.

Viele in der IT haben auch Kali Linux irgendwo installiert.
Und genau diese Security Analyse Distribution
ist auch betroffen.


Hier noch eine schöne Analyse wie knapp das war und
wie wachsam wir in der IT sein müssen.

https://www.derstandard.at/story/300000 ... hrammt-ist

Was ich gut finde ist das die Linux Distributionen
sofort voll transparent reported haben.

Und das die Security Community auf LinkedIn so schnell reagiert und reported hat.

Und Heise hat ebenfalls schnell berichtet,
Christopher Kurz von Heise Security schrieb gestern,
das er den ganzen Tag und die ganze Nacht analysiert und
Meldungen gelesen hat.
Das wird vielen so gegangen sein.

Mich bestärkt das wieder mal im Einsatz der LCOS
Router und der jeweils härtestmöglichen Einstellung der
Firewall Rules.

Alle Linux Basierenden LCOS Geräte wie
Debian in der UF
OpenWRT bei den LX APs
Embedded Linux bei den Switchen
müssen noch betrachtet werden.

Auch wenn die Wahrscheinlichkeit gering ist,
das die betroffen sind würde ich mir doch
eine Info von LANCOM wünschen.

Stand heute 31.03.2024 18:58 Uhr gibt es keine Info.


Viele Grüße

ts

[plumpsack]

Gähn...

hmm ... dir ist schon klar warum die bei Show-Down gefunden werden?

Falls nicht, da war etwas in der 10.70 ... (RN_LCOS-1070-Rel_DE.pdf)

→ Der Gerätename wird nicht mehr beim WEBconfig-Zugriff über WAN-
Verbindungen angezeigt.
→ Das Telnet(-SSL)-Banner wird jetzt erst nach einem Login angezeigt.

Auch das die Geräte veraltete Software einsetzen sowie mit TLS V1 arbeiten lässt so einiges zu wüschen übrig.

Gut das die Besitzer nicht zur Verantwortung herangezogen werden können wenn etwas passiert:

"ehm .. ist halt Software ... da kann man nix machen ..."

SSH auf einen Port >= 1024 zu setzen kann man machen ... sollte man aber nicht.

Raspberry, z.B., kostet "kein Geld" - per VPN drauf ... eth2 -> up und schon steht die Verbindung zum Lancom.

(nur ein Beispiel ...)

Man kann sich schützen, wenn man es will ....

[tstimper]

So , für alle Mac User:

Macports ist (war) auch betroffen
https://trac.macports.org/ticket/69619

Und Arstechnica schreibt:

https://arstechnica.com/security/2024/0 ... the-world/

Stand 01.04.2024 17:48 Uhr keine Antwort von security@lancom.de

Und vom Support auch nichts.

Wie schon gesagt, alles was das native LCOS hat,
ist vermutlich prinzipiell nicht betroffen.
Bei allen anderen Linux basierten Geräten ist es unwahrscheinlich, dennoch wäre eine Aussage wichtig.

Die embedded Linuxe der WWAN, GPON und AON Module
gibt es ja auch noch.

Verrückt wird es nun bei 3rd Party Modulen …..

Was für ein Desaster…

Wir bleiben dran.

Viele Grüße

ts

[rotwang]

Ich halte die Wahrscheinlichkeit, das LCOS betroffen ist
eher für Null.

Dito. Der SSH-Stack im "klassischen LCOS" (kein -LX, kein -SX, kein -FX) ist ein selbst entwickelter, und der enthält auch keinerlei Patches Richtung Systemd, alleine schon weil das 'klassische' LCOS nicht Linux-basiert ist und keinen Init-Prozess in diesem Sinne hat. LZMA wird m.W. auch nirgendwo im LCOS benutzt oder hinzugelinkt. Es wird bestenfalls während des Build-Prozesses genutzt, um die fertig gelinkten LCOS-Images zu komprimieren. Und auf dem Build-Server läuft eine hinreichend stabile/abgehangene Linux-Distri, dass die fragliche Version der xz-utils dort noch nicht angekommen ist.

[rotwang]

Hier noch eine schöne Analyse wie knapp das war und
wie wachsam wir in der IT sein müssen.

Das schlichte Problem heutzutage sind die viel zu komplexen Abhängigkeiten, die niemand mehr durchblickt, und irgendwo in diesem Abhängigkeitsbaum steckt ein Tool, das von einer Einzelperson in der Freizeit gepflegt wird. Wird von Hinz und Kunz benutzt, aber nie sieht diese Person irgendwelchen Dank oder Anerkennung dafür - das wird ja als Selbstverständlichkeit betrachtet, dass dieses Tool da ist und einfach zu funktionieren hat. XKCD hat das schön zusammengefasst:

https://xkcd.com/2347/

Im Prinzip das gleiche Thema wie damals bei Heartbleed, wo dann auf einmal auffiel, dass alle Welt eine OpenSSL benutzt, die mangels Funding von anderthalb Programmierern zusammen gehalten wird. Da ist das Thema dann weit genug hoch gekocht, dass sie mehr Vollzeit-Entwickler einstellen konnten. Vielleicht passiert das hier jetzt auch, aber es gibt sicher Hunderte solcher Projekte in einer ähnlichen Situation.

[tstimper]

Hi Rotwang,

Vielen Dank für Deine Meldung bzgl. LCOS

Ich vermute, das LCOS-LX, FX und SX auch safe sind.

Warten wir mal ab, ob das auch noch jemand bestätigen kann.

Viele Grüße

ts

[rotwang]

Wir haben seit einigen Monaten auch beobachtet,
das SSH Connects auf LCOS Geräte länger brauchen als früher.

Da kann es alle möglichen Gründe für geben. Die neue OpenSSL in LCOS 10.80++, neu ausgerollte Geräte, die im Default einen längeren RSA-Hostkey benutzen, Clients, die andere Krypto-Algorithmen aushandeln als früher...