NieuwsCryptoAanval op Rust-toeleveringsketen treft veelgebruikte crates, met mogelijke blootstelling van het Solana-ecosysteem

Aanval op Rust-toeleveringsketen treft veelgebruikte crates, met mogelijke blootstelling van het Solana-ecosysteem

Auteur: Hokanews·

Belangrijkste punten

  • Beveiligingsonderzoekers meldden schadelijke releases van arrayref@0.3.10, internment@0.8.7 en append-only-vec@0.1.9 in het Rust-ecosysteem.
  • De gecompromitteerde packages gebruikten een lookalike-afhankelijkheid die leek op proc-macro1, en het bijbehorende buildscript kon tijdens de compilatie een externe payload downloaden en uitvoeren.
  • Omdat Cargo buildscripts automatisch uitvoert, konden ontwikkelaars en CI-omgevingen al worden blootgesteld door simpelweg getroffen versies te compileren.
  • Het beveiligingsteam van Rust heeft de schadelijke releases verwijderd en het maintainer-account dat bij de packages hoorde geblokkeerd.
  • De getroffen crates komen voor in enkele Solana-gerelateerde afhankelijkheidsketens, maar het rapport toont niet aan dat Solana of downstream-projecten zijn gecompromitteerd.
Aanval op Rust-toeleveringsketen treft veelgebruikte crates, met mogelijke blootstelling van het Solana-ecosysteem

Een gecoördineerde aanval op de toeleveringsketen heeft verschillende veelgebruikte Rust-packages getroffen, wat zorgen baart bij ontwikkelaars en projecten waarvan de afhankelijkheidsketens componenten bevatten die zijn gekoppeld aan het Solana-ecosysteem. Beveiligingsonderzoekers van SlowMist, Socket en StepSecurity meldden dat schadelijke releases arrayref@0.3.10, internment@0.8.7 en append-only-vec@0.1.9 troffen.

De gecompromitteerde releases introduceerden een typosquat-afhankelijkheid die leek op het legitieme package proc-macro1 en waarvan het buildscript tijdens Cargo-builds een externe payload downloadde en uitvoerde. Als gevolg daarvan konden ontwikkelaars en continuous integration-systemen (CI) mogelijk al worden blootgesteld door simpelweg een project te compileren dat afhankelijk was van een van de getroffen versies. Volgens informatie die @WuBlockchain op X deelde, heeft het beveiligingsteam van Rust de schadelijke releases verwijderd en het getroffen maintainer-account geblokkeerd.

Schadelijke packages verspreid via de afhankelijkheidsketen

Het incident draait om het package-ecosysteem van Rust, waarin ontwikkelaars doorgaans gebruikmaken van externe crates om functionaliteit toe te voegen aan applicaties en softwareprojecten. In dit geval identificeerden onderzoekers schadelijke versies van drie crates: arrayref@0.3.10, internment@0.8.7 en append-only-vec@0.1.9.

De schadelijke releases bevatten een afhankelijkheid die was ontworpen om te lijken op het legitieme package proc-macro1. Deze techniek, bekend als typosquatting, probeert een schadelijk package te laten doorgaan voor een legitieme afhankelijkheid. Het is een terugkerende tactiek in opensource-registries, waaronder npm en PyPI van Python, waarbij lookalike-namen herhaaldelijk zijn gebruikt om schadelijke code binnen te smokkelen via routinematige updates van afhankelijkheden.

De aanval werd extra significant omdat de schadelijke afhankelijkheid een buildscript bevatte dat in staat was een externe payload te downloaden en uit te voeren op het moment dat het getroffen package werd gecompileerd. Het beveiligingsrisico was daardoor niet per se beperkt tot gebruikers die handmatig een duidelijk verdacht programma installeerden of uitvoerden: ook een ontwikkelaarswerkstation of CI-omgeving kon mogelijk worden getroffen als onderdeel van het normale compilatieproces van software.

Bouwproces creëerde potentieel beveiligingsrisico

Cargo is de package manager en het bouwsysteem van Rust, en ontwikkelaars gebruiken het routinematig om afhankelijkheden op te halen en projecten te compileren. De gemelde aanval maakte misbruik van die werkwijze. Omdat Cargo een buildscript van een crate automatisch uitvoert als onderdeel van de compilatie, wordt zo'n script uitgevoerd met de rechten van de gebruiker of het CI-account dat de build uitvoert.

Wanneer een getroffen afhankelijkheid werd gecompileerd, kon het schadelijke buildscript een externe payload downloaden en uitvoeren. Dit creëerde een mogelijke route voor een aanvaller om code uit te voeren op de machine van een ontwikkelaar of op een CI-host.

CI-systemen zijn bijzonder belangrijk in de moderne softwareontwikkeling omdat ze automatisch code bouwen, testen en uitrollen. Een gecompromitteerde bouwomgeving kan daarom risico's met zich meebrengen die verder gaan dan één enkel ontwikkelaarswerkstation, aangezien buildmachines en ontwikkelaarswerkstations vaak credentials bevatten zoals API-tokens, deploy-keys en signatuurmateriaal. Om die reden behandelen beveiligingsteams code-uitvoering tijdens de build doorgaans als reden om alle secrets op getroffen systemen te roteren.

Het incident benadrukt het bredere beveiligingsprobleem rond softwaretoeleveringsketens, waarbij schadelijke code een project indirect binnen kan komen via afhankelijkheden die ontwikkelaars zelf niet hebben geschreven of beoordeeld.

Solana-gerelateerde afhankelijkheidsketens vragen aandacht

De crate arrayref wordt in het hele Rust-ecosysteem veel gebruikt en komt voor in afhankelijkheidsketens van componenten die zijn gekoppeld aan Solana. De validatorsoftware van Solana en veel van het omringende tooling zijn geschreven in Rust, waardoor algemene crates zoals arrayref kunnen voorkomen in Solana-gerelateerde afhankelijkheidsbomen, ook al zijn de crates zelf niet specifiek voor blockchains. De aanwezigheid van een getroffen crate binnen een afhankelijkheidsketen betekent echter niet dat downstream Solana-gerelateerde projecten zijn gecompromitteerd.

Dit onderscheid is belangrijk omdat opensourcesoftware vaak afhankelijk is van meerdere lagen afhankelijkheden. Een kwetsbaar of gecompromitteerd package kan ergens in de afhankelijkheidsboom van een project voorkomen zonder dat dit noodzakelijkerwijs leidt tot een geslaagde inbreuk op de uiteindelijke applicatie of het netwerk.

Beveiligingsonderzoekers maken daarom onderscheid tussen blootstelling aan een schadelijke afhankelijkheid en bewijs dat de schadelijke code daadwerkelijk is uitgevoerd binnen een specifiek downstream-project of -omgeving. Het gemelde incident bevestigt dat de getroffen releases schadelijke code bevatten, maar stelt niet vast dat elk project dat verwante afhankelijkheden gebruikte is gecompromitteerd.

Beveiligingsteam van Rust verwijdert schadelijke releases

Het beveiligingsteam van Rust reageerde door de schadelijke releases te verwijderen en het maintainer-account dat bij de packages hoorde te blokkeren. Volgens de gemelde informatie zijn de machine van de maintainer of de publicatie-credentials vermoedelijk gecompromitteerd.

Een gecompromitteerd publicatie-account kan in opensource-ecosystemen een aanzienlijk risico vormen, omdat aanvallers mogelijk schadelijke software kunnen verspreiden onder de identiteit van een legitieme maintainer. Het verwijderen van de getroffen versies beperkt verdere verspreiding via het package-ecosysteem, terwijl het blokkeren van het account voorkomt dat er aanvullende releases worden gepubliceerd via de gecompromitteerde credentials. Beveiligingsadviezen voor gecompromitteerde Rust-crates worden bijgehouden in de door de community beheerde RustSec-advisorydatabase, een van de kanalen die ontwikkelaars kunnen monitoren naast het crates.io-register.

Het incident toont ook het belang aan van het monitoren van afhankelijkheden en het beoordelen van onverwachte package-updates, vooral wanneer projecten afhankelijk zijn van grote en complexe afhankelijkheidsbomen.

Bredere implicaties voor Rust-ontwikkelaars

Aanvallen op de toeleveringsketen zijn in de hele softwareontwikkeling een belangrijke zorg geworden, omdat ze zijn gericht op de infrastructuur en afhankelijkheden die worden gebruikt om applicaties te bouwen in plaats van direct de uiteindelijke applicatie aan te vallen. In dit geval was de schadelijke code ingebed in package-releases en werd deze geactiveerd tijdens het bouwproces. Dit patroon heeft goed gedocumenteerde precedenten, waaronder de XZ Utils-backdoor die in maart 2024 werd onthuld, waarbij een aanvaller misbruik maakte van de positie van een maintainer in een fundamentele opensource-compressiebibliotheek, en de inbreuk op het @solana/web3.js-package op npm in december 2024, waarbij een JavaScript-bibliotheek werd getroffen die veel wordt gebruikt door Solana-ontwikkelaars. Beide gevallen, net als dit incident, laten zien hoe vertrouwen in een maintainer-account of package-identiteit een aanvalsoppervlak kan worden.

Ontwikkelaars die met Rust-projecten werken kunnen de blootstelling aan vergelijkbare incidenten beperken door afhankelijkheidsversies te monitoren, onverwachte wijzigingen te beoordelen en beveiligingstools te gebruiken die verdachte packages of afhankelijkheidsgedrag kunnen herkennen. Voor dit incident specifiek betekent dit: lockfiles zoals Cargo.lock doorzoeken op de drie getroffen versies, CI- en buildlogs controleren op onverwachte uitgaande netwerkactiviteit, en credentials roteren op elke machine waarop de getroffen releases zijn gecompileerd. Organisaties die afhankelijk zijn van geautomatiseerde CI-omgevingen moeten ook rekening houden met de beveiliging van hun bouwinfrastructuur, omdat schadelijke afhankelijkheden mogelijk code kunnen uitvoeren voordat een applicatie wordt uitgerold.

De reactie van het Rust-ecosysteem toont het belang van gecoördineerde beveiligingsmonitoring en snelle verwijdering van gecompromitteerde packages. Hoewel de getroffen crates zijn gekoppeld aan afhankelijkheidsketens met Solana-gerelateerde componenten, bevestigt de beschikbare informatie niet dat Solana zelf of specifieke downstream-projecten zijn gecompromitteerd. Het incident dient juist als herinnering dat veelgebruikte opensource-afhankelijkheden een mogelijke aanvalsvector kunnen worden wanneer publicatie-credentials of maintainer-omgevingen worden gecompromitteerd.

Bron: Hokanews