Manipulierte Rust-Pakete erreichten crates.io
Unbekannte Angreifer haben mehrere legitime Rust-Pakete auf crates.io manipuliert. Crates sind wiederverwendbare Softwarepakete, die Rust-Projekte über den Paketmanager Cargo als Abhängigkeiten einbinden können. Der Angriff nutzte automatische Build-Skripte, um Schadsoftware auf Entwicklerrechner und Systeme für kontinuierliche Integration und Bereitstellung, kurz CI/CD, zu laden.
Betroffen waren neue Versionen von arrayref, internment und append-only-vec. Alle drei Pakete stammen vom selben Entwickler. Wie dessen Rechner oder Zugangsdaten kompromittiert wurden, ist bislang nicht bekannt.
Der Angreifer zog zuvor legitime Versionen von arrayref im Paketregister zurück. Dadurch sollten automatische oder manuelle Aktualisierungen offenbar auf die manipulierte Ausgabe gelenkt werden.
Typosquatting gegen proc-macro2
In den betroffenen Paketen wurde eine zusätzliche Abhängigkeit namens proc-macro1 hinterlegt. Der Name ähnelt dem legitimen Standardpaket proc-macro2 und ist damit ein typischer Fall von Typosquatting. Dabei soll ein leicht veränderter Paketname Vertrauen erzeugen oder bei einer flüchtigen Prüfung unauffällig bleiben.
Die eigentliche Angriffsfunktion steckte in der Datei build.rs von proc-macro1. Cargo führt solche Build-Skripte während der Kompilierung automatisch aus. Das Skript erkannte Betriebssystem und Prozessorarchitektur, lud die passende Schadsoftware von einem externen Server und startete sie.
Ein regulärer Build genügte, um fremden Code auf dem Entwicklerrechner oder einem CI-System auszuführen.
Schadsoftware lag für Linux, Windows, Intel-Macs und Apple-Silicon-Macs bereit. Der nachgelagerte Infostealer zielte auf Browserdaten aus Chrome, Brave und Edge sowie auf Daten von Krypto-Wallet-Erweiterungen. Zusätzlich konnte er sich dauerhaft im System verankern und Befehle von einem Command-and-Control-Server empfangen.
Kurzes Zeitfenster, große Reichweite
Die manipulierten Versionen waren weniger als zwei Stunden verfügbar. Wegen der hohen Verbreitung einzelner Pakete reicht die kurze Dauer jedoch nicht aus, um eine Kompromittierung auszuschließen.
| Paket | Manipulierte Version | Verfügbar | Gesamtdownloads |
|---|---|---|---|
| arrayref | 0.3.10 | 86 Minuten | rund 245 Millionen |
| internment | 0.8.7 | 90 Minuten | nicht genannt |
| append-only-vec | 0.1.9 | 107 Minuten | mehr als 4 Millionen |
Die Downloadzahlen stammen aus der gesamten bisherigen Laufzeit der Pakete. Sie sagen nicht aus, wie viele Entwickler die schädlichen Versionen tatsächlich heruntergeladen oder ausgeführt haben. Auch zur Zahl kompromittierter Systeme liegen keine bestätigten Angaben vor.
Das Rust Security Response Team entfernte die manipulierten Veröffentlichungen. Zusätzlich wurden die Pakete proc-macro-en, aovine, arone, aronenao und tinymember gelöscht. Sämtliche Versionen dieser weiteren Crates gelten als bösartig.
Was Rust-Nutzer jetzt prüfen sollten
Für Unternehmen mit Rust-basierten Backend-Diensten oder Eigenentwicklungen ist eine Prüfung der Entwicklungsumgebung und der CI/CD-Pipelines erforderlich. Das gilt auch dann, wenn Abhängigkeiten nur indirekt über andere Pakete eingebunden wurden.
- Cargo.lock-Dateien auf die betroffenen Paketnamen und Versionen prüfen.
- Lokale Cargo-Caches und zentrale Build-Caches kontrollieren.
- Build-Protokolle und erzeugte Artefakte auf die aufgeführten Versionen untersuchen.
- Verdächtige Entwicklerrechner und Build-Systeme isolieren und auf Browserdatenzugriffe, Persistenzmechanismen sowie externe Verbindungen prüfen.
- Abhängigkeiten künftig fest versionieren und nach interner Prüfung über ein eigenes Paketabbild bereitstellen.
Der erste maßgebliche Hinweis auf den Angriff kam vom Research-Team des deutschen IT-Sicherheitsunternehmens Nextron Systems. Damit hat der Vorfall einen direkten Bezug zum DACH-Raum, auch wenn die kompromittierten Pakete weltweit über crates.io verteilt wurden.
Open Source reduziert keine Sicherheitsverantwortung
Eigene Software kann teure SaaS-Abos und eine starke Anbieterbindung vermeiden. Sie verlagert jedoch Verantwortung in die eigene Lieferkette. Besonders kritisch sind Build-Skripte, weil sie bereits während des Kompilierens Code ausführen und häufig Netzwerkzugriff sowie Zugang zu internen Systemen besitzen.
Build-Umgebungen sollten deshalb isoliert werden. Externer Netzwerkzugriff lässt sich begrenzen, während freigegebene Abhängigkeiten über interne Spiegelserver kontrolliert bereitgestellt werden können. Festgeschriebene Versionen verhindern zudem, dass eine Pipeline ungeprüft auf eine neue Veröffentlichung wechselt.
Der Fall reiht sich in eine wachsende Zahl von Angriffen auf Entwicklungswerkzeuge und Abhängigkeitsketten ein. Beim Supply-Chain-Angriff auf LiteLLM waren ebenfalls CI/CD-Zugangsdaten ein zentrales Risiko. Auch automatisierte Angriffe auf Open-Source-Projekte bei GitHub zeigen, dass öffentliche Entwicklungsökosysteme zunehmend als Zugang zu Unternehmenssystemen missbraucht werden.
Open Source und Eigenentwicklung bleiben wirtschaftlich attraktive Alternativen zu Software-Abos. Ohne isolierte Builds, kontrollierte Paketquellen und nachvollziehbare Abhängigkeiten entsteht jedoch eine andere Form der Abhängigkeit, diesmal von der Integrität externer Paketregister und Maintainer-Konten.