Ein aktueller Rust Supply-Chain-Angriff zeigt einmal mehr, wie verwundbar moderne Softwarelieferketten sind. Laut dem Sicherheitsunternehmen Wiz sollen nordkoreanische Hacker das Rust-Ökosystem über manipulierte Open-Source-Pakete angegriffen haben. Die Attacke setzte bei einer besonders beliebten crate an und breitete sich anschließend über weitere Pakete desselben Verantwortlichen aus.
Der Vorfall wurde am 20. August beobachtet. Entscheidend: Die schädlichen Versionen gelangten über den legitimen Maintainer-Zugang auf crates.io, wodurch der Vertrauensmechanismus der Paketlieferkette ausgenutzt wurde.
Was wurde im Rust Supply-Chain-Angriff kompromittiert?
Im Zentrum stand die crate arrayref, ein Dienstprogramm zur Array-Umwandlung. Sie zählt zu den meistgenutzten Komponenten im Rust-Umfeld: Berichten zufolge hatte arrayref über 245 Millionen Downloads und war in etwa 75%** der Rust-Umgebungen zu finden.
Der Angreifer veröffentlichte dabei eine manipulierte Version, die der Quelle zufolge als [email protected] geführt wurde. Diese Version wurde aus dem Konto des legitimen Maintainers in den öffentlichen Paketindex geladen.
Bemerkenswert ist der schnelle Anschluss: Etwa 20 Minuten später erschienen ebenfalls vergiftete Versionen weiterer crates, nämlich internment und append-only-vec. Beide Pakete stammten aus demselben Verantwortlichenkreis, was auf eine gezielte Ausnutzung des kompromittierten Zugangs hindeutet.
Wie funktionieren die vergifteten Abhängigkeiten?
Die betroffenen Pakete sowie zusätzlich vom Angreifer selbst betriebene crates – darunter aovine, arone, aronenao und tinymember – verwiesen auf dieselbe schädliche Abhängigkeit: [email protected]. Diese Abhängigkeit spielte dabei die Rolle eines Ersatzes für die legitime crate proc-macro2.
Damit gelang es dem Angreifer, eine Identitätsverwischung vorzunehmen: Das bösartige Paket imitierte proc-macro2, während es tatsächlich eine andere, schädliche Variante mitlieferte. Aus Sicht der Build-Pipeline ist das besonders gefährlich, weil Abhängigkeiten beim Kompilieren automatisch verarbeitet werden.
Der Kern der Bedrohung: manipulierte build.rs-Datei
Innerhalb der schädlichen Abhängigkeit war laut Analyse eine Datei namens build.rs versteckt. Diese Datei ist dafür bekannt, beim Build-Prozess ausgeführt zu werden. Genau das machte sie für den Angreifer zum idealen Einstiegspunkt.
Die build.rs-Logik sollte demnach eine zweite Stufe nachladen: Sie holte abhängig von der Plattform ein weiteres Binary über TLS nach. Gleichzeitig wurde die Prüfung der Zertifikate deaktiviert. Das senkt die Hürde für Man-in-the-Middle- oder Umleitungsangriffe und erleichtert es, eine Zielinstanz auf einen kontrollierten Payload-Server zu bringen.
Reaktion der Rust-Community und sichere Entfernung
Nachdem der Vorfall entdeckt wurde, griff die Rust Security Response Team ein. Die betroffenen Pakete wurden etwa 86 Minuten nach dem Kompromiss entfernt.
Zur Einordnung veröffentlichte das Team eine konkrete Beobachtung: Eine neue Version von arrayref wurde mit einer direkten Abhängigkeit auf proc-macro1 wiederhergestellt. Laut Reaktion bedeutet das, dass dadurch der Ausführungsweg für das bösartige Build-Skript unterbrochen wurde.
In der Folge teilte das Rust-Sicherheits-Team mit, dass die schädlichen Pakete entfernt und saubere Iterationen wieder verfügbar gemacht wurden. Wichtig: Das Team fand nach eigenen Angaben keine Belege, dass die schädlichen Versionen tatsächlich im laufenden Betrieb eingesetzt wurden.
Welche Hinweise sprechen für nordkoreanische Akteure?
Wiz ordnet den Angriff einem mutmaßlich nordkoreanischen Akteur zu. Namentlich nennt der Bericht Sapphire Sleet. Dieses Threat-Model wird bereits mit früheren Supply-Chain-Vorfällen in Verbindung gebracht, unter anderem mit den Axios– und Mastra-Angriffen im April und Juni.
Der Zusammenhang soll laut Wiz über Überschneidungen in der Infrastruktur belegt worden sein. So wurden unter anderem Kennungen und Kommunikationsspuren genannt: Die Payloads hätten auf einen Endpunkt gebackt, der auch im Kontext der Mastra-Kampagne verwendet wurde. Zudem soll Command-and-Control-Verkehr zu einer IP gehören, die auch in der Axios-Aktion auftauchte. Schließlich wurde berichtet, dass dieselbe IP-Range der Infrastruktur von Hostwinds LLC in allen drei Vorfällen genutzt worden sei.
Die Attacke wirkte vorbereitet und präzise
Eine weitere Analyse von StepSecurity beschreibt den Angriff als sorgfältig geplant. Besonders auffällig sei gewesen, dass der Akteur Schritte mit hoher Genauigkeit ausführte: Dazu zählte das Erstellen von Varianten, die durch Typosquatting an legitim wirkende Pakete angelehnt waren – also an Namen, die leicht zu verwechseln sind.
Außerdem wurden offenbar pro-macro-bezogene Versionen und ein nachgeahmtes Konto unmittelbar vor dem Zeitpunkt der vergifteten arrayref-Veröffentlichung vorbereitet. Genau solche Timing-Details können helfen, Entdeckung und Reaktion zu verzögern.
Warum der Maintainer möglicherweise nicht selbst der Angreifer war
Die Rust Security Response ließ zudem eine wichtige Vermutung erkennen: Nach Einschätzung des Teams ist davon auszugehen, dass der ursprüngliche Autor von arrayref selbst nicht böswillig handelte. Wahrscheinlicher sei, dass der Rechner oder die Zugangsdaten des Maintainers kompromittiert wurden.
Dementsprechend versuchte das Team, den Maintainer zu kontaktieren. Das Ziel: den Ursprung der Kompromittierung zu klären und weitere Verbreitungswege zu verhindern.
Was bedeutet der Rust Supply-Chain-Angriff für Nutzer und Teams?
Auch wenn das Team keine Hinweise auf tatsächliche Nutzung fand, bleibt die Botschaft klar: Supply-Chain-Angriffe sind vor allem dann gefährlich, wenn sie sich in den üblichen Build- und Abhängigkeitsprozess einschleusen. Gerade im Rust-Ökosystem, in dem crates häufig automatisch eingebunden werden, kann eine manipulierte Abhängigkeit schon beim Kompilieren Schaden anrichten.
Für Entwicklungsteams ist deshalb vor allem relevant, verdächtige Paketänderungen schnell zu erkennen. Dazu gehören ungewöhnliche Versionen, unerwartete Abhängigkeiten sowie Fälle, in denen Maintainer-Aktionen nicht zum eigenen Ablauf passen.
Praktisch hilft es, auf Updates und Sicherheitsmeldungen der Community zu achten und die eigenen Abhängigkeitsketten regelmäßig zu prüfen. Wenn ein Paket als kompromittiert gemeldet wird, sollten Builds umgehend auf gesäuberte Versionen umgestellt werden.
Fazit
Der Rust Supply-Chain-Angriff zeigt, wie geschickt Angreifer Vertrauen in Open-Source-Paketquellen missbrauchen können. Im beschriebenen Fall lief der Kompromiss über die populäre crate arrayref, nutzte eine nachgeahmte Abhängigkeit und platzierte eine build.rs-Logik, die eine weitere Payload über TLS nachladen sollte – inklusive deaktivierter Zertifikatsprüfung.
Glücklicherweise reagierte die Rust-Sicherheitscommunity schnell genug, um die schädlichen Pakete aus dem Verkehr zu ziehen und saubere Versionen wiederherzustellen. Dennoch bleibt der Vorfall ein deutliches Signal: In modernen Lieferketten zählt Geschwindigkeit bei Erkennung und Gegenmaßnahmen genauso wie saubere Prozesse rund um Abhängigkeiten.
Quelle: https://www.securityweek.com/rust-supply-chain-attack-linked-to-north-korean-hackers/
