NachrichtenKryptoAngriff auf die Rust-Lieferkette trifft weit verbreitete Crates mit möglicher Exposition des Solana-Ökosystems

Angriff auf die Rust-Lieferkette trifft weit verbreitete Crates mit möglicher Exposition des Solana-Ökosystems

Autor: Hokanews·

Wichtige Erkenntnisse

  • Sicherheitsforscher meldeten schädliche Releases der Rust-Crates arrayref@0.3.10, internment@0.8.7 und append-only-vec@0.1.9.
  • Die kompromittierten Pakete nutzten eine täuschend ähnliche Abhängigkeit, die proc-macro1 ähnelte, und deren Build-Skript während der Kompilierung eine entfernte Nutzlast herunterladen und ausführen konnte.
  • Da Cargo Build-Skripte automatisch ausführt, konnten Entwickler und CI-Umgebungen bereits beim Kompilieren betroffener Versionen exponiert werden.
  • Das Sicherheitsteam von Rust entfernte die schädlichen Releases und sperrte das zugehörige Maintainer-Konto.
  • Die betroffenen Crates erscheinen in einigen Solana-bezogenen Abhängigkeitsketten, doch der Bericht zeigt nicht, dass Solana oder nachgelagerte Projekte kompromittiert wurden.
Angriff auf die Rust-Lieferkette trifft weit verbreitete Crates mit möglicher Exposition des Solana-Ökosystems

Ein koordinierter Angriff auf die Lieferkette hat mehrere weit verbreitete Rust-Pakete getroffen und bei Entwicklern sowie Projekten Besorgnis ausgelöst, deren Abhängigkeitsketten Komponenten mit Bezug zum Solana-Ökosystem enthalten. Sicherheitsforscher von SlowMist, Socket und StepSecurity berichteten, dass schädliche Releases die Pakete arrayref@0.3.10, internment@0.8.7 und append-only-vec@0.1.9 betrafen.

Die kompromittierten Releases führten eine Typosquatting-Abhängigkeit ein, die dem legitimen Paket proc-macro1 ähnelte, dessen Build-Skript während Cargo-Builds eine entfernte Nutzlast herunterlud und ausführte. Dadurch konnten Entwickler und Continuous-Integration-(CI)-Systeme potenziell allein durch das Kompilieren eines Projekts betroffen sein, das von einer der betroffenen Versionen abhing. Nach Informationen, die von @WuBlockchain on X geteilt wurden, entfernte das Sicherheitsteam von Rust die schädlichen Releases und sperrte das betroffene Maintainer-Konto.

Schädliche Pakete über die Abhängigkeitskette eingeschleust

Der Vorfall betrifft das Paket-Ökosystem von Rust, in dem Entwickler häufig auf Drittanbieter-Crates zurückgreifen, um Funktionen innerhalb von Anwendungen und Softwareprojekten bereitzustellen. In diesem Fall identifizierten Forscher schädliche Versionen von drei Crates: arrayref@0.3.10, internment@0.8.7 und append-only-vec@0.1.9.

Die schädlichen Releases enthielten eine Abhängigkeit, die dem legitimen Paket proc-macro1 nachempfunden war. Diese als Typosquatting bekannte Technik versucht, ein bösartiges Paket ähnlich wie eine legitime Abhängigkeit erscheinen zu lassen. Sie ist eine wiederkehrende Taktik in Open-Source-Registries, einschließlich npm und Python's PyPI, wo täuschend ähnliche Namen wiederholt verwendet wurden, um schädlichen Code über routinemäßige Abhängigkeitsaktualisierungen einzuschleusen.

Der Angriff wurde besonders relevant, weil die schädliche Abhängigkeit ein Build-Skript enthielt, das beim Kompilieren des betroffenen Pakets eine entfernte Nutzlast herunterladen und ausführen konnte. Das Sicherheitsrisiko beschränkte sich daher nicht notwendigerweise auf Nutzer, die ein offensichtlich verdächtiges Programm manuell installiert oder ausgeführt hatten: Auch ein Entwicklerarbeitsplatz oder eine CI-Umgebung konnte im Rahmen des normalen Software-Kompilierungsprozesses betroffen sein.

Build-Prozess schuf potenzielles Sicherheitsrisiko

Cargo ist Rusts Paketmanager und Build-System, und Entwickler nutzen es routinemäßig, um Abhängigkeiten abzurufen und Projekte zu kompilieren. Der gemeldete Angriff nutzte genau diesen Ablauf aus. Da Cargo das Build-Skript eines Crates automatisch als Teil des Kompilierens ausführt, läuft ein solches Skript mit den Berechtigungen des Benutzers oder des CI-Kontos, das den Build ausführt.

Wurde eine betroffene Abhängigkeit kompiliert, konnte das schädliche Build-Skript eine entfernte Nutzlast herunterladen und ausführen. Dadurch entstand ein möglicher Weg für einen Angreifer, Code auf dem Rechner eines Entwicklers oder auf einem CI-Host auszuführen.

CI-Systeme sind in der modernen Softwareentwicklung besonders wichtig, weil sie Code automatisch bauen, testen und bereitstellen. Eine kompromittierte Build-Umgebung kann daher Risiken über einen einzelnen Entwicklerarbeitsplatz hinaus darstellen, da Build-Maschinen und Entwicklerrechner häufig Anmeldedaten wie API-Tokens, Deploy-Keys und Signaturmaterial enthalten. Aus diesem Grund behandeln Sicherheitsteams Codeausführung zur Build-Zeit oft als Anlass, alle auf betroffenen Systemen vorhandenen Geheimnisse zu rotieren.

Der Vorfall verdeutlicht die breitere Sicherheitsherausforderung bei Software-Lieferketten, bei der schädlicher Code indirekt über Abhängigkeiten in ein Projekt gelangen kann, die Entwickler möglicherweise nicht selbst geschrieben oder geprüft haben.

Solana-bezogene Abhängigkeitsketten rücken in den Fokus

Das Crate arrayref wird im gesamten Rust-Ökosystem breit verwendet und erscheint in Abhängigkeitsketten mit Komponenten, die mit Solana verbunden sind. Solanas Validator-Software und ein Großteil des dazugehörigen Toolings sind in Rust geschrieben, weshalb allgemeine Crates wie arrayref in Solana-bezogenen Abhängigkeitsbäumen auftauchen können, obwohl die Crates selbst nicht blockchain-spezifisch sind. Das Vorhandensein eines betroffenen Crates innerhalb einer Abhängigkeitskette bedeutet jedoch nicht, dass nachgelagerte Solana-bezogene Projekte kompromittiert wurden.

Diese Unterscheidung ist wichtig, weil Open-Source-Software häufig auf mehrere Ebenen von Abhängigkeiten angewiesen ist. Ein verwundbares oder kompromittiertes Paket kann irgendwo im Abhängigkeitsbaum eines Projekts auftauchen, ohne zwangsläufig zu einer erfolgreichen Kompromittierung der finalen Anwendung oder des Netzwerks zu führen.

Sicherheitsforscher unterscheiden daher zwischen der Exposition gegenüber einer schädlichen Abhängigkeit und dem Nachweis, dass der schädliche Code tatsächlich in einem bestimmten nachgelagerten Projekt oder einer Umgebung ausgeführt wurde. Der gemeldete Vorfall zeigt, dass die betroffenen Releases schädlichen Code enthielten, belegt jedoch nicht, dass jedes Projekt mit verwandten Abhängigkeiten kompromittiert wurde.

Rust-Sicherheitsteam entfernt schädliche Releases

Das Sicherheitsteam von Rust reagierte, indem es die schädlichen Releases entfernte und das mit den Paketen verbundene Maintainer-Konto sperrte. Den gemeldeten Informationen zufolge waren vermutlich der Rechner des Maintainers oder dessen Veröffentlichungszugangsdaten kompromittiert.

Ein kompromittiertes Veröffentlichungskonto kann in Open-Source-Ökosystemen ein erhebliches Risiko darstellen, da Angreifer möglicherweise unter der Identität eines legitimen Maintainers schädliche Software verteilen können. Das Entfernen der betroffenen Versionen begrenzt die weitere Verbreitung über das Paket-Ökosystem, während die Sperrung des Kontos verhindert, dass über die kompromittierten Zugangsdaten weitere Releases veröffentlicht werden. Sicherheitswarnungen zu kompromittierten Rust-Crates werden über die von der Community gepflegte RustSec-Advisory-Datenbank verfolgt, eine der Quellen, die Entwickler zusätzlich zum crates.io-Register überwachen können.

Der Vorfall zeigt auch, wie wichtig es ist, Abhängigkeiten zu überwachen und unerwartete Paketaktualisierungen zu prüfen, insbesondere wenn Projekte auf große und komplexe Abhängigkeitsbäume angewiesen sind.

Weiterreichende Folgen für Rust-Entwickler

Angriffe auf die Lieferkette sind in der Softwareentwicklung zu einem bedeutenden Sicherheitsproblem geworden, weil sie die Infrastruktur und die Abhängigkeiten ins Visier nehmen, die zum Bauen von Anwendungen verwendet werden, statt die Endanwendung direkt anzugreifen. In diesem Fall war der schädliche Code in Paket-Releases eingebettet und wurde während des Build-Prozesses aktiviert. Das Muster hat gut dokumentierte Vorläufer, darunter die im März 2024 offengelegte XZ-Utils-Hintertür, bei der ein Angreifer die Position eines Maintainers in einer grundlegenden Open-Source-Kompressionsbibliothek ausnutzte, sowie die im Dezember 2024 erfolgte Kompromittierung des Pakets @solana/web3.js auf npm, das eine von Solana-Entwicklern häufig verwendete JavaScript-Bibliothek betraf. Beide Vorfälle zeigen wie dieser, wie Vertrauen in ein Maintainer-Konto oder eine Paketidentität zur Angriffsfläche werden kann.

Entwickler, die Rust-Projekte nutzen, können ihr Risiko ähnlicher Vorfälle verringern, indem sie Abhängigkeitsversionen überwachen, unerwartete Änderungen prüfen und Sicherheitstools einsetzen, die verdächtige Pakete oder Abhängigkeitsverhalten erkennen können. Für diesen konkreten Vorfall bedeutet das, Lockfiles wie Cargo.lock nach den drei betroffenen Versionen zu durchsuchen, CI- und Build-Protokolle auf unerwartete ausgehende Netzwerkaktivitäten zu prüfen und Anmeldedaten auf jedem Rechner zu rotieren, auf dem die betroffenen Releases kompiliert wurden. Organisationen, die auf automatisierte CI-Umgebungen setzen, müssen außerdem die Sicherheit ihrer Build-Infrastruktur berücksichtigen, da schädliche Abhängigkeiten potenziell Code ausführen können, bevor eine Anwendung bereitgestellt wird.

Die Reaktion des Rust-Ökosystems zeigt die Bedeutung koordinierter Sicherheitsüberwachung und der schnellen Entfernung kompromittierter Pakete. Obwohl die betroffenen Crates Verbindungen zu Abhängigkeitsketten mit Solana-bezogenen Komponenten haben, legen die verfügbaren Informationen nicht nahe, dass Solana selbst oder bestimmte nachgelagerte Projekte kompromittiert wurden. Der Vorfall erinnert vielmehr daran, dass weit verbreitete Open-Source-Abhängigkeiten zu einem potenziellen Angriffsvektor werden können, wenn Veröffentlichungszugänge oder Maintainer-Umgebungen kompromittiert sind.

Quelle: Hokanews