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:- xz/liblzma: Erläuterung der Verschleierung im Bash-Stadium. Schöne Analyse der Deobfuskation durch das Injektionsskript in vier „Phasen“.
- Filippo Valsordas Bluesky-Thread Analyse der Hintertür selbst in RSA_public_decrypt, die ihre Natur zeigt: ein RCE, kein Auth-Bypass und gated (akzeptiert den privaten Schlüssel des Autors und kehrt andernfalls zum normalen Verhalten zurück) / nicht rückzahlbar. Der Autor wollte sich möglichst unauffällig verhalten, um nicht entdeckt zu werden!
- XZ-Backdoor-Analyse von @smx-smx (WIP) – Zusätzliche Analyse der Hintertür (ich habe mich fast am Anfang verlaufen 😀)
- xz Backdoor-Dokumentationswiki, eine weitere Analyse des 5.6.1-Injektionsskripts.
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.“
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.
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.“





