Xzbot: Notizen, Honeypot und Exploit-Demo für die xz-Backdoor

Analyse der xz-Backdoor (CVE-2024-3094)

• honeypot: Erkennt Eindringversuche über einen gefälschten verwundbaren Server
• ed448 patch: Patcht liblzma.so, damit ein eigener öffentlicher ED448-Schlüssel verwendet wird
• backdoor format: Format der Backdoor-Payload
• backdoor demo: CLI zum Auslösen von RCE unter der Annahme, dass der private ED448-Schlüssel bekannt ist

honeypot

• Stellt einen einfachen openssh-Patch bereit, der alle Verbindungsversuche protokolliert, deren öffentlicher Schlüssel N dem Backdoor-Format entspricht
• Verbindungsversuche erscheinen in den sshd-Logs wie folgt

ed448 patch

• Die Backdoor verwendet einen hartcodierten öffentlichen ED448-Schlüssel zur Signaturprüfung und Payload-Entschlüsselung
• Wenn dieser Schlüssel durch den eigenen ersetzt wird, kann die Backdoor ausgelöst werden
• Lädt das libxzma-Shared-Object mit integrierter Backdoor herunter und ersetzt den Schlüssel durch Ausführen des Patch-Skripts

backdoor format

• Die Backdoor kann ausgelöst werden, indem eine Verbindung mit einem SSH-Zertifikat hergestellt und die Payload in den N-Wert des CA-Signaturschlüssels eingebettet wird
• Diese Payload muss mit dem ED448-Schlüssel des Angreifers verschlüsselt und signiert werden
• Die Payload-Struktur folgt dem angegebenen Format

backdoor demo

• Zeigt, wie eine Verbindung zu einem verwundbaren SSH-Server hergestellt und der Befehl id > /tmp/.xz ausgeführt wird
• Auf dem verwundbaren Server kann der system()-Aufruf überwacht und die Ausführung des Befehls beobachtet werden
• Der normale sshd-Prozessbaum und der über die Backdoor erzeugte Prozessbaum sehen unterschiedlich aus

Meinung von GN⁺

• Dieser Artikel behandelt eine eingehende Analyse der xz-Backdoor-Schwachstelle mit der Kennung CVE-2024-3094 und bietet Sicherheitsforschern sowie Systemadministratoren sehr nützliche Informationen.
• Indem gezeigt wird, wie sich die Backdoor erkennen und wie darauf reagiert werden kann, kann er beim Schutz verwundbarer Systeme helfen.
• Da solche Schwachstellen grundlegende Sicherheitsmechanismen eines Systems umgehen können, sollten Softwareentwickler und Sicherheitsexperten diese Art von Schwachstellen verstehen und Maßnahmen zu ihrer Vermeidung ergreifen.
• Andere Sicherheitstools oder Projekte mit ähnlichen Funktionen sind etwa OpenSSH, Fail2Ban und Snort; sie können zusätzliche Verteidigungsebenen zum Schutz von Systemen bieten.
• Da dieser Artikel technische Details zu einer neuen Schwachstelle liefert, kann er der Security-Community dabei helfen, stärkere Verteidigungsstrategien zu entwickeln.

[GN⁺]

Hacker-News-Kommentare

• Zusammenfassung der Hacker-News-Kommentare:
  • Ein interessanter Hinweis auf eine RCE-Schwachstelle (Remote Code Execution), für die der private Schlüssel des Angreifers erforderlich ist. Korrektur: Der Link wurde falsch verstanden; der ursprüngliche Kommentar bleibt der Dokumentation halber erhalten.

    • Diese Schwachstelle wirkt ironischerweise so, als sei sie mit Blick auf Sicherheit entwickelt worden. Außerdem scheint die Person, die die Backdoor in demselben Mail-Thread committet hat, in letzter Zeit auch zum Kernel beigetragen zu haben.

  • Bewunderung für die Hacker-Community und insbesondere für amlweems, weil ein POC (Proof of Concept) so schnell implementiert und dokumentiert wurde. Korrektur: Der nächste Schritt ist herauszufinden, wie man verwundbare Distributionen identifiziert und aktives Probing von SSH-Servern überwacht.

    • Lob für die schnelle Reaktion und Analyse der Community.

  • Neugier, ob das PoC gegen Tools zur Erkennung von anormalem Verhalten wie Carbon Black, AWS GuardDuty, SysDig usw. getestet wurde und ob es dadurch schnell erkannt werden könnte.

    • Interesse an PoC-Tests mit Tools zur Anomalieerkennung.

  • Die Frage, ob es auch ohne SSH-Verbindung funktioniert hat. In der String-Liste auf GitHub stehen auch "DISPLAY" und "WAYLAND_DISPLAY".

    • Spekulationen über einen größeren Wirkungsbereich aufgrund von Strings, die nicht direkt mit SSH zusammenhängen.

  • Eine Frage dazu, wie der Patch auf openssh_RSA_verify angewendet wurde, wenn zur Laufzeit kein openssh.patch erforderlich ist und liblzma.so.5.6.1 in den Speicher geladen wird.

    • Eine technische Frage zum Ablauf der Ausnutzung zur Laufzeit.

  • Der Hinweis, dass ein erfolgreicher Angriff keine Logs hinterlässt. Daraus ergibt sich die Frage, ob Angreifer beliebige Befehle ohne Log-Einträge ausführen konnten.

    • Sorge darüber, dass ein Angriff ohne Log-Erzeugung möglich war.

  • Meinungen dazu, wie die Maintainer der xz-, OpenSSH- und Linux-Projekte auf diese Schwachstelle reagiert haben und wie sich solche Schwachstellen künftig verhindern lassen.

    • Interesse an den Reaktionen der Projektverantwortlichen und an künftigen Präventionsmaßnahmen.

  • Eine Diskussion über staatlich organisierte Spionage und Backdoors. Die USA bevorzugen eher Eingriffe auf Hardware-Ebene, während andere Staaten wie Israel sich auf langfristige Software-Backdoors konzentrieren.

    • Analyse länderspezifischer Backdoor-Strategien.

  • Die Frage, warum ED448 verwendet wurde, obwohl üblicherweise curve 25519 empfohlen wird.

    • Zweifel an der Wahl eines bestimmten kryptografischen Algorithmus.