News Sicherheitslücke in xz: Backdoor in Linux-Archivbibliothek macht Systeme angreifbar

[Redundanz]

auf manchen seiten wird direkt zu kompletter Neuinstallation des Systems geraten... Übertriebene Vorsichtsmaßnahme oder gerechtfertigt?

wenn man davon ausgeht, dass da nicht noch andere zugangswege unentdeckt/verborgen sind, dann kommts darauf an ob du sshd laufen hattest während die entsprechend getaggten versionen der liblzma-library bei dir installiert waren.
falls ja, könnten in diesem zeitraum ja bereits via rce weitere vom xz-exploit unabhängige payloads abgelegt worden sein. somit wäre das system auch dann noch kompromittiert, selbst wenn du jetzt das xz downgrade gemacht hast.

man kann es sich so vorstellen wie ein einbrecher, der erst irgendwie deinen ersatzschlüssel für deine haustür entwenden konnte (wie auch immer und von wo auch immer). und damit ist er dann solange du es nicht bemerkt hattest in dein haus, hat aber nichts gestohlen, sondern nur dein kellerfenster so präpariert, dass er es von außen öffnen kann.
du merkst, dass dein ersatzschlüssel nicht mehr an seinem ort ist -> wechselst das schloss aus, aber der einbrecher kann jetzt weiterhin durch das kellerfenster, was er von innen entsprechend präpariert hat... und du wiegst dich bereits in sicherheit wegen dem ausgetauschten schloss.

wenn du sshd grundsätzlich nicht laufen hast und bestenfalls auch gar nicht von außen den port durchreichst dann wäre stand heute ein apt-get/dnf/... upgrade ausreichend.

 

[Snowi]

Ich sehe es bzgl. SSH so: Wenn es nicht gerade wie hier durch Abhängigkeiten infiziert ist, ist OpenSSH wohl eine der Softwareprodukte, denen ich am meisten vertraue im Bezug auf Sicherheit. Die OpenBSD Leute die auch OpenSSH entwickeln wissen und verstehen was sie tun, und OpenSSH bietet deutlich weniger Angriffsfläche als es ein VPN Server tut.
Ob ich einen VPN Server Bruteforce oder einen SSH Server, ist am Ende egal. Beides ist gleich unwahrscheinlich, wenn richtig implementiert. OpenSSH wird aber deutlich strenger kontrolliert durch die OpenBSD Leute, als es deutlich größere VPN implementierungen sind.

Man kann SSH durch Portknocking oder so absichern, aber solange die Konfiguration vernünftig ist, ist das wohl die unwahrscheinlichste Schwachstelle im System.

Das praktische Problem in diesem Fall hätte auch jede VPN Software treffen können, dass es SSH war, ist vermutlich nur deshalb der Fall, weil es auf Servern öfter offen/installiert ist, als VPN Server. Wenn VPN Server immer der Standard wären, und nicht SSH, hätte es wohl eher einen gängigen VPN Server als Ziel gehabt.

 

[Fedorauser]

Hat noch jemand gerade über 4000 zu aktualisierende Pakete in OpenSuse Tumbleweed? Könnte das mit xz zu tun haben?

Edit: Okay hab was gefunden:
https://www.reddit.com/r/openSUSE/c...package_update_for_tumbleweed_an_explanation/

Aktualisierte seit mehr als zwei Wochen nicht mehr auch nicht durch anstoßen...
Es zeigte keine Upgrades und Updates an uns das dies über zwei Wochen nicht sein konnte zog ich den Killswitch...
Es lief als Testsystem in einer VM und wurde sofort komplett entfernt.

Stellt sich die Frage nach einer Analyse was der Hack konnte oder kann und ob dieser auch aus ner VM agieren könnte und den Host infiziert.?

 

[Miuwa]

Ich hab mir schon gestern das Orginal durchgelesen.

Es betrifft nur Distributionen die sshd gegen systemd (liblzma) linken. Nur in diesem fall wird bei der Nutzung von sshd Code nachgeladen.

Nutzbar war die Backdor nur in Fedora Rawhide und Debian Testing. Und das nur kurz.

Es gab nie ein Problem?

Je nachdem welchen Artikel du meinst, war dort der Schadcode noch nicht vollständig analysiert. Sprich die von dir geschilderte Situation ist "ein" mögliches Angriffszenario. AFAIK war/ist es aber noch nicht gesichter, ob das auch das "einzige" ist.

 

[Lora]

Also Root SSH Zugriff ist doch standardmäßig nicht aktiviert:

https://itv4.de/root-ssh-zugriff-unter-debian-aktivieren/

Korrigiert mich wenn ich mich täusche. Zudem sollte Debian testing schon gepacht sein.
Hatte die Tage keine Zeit alles bei den Updates zu lesen. Aber Danke für die News.

 

[mibbio]

Also Root SSH Zugriff ist doch standardmäßig nicht aktiviert:

https://itv4.de/root-ssh-zugriff-unter-debian-aktivieren/

Es gibt echt Leute, die eine laientaugliche Anleitung dafür ins Netz stellen, ohne ausdrücklich auf die Risiken hinzuweisen? Debian (und andere Distributionen) haben das ja nicht als Default so eingestellt, um die Nutzer zu ärgern, sondern weil es sicherer und best practice ist.

Und auch bei einem lokalen, nur im LAN erreichbaren Server sollte man root-Login per SSH deaktiviert lassen für den Gewöhnungseffekt. Denn wer sich beim Server im LAN angewöhnt, sich als root über SSH anmelden zu können, wird das tendenziell aus Bequemlichkeit auch später auf einem Server im Intenet so machen.

 

[Snowi]

Es gibt echt Leute, die eine laientaugliche Anleitung dafür ins Netz stellen, ohne ausdrücklich auf die Risiken hinzuweisen?

Das ist doch eigentlich der Normalzustand. Ich hab damals auch mit so Anleitungen angefangen, mich aber glücklicherweise immer für Security interessiert, und daher immer viele verschiedene Anleitungen gelesen und versucht alle Best-Practices aus diesen Anleitungen umzusetzen.
Problematisch wird es da nur, wenn man das nicht so macht, was wohl auf die meisten zutrifft...

 

[mibbio]

Problematisch wird es da nur, wenn man das nicht so macht, was wohl auf die meisten zutrifft...

Eben deswegen gehört in so eine Anlietung zumindest der deutliche Hinweis, dass es ein Sicherheitsrisiko darstellt, nicht den Best Practices entspricht und man es nur ändern sollte, wenn man einen triftigen Grund dafür hat.

Bequemlichkeit ist dabei für mich kein valider Grund, denn der führt dazu, dass man es dann immer so macht. Deshalb geht selbst bei meinem RasPi zuhause SSH nur als non-root und mit key-based Athentication (mit Passwort für den Key). Einfach um mir das so anzugewöhnen.

Wenn man sich seinen SSH-Client einmal passend konfiguriert, ist das auch nicht unbequemer als Nutzername+Passwort. Auf mein RasPi komme ich bspw. einfach mit ssh raspi, weil Nutzername, IP und zugehöriger Key für "raspi" in der Config vom Client hinterlegt sind.

 

[Dalek]

Schwache Passwörter sind die größte Lücke in SSH, mit riesigem Abstand zu allen anderen Möglichkeiten. Wenn man SSH mit Keys verwendet dann ist das schonmal verdammt sicher. Das ist der Faktor der am wichtigsten ist, alles andere ist dagegen Kleinkram.

Lücken in SSH sind sehr selten, das ist nicht die Angriffsfläche über die ich mir die meisten Gedanken machen würde.

 

[g9robot]

Neuer Versuch backdoor in Open Source zu platzieren. Hoffentlich spricht es mehr Leute an sich damit zu befassen

 

[Zornica]

wenn man davon ausgeht, dass da nicht noch andere zugangswege unentdeckt/verborgen sind, dann kommts darauf an ob du sshd laufen hattest während die entsprechend getaggten versionen der liblzma-library bei dir installiert waren.
falls ja, könnten in diesem zeitraum ja bereits via rce weitere vom xz-exploit unabhängige payloads abgelegt worden sein. somit wäre das system auch dann noch kompromittiert, selbst wenn du jetzt das xz downgrade gemacht hast.

[...]

wenn du sshd grundsätzlich nicht laufen hast und bestenfalls auch gar nicht von außen den port durchreichst dann wäre stand heute ein apt-get/dnf/... upgrade ausreichend.

sshd läuft, aber da der server innerhalb des Instituts steht kann ich nicht genau sagen ob da ein port durchgereicht wird... die kiste war aber vor einigen wochen für einige Tage per VPN am Netz...

ich nehm an, dass da bei etwaigen payloads auch gegenüber von snapper rollbacks vorgesorgt worden wäre?

 

[Pummeluff]

Und auch bei einem lokalen, nur im LAN erreichbaren Server sollte man root-Login per SSH deaktiviert lassen

Mein öffentlich erreichbarer V-Server ist nur per root erreichbar. Gibt keinen nicht technischen User da. Und auch mein NAS im LAN ist von außen per ssh mit root erreichbar.

Die ganze sudo-Geschichte, wie sie von Ubuntu verwendet wird, empfinde ich eher als Risiko, vor allem aber als aufwendig und überflüssig.

 

[SheepShaver]

“Die ganze sudo-Geschichte”, wie du sie nennst ist Standard auf jedem Linux bzw. jedem Unixoiden Betriebssystem und zentraler Bestandteil des Sicherheitskonzeptes, da so sauber protokolliert werden kann, welche Kommandos mit Adminrechten laufen. Auch werden durch die Nutzung von Sudo diverse Exploits verhindert. Ganz davon abgesehen ist es auch riskant sich als Root einzuloggen, da jeder Befehl Zugriff auf alles hat und jeder kleine Fehler zu permanentem Datenverlust führen kann.
Eine Root-Shell ist eine furchtbar schlechte Idee, nicht umsonst wird überall davon abgeraten. Damit macht man wirklich alles falsch.
Keine Ahnung, wie man darauf kommen kann, das habe etwas mit Ubuntu zu tun.

 

[Skysnake]

Ja ne root shell erfordert mehr Sorgfalt, aber sudoers soll ja auch nicht unendlich Rechte erhalten. Es macht da schon teils Sinn mit root zu arbeiten in meinen Augen.

Wenn ich den ganzen Rag nichts anderes Mache als administrieren dann suchen sudo teils schon. Also gerade beim Debugging. Aber wer macht das schon?

 

[TheChris80]

Das Rootkonto nutzt man nur wenn man sehr viele Befehle hintereinander eingeben muss die Root benötigen.
Ist man fertig dann schnell "exit". Ansonsten reicht sudo vollkommen aus.
Wer aktiv mit dem Rootkonto arbeitet der wird schnell Lehrgeld zahlen.

Mal eine andere Frage.
Ich glaube zwar nicht das ich betroffen bin ,jedoch ist es doch generell sicherer SSH auf das Heimnetzwerk zu begrenzen. Oder liege ich da falsch?
Natürlich sind Web-Server ausgenommen sonst hat der Admin ein Problem beim einloggen.

 

[Snowi]

Ich glaube zwar nicht das ich betroffen bin ,jedoch ist es doch generell sicherer SSH auf das Heimnetzwerk zu begrenzen. Oder liege ich da falsch?

Pauschal bist du sicher, solange du nur Stabile Repos von Debian, Ubuntu oder Fedora nutzt, betroffen sind aber u.a. OpenSuse Tumbleweed (Der Rolling Release), Arch und Kali.
Bei Debian/Ubuntu/Fedora waren betroffenen Versionen, soweit bekannt, nur in Unstable/Testing Repos.

Aber ja, die Backdoor benötigt von außen Zugriff via SSH, wenn du den Zugang aufs Heimnetz einschränkst, zB über eine Firewall, dann ist das nach aktuellem Kenntnisstand nicht kritisch. Es gab noch weitere Bedingungen, die findet man zB im aktuellen Heise Beitrag dazu.

 

[lorpel]

Bei Open source kann man. Zwar theoretisch die Fehler finden, aber ich kenne keinen einzigen Programmierer der danach aktiv sucht. Ich übrigens auch nicht. Jeder hofft, dass die anderen das schon machen werden. ist eben eine total langweilige Aufgabe, fremden Code auf Fehler zu überprüfen.

Wenn was gefunden wird, dann eher zufällig, weil jemand über den Code stolpert. 🪤

 

[aluis]

Und ein VPN hätte hier wie genau Besserung gebracht?

Die Backdoor hätte mit VPN nicht funktioniert.

Dann hast du den Artikel nicht richtig verstanden. Die Backdoor ist in der liblzma und nicht im SSHd. Lediglich der Payload der Lücke wird nur aktiv wenn er SSH findet.

Die Backdoor hätte ohne offenen SSH Port nicht funktioniert.

Ein aktuell gehaltener SSH Zugriff (OHNE root) über ed25519 Key kann als sicher eingestuft werden.

Es ist nicht der erste erfolgreiche Angriff, welcher SSH Keys ausgehebelt hat. Ich erinnere nur mal an die krasse SSL Lücke, wo nur noch Zufallszahlen zwischen 1 und 65536 generiert wurden.

Warum bestreiten hier so viele, dass die Angriffsfläche ohne offenen Port astronomisch kleiner ist? Der Akteur hätte einfach nach offenen SSH Ports gescannt. Bei VPN mit tls-auth ist das unmöglich. Um hier Schadcode einzuführen, müsste eine proaktive Backdoor eingeschleust werden, welche sich nach aktiv werden zu einem Kontrollserver verbindet. Sowas wird es niemals in die Repository der Distris schaffen.

Security by Obscurity? Und Containerisierung ohne Hardening der Runtime bringt an der Stelle auch 0 zusätzliche Sicherheit.

Es ging mir um den offenen Port. Container habe ich nur erwähnt, weil jemand bei VPN von einer VIEL größeren Angriffsfläche geredet hat. Sehe ich nicht so, aber hierfür gibt es eben auch eine Lösung. Container.

Und ja, meine Container laufen als unprivilegierter Benutzer und auf die Container ist AppArmor, Tomoyo und SELinux scharf geschaltet. Zugegeben, eine steile Lernkurve.

 

[D.S.i.u.S.]

Kann vielleicht KI code-Security-Check übernehmen oder ist es noch zu dumm dafür?

 

[mibbio]

Die Backdoor hätte mit VPN nicht funktioniert.

Die Backdoor hätte ohne offenen SSH Port nicht funktioniert.

Es ist nicht der erste erfolgreiche Angriff, welcher SSH Keys ausgehebelt hat. Ich erinnere nur mal an die krasse SSL Lücke, wo nur noch Zufallszahlen zwischen 1 und 65536 generiert wurden.

Und wie sähe deine Argumentation aus, wenn mal VPN durch eine Sicherheitslücke auffällt? Mit der Logik dreht man sich am Ende im Kreis, weil jede Software potentiell eine Sicherheitslücke oder Backdoor enthalten kann. Heute ist SSH schlecht, bei der nächsten Sicherheitslücke dann VPN und danach wird dann noch davon abgeraten, Nginx ins Internet zu hängen, weil der eine Backdoor hat usw.

VPN statt (oder vor) SSH macht die Sache im Endeffekt auch nicht wesentlich sicherer, sondern verlagert nur den möglichen Angriffsvektor.

Zumal der aktuelle Fall auch gar keine Lücke in sshd ist, sondern eine Backdoor in liblzma, einer Bibliothek die von sshd normalerweise gar nicht verwendet wird. Es wird sich nur der Umstand zu Nutze gemacht, dass manche Distributionen sshd mit einer Anbindung an systemd packetieren und dadurch die liblzma indirekt mit sshd gelinkt wird. Der SSH-Dienst wird dann nur verwendet, um über diese Bande die Backdoor in liblzma zu triggern.