Een Rust supply chain-aanval heeft aangetoond hoe snel een compromis in de open-source keten kan doorsijpelen naar duizenden projecten. Volgens het cybersecuritybedrijf Wiz werd op 20 augustus een populaire Rust-crate, arrayref, doelwit van vergiftigde publicaties. De zaak speelt zich af in het Rust-ecosysteem en laat zien dat ook projecten met ogenschijnlijk “standaard” dependencies kwetsbaar kunnen zijn.
In dit artikel lees je wat er precies is gebeurd, waarom vooral de vorm van de aanval opvalt, en welke praktische maatregelen je nu kunt nemen om je Rust-builds en CI/CD te beschermen.
Waarom arrayref zo’n groot doelwit was
arrayref is een hulpmiddel voor het omzetten van arrays in Rust. De crate is extreem breed toegepast: het wordt genoemd in ongeveer 75% van omgevingen waar Rust draait. Qua downloads gaat het om meer dan 245 miljoen, waardoor elke verstoring van dit type dependency al snel gevolgen kan hebben voor een groot deel van de softwareketen.
Bij een supply chain-incident is niet alleen de “tijd tot ontdekking” bepalend, maar vooral hoe veel projecten dezelfde crate gebruiken. Dat maakt de impact van een korte publicatie van kwaadaardige varianten relatief groter.
Wat de aanvaller deed: van gecompromitteerd account tot vergiftigde crates
Het incident begon met het publiceren van een kwaadaardige versie onder de naam van de oorspronkelijke maintainer. De aanvaller zette de besmette publicatie door vanaf het account van de legitieme beheerder en stuurde de inhoud vervolgens door via crates.io.
Rond ongeveer 20 minuten na de eerste, vergiftigde release van arrayref verschenen ook andere crates van dezelfde eigenaar met een verdacht spoor: onder meer internment en append-only-vec. Tegelijkertijd waren er ook crates in de omgeving van de aanvaller zelf zichtbaar, met namen die bedoeld waren om verwarring te creëren.
De kern van het probleem zat echter niet alleen in één package. Meerdere gepubliceerde crates verwezen naar dezelfde gemanipuleerde dependency: een aangepaste versie van proc-macro2 die zich voordeed als de legitieme variant.
Hoe de kwaadaardige dependency zich voordeed als proc-macro2
Volgens het onderzoek volgde de aanvaller een aanpak waarbij een legitieme component werd “nagebootst”. De besmette dependency imiteerde proc-macro2 en werd vervolgens door meerdere crates als onderliggende schakel gebruikt.
Daarmee kon de aanvaller de build-keten beïnvloeden op een manier die lastig op te merken is wanneer je alleen naar de direct toegevoegde crate kijkt. Je ziet dan immers vooral “normale” dependencies, terwijl de echte dreiging in de diepere laag verstopt zit.
De build.rs-truc: second-stage code ophalen over TLS
In de gemanipuleerde dependency zat een kwaadwillend bestand: build.rs. Dit bestand is bedoeld om tijdens het bouwen specifieke acties uit te voeren. In dit geval werd een extra “second-stage” binair bestand opgehaald via TLS, maar met een cruciale omissie: de aanval schakelde certificaatvalidatie uit.
Door certificaatvalidatie te ondermijnen, wordt de beveiligingslaag van TLS praktisch betekenisloos voor de aanvaller. Daardoor kan schadelijke code toch worden opgehaald zonder dat een standaard trust-check wordt afgedwongen.
De combinatie van een build-script (build-time) en het omzeilen van verificatie maakt de aanval specifiek gevaarlijk voor softwareteams die builds automatisch uitvoeren in CI/CD of ontwikkelomgevingen.
Snelle verwijdering, maar het incident was al verspreid
De Rust Security Response Team verwijderde de getroffen pakketten nadat de besmetting was vastgesteld. Het bedrijf geeft aan dat er rond 86 minuten na de eerste publicatie een nieuwe versie van arrayref werd teruggezet naar een situatie waarin de dependency niet langer de kwaadwillige route volgt.
De securityrespons gaf ook een duidelijke verklaring voor de compromittatie: een nieuwe update van arrayref koppelde direct aan proc-macro1, wat volgens de analyse zou leiden tot het uitvoeren van een kwaadaardig build-script in plaats van de correcte component.
Daarna meldde de Rust-securitygroep dat alle gemanipuleerde varianten waren verwijderd en dat er “schone” iteraties waren hersteld. Tegelijkertijd was er in het onderzoek geen bewijs dat de kwaadaardige crates daadwerkelijk zijn gebruikt.
Wie mogelijk achter de aanval zat
Wiz koppelde de incidenten aan een dreigingsacteur die eerder werd verbonden aan andere supply chain-aanvallen, waaronder de Axios en Mastra campagnes (in respectievelijk april en juni). In de analyses wordt gesproken over de North Koreaanse actorgroep Sapphire Sleet.
Het verband werd mede gelegd op basis van overlap in infrastructuur: zo werd er gewezen naar een endpoint dat ook bij de Mastra-aanval wordt gebruikt, naar command-and-control (C&C) signalen die aansluiten op infrastructuur uit de Axios-campagne, en naar een gedeelde IP-range die werd gekoppeld aan Hostwinds LLC.
Waarom dit je buildproces raakt (ook als je niets “kwaads” ziet)
Bij dit soort incidenten is het misleidende aspect dat de “schuldige” crate in eerste instantie lijkt op normale, gebruikte open-source modules. De schade ontstaat door wat er gebeurt tijdens de build.
Als jouw team automatisch Rust-projecten bouwt—bijvoorbeeld in CI/CD—dan is het mogelijk dat een build bij het installeren van dependencies een schadelijke actie uitvoert. Zelfs korte periodes waarin een besmet pakket beschikbaar is, kunnen dan al genoeg zijn om risico te creëren.
Wat je nu kunt doen: praktische stappen voor Rust-teams
De aanval is inmiddels hersteld door het verwijderen van kwaadaardige versies, maar dat betekent niet dat je niets meer hoeft te checken. Hieronder staan maatregelen die passen bij de aard van de Rust supply chain-aanval.
- Controleer je dependency-lockfiles: kijk welke versies van arrayref en de onderliggende crates (zoals de proc-macro-laag) in jouw builds worden gebruikt.
- Rebuild en refresh je lockbestand: als je lockfiles inmiddels nog refereren aan versies die tijdens het incident beschikbaar waren, vernieuw dan je dependencies en voer een schone build uit.
- Let op build-time scripts: wees alert op crates die tijdens het buildproces extra scripts of downloads uitvoeren. Beperk waar mogelijk de vrijheid van build-stappen.
- Werk je tooling en policies bij: teams die policy-gedreven dependency checks gebruiken, kunnen incidenten sneller detecteren.
- Log en monitor je CI/CD: controleer of er rond 20 augustus afwijkend gedrag is geweest bij het ophalen van extra binaries of ongebruikelijke network-connecties.
Als je eerder te maken had met soortgelijke supply chain-thema’s, kan het ook helpen om parallellen te trekken met andere incidenten rond build- of dependency-gedreven dreigingen. Zo schreven we eerder over supply chain-issues die via build-stappen konden escaleren, zoals de Rust supply chain waarbij build-time malware via crates werd verspreid.
Extra aandacht voor “typosquatting” en accountcompromis
Een opvallend element in de analyse is de zorgvuldigheid waarmee de aanvaller te werk ging. Er werd gesproken over voorbereidende stappen waarbij versies en namen doelbewust werden gemanipuleerd. Ook werd vastgesteld dat er een impersonatie van een account plaatsvond vlak voor het moment van publicatie.
Dit benadrukt dat je niet alleen naar “wat is de crate-naam” moet kijken, maar ook naar wat er precies in die versie zit. Versiebeheer en verificatie zijn daarbij essentieel: zonder strikte controle kan een project onbedoeld toch de verkeerde variant meenemen.
Samenvatting: snel herstellen, maar blijf alert
De Rust supply chain-aanval via arrayref laat zien hoe een compromis in de open-source keten groot kan uitpakken. Kwaadaardige publicaties werden relatief snel teruggetrokken, en er is volgens het onderzoek geen bewijs dat de crates daadwerkelijk zijn gebruikt. Toch blijft het incident relevant: build-time payloads kunnen teams pas laat opmerken als je niet gericht controleert op dependency-versies en build-gedrag.
Door je lockfiles te controleren, afhankelijkheden te vernieuwen en je CI/CD te monitoren, verklein je de kans dat een vergelijkbaar incident jouw projecten raakt.
Bron: https://www.securityweek.com/rust-supply-chain-attack-linked-to-north-korean-hackers/
