Suche
Close this search box.

Wer ist «Jia Tan»? Eine Spurensuche zur xz-Backdoor

Über ein Monat ist vergangen und wir wissen immer noch nicht viel über die Hintergründe und Hintermänner der xz-Backdoor. Dies, obwohl die Lücke im besten Fall mehrere Milliarden wert gewesen hätte sein können. Doch aus den öffentlichen Aktivitäten von «Jia Tan» sind einige Rückschlüsse möglich. Begeben wir uns also auf eine spannende Suche nach den Indizien und lernen wir, welche Ziele der oder die Angreifer möglicherweise hätten haben können. Und wieso es wichtig ist, dass wir alle unsere Rechner besser schützen, privat, in Firmen, in allen Organisationen.

Da unklar ist, ob hinter der Aktion eine oder mehrere Personen oder sogar eine feste Organisation stecken, werde ich in diesem Artikel der Einfachheit von der „Operation“ sprechen, wenn diese unbekannte(n) Person(en) gemeint sind.

Dies ist eine Art Fortsetzung des Artikels «xz oder: Wie die Open-Source-Community an Ostern die Welt gerettet hat» vom Osterdienstag (2024-04-02). Wer diesen bisher nicht gelesen hat oder die Materie nochmals auffrischen möchte, ist herzlich eingeladen, ihn (nochmals) zu lesen.

Welche Informationen haben wir?

Wir haben Informationen zu Namen, Arbeitszeiten, genutzten IP-Adressen und einem Teil des Zeitplans der Operation. Es gibt Mutmassungen darüber, ob es ein Einzeltäter oder eine Gruppe war. Zusätzlich haben wir aus früheren Cyberangriffen und Verteidigungsszenarien Informationen über mögliche Ziele und deren Werte (Kosten/Nutzen).

Schauen wir uns diese zuerst einzeln an und versuchen sie nachher zusammenzufügen. Das Ziel ist es vor allem, einen Überblick über das zu geben, was an Informationen da ist und was man daraus schliessen kann (und wo man nur Hinweise hat).

Ein weiteres—extrem informatives—Puzzlestück fehlt, nämlich, was das konkrete Ziel gewesen wäre. Ich bin aber froh, dass wir das nicht herausfinden mussten.

Trotzdem geben diese Informationen Einblick in mögliche Ziele und was wir (Einzelne, Firmen, Politik) ändern müssen.

Name

Das Aushängeschild dieser Operation fungierte in dieser Rolle unter dem Namen «Jia Tan» (ein Mal auch «Jia Cheong Tan») mit GitHub-UserID «JiaT75» und Emailadresse «jiat0218@gmail.com» (mit einer Ausnahme). Interessant ist, dass der Name zwar chinesisch klingt, die Schreibweise «Cheong» und die Trennung der beiden Vornamen nicht auf die VR China hindeuteten:

If his full name „Jia Cheong Tan“ is real, it can never be a valid romanization of han character used in China but somewhere in southeast asia like Malaysia. The spelling „Cheong“ is not being used in China now and today Chinese tends to concatenate all the characters of their first name if written in letters.

Kommentar von Junrong Lin auf den Post zur Arbeitszeitanalyse

That’s fair, but he could be Malaysian or Singaporean of Chinese ethnicity […]

Kommentar von Yee Cheng Chin auf den Post zur Arbeitszeitanalyse

Yeah that’s fair enough. I guess I know „Jia Tan“ is a completely meaningless made-up name too but couldn’t resist lol.

Weiterer Kommentar von Junrong Lin auf den Post zur Arbeitszeitanalyse

Neben «Jia Tan» wurden mutmasslich von der Operation auch folgende Personas verwendet, wahrscheinlich alles Sockenpuppen:

Analyse: Der Name des Hauptakteurs soll Hinweise auf China/Südostasien liefern; die anderen Konten vermutlich auf Indien, Nordeuropa, deutschsprachiges Europa (USA?), Japan und Russland hindeuten. Interessant ist, dass nicht-germanischsstämmige Teile von Europa, der Nahe und Mittlere Osten, Afrika und Süd-/Mittelamerika (vielleicht auch Nordamerika, je nachdem, wohin man «Dennis Ens» verortet) fehlen.
Mich würde nicht wundern, wenn insbesondere die von Anfang an genutzten Namen, vielleicht sogar alle, von der echten Herkunft ablenken sollten. (Aber vielleicht hat die Operation genau damit gerechnet und uns ein zweites Schnippchen geschlagen.)
Bauchgefühl: Vermutlich jemand, der/die sich nicht sehr gut mit China auskennt, aber als chinesisch durchgehen will.

Arbeitszeiten

Die Operation hat verschiedene Aktivitäten durchgeführt, bei der die Zeit aufgezeichnet wird. Dazu gehört beispielsweise der Mailversand an die Mailinglisten und das Übermitteln der Quellcodeänderungen ans Versionsmanagementsystem git. Beide lassen sich bis zu einem gewissen Grad manipulieren, insbesondere wenn es um Einzelfälle geht. Bei den Quellcodeänderungen („commits“) finden sich im xz-Repository 453 Änderungen. Diese alle konsistent um mehrere Stunden zu verfälschen, wäre ein riesiger Aufwand; erschwert dadurch, dass sie sich auch auf Aktivitäten Dritter beziehen und von diesen wiederum beobachtet werden.

Es ist deshalb davon auszugehen, dass der Zeitpunkt ziemlich zuverlässig ist, auch wenn wir nicht wissen, aus welcher Zeitzone die Kommunikation stattfand.

Die Codeänderungen sind zwar alle mit der Zeitzone „UTC+0800“ markiert, die von Sibirien über China bis Australien geht. Rhea Karty und Simon Henniger kommen in ihrer Analyse zum Schluss, dass die Arbeitszeiten gut zu Bürozeiten (9-18 Uhr) in Osteuropa oder dem Nahen Osten passen. Auch die Arbeitstage bzw. arbeitsfreien Tage passten besser zu (insbesondere christlichen) osteuropäischen als zu chinesichen Feiertagen.

Ganz im Gegensatz dazu glaubt ein User mit dem Pseudonym «trigglux», dass «Jia Tan» seine Operation nicht als Tagesjob erledigt hätte, sondern nach getanem Tagewerk in der Zeitzone „+0800“ sich noch ein paar Stunden xz gewidmet hätte. Allerdings hat auch «trigglux» ausser diesem Post kaum eine Online-Präsenz; viel mehr als diesen Post vom letzten Sommer scheint es zusätzlich nicht zu geben.

Analyse: Beide Thesen sind plausibel. Auch wenn «Jia Tan» (wie) in Osteuropa/Naher Osten gelebt hat, heisst das noch lange nicht, dass sein allfälliger Auftraggeber ebenfalls aus der Gegend kommen muss.
Die Zweitjob-Hypothese von «trigglux» würde allerdings eher auf einen Einzeltäter hindeuten. Wir bewegen uns hier in einem Desinformationsbereich; es könnte also auch sein, dass der Post von «trigglux» entstanden ist, um von Osteuropa oder einer Organisation abzulenken.
Bauchgefühl: Beides ist möglich.

IP-Adressen

Es gibt nur eine IP-Adresse, die öffentlich mit «Jia Tan» assoziiert ist: Die Adresse, von der er aus an Chats zu xz-Themen teilnahm. Diese Adresse gehört zu einem VPN-Betreiber in Singapur. Ob auch sein Verkehr mit seinem Mailprovider (Gmail) oder mit GitHub immer über diese VPN-Verbindung lief, ist leider nicht bekannt. Ich nehme aber an, dass Google und Microsoft (Besitzerin von GitHub) oder der VPN-Provider ihre entsprechenden Logs ausgewertet haben, sofern sie vorhanden waren.

Weitere interessante Parameter hätte die Laufzeit von IP-Paketen sein können. Damit hätte man einen Kreis auf der Weltkugel um diesen VPN-Endpunkt ziehen können, in dem sich der Computer von «Jia Tan» hätte befinden müssen. Aber solche Informationen werden kaum irgendwo standardmässig geloggt.

Analyse: Aus öffentlichen Daten ist keine weitere Einschränkung möglich. Die Provider könnten aber mehr Informationen haben. Die VPN-Adresse passt zum chinesischen/südostasiatischen Image, das mit dem Namen assoziiert werden soll.
Bauchgefühl: China bzw. Südostasien sind ziemlich sicher falsche Fährten, die—wie schon beim Namen—vermutlich vom realen Standort von «Jia Tan» ablenken sollen.

Zeitplan

Ab dem 23. Februar 2024 wurde es konkret. Alles davor war hauptsächlich Vorgeplänkel und Vorbereitungen, welche die Wachsamkeit und Wirksamkeit der Sicherheitsüberprüfungen rund ums Projekt reduzierten. Am 23. Februar wurde der erste echte Schadcode ins Repository eingepflegt: Nicht als Quelltext, sondern versteckt in einer angeblichen Testdatei. (Automatisierte Tests sind ein wichtiger Mechanismus, mit dem das korrekte Funktionieren von Programmen und -teilen gewährleistet wird.)

Der Code, der ab diesem Stichtag eingepflegt wurde, war sehr sorgfältig versteckt und mittels eines ausgeklügelten Plugin-Systems auf langfristige Nutzung in weiteren Projekten ausgelegt. Das deutet—wie auch die Auswahl von xz als Vektor für die ssh-Infektion—auf akribische Planung hin.

Doch der Schadcode war ineffizient—was ihm durch die daraus resultierende Verlangsamung von ssh—schlussendlich zum Verhängnis wurde. Dies markiert einen Qualitätsbruch.

Ursachen für diese plötzliche Eile könnten gewesen sein:

  1. Fehlende diesbezügliche Expertise innerhalb der Operation oder
  2. plötzlicher Zeitdruck, beispielsweise durch folgende Entwicklungen:
    1. Der Release von Ubuntu 24.04, einer Version mit Long-Term-Support (LTS), sollte in zwei Monaten stattfinden. Im kommerziellen Umfeld wird häufig nicht jeder einzelne Release eingespielt (bei Ubuntu alle 6 Monate), sondern der Einfachheit halber oft nur von LTS-Version zu LTS-Version gesprungen. Um also das Firmenumfeld gezielt zu erreichen, wäre eine Inklusion in LTS nötig gewesen. (Eine Inklusion in die Ubuntu LTS-Version wurde übrigens schon vor der Entdeckung der Backdoor abgelehnt, da zu kurzfristig.)
    2. Auch bei ssh stand eine Entkopplung der systemd-Integration in Aussicht. Diese Integration ermöglicht eine bessere Integration in viele Linux-Umgebungen. Dies hätte die geplante Nutzung in OpenSSH verunmöglicht. (Eine ähnlich gute Integration als Ersatz für OpenSSH zu finden, wäre trotz Plugin-System wahrscheinlich nicht einfach gewesen.)
    3. Die xz-Bibliothek wird von ssh gar nie benötigt. Sie ist nur dabei, weil die systemd-Bibliothek integriert wird und andere, nicht angesprochene Funktionen, xz nutzen würden. Trotzdem wird aber die Initialisierungsroutine der Bibliothek ausgeführt, welche die Schadroutinen aktiviert. Die vier Jahre alte Pendenz, die Kompressionsbibliotheken erst bei der ersten Verwendung nachzuladen, wurde ab 29. Februar umgesetzt. Damit wäre der Schadcode nicht mehr aktiviert worden. Möglicherweise hatten die xz-Hintermänner bereits davor Wind von dieser geplanten Änderung bekommen oder ihnen lief die Zeit für die Qualitätssicherung davon.

Analyse: Langfristige und weitsichtige Planung, clevere Ausführung, dann an einem Detail gestolpert. Eine Integration in die LTS-Version schien nicht schon lange geplant gewesen zu sein, was auf Mängel in der strategischen Planung zurückzuführen sein könnte. Ebenso wurde von der Operation nicht erwartet, dass über 3 Jahren später sich die Landschaft mehrfach gegen die geplante Verwirklichung stellen würde.
Bauchgefühl: Möglicherweise steckt dahinter doch kein so grosses, erfahrenes Team. Oder sie waren sich zu sicher.

Einzelperson oder Gruppe?

Egal, ob eine Person oder Gruppe dahinter steckt: Die Sockenpuppe «Jia Tan» wurde wahrscheinlich nur von einem einzelnen Menschen gesteuert, um das Risiko eines Bruchs der Kontinuität an Wissen oder Umgangsformen zu minimieren. (Im Falle einer Gruppe hat sich «Jia Tan» dazu sicher mit dem Team über das Vorgehen abgestimmt.)

Grundsätzlich gibt es Personen, die fähig sind, ein solches Unterfangen alleine durchzuziehen. Beispielsweise sind aus der Frühzeit der iOS-Jailbreaks einzelne Personen bekannt, die sich intensiv mit dem System und der Umgehung von Sicherheitsmassnahmen auskannten. Solche Einzelpersonen sind aber extrem selten.

Analyse: Auch in der Jailbreak-Zeit waren die Personen nicht alleine, sondern tauschten Informationen unter Gleichgesinnten aus.
Bauchgefühl: Ich gehe nicht von einem völligen Einzeltäter aus. Mindestens einen Teil der (Vor-)Überlegungen dürfte mit anderen diskutiert worden sein.

Wer hat welche Interessen

Nehmen wir uns ein paar typische Akteure und schauen, welche Vorteile sie sich durch einen derartigen Cyberangriff erhoffen könnten:

OrganisationstypInteressenHerausforderungen
EinzelpersonGeld, Ruhm, «zum Spass», RacheKnow-How
Kriminelle OrganisationGeld, «Gangsterkrieg» (Macht)
GrosskonzernWirtschaftliche VorteileBisher nur in der Science Fiction
Staatlicher AkteurMacht, wirtschaftliche Vorteile, Kriegsvorteil, evt. Geld (bei einem Staat wie Nordkorea)
Extremistische OrganisationIhrem Gott dienen, Zerstörung, Umsturz

Der Wert einer Sicherheitslücke

Sicherheitslücken und Zugänge zu fremden Rechnern sind eine Handelsware wie Kaffee, Öl oder Elektronikabfall. Auch wenn der Handel meist im Verborgenen stattfindet, haben auch diese «Güter» oft einen bekannten Preis. So werden für Sicherheitslücken in einschlägigen Kreisen für sechs- bis siebenstellige Beträge gehandelt. Ein Zugang zu einem Rechner geht zwischen wenigen Dollar und ein paar Tausend Dollar über den Darknet-Ladentisch, je nachdem, ob es ein langweiliger Privatrechner oder ein Firmencomputer ist, mit dem man in ein Firmennetz eindringen kann.

Zugänge für (Wirtschafts-)Spionage (Punkt 4)

Wert: Dieser Wert ist schwer zu bestimmen, auch wenn er durchaus im Bereich von einer Milliarde liegen könnte.

Ein einzelner Zugang für Ransomware (Punkt 5a)

Ransomware ist nicht das Hobby von ein paar Kleinkriminellen, sondern ein professionell organisiertes internationales kriminelles Netzwerk. Dieses kümmert sich arbeitsteilig um Dinge wie

  • das Einkaufen/Entdecken von Sicherheitslücken,
  • die Erstellung der eigentlichen Ransomware,
  • die Eigennutzung der Ransomware oder das Angebot als Dienstleistung an andere Kriminelle („Ransomware-as-a-Service“),
  • die Akquise von neuen Opfern,
  • den „Kundensupport“ (falls das Opfer Probleme mit der Überweisung in Kryptowährung hat; Gerüchten zufolge der hilfsbereiteste und kompetenteste Support im IT-Umfeld) oder
  • das Waschen des Geldes bzw. das Rekrutieren der dafür notwendigen „Money Mules„.

Wert: Wenige Tausend Euro/Dollar/Franken. Dafür alleine startet man aber keine Operation dieser Grössenordnung.

Viele Zugänge für Ransomware (Punkte 5b/c)

Unsere Operation hatte aber vor, in naher Zukunft mehrere Millionen Zugänge zu haben. Den Erlös pro Zugang einfach mit der Anzahl Zugänge zu multiplizieren wäre hier jedoch naiv. Denn das funktioniert nur, wenn

  • alle Zugänge praktisch gleichzeitig ausgenützt werden können oder
  • die Sicherheitslücke auch nach mehreren Opfern nicht erkannt und behoben (gepatcht) wird.

Falls mehrere Opfer nämlich unter denselben mysteriösen Umständen angegriffen werden, ohne dass dabei eine bereits offensichtlich eine bekannten Sicherheitslücke verwendet wird, werden sich eine Unzahl an Sicherheitsforschern auf dieses Problem stürzen. Und dann ist die Wahrscheinlichkeit hoch, dass mindestens ein Opfer extensive Firewall-Logs auf einem unabhängigen System gespeichert hat, insbesondere, wenn es sich um einen dieser lukrativen Firmenkunden handelt.

Das heisst, ab dem Zeitpunkt, an dem etliche Opfer Spezialisten auf ihr Problem ansetzen, dürfte es maximal noch ein paar Wochen dauern, bis die Ursache identifiziert, die Lücke geschlossen und das Update auf vielen betroffenen Servern installiert wurde. Das dürften bei weitem nicht alle Systeme sein, aber bei kritischen Sicherheitslücken, die prominent aktiv ausgenutzt werden, sind sehr schnell 80-90% der Rechner gepatcht. Aber auch hier gibt es Ausnahmen.

Für den Angreifer heisst das, dass sie nach dem Startschuss der grossflächigen Ausnutzung nur noch wenige Wochen zur Monetarisierung haben. Danach schwimmen ihre Felle davon. Aber in diesen Wochen müssen die wenigen Experten, die sie haben, die Firmennetze auskundschaften und nach wertvollen Systemen und Daten Ausschau halten. Denn nur mit der richtigen Vorbereitung ist die Wahrscheinlichkeit hoch, dass das Opfer auch Geld abwirft, direkt oder indirekt.

Eine Alternative scheint zu sein, zuerst in aller Ruhe alle Systeme auszukundschaften und erst später zuzuschlagen. Das kann funktionieren, wenn das Auskundschaften sehr vorsichtig abläuft. Es ist aber unwahrscheinlich, dass nicht sehr rasch einige wenige Opfer diese Kundschaftertätigkeit erkennen und analysieren. Sobald dies passiert, werden die Lücken auch geschlossen; wenn der Angreifer „Pech“ hat, noch bevor sie die Opfer ausnehmen können. Es kann sein, dass damit zusätzliche Gelder fliessen; es kann aber auch sein, dass die Lücke geschlossen wird, bevor überhaupt signifikant Geld geflossen ist. Diese Alternative dürfte also die durchschnittlich zu erwartenden Einnahmen nicht signifikant erhöhen.

Zusätzliche zweite Backdoor?

Wäre es nicht eine Option, auf allen Abermillionen Rechnern kurz einmal einzuloggen und dann eine zweite Backdoor zu installieren; also für den Fall, dass die ssh-Backdoor auffliegt?

Die xzssh-Hintertür hat den unschätzbaren Vorteil, dass sie

  1. aus einem normalen Softwarepaket besteht, also keine zusätzliche Software benötigt, die auffallen könnte und
  2. keine Verbindung nach aussen zu einem Steuerrechner (Command-and-Control-Server) aufbauen muss, die ebenfalls in einigen Firmennetzen auffallen würde.

Von daher ist diese Lücke fast unschlagbar und die doppelte Backdoor macht kaum Sinn. Ausser in einem Szenario: Die Angreifer installieren die zweite Backdoor auf einigen Systemen, die sie sich für eine zweite Angriffswelle reservieren wollen. Das könnte den zu extrahierenden Wert aus den Opfern verdoppeln. (Aber sie könnten auch darauf hoffen, dass einige Firmen sehr langsam patchen…)

Wert: Zehn bis einige Hundert Millionen Dollar; je nach Anzahl Personen, welche die Firmen gleichzeitig angreifen können.

Zugänge zur punktuellen Zerstörung (Punkt 6)

Gezielt ein einzelnes strategisches Objekt zu vernichten, kann auch ein Ziel sein. So war das mutmassliche Ziel der Stuxnet-Malware die Zerstörung von Urananreicherungszentrifugen des iranischen Atomprogramm. Da die Zentrifugen nicht am Internet hängen, erfolgte die Infektion mehrstufig, wofür Abermillionen Computer als Zwischenwirte dienten; in der Hoffnung, dass der zur Programmierung und Überwachung eingesetzte Laptop irgendwann mit der Zentrifugensteuerung verbunden wird und die Malware dann ihre Wirkung ausüben könne.

Die gesamte Stuxnet-Operation habe 50 Millionen US-Dollar gekostet, heisst es. Es wäre gut möglich, dass ein Staat ein paar 10 Millionen für diese Lücke auf den Tisch legen würde.

Wert: Einige 10 Millionen (auf Basis des einzigen bekannten Werts).

Zugänge zum Lahmlegen eines Landes (Punkt 7)

Eine weitere Möglichkeit wäre, gezielt ein gegnerisches Land lahmzulegen, insbesondere eines, in dem man gerade aktiv im Krieg steht (oder mit dem man einen Krieg anfangen möchte). Das könnte einen Krieg massiv beschleunigen oder einen Sieg auch erst wieder in greifbare Nähe rücken. Der Krieg in der Ukraine beispielsweise kostet Russland mutmasslich über 100 Millionen (CHF/EUR/USD/…) täglich. Aus rein wirtschaftlicher Sicht könnte eine derartige Lücke deshalb etliche Milliarden sparen. Davon könnte man dem Anbieter der Lücke durchaus etwas abgeben.

Unter den rund 28 Millionen Rechnern, die via ssh erreichbar sind, finden sich sicher etliche, die für die nationale Infrastruktur eines Landes wichtig sind. Abgesehen von DDoS kann auch der Ausfall von Hunderttausenden von privaten und Firmen-Rechnern in einem Land zu einem Chaos führen bzw. ein bestehendes Chaos verstärken.

Wert: Etliche Milliarden. (Und rettet möglicherweise gleich auch dem Staatsoberhaupt des Aggressors den Kopf.)

Welches Ländle hätten’s denn gerne?

Wired sprach mit dem ehemaligen Chef der Analyseabteilung von Kasperski, Costin Raiu:

The backdoor’s careful design could be the work of US hackers, Raiu notes, but he suggests that’s unlikely, since the US wouldn’t typically sabotage open source projects—and if it did, the National Security Agency would probably use a quantum-resistant cryptographic function, which ED448 is not. That leaves non-US groups with a history of supply chain attacks, Raiu suggests, like China’s APT41, North Korea’s Lazarus Group, and Russia’s APT29.

Frei übersetzt: Das sorgfältige Design der Backdoor könnte das Werk von US-Hackern sein, bemerkt Raiu. Seiner Ansicht nach sei das aber unwahrscheinlich, da die USA typischerweise keine Open-Source-Projekte sabotierten. Und selbst wenn, dann würde die NSA wohl eine quantensichere Verschlüsselung nutzen statt der verwendeten Ed448. Damit verblieben laut Raius Vermutungen Gruppen ausserhalb der USA, die bereits mit Supply-Chain-Attacken Erfahrung gesammelt hätten, wie APT41 (China), Lazarus (Nordkorea) oder APT29 (Russland).

Andy Greenberg und Matt Burgess: The Mystery of ‘Jia Tan,’ the XZ Backdoor Mastermind, Wired, 2024-04-03.

Viele Punkte an der Aussage klingen plausibel. Auf den ersten Blick auch das Argument mit der Verschlüsselung: Besonders in den USA wird aggressiv umgestellt (siehe Bild weiter unten) auf Verschlüsselungs- und vor allem Signaturalgorithmen, welche auch von einem Quantencomputer nicht geknackt werden können.

Trotzdem ist das für mich in diesem Fall kein Argument:

  1. Die ersten Quantenrechner welche kryptographische Schlüssel knacken können sind—nach aktuellen Prognosen—nicht vor 2030 zu erwarten. Bis dahin wäre die Backdoor nicht mehr relevant. Also ist das kein Grund für die Nutzung eines derartigen Algorithmus
  2. Die geheimen Befehle an die Backdoor mussten mit einem nur dem Angreifer bekannten Schlüssel signiert sein; diese Informationen mussten kompakt übermittelt werden, da sie in eine vorhanden Datenstruktur hinein passen mussten. Die verwendete Ed448-Signatur ist rund 56 Bytes lang; Algorithmen, die gegen Quantencomputer sicher sind, erzeugen Signaturen, die mehrere Kilobytes lang sind. Dies hätte vermutlich zu Problemen geführt.
  3. Eine Verwendung von solchen Algorithmen hätte möglicherweise den Verdacht auf die USA gelenkt.
Die Timeline der NSA zur Einführung von Sicherheitsalgorithmen mit Resistenz gegen Quantencomputer bei nationalen Sicherheitssystemen (national security system, NSS); Signaturen für Softwareverteilung müssen bereits ab 2022 zumindest teilweise umgestellt sein, der Rest ab 2024. (Eigenes Bild nach NSA-Grafik vom September 2022; via hier. Original ist Public Domain, diese Variante entsprechend ebenfalls.)

Analyse: Eine Verwendung von quantensicheren Signaturen, wie von Raiu vorgeschlagen, ergäbe keinen Vorteil, aber gleich zwei Nachteile für die USA. Aufgrund von Raius Aussage alleine sollte die USA also nicht ausgeschlossen werden. In Raius Aufzählung fehlen noch weitere Länder, welche die Fähigkeit hätten, eine derartige Operation durchzuziehen; allen voran Israels Unit 8200, die auch zur Zeitzone passen würden.

Wir basteln uns eine Sicherheitslücke

Über die Urheber der xzssh-Backdoor wissen wir noch kaum etwas, auch über einen Monat nachdem sie aufgeflogen ist.

Wohl kein einzelner Ersttäter

Ein einzelner Ersttäter erscheint mir—wie oben bereits angesprochen—unwahrscheinlich; wahrscheinlicher ist jemand mit einem Netzwerk, mit dem er/sie Ideen austauschen kann. Lose persönliche Netzwerke sind aber meist instabil, sobald es um hohe Risiken oder Geldbeträge geht (oder jemand dann doch Gewissensbisse hat). Entsprechend ist häufig zusätzlich starke Motivation (finanzieller Anreiz, Ideologie/Überzeugung, Druck, …) im Spiel, um dies zu „stabilisieren“. Genau diese bindenden Motivatoren sind jedoch das, was eine Einzelperson/lose Gruppe von einer kriminellen Organisation, einem staatlichen Akteur oder einer ideologischen Gruppierung unterscheiden. All‘ dies zusammen spricht meiner Ansicht nach für eine stabile Organisation.

Was waren wohl die Ziele?

Bei den Zielen haben wir deshalb vor allem die Möglichkeiten

  1. kriminelle Netze
    • mit Ransomware unzählige Millionen zu erpressen,
  2. staatliche Akteure
    • mit Wirtschaftsspionage langfristig Vorteile in der Grössenordnung 1+ Milliarden zu verschaffen,
    • ein spezifisches militärisches Ziel angreifen und zerstören,
    • ein ganzes Land lahmlegen (als Vorbereitung für einen Krieg oder als Beschleunigung eines laufenden Kriegs) und damit Milliarden zu sparen,
  3. ideologische Gruppierungen

Obwohl Zeitzone und finanzielle Vorteile (Reduktion der Kriegsausgaben um mehrere Milliarden und Reduktion der Opfer an Soldaten) zu einem russischen Cyberangriff auf die Ukraine zur rascheren Beendigung des Kriegs (und Stärkung Putins) passen würden, war dies mutmasslich nicht der ursprüngliche Plan, als die Operation 2021 startete. Auch die relativ langsame Vorgehensweise passt nicht zu einem derartigen Plan.

Die langsame Vorgehensweise passt für mich ebenfalls nicht zu einer Ransomware-Gruppe. Auch ideologische Gruppierungen sehe ich eher nicht.

Damit bleiben Wirtschaftsspionage und eine spezifische Zerstörung meine Topkandidaten; aber dort hätte ich mehr Planung und weniger Hektik am Schluss erwartet.

Daher ist zur Zeit meine Lieblingsthese, dass der Operation—mutmasslich einem staatlichen Akteur in Zentral- und Osteuropa, Afrika oder dem Nahen Osten—erst Anfang Jahr bewusst wurde, welche Macht sie mit dieser Lücke in den Händen halten.

Aber vieles davon werden wohl Mutmassungen bleiben. Das wird sich erst ändern, wenn wir den stärksten Hinweis, das echte Ziel, kennen. Vielleicht wird uns «Jia Tan» irgendwann verraten. Zum Glück haben wir das aber nicht „live“ herausfinden müssen.

Was lernen wir daraus?

  1. „Für mich/uns interessiert sich ja eh keiner“: Ich glaube, die wichtigste Erkenntnis ist, dass wir alle, als Individuum oder als Teil einer Firma/Organisation, eine wichtige Rolle in einem Cyberangriff spielen könnten. Und wir uns und unsere Organisation entsprechend schützen müssen.
  2. Bedrohungslage erkennen. Wer glaubt, dass Computer unter deren Verantwortung oder Informationen darauf missbraucht werden könnten, um Chaos zu stiften (oder dieses Chaos zu verstärken), sollte diese Rechner und Daten besonders gut schützen. (Der nächste militärische oder wirtschaftliche Konflikt wird eine grosse Cyberkomponente beinhalten.)
  3. Wir alle sollten uns besser schützen. Diese Checklisten mit Hintergrundinformationen bieten einen guten Start für Einzelne und kleine Firmen. (Auch für grössere Firmen sind sie nicht falsch, dort braucht es aber jemanden mit spezifischer Kenntnis über die IT-Prozesse vor Ort.)
  4. Früherkennung von Anomalien. Falls irgendwas sich unerklärlicherweise anders verhält als erwartet: Unbedingt mit einem Experten sprechen. Jemand Unbefugtes könnte gerade dabei sein, es sich in Ihrer IT-Infrastruktur gemütlich zu machen.

Quellen und Literatur

Über Hackergruppen und deren Aktivitäten

Schutzmassnahmen gegen Cyberangriffe

Hintergründe zu xz und «Jia Tan»

Post-Quanten-Kryptographie

Mehr Informationen und Hintergrundmaterial

Viel mehr Lesematerial und Hintergrund findet sich im originalen DNIP-xz-Artikel. Aber auch unsere früheren Artikel zu Sicherheitslücken helfen beim Verständnis der Bedrohung sowie der Priorisierung und Planung von Schutzmassnahmen. Wir haben auch eine Liste von Tools, mit denen man mehr über Webseiten und die Akteure dahinter erfahren kann.

Anhang: Indizien

Welche Aktivitäten sind von dieser Kunstfigur—besonders im Englischen auch «Persona» genannt—«Jia Tan» bekannt?

Commits

Am Offensichtlichsten sind die 453 eingebrachten Änderungen im xz-Quellcode. In diesen sogenannten «Commits» werden Modifikationen an einer oder mehrere Dateien zusammengefasst. Die Commits dienen der Nachvollziehbarkeit, Dokumentation und Gruppierung dieser Änderungen; meist das Beheben eines Fehlers oder das Anbringen einer Verbesserung.

NameEmailAnzahl Commits
Jia Tanjiat0218@gmail.com449
jiat75jiat0218@gmail.com2
Jia Cheong Tanjiat0218@gmail.com1
Jia Tanjiat75@gmail.com1
Autoreninformation aus den 453 Commits (zwischen 2022-01-28 und 2024-03-26).

GitHub

Insgesamt listet GitHub 1218 Aktivitäten in verschiedenen Projekten auf. Diese Aktivitäten reichen vom Erzeugen von Projekten über Diskussionen innerhalb des Projekts («issues» und «comments») bis zum Vorschlag von Änderungen («pull request») und dem eigenständigen Einbringen der Änderungen («commit»). Seine Hauptaktivitäten waren bei xz, aber auch in anderen Projekten (die dann alle diese Änderungen überprüft haben).

Kommunikation

Ausserhalb der Aktivitäten rund um xz tauchen die Mailadressen nicht auf. Weitere Aktivitäten von «Jia Tan» spielten sich in IRC-Online-Chat-Foren ab; dazu (und wahrscheinlich auch für die anderen Aktivitäten) wurde eine IP-Adresse eines VPN-Providers in Singapore verwendet. Der Kommunikationsstil wird als sehr knapp, sehr trocken, aber nicht unfreundlich angegeben und mit ChatGPT-Output verglichen.

Der Name «Jia Tan» taucht zwar auch an anderer Stelle (LinkedIn, Webseiten) auf; diese scheinen aber keinen Zusammenhang mit „unserem“ «Jia Tan» zu haben.

dnip.ch mit Deiner Spende unterstützen

Wir wollen, dass unsere Inhalte frei verfügbar sind, weil wir es wichtig finden, dass möglichst viele Menschen in unserem Land die politischen Dimensionen der Digitalisierung erkennen und verstehen können.

Damit das möglich ist, sind wir auf deine Unterstützung angewiesen. Jeder Beitrag und sei er noch so klein, hilft uns, unsere Aufgabe wahrzunehmen.

6 Antworten

  1. Die Akteure scheinen ja fast alle GMail-Adressen benutzt zu haben und ich gehe jetzt mal davon aus, dass die valide sind. Könnte man nicht Google ermutigen, die Logs zu analysieren? Mit etwas Glück war das damit konfigurierte E-Mail-Programm (oder der Webbrowser dafür) nicht nur angemeldet, wenn es aktiv geplant war, tatsächlich eine E-Mail zu schreiben. Und nur ganz vielleicht war dann gerade der VPN-Tunnel nicht aktiv (unwahrscheinlich, aber Fehler passieren). Auch das genutzte E-Mail-Programm inkl. Webbrowser könnte Aufschlüsse geben

    (ja, ich bin früh dran, sieht so aus, als wenn der Hinweis auf den Artikel rausgeflutscht wäre, als der Review noch nicht abgeschlossen war, worauf diverse rote und orange Balken hindeuten)

    1. (Der frühe Vogel fängt den Bug. Ja, ich wollte, dass der Artikel mit der heutigen Morgenmail rausgeht, da der nächste schon am Donnerstag erscheint. Aber es brauchte dann doch noch mehr Zeit…)

      Zu Google/Microsoft: Ich bin mir sicher, dass diese ihre Logs auch schon freiwillig angeschaut haben, und sei es nur, um ihre eigenen Security-Produkte aufgrund der Resultate zu verbessern. Ich gehe nicht davon aus, dass sie allfällige Erkenntnisse zu diesem Zeitpunkt mit der Öffentlichkeit teilen wollen; nicht, bevor sich allfällige Indizien erhärtet haben.

      Gleichzeitig gehe ich davon aus, dass die Operation das VPN ernst nahm, z.B. nur von einem dedizierten Rechner aus arbeitete, der hinter einer VPN-Box hing. (Und dass allfällige Nachahmer aus den Fehlern lernen werden. Deshalb sollten auch wir daraus unsere Lehren ziehen.)

  2. Der Fall wird extrem aufgebauscht.
    1. xz war immer ein Amateurprojekt. lzma2 ist nicht einmal ein gescheiter Algorithmus, sondern eine fachlich schlechte Variante von lzma, die lzma schneller erscheinen lässt und zu einem kaputten Dateiformat führt. Es gab schon lange Streit in der FOSS-Community über die miserable Qualität von xz.
    https://www.nongnu.org/lzip/xz_inadequate.html
    2. Dazu war xz lange ein quasi-verwaistes Einmannprojekt. Das eine hängt mit dem anderen sicher zusammen, denn ein Experte im Bereich Datenkompression hätte sich da nicht wohlgefühlt. Es ist überhaupt nicht überraschend, dass das xz getroffen hat.
    3. Es war Zufall, dass sie mit xz an ssh kamen. systemd hatte xz schon vor Bekanntwerden der Lücke rausgeschmissen. Deshalb hatten die Angreifer ja auf einmal so Zeitdruck, die Backdoor schnell reinzubekommen, bevor die neue systemd-Version sich verbreitet.
    4. Der Code hatte einige Smells und Red Flags. Die Backdoor war technisch betrachtet in der Tat gut versteckt in den binären Testdaten. Genau aus diesem Grund sind binäre Testdaten aber in der FOSS-Welt geächtet. Das wussten die Angreifer genau, die haben nämlich im README extra Mühe gegeben, Ausreden zu schreiben, warum sie diese Binärdateien haben und nicht ein Skript, welches Testdaten generiert. Sie behaupteten, die Testdaten wären manuell mit dem Hexeditor erstellt worden. Das ist aber nicht plausibel, weil die Testdaten mit jedem neuen Release der Backdoor komplett durchgewürfelt hätten. Und die Debianer hätten früher oder später die Binärdatei schon allein aus Lizenzgründen herausgepatcht.

    Es war eine gefährlicher Backdoor, ein lange geplanter Angriff, und er hätte bald einige Nutzer betroffen. Das ist schon richtig. Aber die Ansicht «das könnte jedes Projekt treffen» teile ich überhaupt nicht.

    Mein Fazit aus diesem Vorfall ist es, dass man Projekte mit mangelnder Aktivität und Qualität nicht so tief ins System lassen darf.

    Und apropos Linux-Backdoor: Microsoft hat auch überall diese Bibliothek drin, sicher vor allem in Teams und Edge. Auch wenn diese konkrete Backdoor auf SSH abzielte, hätte sie auch auf diese Programme abzielen können.

  3. Danke für diesen Artikel. Ich möchte nur ein Punkt bemängeln:

    > Diese alle konsistent um mehrere Stunden zu verfälschen, wäre ein riesiger Aufwand;

    Ich stimme mit „riesig“ nicht zu. Klar, ist eine Verknüpfung von ein paar git-commands notwendig, aber die von den Commits ausgewiesenen Zeitstempel haben absolut keine Belastbarkeit. Wird der Commit verfälscht, bevor er das erste Mal gepushed wird, kann dies auch nicht von Dritten „in flagranti“ gesehen werden

    1. Die git-Commits alleine umzudaten ist nicht schwer, da gebe ich dir recht. (Allenfalls hat GitHub aber noch die Push-Zeiten irgendwo in den Logs um die mehr zu plausibilisieren.)

      Das Dchwierige ist, das auch mit den Diskussionen in den Issues, anderen Projekten und ausserhalb von GitHub; Pull Requests, … zu koordinieren.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Weitere Beiträge