XZ-Backdoor: „Kein Authentifizierungs-Bypass, sondern RCE – mit Gate und nicht replaybar“

• Einer vorläufigen Reverse-Engineering-Analyse der xz-Backdoor zufolge handelt es sich bei diesem Verhalten nicht einfach um einen Authentifizierungs-Bypass, sondern eher um Remote Code Execution (RCE)
• Kern ist der Ablauf, bei dem das gehookte RSA_public_decrypt die Signatur des Host-Keys des Servers mit einem fest codierten Ed448-Key verifiziert
• Wenn die Signaturprüfung erfolgreich ist, kann die Payload an system() übergeben und ausgeführt werden
• Die Analyse sind mit Genehmigung geteilte vorläufige Ergebnisse; der Bluesky-Beitrag enthält zitierte Beiträge oder eingebettete Inhalte
• Die Backdoor wird als mit Gate versehen und nicht replaybar zusammengefasst und ist daher anders zu betrachten als Angriffe, die dieselbe Eingabe einfach wiederverwenden

---

Ausführungsablauf der xz-Backdoor

• Die mit Genehmigung geteilte vorläufige Analyse des Reverse Engineering konzentriert sich auf das gehookte RSA_public_decrypt
  • Es verifiziert die Signatur des Host-Keys des Servers mit einem fest codierten Ed448-Key
  • Nach der Verifizierung wird die Payload an system() übergeben

Einordnung und Einschränkungen

• Dieses Verhalten wird nicht als Authentifizierungs-Bypass, sondern als Remote Code Execution (RCE) eingestuft
• Die Backdoor wird als mit gated/unreplayable-Eigenschaften beschrieben
• Der ursprüngliche Bluesky-Beitrag enthält zitierte Beiträge oder andere eingebettete Inhalte

[GN⁺]

Hacker-News-Kommentare

• Es gibt Ergebnisse aus weiterem Reverse Engineering zu diesem Vorfall. Darin enthalten sind Informationen zur Symbol-Neuzuordnung, die aus dem Prefix-Trie extrahiert wurden, das die Backdoor zum Verbergen von Strings verwendete, und es sieht so aus, als habe sie sich auch vor dem Reverse Engineering bzw. der Analyse selbst verbergen wollen
  https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9...
  Die vollständige Liste der decodierten Strings gibt es hier
  https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01
  Soweit ich das beurteilen kann, ohne mich mit den Interna von OpenSSL gut auszukennen, wird der N-Wert offenbar aus dem Feld n von rsa_st geholt
  https://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
  Dieser Wert ist ein BIGNUM und scheint ein Typ mit variabler Länge zu sein
  https://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
  Die Backdoor extrahiert diesen Wert aus einem vom Remote-Angreifer erhaltenen Zertifikat, versucht damit per ChaCha20 zu entschlüsseln und übergibt das Ergebnis bei Erfolg an system(). system() ist im Wesentlichen ein einfacher Wrapper, der eine Zeile Shell-Skript mit den Rechten des Benutzers ausführt, unter dem der aktuelle Prozess läuft
  Wenn ich das richtig verstehe, ist das schlimmer als eine Umgehung des Public Key. Bei einer Public-Key-Umgehung würde man theoretisch nur die Rechte des Benutzers erhalten, als der man sich anmelden will, und in gehärteten SSH-Konfigurationen wäre der Root-Login wahrscheinlich blockiert
  Hier handelt es sich aber um Remote Code Execution im Kontext des sshd-Prozesses selbst, sodass die Payload bei einem als Root laufenden sshd ebenfalls als Root ausgeführt werden kann. Für weit verbreitete RCE ist das praktisch fast der schlimmste Fall

  • Mit geeignetem Sandboxing, SELinux und Mitigations ließe sich womöglich verhindern, dass der Angreifer etwas mit Root-Rechten tut. Allerdings ist es sehr schwierig, auf einen SSH-Daemon effektiv Sandboxing anzuwenden
  • Absolut gewaltig. Ich kann mir nicht einmal vorstellen, wie man entscheidet, was man mit den Rechten von einer Milliarde Computern machen würde

• Ich frage mich, wie wahrscheinlich es gewesen wäre, dass diese Backdoor später entdeckt worden wäre, wenn sie nicht wegen des Performance-Problems aufgefallen wäre. Ich habe das Performance-Problem als Fehler bzw. behebbaren Mangel im Code verstanden; wichtig ist auch, ob es Werkzeuge gegeben hätte, die so etwas hätten aufspüren können
  Solche Fragen hängen damit zusammen, ob dies die erste Backdoor dieser Art ist oder nur die erste, die ans Licht gekommen ist

  • Aus der Perspektive von jemandem, der etwa ein Jahr in einem Umfeld mit sehr vielen böswilligen IT-Akteuren gearbeitet hat, würde ich sagen, dass die Entdeckungswahrscheinlichkeit immer recht hoch ist. Geheimhaltung erfordert unvorstellbar viel Energie, und ebenso die konsistente Aufrechterhaltung der Wahrheit
    Ein kleiner Fehler kann alles zum Einsturz bringen, und manchmal reicht schon ein einziger Satz, um eine Kettenreaktion auszulösen, durch die ein aufwendig ausgearbeiteter Plan auffliegt
    So laufen kriminalistische Ermittlungen jeden Tag ab. Die Polizeiarbeit ist zwar ressourcenbegrenzt, aber Software wird täglich von Hobby-Analysten, von Experten, die sie quasi als Hobby ständig analysieren, und von Fachleuten, die das beruflich tun, untersucht
    Am Ende wäre es daher wahrscheinlich irgendwann entdeckt worden
    Der XZ-Angriff wurde sehr gut durchgeführt und ist beinahe ein Meisterwerk. Es würde mich nicht überraschen, wenn staatliche Stellen beteiligt gewesen wären. Gleichzeitig war auch enorm viel Glück dabei. Hätte man nur eines der Dinge entdeckt, die jetzt als Problem markiert sind, wären nicht nur ich, sondern viele Kollegen in eine lange Verfolgung eingestiegen
    Eine Schlussfolgerung ist, dass es unmöglich gewesen wäre, so etwas zu finden, wenn xz/liblzma nicht Open Source gewesen wäre. Natürlich wurde es dadurch auch überhaupt erst möglich, aber man muss sich nur vorstellen, das hätte in Windows oder MacOS gesteckt
  • Wenn der Exploit nicht verwendet worden wäre, wäre die Entdeckungswahrscheinlichkeit ziemlich niedrig gewesen. Das Versteck war gut gewählt. Es lag faktisch außerhalb der Codebasis, also an einem Ort, den Auditoren nicht anschauen
    Allerdings wird der Zweck nicht erfüllt, wenn man es nie benutzt. Je öfter es eingesetzt wird, desto größer wird später auch die Wahrscheinlichkeit der Entdeckung. Vergleichbar mit SolarWinds
  • Ich denke, in den kommenden Monaten werden sehr viele Menschen intensiv in diese Richtung nachdenken. Die Frage ist, ob es um Code Review geht oder um irgendeine Form von Verhaltensanalyse
    Persönlich fand ich den system()-Aufruf etwas schlampig, und ein Scanner für Binärfunktionen hätte diesen Pfad womöglich aufspüren können
  • Das wäre wohl schwer zu erwischen gewesen. Der sshd-Patch erfolgt beim erlaubten Schritt des Linking-Zeitpunkts, und wenn diese Analyse stimmt, ist es nicht einmal eine Master-Key-Backdoor, also gibt es keine üblichen Login-Audit-Spuren. Außerdem kann es völlig legitim sein, dass sshd andere Prozesse startet
    Eine sehr eng gefasste SELinux-Policy könnte vielleicht erfassen, wenn sshd etwas anderes als eine Shell ausführt, aber so ein Härtungsgrad ist äußerst selten
    Man hat im Grunde auch schon ausprobiert, ob man es von außerhalb des Ziels entdecken kann. Mehrere Leute haben sich die Payload mit valgrind und Ähnlichem angesehen, aber nichts erkannt. Sie ist auch ziemlich gut dagegen geschützt, in Debugging-Umgebungen entdeckt zu werden. Denn die offengelegte Infrastruktur unter der Payload ist mit Werkzeugen wie ASan nicht kompatibel
    Selbst wenn es gelinkt wird, läuft der Code lange vor main(), daher beobachtet man die Ausführungsszene normalerweise nicht, selbst wenn man mit dem Debugger in der Nähe von liblzma sucht
    Mit strace könnte man alle Systemaufrufe und die Linker-Aktivität sehen, nachdem der Prozess erzeugt wurde. Nach allem, was bisher bekannt ist, scheint die Payload in diesem Schritt aber keine Systemaufrufe zu verwenden, um über ihre Aktivierung zu entscheiden, sondern schaut eher auf argv, environ und Ähnliches
  • Als interessanter Nebenaspekt fällt mir ein, dass auch der Ken-Thompson-Angriff in PWB wegen eines Speicher-Performance-Bugs entdeckt wurde
    [0] https://en.wikipedia.org/wiki/PWB/UNIX
    [1] https://news.ycombinator.com/item?id=38020792

• Anscheinend gibt es in der binären Payload einen codierten String
  https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01...
  Dieser String fungiert als Kill Switch
  https://piaille.fr/@zeno/112185928685603910
  Falls das wirklich so ist, könnte eine Gegenmaßnahme folgende sein

  echo "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" | sudo tee -a /etc/environment  
  

  • -a muss unbedingt enthalten sein. Sonst könnte man die Umgebungsdatei überschreiben. Generell sollte man aber auf eine nicht kompromittierte Version aktualisieren und neu starten
  • Sehr seltsam. Das riecht stark nach einem staatlichen Akteur, der sich eine Möglichkeit offenlassen wollte, die eigenen Systeme zu schützen

• Kann jemand kurz erklären, was die Backdoor genau macht? Weiß man das schon? Die Backdoor selbst scheint ja nicht die Payload zu sein, deshalb frage ich mich, ob dafür ein bösartiges komprimiertes Archiv nötig ist oder ob sie sich in den sshd-Prozess einklinkt und auf schädliche Pakete eines entfernten Angreifers lauscht
  Im Original klingt es so, als könnte ein Angreifer in der Phase vor der Authentifizierung einer SSH-Sitzung eine schädliche Payload schicken, aber ich verstehe nicht, warum gesagt wird, dass vielleicht nie ein Exploit auftaucht. Wenn man den Code reverse engineeren kann, müsste man dann nicht auch einen Proof of Concept schreiben können?
  Wie übernimmt der Angreifer am Ende also die Kontrolle über eine Maschine mit dieser Backdoor?

  • Stell es dir wie eine Tür vor, die sich nur öffnet, wenn man exakt richtig anklopft. Für jemanden, der das geheime Klopfen nicht kennt, sieht sie einfach wie eine Wand aus und verhält sich auch so. Ohne das geheime Klopfen lässt sich womöglich nicht einmal beweisen, dass sie überhaupt aufgeht
    Hier ist es ähnlich. xz versucht erst, bestimmte Daten zu entschlüsseln, bevor es etwas Verdächtiges tut. Weil es asymmetrisch ist, kann die Entschlüsselung verifiziert werden, ohne den geheimen Schlüssel zur Verschlüsselung bereitzustellen. Dafür gibt es den passenden öffentlichen Schlüssel
    Den geheimen Schlüssel zu finden ist praktisch unmöglich, und da sich das Verhalten bei fehlgeschlagener Entschlüsselung nicht auffällig unterscheidet, wird möglicherweise nie Exploit-Code veröffentlicht. Die einzige Möglichkeit, Exploit-Code zu erstellen, wäre, dass der geheime Schlüssel irgendwie gefunden wird, und realistisch gesehen kann er nur durch ein Leak der Backdoor-Entwickler auftauchen
  • Soweit ich gelesen habe, sieht der Angriffsvektor so aus. sshd startet, lädt libsystemd, und diese lädt die XZ-Bibliothek mit dem eingeschleusten Code
    Die XZ-Bibliothek injiziert eigene Versionen von OpenSSL-Funktionen zur Verifikation von RSA-Signaturen
    Wenn sich jemand per SSH anmeldet und dabei ein signiertes SSH-Zertifikat zur Authentifizierung vorlegt, werden diese manipulierten Funktionen aufgerufen
    Zertifikate können im normalen Login-Prozess Assertions enthalten, etwa Benutzername oder Rolle, und damit wird entschieden, ob ein Zertifikat für den Login eines bestimmten Benutzers gültig ist. Erkennt die manipulierte Funktion jedoch ein Zertifikat, das mit einem bestimmten Angreifer-Schlüssel signiert wurde, extrahiert sie Teile eines Unterfelds des Zertifikats und führt sie als Systembefehl aus. Der Ausführungskontext ist sshd, also der Benutzer root
    Leider kennt man den Signaturschlüssel des Angreifers nicht, sondern nur den öffentlichen Schlüssel, den der eingeschleuste Code zur Verifikation nutzt. Im Grunde kann der Angreifer auf einem infizierten System beliebige Befehle als root ausführen, und Spuren davon wären vermutlich höchstens ein fehlgeschlagener Login-Versuch. Auf Systemen mit Internetzugang kommt so etwas ohnehin ständig vor
  • Anscheinend weiß man noch nicht genau, was es tut. Den Teil mit „nicht replaybar“ verstehe ich aber so: Wenn die Payload falsch ist oder die Signatur mit dem Angreifer-Schlüssel nicht verifiziert wird, fällt die Backdoor auf normales Verhalten zurück
    Entscheidend ist, dass die Signatur mit dem Angreifer-Schlüssel erforderlich ist. Solange dieser Schlüssel nicht geleakt wird oder der RSA-Algorithmus nicht gebrochen ist, können andere Forscher oder Dritte diese Backdoor nicht ausnutzen. Wenn RSA gebrochen wäre, hätten wir allerdings sehr viel größere Probleme
  • Wenn Public-Key-Kryptografie korrekt eingesetzt wurde und es keine ausnutzbaren Bugs gibt, lässt sich auch per Reverse Engineering kein Proof of Concept bauen
  • Der verteilte Exploit war binär und nicht als Source verfügbar und zudem raffiniert in Testdaten versteckt. Außerdem verifiziert er Payloads mit einem nicht öffentlichen privaten Schlüssel
    Aktuell kann also nur der Angreifer selbst den Exploit ausführen, weshalb auch kein Scannen möglich ist. Abgesehen von Nebeneffekten wie Performance-Einbrüchen ist die Erkennung schwierig, und genau so wurde es letztlich entdeckt

• Es ist schwer nachvollziehbar, dass ein so wichtiges Paket, das täglich auf so vielen Linux-Servern genutzt wird, wegen Geldmangels nicht mehr vom ursprünglichen Autor gepflegt werden kann. Im Open-Source-Bereich muss sich etwas ändern
  Eine mögliche Lösung wäre eine Lizenz, die Unternehmen oder Organisationen ab einer bestimmten Größe verpflichtet, für die Wartung zu zahlen

  • Gegen solche Lizenzen gibt es großen Widerstand. Dann heißt es sofort „nicht mehr frei“, und es beginnt ein starker Gegenwind, der die betreffenden Akteure schnell ins Abseits stellt
  • Ich frage mich, ob es wirklich Geldmangel ist oder eher Burnout
  • Der vorgeschlagene EU Cyber Resilience Act beansprucht, genau dafür eine Lösung zu sein. Vereinfacht gesagt haften Hersteller während der gesamten Lebensdauer eines Produkts für Schwachstellen, egal ob in einer Firewall oder einem Toaster
    Dadurch haben Hersteller einen Anreiz, Open Source sicher zu halten. Sie können Maintainer bezahlen, Code-Audits beauftragen oder feste Mitarbeiter einstellen, die Beiträge leisten
  • Wichtigkeit und Notwendigkeit sind nicht dasselbe. Dieses Paket ist weniger wichtig als vielmehr notwendig
  • Ich verstehe nicht, warum etwas so Komplexes wie xz nötig ist. Der bzip2-Code ist klein und sollte mit einem Bruchteil der Zeit einer einzelnen Person wartbar sein

• Wenn man aktuell ins xz-Repository geht, ist es wegen eines Verstoßes gegen die GitHub-Nutzungsbedingungen deaktiviert. Dass es deaktiviert wurde, ist nachvollziehbar, aber ich hätte mir gewünscht, dass GitHub den Code und die Historie stehen lässt, ein Banner anzeigt und nur die missbrauchbaren Funktionen blockiert
  So könnten Forscher und andere den Exploit weiterhin studieren. Wenn in einem harmloseren Fall eine Bibliothek Malware hostet und das Repository dann einfach verschwindet, könnte man das leicht als unbedeutend abtun

  • Vermutlich wollte man nicht, dass automatisierte Tools es herunterladen
  • Die GitHub-Ereignisse zu diesem Repository kann man hier als CSV ansehen: https://github.com/emirkmo/xz-backdoor-github
    Wenn dich der Source Code interessiert, ist er leicht zu finden. Dieser Code und das Git-Repository sind mit vielen Git-Repositories weltweit verbunden, und der Source wurde auch mehrfach in Releases gebündelt
  • xz hat einen eigenen Git-Mirror, in dem alle Commits einsehbar sind

• Als faktischer Maintainer eines wenig bekannten Open-Source-Spiels habe ich erlebt, wie Entwickler kommen und gehen. Wertvolle Beiträge merge ich im Grunde einfach alle.
  Manche Mitwirkende arbeiten sich mit sehr unterschiedlichen Coding-Stilen ziemlich tief in Funktionen hinein, in einem Mix aus C und C++. Ich verstehe nicht immer jedes Implementierungsdetail vollständig, aber irgendwo im Hinterkopf bleibt der Gedanke, dass das Projekt ruiniert wäre, wenn jemand eine wirklich böse Backdoor einschleusen würde.
  Zum Glück ist das Spiel so obskur und die Angriffsfläche so klein, dass es kaum auffällt. Trotzdem hat mich das davon abgehalten, aus gutem Willen vielleicht einmal Windows-Binärdateien zu signieren.
  Diese xz-Backdoor ist wirklich ein gewaltiger Albtraum, und ich empfinde großes Mitgefühl für die ursprünglichen Entwickler und alle, die darin verwickelt wurden.

  • Das stimmt natürlich, aber es ist kein Problem, das nur Software betrifft. Eigentlich bin ich mir nicht einmal sicher, ob man es in einem sinnvollen Sinn überhaupt ein „Problem“ nennen kann.
    Wenn man auf einem Waldweg spazieren geht, kann einen auch einfach ein vorbeifahrendes Auto erfassen. Der Fahrer wird vermutlich nie gefasst, man kann es nicht verhindern, und die Polizei steht auch nicht daneben. Dieses Szenario ist viel beängstigender als eine Software-Backdoor und dennoch nur ein minimales Risiko, das wir akzeptieren müssen, um überhaupt irgendetwas im Leben tun zu können. Und so etwas passiert tatsächlich.
    Letztlich wollen die meisten Menschen anderen aber nicht aktiv schaden. Alles, was Menschen tun, beruhte immer auf dieser Annahme, und das tut es auch heute noch.
    Die Vorstellung, dass sich so etwas verhindern ließe, wenn wir nur Code Reviews etwas strenger machen, mehr Linter, CI und Pattern Matching einsetzen, Code Signing weiter verbreiten und die Identität von Menschen verifizieren, ist eher das eigentliche Problem. Das ist ein Symptom einer Silicon-Valley-artigen Wahnvorstellung, nach der die Welt auf jeder Detailebene verwaltet und kontrolliert werden kann und sollte. Solche „Heilmittel“ können weit schlimmer sein als jede Krankheit, die sie verhindern sollen.
  • Der verstorbene Pieter Hintjens von ZeroMQ hat die Praxis des Optimistic Merging verteidigt. Dabei werden Beiträge sofort gemergt, ohne auf Code Review oder CI-Ergebnisse zu warten. Ein Ansatz mit lockeren Merge-Kriterien ist also nicht völlig aus der Luft gegriffen.
    [1]: http://hintjens.com/blog:106
    Ich verstehe den Vorteil, eine Community aufzubauen, in der Mitwirkende gern an einem Projekt teilnehmen. Für mich fühlte es sich aber immer so an, als würde das ein Projekt ohne klare Vision oder Richtung wachsen lassen und am Ende Maintainern eine übermäßige Last aufbürden, weil sie die Beiträge anderer nachträglich an einen gemeinsamen Standard anpassen müssen.
    Echtes Code Review wird damit auf einen unbekannten Zeitpunkt in der Zukunft verschoben; ob es dann gründlich sein wird, wer die Verantwortung dafür trägt oder wer Probleme behebt, bleibt unklar. Unterm Strich klingt das wie ein Rezept für Chaos, bei dem man nicht kontrollieren kann, was letztlich an Benutzer ausgeliefert wird.
    Dann gibt es noch das Problem der Verbreitung von Schadcode. Auch in den Kommentaren zu dem Blogbeitrag wird das angesprochen, und Pieter beschreibt dort exakt dasselbe Szenario wie im Fall xz.
    „Nehmen wir an, Mallory ist geduldig, täuschend und verhält sich lange genug wie ein legitimer Contributor, um die Kontrolle über das Projekt zu gewinnen, und pflanzt dann nach und nach eine Backdoor ein. Dann hilft auch sorgfältiges Code Review nicht. Mallory muss nur genügend Vertrauen gewinnen, um Maintainer zu werden; ob das gelingt, ist keine Frage des Ob, sondern des Wie.“
    Er kommt zu dem Schluss, dass „die beste Verteidigung die Größe und Vielfalt der Community“ sei.
    Ich denke jedoch, dass sorgfältiges Code Review die Wahrscheinlichkeit eines solchen Vorfalls tatsächlich verringern kann. Wenn alle Beiträge gründlich geprüft werden, egal ob von vertrauenswürdigen oder externen Contributors, steigt die Chance, merkwürdiges Verhalten oder Commits, die angeblich A tun, in Wirklichkeit aber B machen, früher zu entdecken.
    Ob Optimistic Merging tatsächlich zu größeren und vielfältigeren Communities führt, ist ebenfalls umstritten. Es gibt viele Projekte mit aktiven Communities und zugleich strengen Contribution Guidelines. Außerdem beantwortet es nicht die Frage, wann und wie bösartige Patches erkannt werden sollen.
    Das Problem bei xz war nicht eine kleine Community, sondern, dass es gar keine Community gab. Ein einzelner bösartiger Akteur hatte die Kontrolle über das Projekt übernommen, und es gab fast keinerlei Aufsicht durch andere. Contribution Guidelines waren kein Faktor für die Größe der Community, und das wäre unabhängig davon passiert, ob Optimistic Merging verwendet wurde oder nicht.
    [2]: http://hintjens.com/blog:106/comments/show#post-2409627
  • Es erstaunt mich immer wieder, dass Unternehmen einerseits enorme Anstrengungen in die Absicherung ihrer Netzwerkgrenzen stecken, während in Entwicklungsorganisationen ganz selbstverständlich Dinge wie brew install cask oder vi/emacs/vscode-Erweiterungen installiert werden.
    Rust kann man wohl als Programmiersprache beziehungsweise Community bezeichnen, die standardmäßig am sichersten ist, mit einem sicherheitsorientierten Design, das Spielereien mit Pointern fast vollständig unterbindet. Und trotzdem sieht der häufigste und empfohlene Installationsweg so aus, und ich bin selbst ein völliger Heuchler und mache es auch oft so.
    https://www.rust-lang.org/tools/install
    Das ist nur ein Beispiel. Bei viel zu vielen Menschen ist es zur reinen Gewohnheit geworden, gleichzeitig darüber zu streiten, wessen unsafe-Block problematisch ist, und sich im selben Atemzug mit „curl das und pipe es in sh“ selbst Remote Code Execution zu öffnen.
  • Ehrlich gesagt war es nur eine Frage der Zeit, bis unser guter Wille ausgenutzt wird. Dinge wie „Break it fast and fix it fast“ oder „Wer will die Ownership meines Projekts übernehmen?“ laden geradezu zu Problemen ein, aber solange Open Source unbezahlte Liebesarbeit rund ums Programmieren bleibt, ist es auch schwer vorstellbar, ohne so etwas auszukommen.
    Es ist traurig, dass so etwas passiert ist, aber nicht überraschend. Ich hoffe, dass bessere Werkzeuge zur Abwehr solcher bösartiger Akteure entstehen — und zwar ebenfalls als Open Source.

• Dieses Backdoor wirft einige Fragen auf. Welche anderen Backdoors wurden noch von demselben oder einem ähnlichen Team platziert? Wie viele solcher Teams sind aktiv? Wie viele Abhängigkeiten sind für solche Infiltrationsangriffe anfällig? Wie groß ist in unserer Branche die Angriffsfläche für solche verdeckten Operationen gegen ausgewählte Ziele?
  Für wichtige Netzwerkdienste wie apache httpd, postgres, mysql, nginx, openssh, dropbear ssh, haproxy, varnish, caddy, squid, postfix sowie all ihre Abhängigkeiten und die gesamten Committer-Graphen dieser Abhängigkeiten zu erstellen, könnte ein erster Schritt sein, um herauszufinden, wo der Ertrag am höchsten und die Überwachung am geringsten ist
  Das dürfte kaum der erste Fall sein, in dem jemand so etwas versucht hat. Es ist nur der erste Fall, der gescheitert ist und dadurch ans Licht kam. Ich kenne eine entdeckte Backdoor, die gegen den Linux-Kernel versucht wurde, aber das hier ist ein Remote-Angriff und von völlig anderer Natur

  • Warum hat man sich nicht wie alle anderen einfach für einen Zero-Day entschieden, sondern eine Backdoor gebaut?
    Warum wurde nicht etwas Harmloswirkendes verteilt, das selbst bei Entdeckung wie ein Bug hätte aussehen können, sondern eine voll funktionsfähige Backdoor implementiert und sogar die Verteilungsmethode verborgen?
    Das muss eine bewusste Entscheidung gewesen sein. Der Grund dafür könnte einen Hinweis darauf geben, was das Ziel war
  • Man sollte auch fragen, warum Debian gepatcht hat, sodass Dienste, die als root laufen und Verbindungen aus dem Internet annehmen, unnötige Bibliotheken laden

• Das scheint zu bedeuten, dass man zum Scannen auf remote ausnutzbare Instanzen den privaten Schlüssel des Angreifers bräuchte, den wir nicht haben. Die einzige andere Möglichkeit wäre, lokal ein Erkennungsskript auszuführen

  • Eine völlig schreckliche Methode, zu der manche Scanner greifen könnten, wäre, alles als „potenziell verwundbar“ zu markieren, wenn RSA-Authentifizierung angeboten wird. Die meisten SSH-Server bieten RSA-Authentifizierung an, und auch das SecSH-RFC bezeichnet deren Implementierung faktisch als verpflichtend. Das könnte Menschen dazu drängen, wieder auf Passwort-Authentifizierung umzusteigen
    Solange sich nicht herausstellt, dass dieses Problem auf realen Systemen breit verbreitet ist, wirkt so ein Vorgehen noch schlimmer als die ähnlichen „Experten“, die früher jedes Jahr Passwortwechsel verlangten und damit die tatsächliche Sicherheit senkten, während nur die Sicherheit auf dem Papier besser aussah
  • Da der Code zur Signaturprüfung offenbar nur ausgeführt wird, wenn der öffentliche Client-Schlüssel zu einem bestimmten Fingerabdruck passt, könnte man ihn vielleicht über Timing-Informationen erkennen
    Die Signaturprüfung der Backdoor dürfte etwa 100µs dauern, daher sollte die Verarbeitung eines Schlüssels mit passendem Fingerabdruck entsprechend länger dauern als bei einem, der nicht passt. Dieser Zeitunterschied wäre zumindest im LAN realistisch erkennbar und könnte, wenn der Scanner nahe am Ziel ausgeführt wird, vielleicht sogar über das Internet hinweg messbar sein
    Systeme, die nach wiederholten fehlgeschlagenen Authentifizierungen die Client-IP blockieren, würden das Scannen erschweren
    (https://bench.cr.yp.to/results-sign.html gibt für Ed448-Verifikation etwa 400.000 Zyklen an, was bei 4GHz rund 100µs entspricht)
  • Im Tweet steht, sie sei „nicht wiederholbar“. Ich frage mich, warum sie nicht wiederholt werden kann. Ist die Backdoor so aufgebaut, dass das eingeschleuste sshd irgendeine Challenge ausgibt, die der Angreifer dann signieren muss?

• Vielleicht ist das keine populäre Meinung, aber ich kann nicht anders, als die gesamte Operation zu bewundern. Natürlich verurteile ich sie, aber trotzdem bewundere ich sie. Von der Konzeption bis zur Ausführung wirkte das wirklich wie ein Kunstwerk, und dass es so früh entdeckt wurde, war ein enormes Glück

  • Wäre die Payload nicht dadurch aufgefallen, dass SSH-Logins zufällig für 0,5 Sekunden hängen blieben, wäre sie vermutlich lange unentdeckt geblieben
    Beim nächsten Mal werden die Angreifer wahrscheinlich eine Payload bauen, die bei Tätigkeiten, auf die Menschen warten, keine seltsamen Latenzspitzen erzeugt
    Das erinnert mich irgendwie daran, wie Kim Dotcom herausfand, dass er Ziel illegaler Überwachung war: In MW3 war sein Ping plötzlich stark erhöht. Bei der Untersuchung stellte sich heraus, dass nur seine Pakete physisch über ein sehr weit entferntes GCSB-Büro umgeleitet wurden. Das GCSB ist nicht befugt, neuseeländische Daueraufenthaltsberechtigte zu überwachen. Am Ende erhielt er eine persönliche Entschuldigung vom neuseeländischen Premierminister
  • „Wie auch immer, der Typ, dessen Änderung niemals hätte gemergt werden dürfen, hat etwas Großes vollbracht. Schrecklich, aber groß.“
    Der genialste Teil war meiner Ansicht nach die Wahl des Projekts zur Infiltration. Wenn man im Nachhinein die Diskussion um den IFUNC-Pull-Request von „Hans“ liest, ist das schmerzhaft, zeigt aber sehr gut, warum genau dieses Projekt ausgewählt wurde
    Ich würde gern wissen, wie viele Personen hinter „Jia“ und „Hans“ standen und wie Kommunikation sowie Codebeiträge analysiert und strategisch geplant wurden. Manche Aspekte, etwa eine Art dritte Persona, die in der Mailingliste als Druckmittel auftrat, wirken etwas schlampig gemacht
    Deshalb ist es immer noch möglich, dass es ein ausgeklügeltes kleines Team oder sogar eine einzelne Person war. Wenn es ein staatlicher Akteur war, würde ich erwarten, dass es Leute gibt, die den ganzen Tag nichts anderes tun, als für solche Operationen falsche Identitäten zu erschaffen und zu pflegen
    Es wäre problematisch gewesen, wenn jemand gedacht hätte: „Es ist merkwürdig, dass diese drei Nutzer so unhöflich Druck machen. Wer sind die? Die Accounts wurden alle ungefähr zur gleichen Zeit erstellt. Verdächtig. Warum sollte jemand das mit Fake-Accounts so aggressiv pushen? Das sollte man untersuchen.“ Verglichen mit dem Gesamtaufwand der Operation war dieser Teil entweder nachlässig, schlecht geplant oder unterfinanziert
  • Ich stimme zu, aber der Teil mit dem Social Engineering fühlt sich besonders brutal an
  • Ich glaube nicht, dass das eine so unpopuläre Meinung ist. In vielerlei Hinsicht ist das ein sehr beeindruckender Angriff. Er war subtil, über mehrere Jahre aufgebaut, und wenn der Angreifer nicht den Fehler gemacht hätte, jene merkwürdige Performance-Verschlechterung auszulösen, die die Untersuchung anstieß, hätten wir es wahrscheinlich nie bemerkt
    Wenn man eine dramatische Hypothese ergänzen will, könnte man sagen, der Angreifer habe vor der Informations-Atombombe, die er selbst zünden würde, Angst bekommen und es absichtlich vermasselt
    Man kann das Endergebnis verabscheuen und trotzdem die Komplexität des Angriffs anerkennen
  • Ich weiß nicht, ob „Bewunderung“ das richtige Wort ist, aber es war definitiv eine ziemlich beeindruckende Operation