NachrichtenMakroKoordinierter Supply-Chain-Angriff trifft beliebte Rust-Crates mit Schadsoftware zur Build-Zeit

Koordinierter Supply-Chain-Angriff trifft beliebte Rust-Crates mit Schadsoftware zur Build-Zeit

Autor: Metaverse Post·

Wichtige Erkenntnisse

  • Bösartige Versionen der Rust-Crates arrayref, internment und append-only-vec wurden so verändert, dass sie von proc-macro1 abhängen, einem Typosquat von proc-macro2, der beim Cargo-Build Schadsoftware ausführte.
  • Das plattformübergreifende Implant infizierte Linux-, macOS- und Windows-Systeme, sammelte Systemdetails und Chromium-Browserdaten und etablierte Persistenz sowie Command-and-Control-Kommunikation.
  • Das Rust Security Response Team entfernte die verseuchten Releases und sperrte das Konto des Maintainers; laut Schlussfolgerung waren wahrscheinlich der Rechner des Entwicklers oder dessen Veröffentlichungs-Zugangsdaten kompromittiert, statt dass der Maintainer böswillig handelte.
  • arrayref hatte rund 152 Millionen Downloads angesammelt und taucht in Abhängigkeitsbäumen mit Solana-bezogenen Komponenten auf, was eine breite Angriffsfläche über Entwickler-Rechner und CI/CD-Infrastruktur schafft.
  • Da Cargo yanked Versionen bei der Berechnung neuer Abhängigkeitsbäume überspringt, aber bereits in Cargo.lock-Dateien erfasste Versionen berücksichtigt, hängt die tatsächliche Exposition vom gepinnten Lockfile jedes Projekts ab.
Koordinierter Supply-Chain-Angriff trifft beliebte Rust-Crates mit Schadsoftware zur Build-Zeit

Am 20. August 2026 identifizierten Sicherheitsforscher einen koordinierten Supply-Chain-Angriff auf drei auf crates.io veröffentlichte, weit verbreitete Rust-Crates. Die kompromittierten Pakete – arrayref Version 0.3.10, internment 0.8.7 und append-only-vec 0.1.9 – wurden so verändert, dass sie eine bösartige Abhängigkeit enthielten, die während des üblichen Kompiliervorgangs Remote-Code ausführte. Das Rust Security Response Team entfernte umgehend die betroffenen Releases und sperrte das Konto des Maintainers. Nach ersten Erkenntnissen war wahrscheinlich der Rechner des rechtmäßigen Entwicklers oder dessen Veröffentlichungs-Zugangsdaten kompromittiert worden, statt dass der Maintainer in böser Absicht handelte.

Typosquat-Abhängigkeit lieferte die Schadsoftware aus

Der Angriff nutzte eine per Typosquat getarnte Crate namens proc-macro1, die sich als legitime Bibliothek proc-macro2 ausgab. Sobald Cargo die Abhängigkeit auflöste, führte es automatisch ein bösartiges Build-Skript aus, das Command-and-Control-Adressen aus Base64-obfuszierten Daten rekonstruierte, die TLS-Verifizierung deaktivierte und eine plattformspezifische Nutzlast von einem vom Angreifer kontrollierten Server herunterlud. Da die Kompromittierung zur Build-Zeit erfolgte, konnte bereits das bloße Kompilieren eines Projekts, das transitiv von einer der bösartigen Crates abhing, eine Entwickler-Workstation oder einen Continuous-Integration-Host infizieren – selbst wenn der Anwendungscode nie direkt eine verdächtige Funktion aufrief.

Die Täuschung zielte auf einen der universellsten Bausteine von Rust – proc-macro2 bildet die Grundlage der Makro-Verarbeitung für einen großen Teil der veröffentlichten Crates –, und Registries wie crates.io, npm und PyPI vergeben Paketnamen nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“ – eine Praxis, die Typosquatting seit Langem zu einer bevorzugten Supply-Chain-Technik über verschiedene Sprach-Ökosysteme hinweg macht.

Plattformübergreifendes Verhalten der Hintertür

Die Schadsoftware funktionierte unter Linux, macOS und Windows. Unter Linux und macOS platzierte sie eine ausführbare Datei in temporären Verzeichnissen und startete sie als entkoppelten Prozess. Unter Windows setzte sie PowerShell- und Visual-Basic-Skripte ein, um Ausführungsrichtlinien zu umgehen und verborgene Prozesse auszuführen. Die Hintertür der zweiten Stufe erstellte anschließend ein Profil des infizierten Systems und sammelte Benutzernamen, Hostnamen, installierte Anwendungen und Browserdaten aus Chromium-basierten Browsern. Sie etablierte Persistenz auf Benutzerebene über Registry-Run-Keys, systemd-User-Services oder macOS-LaunchAgents, hielt die Kommunikation mit einem Command-and-Control-Endpunkt aufrecht und unterstützte Remote-Anweisungen für weitere Ausführungen und Konfigurationsänderungen.

Das Sicherheitsunternehmen Socket dokumentierte die Kompromittierung auf X:

Popular Rust crates compromised: Affected versions of arrayref, internment, and append-only-vec were modified to depend on proc-macro1, a malicious typosquat of proc-macro2. Its build script downloaded and executed malware during Cargo builds. Analysis:

— Socket (@SocketSecurity), August 20, 2026

Breitere Auswirkungen auf das Ökosystem und Maßnahmen zur Behebung

Der Vorfall hat erhebliche Auswirkungen auf das Rust-Ökosystem und die angrenzende Blockchain-Infrastruktur. Allein arrayref hatte vor der Kompromittierung rund 152 Millionen Downloads angesammelt und liegt in Abhängigkeitsbäumen, die Solana-bezogene Komponenten und beliebte Frameworks für grafische Oberflächen umfassen. Auch wenn nachgelagerte Projekte nicht zwangsläufig kompromittiert waren, sofern sie die bösartigen Versionen nicht ausdrücklich auflösten und bauten, erzeugt die weit verbreitete transitive Nutzung der Crate eine breite Angriffsfläche über Entwicklungsumgebungen, CI/CD-Pipelines und automatisierte Release-Infrastruktur hinweg, die häufig sensible Tokens und Signaturmaterial beherbergen.

Der Vorfall reiht sich zudem in eine umfassendere Welle von Registry-Kompromittierungen ein. Im August 2025 veröffentlichte eine als rk0x verfolgte Kampagne mit gestohlenen Maintainer-Zugangsdaten mit Schadsoftware versehene Versionen beliebter Rust-Crates, um Browser-Zugangsdaten und Kryptowährungs-Wallets abzugreifen, während npm und PyPI bereits mehrfach eigene Typosquatting- und Account-Übernahme-Kampagnen überstehen mussten. Die XZ-Utils-Hintertür von März 2024 zeigte ebenfalls, wie eine einzige weit verbreitete Open-Source-Bibliothek zu einem Engpass werden kann, der eine riesige Zahl nachgelagerter Systeme erreicht.

Die Ermittler identifizierten weitere vom Angreifer kontrollierte Staging-Crates – proc-macro-en, aovine, arone, aronenao und tinymember –, die anschließend aus der Registry entfernt wurden. Der Bedrohungsakteor zog zudem frühere legitime Versionen von arrayref zurück (yanked), was die Abhängigkeitsauflösung potenziell auf das bösartige Release lenken sollte, bevor Administratoren eingriffen. Nach den Auflösungsregeln von Cargo werden yanked Versionen bei der Berechnung neuer Abhängigkeitsbäume übersprungen, bereits in einer Cargo.lock erfasste Versionen werden jedoch weiterhin gebaut, sodass die tatsächliche Exposition von den gepinnten Lockfiles abhängt und nicht allein vom Zustand der Registry.

Organisationen wird empfohlen, Cargo.lock-Dateien, Abhängigkeitsinventare und Build-Logs auf die betroffenen Versionen und zugehörige Indikatoren zu prüfen. Jedes System, das eines der bösartigen Releases kompiliert hat, sollte als potenziell kompromittiert behandelt werden – mit einer Rotation der für die Build-Umgebung zugänglichen Geheimnisse, einer forensischen Suche nach bekannten Netzwerk- und Host-Artefakten und einem Neuaufbau der Software aus verifiziert sauberen Umgebungen. Verteidiger sollten außerdem Verbindungen zur identifizierten Command-and-Control-Infrastruktur und den deterministischen Ausgaben des Domain-Generierungsalgorithmus des Implants überwachen. Die Ökosystem-Werkzeuge unterstützen diese Analyse: cargo tree listet transitive Abhängigkeiten zur Prüfung auf, und die RustSec-Advisory-Datenbank, die über cargo audit eingebunden wird, katalogisiert bekannte verwundbare Crate-Versionen.

Quelle: Metaverse Post