XZ-Backdoor-Angriff

XZ Backdoor: „Das war knapp“

Hintertüren für SSH

Ein böswilliger oder kompromittierter Betreuer hat bösartiges Verhalten in eine Bibliothek namens Abonnieren, Teil der xz-Komprimierungstools und -Bibliotheken, was zu einer Hintertür in SSH führt. Dies ist ein fortgeschrittener Software-Supply-Chain-Angriff, da die Bibliothek absichtlich für die Hintertür modifiziert wurde, mit Verschleierungs- und Stealth-Techniken, um die Angriffsnutzlast vor Prüfern zu verbergen. Der Angriff wurde erst kürzlich (am 29. März) entdeckt und bekannt gegeben, und die Abwehrmaßnahmen laufen noch. Er konnte jedoch schnell eingedämmt werden, da er anscheinend nur Vorabversionen einer begrenzten Anzahl von Umgebungen betrifft (DEB- und RPM-Pakete für die x86_64-Architektur und mit GCC erstellt). Wie dem auch sei, der CVE erhielt eine CVSS-Basisscore von 10, die für die kritischsten Cybersicherheitslücken reserviert ist. Sollte es in stabile Distributionen gelangen, wären die Auswirkungen überwältigend.  Die technische Analyse des Angriffs, einschließlich der xz-Hintertür ausführlich erklärt, wurde an anderer Stelle analysiert. Dieser Beitrag konzentriert sich auf den zeitlichen Ablauf des Angriffs, wie er erkannt werden konnte, wie der Vorfall bis heute gehandhabt wurde und welche Lehren aus dem Angriff gezogen werden können.

So wurde die XZ-Hintertür eingeschleust

Hinweis: Das Git-Repository befindet sich in git.tukaani.org. Jedoch Es gab auch eine Auf GitHub gehostetes Repository (derzeit gesperrt), wo das GitHub-Konto die Änderungen gepostet hat, die später in das Git-Repository integriert wurden. Ein Teil der Hintertür scheint nur in den verteilten Tarballs für die Versionen 5.6.0 und 5.6.1 zu sein, nicht in den Git-Repositories und basiert auf einem einzelne Zeile in build-to-host.m4 Makrodatei, die von autoconf verwendet wird. Der andere Teil befand sich in zwei angeblichen Testdateien bad-3-corrupt_lzma2.xz und gut-groß_komprimiert.lzma Das waren commitTed vom GitHub-Konto „Jia Tan“ (JiaT75) In der xz-Repository am 23. Februar. Es war eine harmlose Änderung, die Testdateien hinzufügte (angeblich komprimierte Blöcke mit den Endungen .lzma und .xz). Interessanterweise wurden die Testdateien von den Tests nicht verwendet! Die Zeile in der .m4-Datei fügt ein verschleiertes Skript ein (im Tarball enthalten), das am Ende von configure ausgeführt wird, wenn bestimmte Bedingungen erfüllt sind. Es ändert das Makefile für die Abonnieren Bibliothek, die Code enthält, der Daten aus der .xz-Datei extrahiert, die nach der Deobfuskation in diesem Skript, wird am Ende von configure aufgerufen. Es entscheidet, ob der Build-Prozess geändert werden soll, um Code einzufügen: nur unter GCC und dem GCC-Linker, unter Debian oder rpm und nur für x86_64 Linux. Bei Übereinstimmung unterbricht der eingefügte Code die Ausführung, indem er zwei ifunc Resolver, sodass bestimmte Aufrufe ersetzt werden. Dies führt dazu, dass die Symboltabellen im Speicher analysiert werden (dies dauert eine Weile, was zur Erkennung führte, wie später erläutert). Dann wird es interessant: Die Hintertür installiert einen Audit-Hook im dynamischen Linker und wartet auf das Eintreffen des Funktionssymbols RSA_public_decrypt. Dieses wird an einen Punkt im Code der Hintertür umgeleitet, der wiederum libcrypto, vermutlich um eine normale Authentifizierung durchzuführen. Und die Nutzlast wird aktiviert, wenn das laufende Programm den Prozessnamen hat /usr/sbin/sshd. Es war klar, dass SSH-Server das Ziel waren. Traditionell sshd Server wie OpenSSH waren nicht verknüpft mit Abonnieren, aber sshd ist oft gepatcht um systemd-notify zu unterstützen, damit andere Dienste gestartet werden können, wenn sshd läuft. Und dann wird liblzma indirekt geladen von systemd, und der Kreis schließt sich. Die Hintertür ist noch nicht vollständig analysiert, aber es scheint Ermöglicht die Ausführung von Remote-Befehlen. (RCE) mit den Privilegien des SSHD-Daemons, die in einem Vorauthentifizierungskontext ausgeführt wird. Informationen aus dem Remote-Zertifikat werden, wenn sie mit der Hintertür übereinstimmen, mit ChaCha20 entschlüsselt und nach erfolgreicher Entschlüsselung an den System(). Es handelt sich also im Wesentlichen um einen Gated RCE, der viel schlimmer ist als eine bloße Umgehung des öffentlichen Schlüssels.  Ein späteres 5.6.1-Tarball zeigte zusätzliche Bemühungen, die Spuren zu verbergen, weitere Verschleierung für Symbolnamen hinzuzufügen und zu versuchen, die aufgetretenen Fehler zu beheben. Ein Erweiterungsmechanismus Außerdem wurde eine Funktion implementiert, mit der in zusätzlichen Testdateien nach bestimmten Signaturen gesucht wurde, die der Hintertür hinzugefügt werden sollten. Dieser ziemlich raffinierte Angriff könnte unbemerkt bleiben, bis stabile Linux-Distributionen verfügbar sind. Glücklicherweise prüfen einige Leute gerne, warum ungewöhnliche Dinge passieren.  

Die Entdeckung des XZ-Backdoor-Angriffs

Häufig wird das eingeschleuste bösartige Verhalten durch Zufall oder Unfall entdeckt. Ein gutes Beispiel war ein Veraltungswarnung („Wer kümmert sich schon um Warnungen?“), die zur Entdeckung der Event-Stream-Angriff im Oktober 2018. Ein anderer ist der Benutzer, der warnte Codecov im April 2021, dass ihr Bash-Uploader-Skript die Prüfsumme nicht bestanden hat („Wer überprüft die Integrität von Artefakten mit Prüfsummen?“) Anomalien und seltsame Symptome mit ssh logins (logins viel CPU-Beanspruchung und erhöhte verstrichene Zeit, Valgrind-Fehler) weckte die Neugier von Andres Freund, ein aufmerksamer PostgreSQL-Entwickler, aber kein Sicherheitsanalyst (wie er sagte). Nach einigen Untersuchungen mit OpenSSH auf Debian Sid kam er zu dem Schluss, dass ein Antwortzeitproblem auf einer Bibliothek beruhte, Abonnieren, Teil der xz-utils Komprimierungsbibliothek. Der Grund: „das Upstream-xz-Repository und die xz-Tarballs wurden mit einer Hintertür versehen„. Diese Diagnose war so genau!   Am 29. März 2024 veröffentlichte Andres in Openwall die erste Analyse: „Hintertür im Upstream xz/liblzma, die zur Kompromittierung des SSH-Servers führt”. Tatsache: Die Tarballs von XZ Utils 5.6.0 und 5.6.1 enthalten eine Hintertür. Diese Tarballs wurden vom oben genannten Jia Tan-Konto erstellt und signiert.  He gepostet in Mastodon später am Tag, als ihm klar wurde, dass die Entdeckung zufällig war und viele Zufälle erforderte. Die Kommentare anderer Benutzer sind lesenswert. GitHub-Benutzer Abonnieren (aka Sam James) veröffentlichte einen netten Gist FAQ zur xz-utils-Hintertür wo der Angriff zusammengefasst wurde, mit Verweisen auf weitere eingehende Analysen der Angriffsnutzlast. Diese Analysen waren technisch interessant und halfen uns, die Injektion, die sehr aufwändig war, besser zu verstehen: Das ist schön Poster von Thomas Roccia  zeigt einen Teil der Aktivität von JiaT75 im GitHub-Repository und wie das Injektionsskript die binäre Hintertür einfügt, was die xz-Hintertür erklärt.

Wie der Vorfall gehandhabt wurde

Die Offenlegung durch Andreas Freund war vorsichtig, weil, in seinen eigenen Worten:

Angesichts der offensichtlichen Upstream-Beteiligung habe ich keinen Upstream-Fehler gemeldet. Da ich zunächst dachte, es handele sich um ein Debian-spezifisches Problem, schickte ich einen vorläufigen Bericht an security@...ian.org. Anschließend meldete ich das Problem an distros@. CISA wurde durch eine Verteilung benachrichtigt.“

Red Hat hat diesem Problem die Bezeichnung CVE-2024-3094 zugewiesen. Danach verbreitete sich die Nachricht wie ein Lauffeuer. Lasse Collin, der andere Betreuer des XZ, fügte hinzu: neu commit am Sa 30. März mit dem Titel „CMake: Sabotierte Landlock-Sandbox-Prüfung beheben“. Eine der Sandboxing-Landlock-Methoden der Bibliothek wurde sabotiert, zumindest beim Erstellen mit CMake. Er hat das Problem umgehend im XZ Utils-Hintertür. Red Hat hat dieses Problem zugewiesen CVE-2024-3094 (siehe auch in CVE, NVD, Ubuntu). Es erhielt eine satte CVSS-Basiswert von 10. Solche Ergebnisse erobern das Internet immer im Sturm. CISA veröffentlichte am selben 29. März eine alarmieren, aufgrund der Dringlichkeit möglicherweise zu simpel, und empfiehlt den Benutzern, auf die stabile Version 5.4.6 herunterzustufen. GitHub-Repositories unter der Organisation Tukaani wurden deaktiviert (ist das gut oder schlecht? Ich denke, gut: Viele Distributionen und Organisationen verlinkten immer noch auf die GitHub-Releases, um die infizierten Tarballs zum Erstellen zu beziehen. Das Deaktivieren des Repos verhindert das. Es gibt sowieso eine Kopie der Repos unter git.tukaani.org). Die GitHub-Konten JiaTan75 und Lasse Collins‘ (Larhzu) wurden ebenfalls gesperrt. Dies ist Teil der Containment, selbst wenn es unschuldige Menschen betreffen kann. JiaT75 Aktivität in nicht deaktivierten Repositorien ist noch nicht zu sehen. Die Industrie reagierte prompt. Viele Hersteller veröffentlichten Regeln zur Erkennung anfälliger Systeme, wie zum Beispiel Yara regiertoder Unterstützung bei kommerziellen Tools von Sysdig, PANund andere. Sicherheitsspezialisten wie James Berthoty gepostet über die Überprüfung unseres Umgangs mit Open-Source-Software.  Wir befinden uns jetzt in der Phase der Beseitigung und Wiederherstellung des Vorfalls. Andere von JiaTan75 verwaltete Projekte werden genau überprüft, insbesondere das libarchive/libarchive (wo JiaTan75 regelmäßig Beiträge verfasste) und der Fuzzer Oss-Fuzz (wo dies commit von JiaTan75 versuchte, oss-fuzz zu vermeiden, was in der Tat konnte die Hintertür nicht erkennen). Diese Verschleierungsversuche liefern weitere Beweise. 

Wer wird angegriffen?

Entweder wurde das GitHub-Konto JiaT75 kompromittiert (denken Sie daran, dass GitHub kürzlich 2FA vorgeschrieben hat) oder der physische Benutzer, dem das Konto gehört, ist auf die dunkle Seite gewechselt. Aber es gibt zwingende Gründe, an eine Advanced Persistent Threat (APT) zu denken, möglicherweise staatlich unterstützt, aufgrund der technischen Raffinesse des Angriffs. Weitere Untersuchungen durch Cybersicherheitsbehörden und Strafverfolgungsbehörden werden es zeigen … Dieser Eintrag in YCombinator Hacker News über Jia Tan wirft etwas Licht auf das „Wer“ und seine Aktivitäten. Empfehlenswert! Es gibt viele Informationen darüber, wie die Bösewichte versuchen, andere Benutzer mithilfe von Social Engineering zu täuschen.

Sehr ärgerlich – der mutmaßliche Autor der Hintertür stand wochenlang mit mir (rwmj) in Kontakt, um xz 5.6.x wegen seiner „tollen neuen Funktionen“ in Fedora 40 & 41 zu integrieren. Wir haben sogar mit ihm zusammengearbeitet, um das Valgrind-Problem zu beheben (das, wie sich jetzt herausstellt, durch die von ihm hinzugefügte Hintertür verursacht wurde). Wir mussten gestern Abend nach einem unbeabsichtigten Verstoß gegen das Embargo schnellstmöglich das Problem beheben. Er ist seit zwei Jahren Teil des xz-Projekts und hat alle möglichen binären Testdateien hinzugefügt. Ehrlich gesagt wäre ich bei diesem Grad an Komplexität selbst älteren xz-Versionen gegenüber misstrauisch, bis das Gegenteil bewiesen ist.

Jia Tan hat Maßnahmen ergriffen, um eine Verfolgung zu verhindern: Offenbar hat er VPN (vpn.singapore.witopia.net) für die Verbindung verwendet – was an sich ok ist. Und viele Änderungen scheinen durch temporäre, einmalige E-Mails (in diesem Fall von ProtonMail) unterstützt zu werden, die dazu drängen, die Änderungen zu übernehmen. Der Akteur könnte beabsichtigen, noch tiefer vorzudringen, bis hin zum Linux-Kernel, als Mitwirkender an der xy-eingebettet Projekt. Eine erste Analyse ergab bis heute keine Hinweise auf eine Fehlgeburt. Hinweis: eine weitere der unauffällige XZ-Mitarbeiter „Hans Jansen“ (GitHub-Benutzer „hansjans162“) ist auf dem Prüfstand. Sein Account bei Debian ist jetzt verstopft. Er hat viele Updates für Debian Games gemacht, um das gewünschte Update auf debian/xz-utils zu verbergen, ein Update auf Upstream 5.6.1, um die Verbreitung der Hintertür zu beschleunigen, debian/unstable Alles, was wir derzeit sagen können, ist, dass es sich um einen (noch nicht identifizierten) APT handelt, der verschiedene Konten verwendet, seit mindestens zwei Jahren an dieser Kampagne arbeitet und geduldig daran arbeitet, einen RCE in SSH zu implantieren.

Konnte der XZ-Backdoor-Angriff verhindert werden?

Ziemlich schwierig.  Erstens gelangte ein Teil der eingeschleusten Hintertür in komprimierte Testdateien, die nicht von Tests verwendet wurden. Im Nachhinein könnte das einige (laute) Alarme auslösen, aber wer prüft schon, ob alle Testdateien in der Praxis von tatsächlichen Tests verwendet werden? Zweitens gelangte ein Teil der eingeschleusten Hintertür in Makrodateien in die Release-Tarballs, und es ist schwierig, manuell auf Unterschiede zu den erwarteten Tarballs zu prüfen. Die Automatisierung ist zudem komplex, da das erwartete Ergebnis des Builds selbst (für jeden, der weiß, wie Automake/Autoconf funktioniert) schwer zu modellieren ist, um zu analysieren, ob der echte Tarball den Erwartungen entspricht. Einige stellten es as „Die Nichtübereinstimmung der Tarballs mit dem Git-Baum ist ein Feature, kein Bug“. Die Herkunft binärer Tarballs aus ihrem Quellcode ist ein ungelöstes Problem. Ruf des Benutzers? Nun, der GitHub-Account JiaTan75 hat der Vergangenheit zufolge keine betrügerischen Dinge getan commits. Es wurde erst suspendiert, nachdem sich die Beweise angesammelt hatten, aber bis zum 29. März war das ein normaler Benutzer, der normale Geschäfte abwickelte. Nun, nicht so normal. Später commits (fehlen uns die Worte., fehlen uns die Worte., fehlen uns die Worte.und fehlen uns die Worte. wodurch der Exploit-Code angepasst wurde) versuchte, die Valgrind-Fehler und Abstürze in einigen Konfigurationen zu beheben, die auf Unterschiede im von der Hintertür erwarteten Stapellayout zurückzuführen waren. Commit Überprüfungen könnten dies erkennen, aber wer hat schon die Geduld, Änderungen in einer binären Testdatei oder die wahre Motivation für eine Änderung der GCC-Attribute im C-Quellcode zu analysieren? Sollte man Alarm schlagen, wenn ein SSH login dauert 800 ms statt 300 ms? Wahrscheinlich würden nur übervorsichtige Leute darauf aufmerksam werden. Cicero sagte: „Voreiligkeit gehört zur Jugend, Besonnenheit zum Alter.“   Die ifunc-Infrastruktur wurde im Juni 2023 von „Hans Jansen“ und „Jia Tan“ hinzugefügt. Dies ist die erste commit Hinzufügen von ifunc-Unterstützung zu crc64_fast.c (wird später zum Einfügen der Hintertür verwendet). Monate vor dem Einfügen der Backdoor-Binärdateien in die Testdateien!

Hinweis: Autor und commitDie Änderungen können hier unterschiedlich sein, aber das ist normal: Lasse Collin ist der Projektbetreuer und hat die Änderungen zusammengeführt. Er dankt sogar „Hans Jansen“ …

Vor Andres Freunds Beitrag und dem von RedHat erstellten CVE hat niemand Bedenken geäußert. Wenn Sie eine Kaskade von Tools sehen, die dies erkennen würden, erkennen sie jetzt die betroffene Komponente. ex post facto

Die beste Vorbeugung liegt wahrscheinlich in der Natur der Linux-Distributionen und darin, dass instabile, hochmoderne Versionen nur nach einem schrittweisen Prozess in stabile Distributionen übergehen.

Lehren aus dem XZ-BBackdoor-Angriff

Wir haben festgestellt, wie schwierig es ist, absichtlich Hintertüren. Hintertüren sollten als interne Bedrohung betrachtet werden, da sie von internen Mitarbeitern oder über kompromittierte interne Konten platziert werden. Und diesen Leuten wird meist vertraut. Und wenn die Hintertür in das verteilte Artefakt implantiert ist, ist es schwieriger, sie zu erkennen.

Einige Autoren wie Kevin Beaumont darauf hingewiesen fragst, was eine große Angriffsfläche für Dienste von Drittanbietern über Hintertüren öffnet. Dies ist es, was der Bösewicht hier missbraucht hat. Systemd hat viele Aufmerksamkeiten, aber XZ ist eine obskure Bibliothek weiter oben in der Kette. „Wenn der Upstream verunreinigt ist, trinken alle weiter unten vergiftetes Wasser.“

Eine unabhängige Änderungsanforderung im System für dynamisches Laden von Komprimierungsbibliotheken, das die Hintertür entfernen würde, wurde bereits in das System integriert, aber noch nicht ausgeliefert. Die zusätzlichen Abhängigkeiten, die libsystemd einführt, können die Quelle von Schwachstellen seinund gestern Diese Anfrage wurde geöffnet

A Kommentar in „xz: Deaktivieren Sie ifunc, um das Problem zu beheben“ commit gab einen scharfen Einblick in die Frage, worauf wir uns konzentrieren müssen, wenn wir derartige Aktivitäten verhindern wollen (Hervorhebung durch mich):

„Die Lektion, die wir als Gemeinschaft lernen sollten, ist, software supply chain security ganzheitlich, indem Build-Systeme über den bloßen Quellcode hinaus geprüft werden. Wie beim SolarWinds-Einbruch, bei dem Angreifer Software-Updates für das Closed-Source-Überwachungssoftwareangebot von SolarWinds modifizierten.“

Die frühe Entdeckung und die prompte Reaktion begrenzten die Auswirkungen sehr. Wenn Sie sich an die Schlussszene aus Men in Black III: „Das war knapp“. Auch dieses Mal hat K nicht vergessen, den Tipp zu hinterlassen. Und kein Boglodit hat stabile Linux-Distributionen betreten.
1. „Ich bin *kein* Sicherheitsforscher und auch kein Reverse Engineer.“ 2. Jia ist ein häufiger chinesischer Vorname. Tan ist auch ein häufiger Familienname und bedeutet „großartig“. Viele nicht verwandte Personen tragen diesen Namen. Bitte verurteilen Sie niemanden mit diesem Namen!
SCA-Tools-Software-Zusammensetzungs-Analyse-Tools
Priorisieren, beheben und sichern Sie Ihre Softwarerisiken
7-Tage kostenlose Testversion
Keine Kreditkarte erforderlich

Sichern Sie Ihre Softwareentwicklung und -bereitstellung

mit der Xygeni-Produktsuite