Rust-ontwikkelaars worden door gerichte malwarecampagnes aangevallen

De Rust Foundation waarschuwt dat er 'een gerichte malwarecampagne tegen Rust-ontwikkelaars' gaande is. Volgens de stichting die de ontwikkeling van de programmeertaal beheert, zijn er al meerdere aanvalspogingen ondernomen tegen prominente ontwikkelaars. Dat speelt al sinds juni.

De stichting schrijft over de campagne in een blogpost. Veel details geeft de stichting niet. Het is daardoor niet duidelijk hoe wijdverspreid de aanvalspogingen precies zijn. Wel zeggen de ontwikkelaars dat de aanvallen erg gericht zijn.

De aanvallen beginnen met een persoonlijk videogesprek, bijvoorbeeld als onderdeel van een sollicitatie. Daarbij halen de aanvallers de slachtoffers over iets op hun systeem te installeren zoals een vermeende audiocodec. Het echte doel is om daarmee apparaten en accounts over te nemen om malware te publiceren, waarschuwt de stichting.

De stichting zegt dat ontwikkelaars goed op moeten letten op deze vorm van phishing. De methode, schrijven de ontwikkelaars, wordt onder andere vaak ingezet door Noord-Korea, maar het is niet duidelijk of dat in dit geval ook aan de orde is. De stichting verwijst naar aanvallen, zoals een recente supplychainaanval eerder deze zomer, maar wil die aanvallen en deze nieuwe nog niet aan elkaar koppelen.

Reacties (43)

[Bedge85]

Ik ben benieuwd welke beveiligingsmaatregelen er gaan komen tegen supply chain attacks in het algemeen. Hoewel AUR (Arch) en NPM (JavaScript) wel wat maatregelen hebben genomen, zijn de maatregelen niet heel systematisch, niet wijdverbreid en reactief.

Ik als afnemer van de software kan zeggen dat ik een bepaalde leverancier van software vertrouw. In mijn geval zijn dat bijvoorbeeld Proton en Ente. Maar deze softwareleveranciers bouwen hun software weer op basis van enorm veel dependencies, en er is ook een keten van dependencies, want een Rust crate of een npm package die ze binnenhalen kan ook weer dependencies hebben. Er bestaat gewoon de kans dat er via zo'n keten toch malware op mijn desktop komt ondanks dat ik de leverancier opzichzelf wel vertrouw.

Dit is ook een van de redenen waarom ik moeite heb met de automatische updatefuncties in software, en al helemaal als die niet uitgeschakeld kunnen worden.

[sdziscool]

hedendaags weiger ik vaak updates van apps die 'kleinschalig' zijn, puur omdat de supply chain attacks een heel realistische vector zijn geworden. Tegelijkertijd kan het ook weer slecht zijn voor de beveiliging vanwege security updates etc.

Mogelijk zou een encompassing security oplossing werken a la een blockchain, maar dat is wel wat moelijker dan een simpele package repo.

[Bedge85]

Nu ik er over nadenk. Op Linux zou iets als flatpak of snap kunnen helpen in het geval dat de sandbox zelf ook goed is geconfigureerd. Bij een goed afgestelde sandbox voorkom je dat een probleem in software pakket X direct gevolgen heeft voor alle andere data op je desktop.

In de praktijk zie ik bijvoorbeeld bij flatpak toch wel heel ruime permissies. Daarnaast kun je een flatpak manifest controleren (waar je behoorlijk technische achtergrond voor moet hebben en dus niet voor iedereen bruikbaar is), maar het manifest kan volgens mij ook aangepast worden zonder dat ik hier als gebruiker van op de hoogte wordt gesteld.

[bzzzt]

Je kan natuurlijk niet alles sandboxen. Een Office pakket zal toegang tot je documenten moeten hebben. Een firewall configuratie tool tot je firewall rules. Eigenlijk is het alleen mogelijk voor 'self contained' applicaties zonder i/o mogelijk een echte sandbox op te zetten (denk aan triviale dingen als een calculator of eenvoudige games).

[Bedge85]

In principe zou je browsers enkel toegang kunnen geven to je Downloads folder en een office applicatie enkel toegang tot je Documents folder.

Een firewall tool moet toegang hebben tot zijn eigen configuratie en netwerk interfaces. Een firewall hoeft geen toegang te hebben tot mijn persoonlijk documenten of afbeeldingen.

[Reactie gewijzigd door Bedge85 op 20 september 2026 12:14]

[bzzzt]

Handig als je een document download en dat even wil aanpassen...

En als die firewall tool een optie heeft om een plaatje van je netwerk te genereren?

[Bedge85]

Maatregelingen die beveiliging verbeteren zorgen altijd voor frictie. Iedereen maakt daarin zijn eigen afwegingen op basis van zijn voorkeuren en persoonlijke situatie.

Het is tot op zekere hoogte geen goed of slecht verhaal. Het is voor mij duidelijk dat we beide andere afwegingen maken op het gebied van beveiliging en dat is prima.

[bzzzt]

Dat gebruikers zelf verantwoordelijk gemaakt worden voor dit soort security is een probleem op zich. Teveel vragen 'weet je zeker dat dit mag' (denk Vista UAC of tegenwoordig AI assistenten) betekent dat gebruikers wennen aan 'ok' klikken.

Alleen constateren dat security nou een keer frictie geeft of anderen 'guilt trippen' dat ze verkeerde afwegingen maken is ook niet bepaald productief.

[latka]

Leuk zo'n sandbox, maar de bulk van die flatpaks bevatten lekke 3rd party dependencies. Dus zelfs als de sandbox perfect is, is de applicatie in de sandbox zo lek als een zeef. Tenzij het "hello world" is als app heeft de app in ieder geval 1 of meer permissies en dus een weg naar je filesysteem of netwerk. Flatpaks zijn nooit een oplossing voor welk probleem dan ook.

[William_H]

Het gaat er om dat als een depency een lek bevat, dat die bij gewone installaties gelijk toegang heeft tot alle programma's die die depency gebruiken. Bij Snap en Flatpack is dit vanwege de sandbox al niet mogelijk. Maar daarnaast is de kans dat alle geïnstalleerde programma's toevallig allemaal geupdatet zijn met die laatste depency nihil.

[latka]

De ervaring leert dat flatpaks slecht onderhouden worden. De lekke dependency kan er zo maanden inzitten. De sandbox is een wassen neus omdat ze meestal teveel permissies hebben of omdat het pakket zo complex is dat het veel permissies nodig heeft. Nog los van alle local root exploits van de afgelopen maanden.

[RoestVrijStaal]

Meh Flatpak. Beloftes die gepaard gaan met gebruikerspesterijen.

Bij XnViewMP als flatpak kreeg ik maar niet mijn native install van GIMP als "Openen met externe applicatie" aan elkaar geknoopt.

En omdat het een GTK applicatie is, zat de "Ja"-knop bij "Wilt u deze afbeelding verwijderen" aan de rechterkant in plaats van de linker in tegenstelling tot de rest van de applicaties van mijn KDE omgeving. Met als resultaat dat ik dus bij het skimmen van fotocollecties `delete` + `pijl rechts` + `enter` in plaats van `delete` + `enter`. Waardeloos dus.

Helpt ook niet mee dat de onofficiële Flatpak die er enkel was, achterliep op de officiële release.

Ik had er genoeg van en gebruik nu de native XnViewMP.

Ik kan nu GIMP gewoon via XnViewMP via de "Openen met externe applicatie" starten als een foto wat meer retouchering nodig heeft. En omdat de "Ja"-knop op dezelfde positie staat als native KDE dialogen, gaat verwijderen gaat nu ook makkelijker met `delete` + `enter`.

Flatpak gebruiken? Enkel als het niet anders kan.

[Wolfos]

Tja, veel applicaties verbinden niet eens met het internet. Lijkt me weinig risico. Een geïnfecteerd bestand openen kan ook maar dat gebeurt niet zo snel.

[MickeVrolijk]

Als afnemer van software kan je naar de bill of materials vragen wat je een overzicht geeft van alle transitieve afhankelijkheden. Een beetje goede ontwikkelaar zal zijn afhankelijkheden ook automatisch scannen en tegen cve databases houden.

Tot slot kan je in je build proces ook nog scannen op het gebruik van libraries / containers / github actions en verplichten dat je specifieke versies gebruikt in plaats van de latest.

[cedrix5]

Na de inwerkingstreding van NIS2 lijkt dit inderdaad een grote uitdaging te worden. Ik werk met een security architect die (naast zijn werk) hier een SaaS oplossing voor aan het bouwen (ondertussen verkopen) is. Het is echt wel mogelijk om (een deel) van die keten goed in kaart te brengen, maar je gaat dan wel geautomatiseerde tooling moeten aanwenden.

[blackSP]

Ik ben helemaal gestopt met aur, alleen nog de officiële repos voor mij. Gelukkig heb ik geen specifieke tools die alleen in de user repos te vinden zijn

[R_Zwart]

Je ontkomt niet aan een grondige due dilligence. Als wij software leveren, eist onze klant een compleet overzicht van FOSS componenten en 3pp software. Dat worden contract documenten dus heb je een probleem als het niet klopt. Op onze beurt verwachten wij weer hetzelfde van onze partners (en zij weer van hun partners). Er is een team fulltime bezig om het allemaal te controleren en te testen. Alle goedgekeurde softwarecomponenten gaan in een vault en ontwikkelaars mogen alleen die gebruiken. Iets anders komt niet door de controles. Het is veel werk en heeft impact op de doorlooptijd maar je moet wel.

[hqql]

Mja, beetje normaal opletten en nadenken en er is niks aan de hand dus, net zoals bij elke andere vorm van phishing. Ben wel benieuwd naar waarom specifiek deze club het doelwit is

[Powerblast]

Naar mijn mening heeft Rust op vlak van supply chain security nog een aantal flaws waardoor het daar relatief eenvoudiger is dan bij andere talen. Daarnaast is de taal ook heel populair waardoor dit waarschijnlijk de aandacht trekt. Het probleem zit hem niet zo zeer in Rust zelf, maar eerder in hoe Cargo (de package manager) werkt.

• Binnen de Rust community heerst toch wel een beetje de trend om voor elke kleine feature een aparte crate te maken en dan vervolgens te includen. Dit zorgt naar mijn mening voor de bekende dependency hell waar ook Javascript en beperkter Java mee te maken hebben. Soms wordt zelfs voor één of twee types een aparte crate toegevoegd. Je kan dus als developer één crate toevoegen die vervolgens zelf er nog eens 50 binnenhaalt.
• Rust analyzer download direct na het wijzigen van je dependencies de source code, zonder dat je eerst kan kijken wat je allemaal zou gaan downloaden qua dep tree. Ik zou het persoonlijk handiger vinden dat ik iets kan toevoegen, cargo tree kan draaien om te kijken wat er daadwerkelijk zou binnengehaald worden. Zover ik weet voert het nog geen build scripts uit, maar ik vind dat wel tricky. Je moet dus potentieel malicious code binnenhalen en maar hopen dat je niet misklikt of je IDE zelf wat automatisch gaat doen. Zou dit dus liever omgekeerd willen zien, zeker omdat cargo check wel scripts uitvoert en dit default in veel IDE's veel te gemakkelijk "per ongeluk" gedraaid wordt.
• Gerelateerd aan het tweede punt en dit is waar de meeste issues zich nu afspelen volgens mij, bij het downloaden wordt ook de build.rs uitgevoerd. Dat voert dus op het moment dat je compiled, source code uit die er instaat. Daarin kan dus gelijk wat in staan en je moet enkel compilen om deze te laten uitvoeren. Je hoeft je programma nog niet te draaien.
• Crates.io heeft geen enkele verificatie dat de source code die daar op staat ook overeenkomt met de code op Github bijvoorbeeld. Meen gelezen te hebben dat 17% van de crates hun code tussen de beide niet matched (niet perse malicous natuurlijk).
• Geen mogelijkheid tot het vertragen van updates. Dit zit nu wel in de nightly build dus hopelijk hebben we dit binnenkort wel beschikbaar.
• Vind persoonlijk de manier van versioning in de cargo.toml ook niet zo handig benoemd. version ="1.0" zou je van denken dat deze de versie vastzet op 1.0. Nee dus , alles wat "binary compatible" is met 1.0 is ook goed. Een malicious version als 1.1 vis je dus potentieel ook binnen.

Ik ben zelf fan van Rust maar er zijn toch nog, zeker met cargo, wat punten die verbeterd kunnen worden om het veiliger te maken. Dit is niet allemaal perse uniek aan Rust alleen, veel van de punten hierboven zijn Java, C# en andere ook even gevoelig aan.

Voordeel is wel dat rustsec bestaat en naar mijn gevoel heel actief monitored . Het blijkt een tricky verhaal en zeker de laatste paar jaar ben ik erg bewust gaan monitoren op wat ik van dependencies binnenhaal. Is het iets klein, dan schrijf ik het nog liever zelf dan dat ik daarvoor weer een crate gebruik. Hoe minder dependencies, hoe beter mijn inziens.

[Reactie gewijzigd door Powerblast op 20 september 2026 15:30]

[GertMenkel]

Dat tools als Rust Analyzer code uitvoeren voor je die zelf kunt lezen, heeft meer met Rust Analyzer te maken dan de rest van het ecosysteem. Ik vind het gemak waarmee crates als veilig worden beschouwd door de gangbare tooling wel vervelend, maar een groot gedeelte van de kwetsbaarheid komt door specifieke tools als die.

Qua upgrades vertragen en versies pinnen: dat kan gewoon. Het is niet de default, maar een crate kan op de specifieke git-revisie/tag/branch worden vastgepind als je dat wilt. Dan ben je ook van het source code-verschil af. Pakketten vastpinnen op versie werkt ook gewoon, mits je dat doet (dus version = "=1.2.3" doen, niet version = "1.2.3").

Dat dit niet altijd de norm is bij Rust-developers, is jammer, maar voor ieder professioneel bedrijf hoop ik dat hun policies daar toch wel op zijn afgestemd. Dingen als pull-through caches waarin oude versies beschikbaar blijven, security-scans kunnen worden gedaan, en security scanners in de CI/CD om te detecteren dat er kwaadaardige dependencies in de keten zitten, is allemaal niet bepaald onmogelijk om op te zetten.

Net als bij andere programmeertalen is dit probleem meer een kwestie van weten/willen dan kunnen. De Rust-tooling stelt je ook prima in staat om systeem-pakketten te gebruiken. Debian heeft bijvoorbeeld een heel stel Rust-pakketten in hun repository (inclusief instructies voor dingen als version pinning voor de documentatie over pakketten onder hun beheer) zodat je net als bij C++ een "vaste" versie hebt die je kunt targeten. Je kunt ook barebones gaan met alleen de standaardlibrary zoals bij diverse C-programma's.

Niets hieraan is Rust-eigen. Ik denk dat dit meer de algemen cultuur van moderne programmeertalen reflecteert. Zelfs op de ouderwetse ontwikkelsystemen (C/C++ en Makefiles) zie je nu dat distributies zelf direct worden aangevallen (Arch meerdere malen, bijvoorbeeld), waardoor zelfs de "mijn dependencies zijn twee systeempakketten"-aanpak niet meer veilig is.

[Artimunor]

helaas is Proton (die je eerder noemde) niet zo professioneel als ik zou willen.

als ik een bug rapporteer op reddit krijg je gewoon van de lead dev van dat subproduct te horen "als je het niet via een officieel bug report meld kijken we er niet naar"

dat lijkt erg op een overwerkte onervaren dev. die dus een zwakke schakel is ondanks dat het bedrijf misschien policies heeft zouden ze mijns inziens juist omdat het om privacy en security gaat elke bug die dat kan beinvloeden serieus moeten nemen ongeacht hoe ze achter het bestaan komen. dat heet eigenaarschap

[Powerblast]

Het pinnen werkt zover ik begrijp enkel voor binaries en direct dependencies. Je kan dan "=x.y.z" zeggen en hij gebruikt steeds die versie. Voor libraries wordt dit echter afgeraden heb ik recent geleerd, omdat bij het builden de Cargo.lock van de library toch genegeerd wordt, de .lock file van de binary primeert. Daarnaast werkt het voor transitive dependencies ook niet. Dit geeft vind ik de vervelende situatie dat je dus volledig moet betrouwen op het al aanwezig zijn van een Cargo.lock file en je als intermediate library builder eigenlijk geen invloed kan uitoefenen op welke exacte versie de eindgebruiker uiteindelijk binnen haalt. In bijvoorbeeld Java is dat niet de standaard. Maven ondersteunt wel ranges, maar versie X is versie X.

Deel je mening verder wel dat het probleem grotendeels bij de tooling zit en niet zo zeer bij de taal zelf . Heb al geleerd om dependency management buiten een IDE te doen zodat zeker Rust analyzer of Rustrover niet automatisch "slim" gaan zijn en vanalles binnenhalen om je te helpen. Dependencies updaten doe ik over command line om dat dus te vermijden.

[Reactie gewijzigd door Powerblast op 21 september 2026 19:12]

[jeroenathome]

Het grote voordeel van Rust is de manier waarop het met het geheugen omgaat. Hierdoor is de kans kleiner dat een beveiligingslek ontstaat. Criminelen balen hiervan omdat het voor hun lastiger wordt om systemen over te nemen.

[bwerg]

Dat is echt niet uniek aan Rust, dat geldt voor elke memory-safe taal. Sterker nog, talen met handmatige (en foutgevoelige) memory-management zijn tegenwoordig in de minderheid. O.a. Java, python, C#, javascript, zijn allemaal memory-safe en worden meer gebruikt dan C(++), volgens mijn n=1-zoekresultaat.

Het enige noemenswaardige aan Rust is wat dat betreft dat de programmeur een mate van controle over memory-allocaties heeft vergelijkbaar met C(++), wat je bij die andere talen doorgaans niet hebt. Die mogelijkheid tot micro-optimalisaties samen met memory-safety is onder mainstream-talen redelijk uniek. Maar dat op zich zal criminelen echt worst wezen.

[Powerblast]

Ik vat het zelf altijd als volgt samen: Codes like Java, runs like C++ . Zo voelt het voor mij althans aan. Rust voelt high level aan op één of andere manier, eens je voorbij de weirdo syntax kunt kijken. Maar het performed wel zoals een low level taal.

[curkey]

In dit artikel is het denk het vooral te doen om de repository van Rust zelf te vergifitgen met malware libraries die in de automatische updates meekomen naar duizenden clients.

[Bedge85]

Maar iedereen heeft wel een slechte dag, is vermoeid, of onoplettend.

[hqql]

Klopt, maar voordat je op het punt zit dat je een "audio codec" tijdens een video sollicitatiegesprek met een niet geverifieerde partij aan het installeren bent moet je toch wel een paar keer een flink slechte dag hebben gehad, mijns inziens.

[R_Zwart]

Dat is bijna alle gevallen de beste oplossing. Maar ze zullen speuren naar de ontwikkelaar die om wat voor reden dan ook even wat minder scherp is. Dit soort aanvallen is altijd een schot hagel, maar je iets raakt heb je wat. Zolang het maar goedkoop genoeg is dit uit te voeren wordt het gedaan.

[Reactie gewijzigd door R_Zwart op 21 september 2026 08:47]

[hqql]

Ik ben wel benieuwd naar wat je precies naïef vindt aan mijn comment?

[themadone]

Op een sollicitatiegesprek een stuk software aangeboden krijgen, tja, je zal het maar installeren....

Wel eentje die ik toe ga voegen aan de lijst met criteria om mensen die beheerswerk willen doen op af te wijzen 🤣

[thegve]

Ik houd mijn computer graag zo clean mogelijk, maar in corona tijd (vooral) waren er allerlei proprietary videocall services. Zoom, Webex en meer waar ik zo even niet op kan komen. Vaak met allerlei obsure websites en software die mega veel permissies wil.

Nu ben ik nerd genoeg dat ik bij mijn toenmalige werkgever in ieder geval een speciale VM had gemaakt hiervoor, maar in die context is het "kennelijk" niet "raar" om van je gesprekspartners te eisen dat ze vage software installeren.

Zelfde voor tech partners waar je een VPN verbinding mee wilt maken en die dan ook met vreemde proprietary software aan komen zetten.

[downtime]

Wat denk je van die verplichte software om examens remote te doen? Doet vaak scans van je PC, wil toegang tot camera en microfoon, etc. Ik vertik het, ga gewoon naar een examencentrum, maar niet iedereen heeft die optie.

[R_Zwart]

Degenen die dit soort gesprekken voeren zijn uiteraard getraind in social engineering en weten hoe je deze doelgroep moet bewerken. En als het bij 1 op de 100 lukt kan het al ruim voldoende zijn om van een succes te spreken (succes voor de hackers). Achteraf zal iedereen die er in is getrapt zichzelf wel voor de kop slaan waarom hij/zij het gedaan heeft.

[Harm_H]

NPM packages en Vscode extensie updates zijn ook al een tijdje hoger risico geworden.

[Powerblast]

Klopt, ik heb zelf de auto update van alle VSCode extensions uit staan om die reden. Enkel VSCode zelf auto update wel nog. De extensions zal ik zelf wel bewust doen.

[Reactie gewijzigd door Powerblast op 20 september 2026 15:12]

[mstrhans]

Sinds de XZ0-hack (2024) zal iedereen wel heel bewust zijn van zulke backdoors? Of is dat heel moeilijk te bestrijden..?

[beerse]

Een ontwikkelaar is ook maar een mens. En daarbij, een taal-ontwikkelaar is iemand anders dan een software-ontwikkelaar.

Overigens wel goed dat ze dit zo aan de grote klok hangen: Iedereen is vatbaar voor dergelijke aanvallen. En iedereen moet dus opletten.

[mjtdevries]

Nee! Niet iedereen is vatbaar voor dergelijke aanvallen. Naieve mensen zijn vatbaar voor dergelijke aanvallen. En blijkbaar zijn er dus ook Rust ontwikkelaars die erg naief zijn.

Maar laten we alsjeblieft dat sprookje niet verder verspreiden dat het iedereen kan overkomen.

Net zoals dat sprookje dat elk bedrijf gehacked kan worden.

Want zodra we die sprookjes gaan geloven, gaan we ook minder moeite doen om onszelf te beschermen en goed op te letten. Want het kan immers iedereen overkomen, dus niemand kan het je kwalijk nemen.

[R_Zwart]

Jij bent 24/7 super scherp? Nooit eens andere dingen aan je hoofd waardoor je toch af en toe wat minder scherp bent?

[mjtdevries]

Je hoeft niet super scherp te zijn om niet zomaar van een onbekende software te installeren.
Je hoeft zelfs niet minder scherp te zijn om dat niet te doen.

Je moet wel heel erg naar de andere kant doorschieten voordat je dat doet.