Der Rabbit Hole der xz-sshd-Backdoor reicht viel tiefer als erwartet

 (twitter.com/bl4sty)
2 Punkte von GN⁺ 2024-04-07 | 1 Kommentare | Auf WhatsApp teilen
  • Die sshd-Backdoor in xz löst teilweise nicht nur den zuerst entdeckten RSA_public_decrypt-Hook aus, sondern auch zusätzliche Codepfade, die schwerer zu erreichen sind
  • Der Angriffsablauf installiert mit einem manipulierten Befehl einen mm_answer_keyallowed-Hook und setzt anschließend mithilfe mehrerer gefälschter ssh-rsa-Public-Keys einen Befehlsbuffer zusammen
  • Dieser „magic buffer“ enthält zusätzliche Backdoor-Befehle und 2 ed448-Signaturen; in die Signaturen fließen der SHA256-Digest des Hostkeys und die session_id des KEX ein
  • Das aktuelle PoC verwendet eine stark modifizierte paramiko-SSH-Clientbibliothek; der Befehl 0x03 ermöglicht RCE auf Basis von system() sowie das Setzen von uid/gid
  • Auch ein Authentifizierungs-Bypass wurde bestätigt: Überschreibt man mit mm_keyallowed_backdoor cmd 1 die Antwort von mm_answer_authpassword, kann man sich mit beliebigen Passwörtern einloggen

Tiefer verzweigte Backdoor-Pfade

  • Die xz-sshd-Backdoor enthält tiefergehende Funktionen als zunächst bekannt; einige davon wurden bereits direkt ausgelöst
  • Der zentrale Einstiegspunkt ist der RSA_public_decrypt-Hook
    • Sendet man einen passend präparierten Befehl, wird ein weiterer Hook in der Funktion mm_answer_keyallowed von sshd installiert
    • Danach werden mehrere gefälschte ssh-rsa-Public-Keys bereitgestellt, um den „magic buffer“ stückweise zusammenzusetzen
  • Der „magic buffer“ ist ein Buffer für zusätzliche Backdoor-Befehle
    • Darin sind auch 2 ed448-Signaturen enthalten
    • Diese Signaturen werden, wie die Backdoor-Signatur auf der RSA_public_decrypt-Seite, mit dem SHA256-Digest des Hostkeys als Salt versehen
    • Die letzte Signatur bezieht außerdem die 0x20 Byte lange session_id ein, die aus dem initialen SSH-Schlüsselaustausch (KEX) abgeleitet wird

PoC und Authentifizierungs-Bypass

  • Das aktuelle PoC ist mit einer stark modifizierten paramiko-SSH-Clientbibliothek implementiert
  • Der derzeit ausgelöste Befehl ist in diesem Codepfad 0x03
    • Er ermöglicht erneut grundlegende RCE über system()
    • Außerdem unterstützt er das Setzen von uid/gid
  • Es bleibt noch weiterer Code zu verstehen; da einer der mm_answer_keyallowed-Backdoor-Befehle letztlich auch mm_answer_keyverify hookt, scheint ein vollständiger Authentifizierungs-Bypass für interaktive Sessions möglich zu sein
  • Anschließend wurde der Authentifizierungs-Bypass bestätigt
    • mm_keyallowed_backdoor cmd 1 kann die Antwort von mm_answer_authpassword mit einem benutzerdefinierten Wert überschreiben
    • Setzt man die Antwort auf { u32(9), u8(13), u32(1), u32(0) }, ist ein Login mit jedem beliebigen Passwort möglich

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-07
Meinungen auf Hacker News

  • https://threadreaderapp.com/thread/1776691497506623562.html

  • Dieser Vorfall wirkt seltsam, weil er in mancher Hinsicht sehr professionell, in anderer aber ziemlich amateurhaft erscheint.
    Über lange Zeit wurde eine vertrauenswürdige Identität aufgebaut, die glaubwürdig genug war, um Maintainer eines wichtigen Pakets zu werden; es gab einen Social-Engineering-Angriff, an dem offenbar mehrere Personen beteiligt waren; die echte Identität und der Ursprung des Angriffs wurden nicht offengelegt; auch die Verschleierung war ausgefeilt.
    Trotzdem wirkt es schlampig, dass Bugs und eine Performance-Regression in die Produktionsversion gelangten. Wenn eine staatlich unterstützte Organisation wirklich kompetent gewesen wäre, hätte sie wohl vor dem Einreichen in ein öffentliches Projekt intern ausreichend getestet und die verdächtige Performance-Verschlechterung beseitigt.

    • Ich glaube, die Erwartungen sind zu hoch, wenn man „staatlich unterstützt“ hört. Große Organisationen werden am Ende anderen großen Organisationen ähnlich und kämpfen mit Bürokratie, Deadlines, Release-Zyklen und Kommunikationsproblemen zwischen Teams.
      Auch der jüngste „vielleicht eine Backdoor“-Vorfall bei iOS zeigt, dass Organisationen, die viele Schwachstellen horten, nicht immer darauf achten, wenn sie einige davon verbrennen.
    • Es ist nicht schwer zu glauben, dass die Leute, die den Code entwickelt haben, nicht gleichzeitig Valgrind laufen ließen und auf die Performance achteten.
      Ziel waren Server und Appliances; wie viele Server oder Appliances lassen schon in ihrem Basis-Image Valgrind laufen? Im Nachhinein denkt man: „Warum sind sie nicht darauf gekommen?“, aber vermutlich haben sie mit den System-Images getestet, auf die sie abzielten, und nicht mit Custom-Images gewöhnlicher Entwickler.
    • Am 29.02.2024 wurde ein PR eingereicht, der verhindern sollte, dass libsystemd gegen liblzma gelinkt wird [0].
      Kevin Beaumont vermutete, dass „Jia Tan“ dies sah und sofort erkannte, dass die Backdoor dadurch wirkungslos werden könnte, und sich deshalb beeilte, um die enorme Arbeit an diesem Exploit nicht zu verlieren [1]; das klingt plausibel.
      Wegen dieses Deadline-Drucks kam es in 5.6.0 zu einem Crash, und es blieb wohl nicht genug Zeit für Feinschliff, um die Performance-Regression zu reduzieren oder zu beseitigen, die letztlich der Hauptgrund war, warum die Sache aufflog.
      [0]: https://github.com/systemd/systemd/pull/31550
      [1]: https://doublepulsar.com/inside-the-failed-attempt-to-backdo...
    • Wenn selbst Google Gemini ohne Weiteres veröffentlichen konnte, ist es dann wirklich so schwer zu glauben, dass eine solche Schattenorganisation auf subtilere Weise scheitert?
      Wie Patrick McKenzie anderswo beschreibt, funktionieren kriminelle Organisationen ähnlich wie nichtkriminelle: über Ausschüsse und Konsens. So betrachtet ist es verständlich, dass das Schiff wegen Performance-Verlusten durch Feature Creep sinkt. Die Firmen, in denen ich gearbeitet habe, haben noch amateurhaftere Fehler gemacht.
    • Auch kompetenten staatlich unterstützten Organisationen können Pannen passieren. Geheimdienste sind manchmal nicht so kaltblütig kompetent, wie man sich das vorstellt. Die Attentatsversuche des Kremls in Großbritannien waren fast eine Komödie der Fehler [1].
      Vielleicht war auch eine andere Backdoor oder ein alternativer Zugangsweg, den sie nutzten, blockiert worden, sodass sie dringend einen neuen Kanal brauchten.
      [1] https://en.wikipedia.org/wiki/Poisoning_of_Alexander_Litvine...

  • Die Raffinesse hier ist wirklich interessant, aber am Ende flog es wegen einer ziemlich auffälligen Performance-Regression auf.
    Das erinnert mich an ein Zitat, das ich in einer True-Crime-Sendung gehört habe: „Es gibt eine Million Wege, wegen Mordes erwischt zu werden, und wenn dir nur die Hälfte davon einfällt, bist du ein Genie.“

    • Wenn man davon ausgeht, dass hinter dem Account ein Team stand, ergibt es Sinn. Jemand hat vielleicht die Funktion entwickelt, und eine andere, nachlässigere oder weniger erfahrene Person hat sie integriert.
      Wieder jemand anderes könnte die Fake-Accounts verwaltet und in Kommentaren und PRs interagiert haben.
    • Vielleicht bin ich naiv oder zu gutgläubig, aber jedes Mal, wenn ich mir Sorgen mache, dass solche Backdoors bereits weit verbreitet sein könnten, denke ich daran.
      Ich weiß nicht, ob diese hier nur durch Pech aufgeflogen ist oder ob solche Angriffe in der Praxis einfach zu schwer erfolgreich umzusetzen sind. Ich hoffe auf Letzteres, aber wirklich wissen kann man es nicht.
    • Wenn ich mich richtig erinnere, trat die Performance-Regression nur auf, wenn der Code mit dem nicht standardmäßigen -fno-omit-frame-pointer kompiliert wurde. https://mastodon.social/@AndresFreundTec/112187000944648334
    • Mit genug Zeit und mehr lokalen Tests hätten sie wahrscheinlich Erfolg gehabt.
      Ich bin überzeugt, dass der Patch von @teknoraver für libsystemd ihren Zeitplan verändert hat.
    • Gilt „wenn dir nur die Hälfte davon einfällt“ auch für diejenigen, die versuchen, einen Mordfall aufzuklären?

  • Wenn bei solchen Vorfällen viele technische Artikel erscheinen, die tief in die Details gehen, wundere ich mich oft, warum alle sagen: „Das muss staatlich unterstützt sein“, „Schau dir die Timestamps an, ein unwiderlegbarer Beweis“
    Der xz-Fall war zwar ein verdeckter, über lange Zeit vorbereiteter Angriff, aber braucht es dafür wirklich etwas, das über eine einzige fähige Einzelperson hinausgeht? Dass beliebige Personen im Netz ihn analysieren und verstehen können, bedeutet auch, dass er in einem Umfang liegt, den eine Person verstehen kann
    Warum soll es nicht einfach eine kluge, aber unzufriedene Person gewesen sein, die allein gehandelt hat?

    • Der wichtigste Faktor, der an einen staatlichen Akteur denken lässt, ist die Größe der erwarteten Belohnung im Verhältnis zur in den Social-Engineering-Angriff investierten Zeit
      Ein gewinnorientierter Plan dieser Art ist irrational. Das schließt einen irrationalen Akteur oder eine Einzelperson mit nicht finanzieller Motivation nicht aus, lässt aber einen staatlichen Akteur als naheliegenden Kandidaten erscheinen
      Bei Erfolg wäre der Verkaufswert enorm gewesen, aber die Wahrscheinlichkeit, einen Exploit in zentrale Infrastruktur einzuschleusen und lange genug unentdeckt zu bleiben, damit Kunden ihn kaufen und nutzen, ist sehr gering. Staaten können sich Moonshots leisten, Einzelpersonen suchen sich meiner Meinung nach eher Ziele mit höherem Erwartungswert
      Natürlich heißt das nicht, dass es ein fähiger staatlicher Akteur war oder dass viele Ressourcen zugewiesen wurden
    • Stimme zu. Dieser Hack erforderte viel Können, Entschlossenheit und Zeit
      Aber gilt das nicht auch für ziemlich viele Open-Source-Entwickler? Die Motivation ist ebenfalls klar. Dieser Exploit wäre auf dem Schwarzmarkt Millionen Dollar wert gewesen
    • Nichts. Niemand weiß, wer er ist
    • Mich würde interessieren, worauf sich „unwiderlegbarer Beweis“ stützt bzw. wo du das gesehen hast
      Ich habe viele Vermutungen von Leuten gesehen, die sich auskennen, aber diese Formulierung nicht

  • Gibt es einen Artikel, der die Obfuskation der Backdoor selbst zusammenfasst? Nicht die Build-Skripte für die Installation, sondern die eigentliche Backdoor
    Ich habe das Binary in Ghidra geladen und die gefundenen Funktionen überflogen, aber weil ich mit dem ifunc-Mechanismus, der zum Abfangen der Ausführung genutzt wird, nicht vertraut bin, habe ich aufgegeben und es anderen überlassen
    Da es Anti-Debugging-Funktionen gibt, nehme ich an, dass auch der Code obfuskiert ist. Weil er als undurchsichtiges Binary verteilt wurde, dachte ich, dass zumindest ein Teil des Codes mit einem Schlüssel verschlüsselt sein müsste, den wir nicht haben. So wie Teile der STUXNET-Payload

    • Eine vollständige Analyse der Backdoor selbst gibt es noch nicht. Manche Anti-Debugging-Mechanismen kann man per Flag umgehen, aber hier wurde das in der Kompilierungsphase erledigt, was es etwas schwieriger macht
      Dass es Anti-Debugging-Funktionen gibt, heißt nicht zwangsläufig, dass der Code obfuskiert ist. Wie oben gesagt, geschah das zur Build-Zeit. Es ist, als hätte man bereits im eigenen Haus Fallen installiert
      Dieser Vorfall zeigt, welche Probleme entstehen, wenn Paketbetreuer nicht die Quellen aus der richtigen Herkunft beziehen

  • Ich habe diesen Vorfall nicht extrem genau verfolgt, aber es ist sehr seltsam, dass man kaum Diskussionen über die Täter des Hacks hört

    • „Allerdings glaube ich, dass er tatsächlich aus der Zeitzone UTC+02 Winter/UTC+03 DST stammt, also aus einer Region, die Osteuropa (EET) oder Israel (IST) umfasst“
      https://rheaeve.substack.com/p/xz-backdoor-times-damned-time...
    • Es gab viele Spekulationen. Es ist wahrscheinlicher, dass es mehrere Personen statt nur einer waren, und es wirkt plausibel, dass eine Ransomware-Gruppe oder ein staatlicher Nachrichtendienst dahintersteckt
    • Wie bei der Satoshi-Analyse wäre es interessant, die Kommunikation der zugehörigen Online-Personas semantisch zu analysieren, um eine kulturelle Richtung abzuschätzen
      Wenn man prüft, ob sich der Schreibstil im Lauf der Zeit verändert hat, könnte man auch sehen, ob mehrere Personen unter derselben Persona aktiv waren. Es gibt auch ziemlich viel committeten Code, daher wäre es sinnvoll, über Unterschiede im Code-Stil zu untersuchen, ob mehr als eine Person beteiligt war
    • Was soll man diskutieren? Es ist nichts bekannt

  • Es ist ein ziemliches Glück, dass das entdeckt wurde, bevor es sich weit verbreitet hat
    Nicht nur aus dem naheliegenden Grund, dass man nicht will, dass eine unbekannte Partei Remote Code Execution in unserer Infrastruktur hat. Wenn Leute weiter darin herumgraben, könnten sie am Ende eine Payload bauen, die es jedem ermöglicht, die Backdoor zu nutzen
    Dass ein Akteur Zugriff hat, ist schon schlimm, aber dass jeder Zugriff haben kann, ist viel schlimmer

    • Wenn die Payload ein privater RSA-Schlüssel ist, ist das nicht nahezu unmöglich?

  • Ein Link als Alternative zu thereaderapp.com:
    https://nitter.poast.org/bl4sty/status/1776691497506623562

  • Es ist erstaunlich, dass es nach mehreren Tagen noch nicht vollständig entschlüsselt ist
    Wenn die Augen der ganzen Welt darauf gerichtet sind und die zentralen Teile theoretisch öffentlich sind, dann bedeutet es, dass die Obfuskation ziemlich gut gemacht ist, wenn sie so lange standhält

  • Mich beunruhigt der Langzeitspiel-Charakter dieses Vorfalls
    Erstens wurde lange abgewartet, um die „Infrastruktur“ zum Erstellen der Backdoor aufzubauen. Zweitens hätte man, nachdem sich der Exploit tatsächlich in der Produktion verbreitet hatte, vermutlich ein weiteres Langzeitspiel vorbereitet. Die richtige Art, einen Lottogewinn auszugeben, ist schließlich Investieren
    Drittens frage ich mich, ob solche Spiele auch jetzt gerade laufen. Das ist beängstigend