Der XZ-Backdoor-Vorfall – erste Analyseergebnisse

 (securelist.com)
2 Punkte von GN⁺ 2024-04-13 | 1 Kommentare | Auf WhatsApp teilen

  • Timeline der Ereignisse:

    • 2024.01.19: XZ-Website wird von einem neuen Maintainer (jiaT75) auf GitHub Pages umgezogen
    • 2024.02.15: build-to-host.m4 wird zu .gitignore hinzugefügt
    • 2024.02.23: Zwei „Testdateien“, die Stufen des bösartigen Skripts enthalten, werden eingeführt
    • 2024.02.24: XZ 5.6.0 wird veröffentlicht
    • 2024.02.26: Commit in CMakeLists.txt, der die Sicherheitsfunktion Landlock sabotiert
    • 2024.03.04: Die Backdoor verursacht Probleme mit Valgrind
    • 2024.03.09: Zwei „Testdateien“ werden aktualisiert, CRC-Funktionen geändert, Valgrind-Problem „behoben“
    • 2024.03.09: XZ 5.6.1 wird veröffentlicht
    • 2024.03.28: Fehler entdeckt, Debian und RedHat benachrichtigt, Debian setzt XZ zurück
    • 2024.03.29: E-Mail auf der OSS-Security-Mailingliste veröffentlicht, RedHat bestätigt Auslieferung der kompromittierten XZ-Version
    • 2024.03.30: Debian stoppt Builds und startet den Rebuild-Prozess
    • 2024.04.02: Der Hauptentwickler von XZ erkennt den Backdoor-Vorfall an

  • Hashwerte der XZ-Distributionen mit enthaltener bösartiger Backdoor:

    • xz-5.6.0: MD5-, SHA1- und SHA256-Hashwerte werden bereitgestellt
    • xz-5.6.1: MD5-, SHA1- und SHA256-Hashwerte werden bereitgestellt

Analyse der Erstinfektion

  • Stage 1 - manipuliertes build-to-host-Skript:

    • Die Release-Source-Dateien waren anfangs harmlos, enthielten jedoch eine Datei build-to-host.m4, die bösartigen Code ausführt, wenn sie von einer vom Angreifer kontrollierten URL heruntergeladen werden
    • Diese .m4-Datei wird während des Builds ausgeführt und verändert sowie entpackt die erste Datei, die dem Testordner hinzugefügt wurde

  • Stage 2 - injiziertes Shell-Skript:

    • Das über die .m4-Datei injizierte bösartige Skript prüft, ob es innerhalb des vorgesehenen Build-Prozesses unter Linux ausgeführt wird
    • Mit der Datei good-large_compressed.lzma wird die nächste Stufe ausgeführt; diese ist normal komprimiert, enthält in den dekomprimierten Daten jedoch auch Müll-Daten
    • Mit den Befehlen head/tail werden 33.492 Byte extrahiert und mit dem Befehl tr eine einfache Substitution angewendet, um die Verschleierung aufzuheben

  • Stage 3 - Extraktion der Backdoor:

    • Das Shell-Skript der letzten Stufe führt mehrere Prüfungen durch, ob es in der erwarteten Umgebung läuft
    • Es extrahiert den eigentlichen binären Backdoor-Code, der an einem anderen Offset in derselben Datei good-large_compressed.lzma verborgen ist
    • Mit dem XZ-Tool wird die Datei extrahiert, und über eine Reihe von head-Aufrufen werden die Binärdaten mit einem RC4-ähnlichen Algorithmus entschlüsselt
    • Die komprimierte Datei wird mit XZ entpackt, Anfangsbytes werden anhand vordefinierter Werte entfernt und dann als liblzma_la-crc64-fast.o gespeichert
    • Die Funktion is_arch_extension_supported in crc_x86_clmul.h wird geändert, sodass der Aufruf von __get_cpuid zu _get_cpuid wird

Analyse der binären Backdoor

  • Szenario des verdeckten Ladens:

    • XZ verwendet für CRC-Berechnungen die Funktionen lzma_crc32 und lzma_crc64, die in der ELF-Symboltabelle als Typ IFUNC gespeichert sind
    • IFUNC wird verwendet, um dynamisch zu entscheiden, ob optimierte Versionen genutzt werden sollen
    • Die Backdoor wird als Objektdatei gespeichert, ihr Hauptziel ist es, beim Kompilieren mit der main-Executable verlinkt zu werden
    • Die Objektdatei enthält das Symbol _get_cpuid; indem im Originalquellcode ein Unterstrich entfernt wird, ruft der Code bei einem Aufruf von _get_cpuid tatsächlich die Backdoor-Version auf

  • Analyse des Backdoor-Codes:

    • Der initiale Backdoor-Code wird zweimal aufgerufen; die eigentliche bösartige Aktivität beginnt, wenn die IFUNC lzma_crc64 _get_cpuid aufruft
    • Er findet die GOT-Adresse, lokalisiert die Position des cpuid-Pointers und ersetzt sie durch einen Pointer auf die bösartige main-Funktion
    • Das Hauptziel ist das Hooking bestimmter Funktionen, um alle Verbindungen zu kompromittierten Systemen überwachen zu können

  • Kernverhalten:

    • RSA_public_decrypt, EVP_PKEY_set1_RSA, RSA_get0_key und weitere libcrypto-Funktionen sind Hooking-Ziele
    • Es wird geprüft, ob der aktuelle Prozess die Ausführungskriterien erfüllt und ob ein Kill Switch vorhanden ist
    • Für String-Operationen wird eine Trie-Struktur verwendet
    • Es werden mindestens drei Symbol-Resolver-Routinen verwendet, um die Position von ELF-Symbol-Strukturen zu finden
    • Durch Missbrauch der Funktion rtdl-audit wird die Symbol-Resolving-Routine gekapert, um das Hooking von Funktionen zu erreichen

Einschätzung von GN⁺

  • Dieser Artikel zeigt sehr gut einen äußerst ausgefeilten Angriff, bei dem Schadcode in Open-Source-Software eingeschleust wurde. Er verdeutlicht, dass die Stärken von Open Source auch gegen das Ökosystem missbraucht werden können.

  • Cyberangriffe und Backdoors auf Linux-Systeme werden immer raffinierter. Besonders Angriffe über SSH-Server können zu einer schwerwiegenden Sicherheitsbedrohung werden.

  • Gleichzeitig zeigt der Fall auch die Selbstreinigungskraft des Open-Source-Ökosystems. Letztlich wurde die Backdoor von der Community entdeckt und schnell eingedämmt. Transparenz ist der Schlüssel.

  • Der Einsatz fortgeschrittener Techniken wie Trie-Datenstrukturen, Symbol Resolvern und dl_audit-Hooking zeigt die technische Evolution von Linux-Malware. Auch der Sicherheit von Linux-Systemen muss besondere Aufmerksamkeit gelten.

  • Wenn Unternehmen Open-Source-Software einführen, ist neben der Lizenz auch eine Prüfung unter Sicherheitsgesichtspunkten unverzichtbar. Es muss genau geprüft werden, ob die Bezugsquelle vertrauenswürdig ist und ob der Code fortlaufend überwacht wird.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-13
Hacker-News-Kommentare

Zusammenfassung:

  • Angesichts des großen Aufwands, den der Angreifer in Skripte und Code gesteckt hat, um einer Erkennung zu entgehen, könnte dieses gesamte Projekt als Alternative zu einem Wechsel oder zu mehreren parallel laufenden Bemühungen fungieren
  • Man sollte berücksichtigen, dass der Fokus auf SSHD andere Teile des Gesamtsystems oder technische und soziale Aspekte beeinflussen kann
  • Es könnte ein nützlicher Hardening-Schritt sein, wenn jede dynamisch gelinkte Bibliothek ihre eigene GOT hat und die Tabelle nach Abschluss des dynamischen Linkings als schreibgeschützt markiert wird
  • Der Source Code scheint dadurch entstanden zu sein, dass ein Disassembler ausgeführt, verstanden wurde, was der Code tut, und anschließend alles in beschreibende Namen umbenannt wurde
  • Die durch einen Bug in der Backdoor verursachte Verzögerung und Verlangsamung von SSH wurde letztlich entdeckt; ich frage mich, ob es dazu eine Analyse gab
  • Das xz-Repository ist auf GitHub wieder aufgetaucht, und die Maintainer räumen auf, indem sie unter anderem die ifunc-Unterstützung entfernen und Code committen, der Testdateien erzeugt
  • Die Vorstellung, dass es viele Backdoors geben könnte, die Menschen nicht entdeckt haben, und die Hoffnung, dass es nichts ähnlich Unauffälliges wie dieses mehr gibt