Hackers infecteren 187 npm-packages met malware die credentials steelt

Hackers hebben meerdere npm-packages in verschillende library's geïnfecteerd met malware die credentials steelt. Volgens beveiligingsbedrijf Aikido gaat het in totaal om in totaal 187 npm-packages, waaronder packages van CrowdStrike.

Aikido schrijft dat de aanval waarschijnlijk het werk is van dezelfde mensen die achter de eerdere aanval op onder meer ansi‑packages zaten. Zij hebben hun aanpak echter verbeterd en een worm gemaakt van de malware. De malware scant het hostsysteem en ci‑omgevingen op secrets en gebruikt de credentialscanner TruffleHog om credentials te identificeren.

Hij publiceert deze gestolen credentials en secrets in een nieuwe GitHub‑repository genaamd 'Shai‑Hulud'. Vervolgens implementeert de malware de kwaadaardige workflow shai‑hulud‑workflow.yml in GitHub Actions om gegevens naar een malafide webhook te sturen.

De worm verspreidt zich door eerst een tarball van een package te downloaden. De malware verhoogt daarna de patchversie en voegt binnen package.json een nieuwe postinstallhook toe. Het kwaadaardige script wordt daarna in de tarball geschreven als bundle.js, gecomprimeerd tot .gzip-bestand en gepubliceerd op npm met gebruikmaking van de credentials van de geïnfecteerde maintainer.

Meerdere packages uit verschillende library's zijn getroffen door de malware, waaronder packages van CrowdStrike. Tegenover The Hacker News meldt het bedrijf dat het de schadelijke npm-packages heeft verwijderd en uit voorzorg alle keys die gebruikt werden in openbare repository's heeft geroteerd.

Reacties (85)

[gitaarwerk]

Deze middag was gelukkig rustiger

Ik zou iedereen willen adviseren die enigzins iets wat met NPM packages (of andere managers) wat doet, gewoon geen automatische patch updates meer te doen. Ook niet van betrouwbare bronnen.

Tools als renovate kunnen automatisch MRs aanmaken, je laat ze enkele dagen staan, en wellicht wat langer als ze wienig maintainers/downloads hebben, en dan merge je ze pas. Due diligence doen op al je sources is voor de meeste mensen/bedrijven niet weggelegd, maar je kan er wel verstandiger mee omgaan.

Daarbij zou je ook je audits regelmatig kunnen timen, en als er belangrijke vulnerabilites zijn, heb je die sneller. Bleeding edge is soms heftig .

Context maakt ook uit. Als je met veel klantgegevens werkt, is het soms veiliger om wat conservatiever te zijn. Bij anere takken van sport maakt het wellicht wat minder uit.

[Nedje]

Dat is op zich prima advies, waren het niet dat het niet (makkelijk) uitvoerbaar is. Voor de dependencies die je direct gebruikt kun je inderdaad de versies pinnen, waar je minder controle over hebt zijn je peer depedencies.

Check deze NPM Docs maar eens. In een veelvoud aan packages zul je zien dat de dependencies opgenomen staan met zogenaamde carets, Als de peer dependency dan als volgt staat: "^1.2.3" komt dat feitelijk neer op: De laatst beschikbare versie in deze range: ">=1.2.3 <2.0.0"

Wanneer je een iets als een private nexus gebruikt kun je dat misschien iets meer sturen. Onze Security afdeling is nogal rap met het verwijderen van dit soort packages uit onze interne nexus., maar bij een npm install wordt er gewoon een call gedaan naar de registry om te zoeken naar de laatste versie die past binnen je range en als dat een publieke repo is ben je de pineut

uiteraard kun je daar aan de slag met overrides, maar dat is, met name in grote repositories, dweilen met de kraan open.

[Reactie gewijzigd door Nedje op 16 september 2025 22:13]

[R4gnax]

Daarom package-lock.json bestanden mee inchecken, en streng zijn op het gebruik van npm ci om exact en enkel exact die package tree te herinstalleren. Het lock file bevat diepgaand exacte versies die geherinstalleerd moeten worden. Het is niet mogelijk om met npm ci per ongeluk een nieuwere versie te installeren. Alle versies zijn inherent gepind op wat er geinstalleerd werd toen het lock file gemaakt werd.

[supersnathan94]

hmm interessant. NPM CI als commando dus.

Daarom package-lock.json bestanden mee inchecken

Wat is hier nu dan de consensus over? Ik hoor hier echt nogal verschillende verhalen over, zeker met Renovate als LM tool.

[Nedje]

@R4gnax heeft volkomen gelijk, de meest veilige optie is simpelweg op je package-lock.json mee te comitten en in CI enkel npm ci te draaien. Iets dat ik eigenlijk in mijn originele post ook had moeten toelichten. Dank voor de toevoeging!

Sterker nog; wanneer je zelf lokaal geen extra dependencies wil installeren kun je ook gewoon npm ci gebruiken. Dat is enige manier waarop je er van uit kunt gaan dat je niet onverwacht updates krijgt.

In mijn organisatie zie ik dat het nog best moeilijk is om de honderden developers mee te krijgen in de aanpassing van werkwijze...


Edit; volgorde aangepast

[Reactie gewijzigd door Nedje op 17 september 2025 10:02]

[supersnathan94]

In mijn organisatie zie ik dat het nog best moeilijk is om de honderden developers mee te krijgen in de aanpassing van werkwijze...

breek me de bek niet open...

Maar het is ook niet heel logisch allemaal hoor. NPM helpt hier zelf ook niet echt in mee om het goed te doen.

Kijk naar iets als maven en gradle, floating versions ... what do you mean?

en dan heb je ook nog tools als Yarn die dus weer met NPM soort van half samenwerken, maar net niet. Dat geeft ook weer allerlei gedoe.

[DdeM]

met 'npm i' is het in principe ook niet mogelijk om per ongeluk een nieuwe versie te installeren, tenzij je op andere niveau's al een security issue hebt. Zolang je een package.lock gebruikt zal 'npm i' ook alleen de versie in de lockfile installeren, tenzij hier een andere versie in staat dan in de package.json, maar code mergen waarvan we de package.json is geupdate maar niet de package.lock is dan het probleem, niet hoe developers de install doen. Anders zal 'npm i' namelijk alleen maar updaten wanneer de developer zelf de package.json update en op dat moment moet deze sowieso 'npm i' draaien.

Dus buiten developer omgeving om altijd 'npm ci' gebruiken (bij pull/merge requests, ci pipeline, etc.) zeker doen, maar lokaal op je dev omgeving zou het geen probleem mogen zijn (althans, het gaat je niet helpen om dit soort hacks te voorkomen).

[Nedje]

Helaas heb je hier ongelijk in. Wanneer je peer dependencies carets of tildes gebruiken specificeren deze een versie range. Oftewel; als jij een dependency hebt op Package A, en die weer een depedency heeft op Package B en C en dat als volgt schrijft: ^1.2.3 vertaalt zich naar >=1.2.3 <2.0.0 (er van uit gaande dat er nieuwere versies zijn dan 1.2.3). Lees de docs hier nog maar eens door


Het gaat je dus zeker wel helpen om dit soort hacks te voorkomen, tot iemand een dependency update doet uiteraard. Dan ben je sowieso de pineut.

[DdeM]

Ik weet hoe die ranges werken, maar een 'npm i' zal geen update doen van eender welke package, wanneer deze in de package.lock staat en deze gelijk is aan de package.json. Gezien peer dependencies ook in de package.lock staan werkt het voor deze dependencies precies hetzelfde, je zal echt zelf ofwel een 'npm update' moeten draaien of actief de versie van een package in de package.json moeten aanpassen (of via npm install <package>), anders krijg je geen updates, ook niet van de peer dependencies.

Kan je zelf ook makkelijk testen, doe maar eens een 'npm outdated' daarna een 'npm i' en daarna weer een 'npm outdated' en je zal zien dat packages met een nieuwe minor/patch versie nog gewoon de oude versie zijn en niet zijn geupdate naar de nieuwe, óók niet als je al je node_modules verwijderd.

[Nedje]

Dat werkt dus enkel wanneer er een package-lock.json aanwezig is! Zoals je in de rest van de comments kunt lezen is dat niet overal het geval. Als ik naar mijn organisatie kijk, wij comitten hem altijd. Echter hebben we ook een reeks gegenereerde packages en die komen zonder package-lock..

[DdeM]

Zonder package-lock werkt alleen ' npm ci' ook niet en dus zal je zonder die altijd 'npm i' moeten doen, dus als er geen package-lock is gaat dat je ook niet helpen... Dat is juist het hele punt wat ik maak.

Zonder package-lock => helaas pindakaas, succes met je malware want je bent gebonden aan 'npm i' en je zal dus altijd de laatste patch versie binnen halen.

Met package-lock => het maakt helemaal niets uit of je 'npm i' of 'npm ci' gebruikt op de dev machine want geen van beide zal een update van de packages doen.

Als je packages gebruikt die zelf geen package-lock hebben maakt dat verder na eerste installatie ook helemaal niets uit, want alle packages komen in jou package-lock te staan, dus na de intiele installatie zullen ook die packages niet zomaar geupdate worden. En zoals je in al mijn comments kan lezen benadruk ik dat ook steeds. Als iemand er dus voor kiest om op zijn omgeving geen package-lock te gebruiken is dat dus het probleem, niet de manier waarop iemand zijn packages installeert.

[Harm_H]

Ik snap niet waarom NPM geen voorkeur heeft voor LTS-versies (Long-term-Support). Erkende versies, business-proof met weinig bugs.

Of misschien is dat er wel als je de vorige major version als LTS ziet.

[gorgi_19]

Ook voor een LTS versie worden patches uitgebracht en onderhoud gepleegd. Dat zijn de zogenoemde 'patchversies'. LTS wil alleen zeggen dat het versies zijn die lang onderhouden worden, niet dat er weinig bugs in zitten.

Dus neem bijvoorbeeld .Net 8 als voorbeeld. Net 8 is een LTS versies, dat betekent dat er 3 jaar onderhoud en updates op plaatsvinden.

Hier ging het ook mis met de npm. Er zijn allemaal genoemde patch versies uitgebracht. Normaliter zijn dat kleine, non-breaking bugfixes. Die bevatten echter in dit geval de worm.

[R4gnax]

Tools als renovate kunnen automatisch MRs aanmaken, je laat ze enkele dagen staan, en wellicht wat langer als ze wienig maintainers/downloads hebben, en dan merge je ze pas.

Yup. Dit is hoe je patch updates zou moeten doen.
Maar maak je geen illusies - het enige wat er zal veranderen als deze practices breed geadopteerd worden, is dat malware actoren zich mee zullen aanpassen en manieren zullen gaan zoeken om hun malware enkele dagen later pas te injecteren. Kan al zo simpel zijn als de daadwerkelijke payload middels postinstall scripts (die ook na een ci operatie draaien!) pas enkele dagen (of zelfs maanden) later te downloaden en toe te laten slaan, en tot die tijd enkel een ogenschijnlijk schadeloos ding te laten doen, wat bijv. lijkt op een phone-home voor installatie telemetrie.

Enige wat echt werkt is proactief scannen op zaken die verdacht er uit zien en mogelijk malware zijn, en deze met het handje gaan inspecteren. Wat dus ook juist is wat tools zoals van Aikido doen. Met alleen afwachten kun je alsnog de bok zijn en al iets schadevols binnen hebben gehengeld zonder dat iets of iemand het gemerkt heeft.

[Reactie gewijzigd door R4gnax op 16 september 2025 22:07]

[gitaarwerk]

Ja, je loopt altijd achter; practief scannen kan, maar ook daar moet je scanner goed genoeg zijn. Beste is gewoon handmatig auditen, maar dat is niet te doen . Aikido maakt natuurlijk hier wel zijn case mee sterk. Maar dit is wel iets wat we al stiekem van mijlenver zagen aankomen. 10 jaar geleden riepen we het ook al.

[J_van_Ekris]

Tools als renovate kunnen automatisch MRs aanmaken, je laat ze enkele dagen staan, en wellicht wat langer als ze wienig maintainers/downloads hebben, en dan merge je ze pas. Due diligence doen op al je sources is voor de meeste mensen/bedrijven niet weggelegd, maar je kan er wel verstandiger mee omgaan.

Daarbij zou je ook je audits regelmatig kunnen timen, en als er belangrijke vulnerabilites zijn, heb je die sneller. Bleeding edge is soms heftig .

GitHub heeft een standaard security optie om alle NPM packages van de package-lock.json te monitoren op security issues. Dus je wordt in dat geval automatisch gewaarschuwd in je repo. Komt netjes beschrijving bij en zelfs een workflow om hem te accepteren/rejecten als issue. Werkt behoorlijk goed.

[gitaarwerk]

Jep, maar ook hier, als het te nieuw is, dan is het ook lastig.

Mijn collega had uitgelegd dat als je vaste versie nummers gebruikt, heb je ook de kans dat er twee versies worden meegebundeld wordt, dus dat is ook niet altijd handig.

PNPM heeft een optie om pas te installeren als een versie meer dan X tijd oud is. Deze is blijkbaar ingesteld na aanleiding van de vorige hack. https://pnpm.io/settings#minimumreleaseage

Er zijn sowieso een hoop maatregelen te doen. En denk dat voor ieder anders een beste manier is. Maar wat hierboven en jij zegt, alle kan helpen, maar niets is waterdicht.

[Cyberpuppy]

En misschien eens kritisch bekijken of je wel een package nodig hebt. Ik heb die lijst gezien en volgens mij bestaat 90% uit zaken die met 1 regel code zijn op te lossen.

[gitaarwerk]

Ja, helemaal mee eens. Het is altijd een balans vinden tussen een externe package gebruiken of zelf "een regel code" onderhouden.

[Afrit13]

Kan iemand voor mij dit bericht vertalen?

[Helium-3]

Als ik (of een bedrijf of wie dan ook) een applicatie maakt of een website bouwt, dan scheelt het enorm veel werk om niet het wiel opnieuw uit te vinden. Maar om gebruik te maken van werk dat anderen al gedaan hebben. Dit werk wordt online veelvuldig gedeeld als 'packages' die verkrijgbaar zijn in een bibliotheek zoals npm. Die packages zijn stukken code die functies bieden, die jij gebruikt in jouw app of website. Dat scheelt jou veel werk. Maar nu heeft een kwaadwillende stiekem die packages voorzien van malware. Dat betekent dat iedereen die een website of app heeft met packages die hierdoor getroffen zijn, automatisch nu deze malware meeneemt als er een nieuwe versie van de app of site wordt uitgebracht, waarin de nieuwste packages (met malware) zijn inbegrepen. En die malware, die bekijkt of er misschien sleutels (credentials) te stelen zijn op de omgeving van de ontwikkelaars of het bedrijf die de packages gebruikt. Helpt dit? :)

[Robtimus]

Dat betekent dat iedereen die een website of app heeft met packages die hierdoor getroffen zijn, automatisch nu deze malware meeneemt als er een nieuwe versie van de app of site wordt uitgebracht, waarin de nieuwste packages (met malware) zijn inbegrepen.

Gelukkig is het iets genuanceerder dan dat. Projecten die NPM gebruiken hebben meestal 2 files waarin de dependencies staan. Je hebt allereerst package.json waarin je als developer aangeeft welke dependencies je wilt hebben. Als je dependencies toevoegt of "npm install" of "npm update" uitvoert, dan wordt de tweede file aangemaakt / geupdatet: "package-lock.json". Deze bevat een snapshot van de versies op het moment dat je die file aanmaakt of update. Het mooie van deze file is dat hij een stabiele build oplevert als je hem gebruikt, met "npm ci". Deze bouwt de hele dependency folder ("node-modules") opnieuw op, maar met de exacte versies uit "package-lock.json". Je krijgt dan deze geinfecteerde versies alleen maar als dat de laatste versie was op het moment dat "package-lock.json" werd aangemaakt of geupdated. Als je "package-lock.json" al een week of 2 niet meer aangepast is heb je deze versies dus niet kunnen binnenhalen, zolang je maar "npm ci" gebruikt.

Om te voorkomen dat je oude versies gebruikt waarvoor een vulnerability wordt gevonden is er nog "npm audit". Dit controleert de huidige versies en rapporteert welke versies daarvan onveilig zijn. Met "npm audit fix" kun je dan automatisch naar veilige versies updaten (voor zover mogelijk). Dit past wel weer "package-lock.json" aan, dus het kan ook weer nieuwe onveilige versies introduceren.

Samenvattend: als je "npm install" of "npm update" gebruikt dan loop je risico, als je "npm ci" gebruikt dan werk je alleen met al eerdere versies.

[ZpAz]

Je kan natuurlijk prima je lock hebben op versies waarin exploits nog niet zijn ontdekt. Die CVE's moeten eerst door iemand ingediend worden. Periodiek scannen op packages die je gebruikt kan het detecteren er van sneller maken, maar niet helemaal vermijden.

[J_van_Ekris]

Gelukkig is het iets genuanceerder dan dat. Projecten die NPM gebruiken hebben meestal 2 files waarin de dependencies staan. Je hebt allereerst package.json waarin je als developer aangeeft welke dependencies je wilt hebben. Als je dependencies toevoegt of "npm install" of "npm update" uitvoert, dan wordt de tweede file aangemaakt / geupdatet: "package-lock.json". Deze bevat een snapshot van de versies op het moment dat je die file aanmaakt of update. Het mooie van deze file is dat hij een stabiele build oplevert als je hem gebruikt, met "npm ci".

Als package maintainer wil ik daaraan toevoegen dat wij de "package-lock.json" zelf via GitHub uitleveren en van daaruit de installer laten werken. Dit doen we bewust omdat we door schade en schande hebben geleerd dat sommige packages met updates (zelfs minor!) breken. We hebben een mix van apt-get Linux packages (Bluetooth, Ant+) en npm packages (vaak de protocollen die over Bluetooth en Ant+ heen lopen, en node.js interfaces). Een mismatch in versies is vaak een bron van ellende. Door de package-lock te hanteren houden we controle op de exacte versie die geinstalleerd wordt en dat scheelt een hoop nare verrassingen. Kost wat werk aan onze kant om de boel up-to-date te houden, maar scheelt een hele hoop discussies over installs die op onverklaarbare wijze breken.

[Jur_]

ware het niet dat het normaliter goed is om regelmatig naar de laatste versie te gaan voor security patches, en dat er tools als renovate zijn om automatisch wijzigingen aan te bieden en laten builden/testen.

Wat de aanval uit het artikel zo pijnlijk maakt, is dat wanneer je netjes je dependencies bijhoud je nu juist (tot de vonst van de malware) kwetsbaar bent. Het gebruik van npm audit in je pipeline en package scanning op mirrors van de npm repo (zoals nexus bijvoorbeeld) zouden je weer zo snel mogelijk moeten laten weten dat je moet down- of upgraden in je package-lock.json.

[DdeM]

Ik hoor wel vaker dat 'npm i' dingen update en dat je risico loopt, maar heb dit echt nog nooit gezien. Net als sanity check even 2 maal een install gedaan, 1 normaal en 1 met alle node_modules eerst weggegooid en.... netjes alle versies van de package.lock zijn geinstalleerd en deze is ook niet geupdate, ondanks dat er nieuwe minor en patch versies zijn van diverse packages.

Dus weet niet op welk moment je meer risico loopt als je 'npm i(nstall)' gebruikt, maar zo te zien bij normaal gebruikt in ieder geval niet. Hij update in ieder geval geen packages en download ook geen nieuwere versies van missende packages als die anders zijn dan de versie die in de package.lock staan.

Dus het enige verschil wat ik dan zo zie is dat 'npm ci' zonder package.lock gewoon niet werkt, maar dat is natuurlijk niet minder risico als je lokaal draait, want lokaal doe je dan alsnog wel een normale install.

En dat is dus het moment dat het fout gaat, deze hele worm werkt op het feit dat initieel iemand zijn packages expliciet update en daarna gaat die aan de gang met de rest, dat ga je met een 'npm ci' niet tegenhouden.

[ZatarraNL]

Deze packages, gaan die ook via Debian of Ubuntu apt repositories? Wat is de kans dat deze geïnfecteerd zijn?

[Epidemias]

Nee, deze packages staan niet op apt repositories.

Alleen software ontwikkelaars moeten hiervoor acties ondernemen.

[wimdebok]

Je kan node npm installeren via apt maar het draait altijd uit op downloaden van packages via het internet en het is niet de voorkeursmethode op de node.js site gebruik zelf nvm en npm laat zich zelf updaten. Wat rondkijken op reddit en internet is het niet nieuw dit soort praktijken.

[CH4OS]

Dat betekent dat iedereen die een website of app heeft met packages die hierdoor getroffen zijn, automatisch nu deze malware meeneemt als er een nieuwe versie van de app of site wordt uitgebracht, waarin de nieuwste packages (met malware) zijn inbegrepen.

Mits de getroffen versies van de packages gebruikt worden, ja. Maar is natuurlijk ook niet altijd het geval. Veel packagemanagers (en in NPM kan dat ook) kun je immers version pinning doen. Genoeg websites die enkel hun dependencies (packages) updaten wanneer het daadwerkelijk nodig is.

Aan de andere kant heb je ook tools zoals bijvoorbeeld Dependabot, die automatisch dependencies bijwerken en dat vervolgens blind gedeployed wordt. Dan ben je dus wel de spreekwoordelijke Sjaak wanneer je een getroffen versie in jouw eigen website duwt.

[Reactie gewijzigd door CH4OS op 16 september 2025 23:39]

[gatlarf]

In’t kort: er wordt op de systemen van legitieme developers (nou ja, het CI-gedeelte) gezocht naar inlogegevens die ze dan misbruiken om als zogezegde legitieme developer malafide code te injecteren in pakketten die door vele mensen gebruikt worden. Op deze manier wordt hun malware verspreid. Daarna verhogen ze het versienummer waardoor er geen updates van die paketten meer geïnstalleerd worden want het update-systeem denkt dat dit de meest recente versie is. En daarna gaan ze vrolijk hun gang met hun worm die zich dan verder probeert te verspreiden.

Dat is ongeveer wat ik er uit opmaak. Geen fijne dag voor iemand die net die versie in zijn software verdeelt…

[Baserk]

Dit is inderdaad wel zeer hermetisch geschreven.

Nul poging om het ook maar enigszins richting de niet-incrowd te duiden.

[bzuidgeest]

Het is verdorie wel een tech site.

[Goldwing1973]

Ja, en? Op de site van formule 1 is ook niet iedereen een coureur.

Daarbij is tech een héél breed begrip, dus dat iemand sommige aspecten niet begrijpt en andere onderwerpen weer wel is niet zo raar.

[bzuidgeest]

Nee, maar niemand gaat daar vragen wat racen is. Je mag veronderstellen dat mensen capabel genoeg zijn om erachter te komen wat npm is als je het al niet weet.

Je moet het zo ongeveer wel tegenkomen in het tech vak vak, zelfs als niet developer.

[Christoxz]

Een journalistieke tech site ja, geen (npm/node/js etc.) developers website.
Ik weet wat het is, maar kan begrijpen dat de meeste die geen (web) developers zijn, geen idee hebben wat npm is, een korte introductie had best gemogen.

[bzuidgeest]

In het tijdperk van google/AI etc??? 5 seconden kleine moeite. Als je het al niet gewoon weet, want zelfs niet developers komen er nog wel eens mee in aanraking. Veel scripts en tools voor users gebruiken het ook of worden op die manier geinstalleerd. Het is alsof je vraagt uit te leggen wat windows update is.

[Baserk]

Dus jij gaat er vanuit dat iedere Tweaker wel moet weten wat nr-ran is.

'Want daar maakt vrijwel iedereen gebruik van, ook gewone users. En hun ouders. En hun grootouders.

Alsof je moet gaan uitleggen wat ltea is.'

Zoiets?

[Reactie gewijzigd door Baserk op 17 september 2025 13:42]

[bzuidgeest]

Hun google werkt toch ook als ze het niet weten? Het moet allemaal maar direct voorgekauwd voorgeschoteld worden. Jeetje zeg. Zeker op een tech site verwacht ik wat zelf denkend vermogen.

[joco]

Wat ik niet begrijp hoe ze die packages kunnen publiceren onder een micro release , dus een 8.0.3 versie wanneer er echt maar een 8.0.0 versie van is..

Als ik dat die moet ik eerst echt inloggen daarna nog een TOTP getal invoeren voor de 2 factor..

Wil je zeggen dat zelfs crowdstrike zelf geen 2 factor beveiliging heeft (of had) op hun npm registry packages?

Ik neem aan dat npm registry dit goed afschermd... (Dat niet maar zo een random account een ander mans package kan aanpassen...

[R4gnax]

Wil je zeggen dat zelfs crowdstrike zelf geen 2 factor beveiliging heeft (of had) op hun npm registry packages?

Houdt er rekening mee dat heel veel bedrijven werken met geautomatiseerde build agents. Die maken vaak gebruik van gepreautoriseerde long-lived tokens. Die tokens zijn niet machine-gebonden. Je hoort die veilig te houden.

Een techniek om dat te doen is om je builds bijv. in Docker containers te draaien en enkel deze secrets zo kort mogelijk bloot te stellen tijdens de laatste publish stap van je package door deze pas in die ene 'layer' van de container te mounten en zichtbaar te maken, en ze daarna ook weer te laten verdwijnen.

In zo'n geval zou een aanval middels een postinstall script niet werken om credentials te stelen, want dat draait veel eerder al. Maar je moet je realiseren dat het worm effect waarbij de package code aangepast wordt alvorens een (ogenschijnlijk legitieme) publicatie doorgang vindt, er niet mee gestopt wordt.

Dat kun je enkel stoppen door exact na te gaan wat je aan het publishen bent, voordat er daadwerkelijk overgegaan wordt tot een publish actie. Door proactief je package te scannen voordat de publish doorgezet wordt.

De kif is dat hoewel het NPM ecosysteem vele services kent (waarvan het merendeel betaald) die proactief packages scannen op malware voordat deze geinstalleerd wordt; er vziw eigenlijk geen zijn die dit outbound doen wanneer een package gepubliceerd wordt.

[Martinspire]

Zozo, al de 2e grote blunder van Crowdstrike in 1 jaar.

Verder opvallend hoeveel packages met minimale security kunnen worden bijgewerkt en dat NPM dus echt geen reet aan het scannen is geweest, de afgelopen tijd. Ik vind het een kwalijke zaak dat er zoveel verspreid lijkt te worden en dat het toch telkens weer een paar uur duurt voordat er ingegrepen wordt. Of om het weer te herstellen als blijkt dat het om een false-positive gaat. Een audit bericht wordt ook veel te laat (of nooit) bijgewerkt om te melden om wat voor malware het gaat.

Ik ben benieuwd hoe lang het duurt voordat er maatregelen worden genomen, anders zie ik dit vrij snel als een kaartenhuis in elkaar zakken. Ook het feit dat Github en NPM zelf vrijwel niet reageren, spreekt wat mij betreft boekdelen.

[Reactie gewijzigd door Martinspire op 16 september 2025 20:52]

[damouze]

Ik zou dit niet als een blunder van Crowdstrike beschouwen, eerder een probleem met de supply chain.

[R4gnax]

Als je core business security is, zeker als die software diep op kernel-niveau actief is, dan dien je elk stuk software van derden dat je binnen haalt en in je producten verwerkt dubbel en dwars te auditen op elke mogelijke vorm van malware voordat een update toegestaan wordt te gebruiken en doe je dat in afgebakende systemen.

Dus ja- dit is een blunder van Crowdstrike, en geeft aan dat ze aldaar nog steeds incompetent bezig zijn.
Het is wachten op strike three.

[Reactie gewijzigd door R4gnax op 16 september 2025 21:59]

[damouze]

De zwakheid zit hem in de supply chain, niet in hoe Crowdstrike ermee omgaat. Sterker nog: ze hebben de zwakheid in hun supply chain ontdekt, onderkend en er actie op ondernomen.

En de reden dat dit soort zwakheden naar boven komen is tweeledig: er worden er mee ontdekt en ze worden ook meer en actiever misbruikt. De onderliggende oorzaak is mentaliteit: men gaat liever mee met de laatste hype dan dat men bewezen technologie-en en software pakketten gebruikt. En niet zelden gebeurt het ook nog eens dat de meest recente hype wordt ondersteund en onderhouden door een enkel persoon of een betrekkelijk kleine groep personen.

Denk aan het 'xz' debacle: een "malicious state actor" wist te infiltreren in een project dat door slechts een enkele maintainer werd onderhouden. Dat project vormt inmiddels echter de basis voor een groot aantal Linux en *BSD distributies. Op zich best curieus omdat er veel stabielere en veel volwassenere compressiealgoritmen en containerformaten bestaan die al sinds jaar en dag beschikbaar zijn. Vergeleken bij die is xz net uit de luiers zogezegd.

[svane]

Ik zou 't Crowdstrike zeker wel aanrekenen. Als er een probleem is in de supply-chain (NPM), dan moet je daar iets aan doen. Ik snap dat dat niet voor iedereen haalbaar is, maar een miljardenbedrijf moet dit toch wel kunnen.

Wat Crowdstrike hier dus blijkbaar heeft gedaan, is NPM packages downloaden, en deze packages code laten uitvoeren. Dat is, als security bedrijf, niet de slimste actie, blijkt maar weer.

Als NPM zo'n risico oplevert, hadden ze ook een dienst als Aikido kunnen gebruiken die de packages ook daadwerkelijk controleert voordat ze die voorschotelen aan hun klanten.

Ook hadden ze bijvoorbeeld pnpm kunnen gebruiken. Daar kunnen packages niet zomaar code uitvoeren. Daar moet je echt handmatig kiezen welke (geüpdate) packages iets mogen uitvoeren. Als jouw dependency dit plotseling verlangt, dan kan je daar tenminste even voorzichtig mee om gaan.

Een foutje is snel gemaakt, dat zeker. Maar Crowdstrike gaat hier niet helemaal vrijuit wat mij betreft

[kozue]

Strike two.
Three Strikes and you’re out?

[Zenomyscus]

Als ik het goed begrijp hebben ze malware in de NPM packages gestopt die belangrijke gegevens steelt, maar hoe is het ze gelukt om die packages aan te passen? Dat gaat ook niet zomaar lijkt me en dat stuk is mij momenteel niet duidelijk. Ik snap dat je misbruik kunt maken van andermans systeem en daarmee gegevens jat, maar hoe is het mogelijk die packages aan te passen?

[Robtimus]

Vorige week hadden ze via een succesvolle phishingpoging kunnen inbreken op het NPM account van een van de maintainers. Daarmee hebben ze nieuwe versies kunnen publishen. Die nieuwe versies hebben nooit op GitHub gestaan omdat ze daar geen toegang toe hadden.

Ik vermoed dat het dit keer op een soortgelijke manier is gegaan. Je hoeft maar van de juiste persoon het account te hacken en dan kun je gewoon packages publishen.

[joco]

Maar al die maintainers (Inc crowdstrike) hebben dus 2 factor allemaal uitstaan?!!?

[Robtimus]

Ik heb me ondertussen hier iets meer in verdiept. Deze nieuwe reeks infecties komen als ik het goed heb gelezen door het automatisch installeren van een geinfecteerde versie. Deze steelt dan credentials uit GitHub en stuurt die naar de hackers, die gebruiken dit vervolgens om nieuwe geinfecteerde versies te uploaden. Die kunnen dan ook weer automatisch geinstalleerd worden, waardoor het zich snel kan uitbreiden. Mogelijk is een enkele hack (misschien die van vorige week) genoeg om een sneeuwbaleffect te veroorzaken.

Ik vermoed dat het probleem iets minder erg was geweest als men meer gebruik maakt van fixed versions. Als je "npm install" of "npm update" gebruikt, dan wordt vaak de laatste versie gebruikt. Dat kan dus van de ene op de andere dag een andere versie zijn. Gebruik je daarentegen "npm ci" dan gebruik je altijd dezelfde fixed versie.

Ik heb een van de Crowdstrike repositories bekeken, en daarin werd "pnpm install" gebruikt. Ik ken "pnpm" niet, maar het is een variant op "npm". Als deze ook de laatste versies download (en wat ik snel had gelezen is dat zo), dan is dit een geval slordig dependency management.

[pieterdebie]

Ik heb me ondertussen hier iets meer in verdiept. Deze nieuwe reeks infecties komen als ik het goed heb gelezen door het automatisch installeren van een geinfecteerde versie. Deze steelt dan credentials uit GitHub en stuurt die naar de hackers, die gebruiken dit vervolgens om nieuwe geinfecteerde versies te uploaden. Die kunnen dan ook weer automatisch geinstalleerd worden, waardoor het zich snel kan uitbreiden. Mogelijk is een enkele hack (misschien die van vorige week) genoeg om een sneeuwbaleffect te veroorzaken.

Ik vermoed dat het probleem iets minder erg was geweest als men meer gebruik maakt van fixed versions. Als je "npm install" of "npm update" gebruikt, dan wordt vaak de laatste versie gebruikt. Dat kan dus van de ene op de andere dag een andere versie zijn. Gebruik je daarentegen "npm ci" dan gebruik je altijd dezelfde fixed versie.

Ik heb een van de Crowdstrike repositories bekeken, en daarin werd "pnpm install" gebruikt. Ik ken "pnpm" niet, maar het is een variant op "npm". Als deze ook de laatste versies download (en wat ik snel had gelezen is dat zo), dan is dit een geval slordig dependency management.

Dat doet het inderdaad. Het verschil is dat NPM deze download naar elk project zelf, download pnpm deze naar een centrale folder. Een beetje zoals een cache.

[Ghoelian]

pnpm probeert blijkbaar wel een beetje slim te zijn hiermee, als pnpm een CI omgeving detecteert is de default van `--frozen-lockfile` true: https://pnpm.io/cli/install#--frozen-lockfile

Ik zou daar persoonlijk alleen niet op durven vertrouwen, beter stel je je CI workflows gewoon goed in.

[Martinspire]

Met session hijacking hoef je geen 2fa te breken

[- peter -]

Denk dat dit gaat leiden tot betaalde NPM (en in de toekomst andere platform) package registries. Je kan moeilijk enorme security gaan optuigen zonder daar kosten voor gaan rekenen. En als t (serieus) geld kost kan je ook de random script kiddy buiten houden.

[R4gnax]

Die heb je al. Dat zijn proxy oplossingen die wel packages op malware analyseren voordat ze doorgelaten worden.

[par4]

Heb je voorbeelden? Ben benieuwd naar de opties.

[icooo]

Het bronartikel is geschreven door een bedrijf dat deze dienst aanbiedt (Aikido).

[Leaplasher]

Is dit vergelijkbaar met een Docker image? Als je dat gebruikt, kan er ook malware in komen en je systeem om zeep helpen?

Host zelf wat sites via diverse Docker images. Wellicht toch verstandiger om maar weer een VM te pakken en daar de benodigde software op te gaan draaien? Blijf je zelf wat meer in controle?

[supersnathan94]

Blijf je zelf wat meer in controle

Nee niet echt. Die controle heb je met Docker ook gewoon.

Wellicht toch verstandiger om maar weer een VM te pakken en daar de benodigde software op te gaan draaien

Nee dat geeft weer andere management taken voor security die je dan alsnog weer moet gaan zitten doen.

Host zelf wat sites via diverse Docker images

Waarom via Docker? Heb je iets van server side rendering er in zitten of andere zaken? Websites kun je vaak via CDN namelijk een stuk goedkoper en sneller serveren als statische downloads. Ze kunnen wel dynamisch van alles inladen, maar de website zelf haalt dan de HTML, CSS en Javascript files uit storage van bijvoorbeeld S3. Dat is significant goedkoper en makkelijker te schalen. Kost ook niks als er geen traffic is anders dan een paar cent aan storage (en daar kom je meestal gratis mee weg omdat het niet boven de grens uit komt).

[Leaplasher]

Docker leek mij makkelijk, pre-build image, weinig aan te doen verder.
Wordpress, MariaDB, etc. Staat ook 'gewoon' thuis op wat hardware dat toch al draait voor HA.
Verder in apart VLAN, geisoleerd van de rest van 't huis.

Mijn sites stellen ook echt 3x niks voor. Paar portals/placeholders voor wat domeinen die ik graag behoudt.
En daarbij een soort reisdagboek. En daar telt het wel op aan GB's. Best wat foto's op staan.
Had 't gehost staan, en die prijzen gingen door het dak, net als bij zoveel hosters.
Vandaar dat ik 't zelf maar ben gaan hosten.

Die S3 optie klinkt wel interessant, waar kan ik daar wat meer over lezen? S3 ken ik nog niet echt namelijk.
Daarbij zijn het ook kosten die ik eigenlijk onder de streep niet hoef te maken door het thuis te hosten?

[supersnathan94]

Daarbij zijn het ook kosten die ik eigenlijk onder de streep niet hoef te maken door het thuis te hosten

Nee niet echt. S3 thuis hosten wordt weer een container opspinnen (minio) in docker.

AWS S3 is een service die in de free tier voor thuisgebruik vrijwel alles dekt.

En als het allemaal wat "trager" mag (dus niet enterprise subs milisecond access) zit je qua kosten te kijken naar iets meer dan 1 cent per gig per maand. Maar meestal kom je daar niet aan.

Bandbreedte kan wel een ding worden met foto's maar ook daarvoor geldt dat een groot deel eigenlijk gratis is en daarna betaal je per gebruik.

Had 't gehost staan, en die prijzen gingen door het dak, net als bij zoveel hosters.
Vandaar dat ik 't zelf maar ben gaan hosten.

Fair. Ik ga dit jaar ook TransIP vaarwel zeggen. Man wat een prijzen.

[Piemol]

Impacted packages

[supersnathan94]

ngx-bootstrap

1,268,837 installs.

ngx-toastr

2,097,820 installs

Dat zijn geen kleine packages hee.

[HollowGamer]

CrowdStrike, waarom bestaat dit bedrijf nog?

[gitaarwerk]

Joa.. kan je ook zeggen van Facebook. Die komen er meestal goed mee weg... maar ik vraag me ook af waarom ze nog bestaan, als we het hebben over nare dingen.

[HollowGamer]

Het voordeel van FB zijn hun bijdrage aan de Linux kernel: Btrfs, zstd, etc.

Heb niet veel met Meta, maar wel met de developers. Zelfde als met Google. Niets met hun moederbedrijf, wel met sommige onderdelen ervan.

Geen idee wat zij doen, dan enkel doen alsof ze iets toevoegen, maar zo lek zijn als een mandje.

[XiliX]

Is BTRFS niet gemaakt door Oracle?

[HollowGamer]

Gemaakt inderdaad, maar Meta doet er ook veel mee.

[gitaarwerk]

Ja, maar als je met het moederbedrijf niets hebt, waarom ga je voor zo'n plek werken... maar er zijn vast zat redenen voor. React komt ook van FB, en werk er dagelijks mee. Ik heb er stiekem wel moeite mee soms.

Anderzijds... Google doet veel voor de community van Android development. Maar al eerder hier op Tweakers een artikel over hoe ze meer het eco-systeem afhankelijk van Google maken. Ook niet heel best... Maar er is ook zat voor Europa te zeggen hoe wij dingen aanpakken. In plaats van alleen boetes uitgeven, zouden we zelf ook voor een beter alternatief kunnen zorgen. Maar het wordt snel ene geld kwestie, en het is soms teveel gereguleerd. Overal wat voor te zeggen :)

[yevgeny]

Alex Ionescu (windows internals auteur) is sinds april dit jaar terug bij Crowdstrike als Chief Technology Innovation Officer.

Ionescu werkte eerder bij Crowdstrike maar heeft in de tussentijd een paar jaar voor de inlichtingen dienst van Canada gewerkt ...

[lf2]

In mijn ogen zou dit probleem zó makkelijk opgelost kunnen worden, maar alles blijft maar "optioneel".

Zo uit mijn hoofd:

• Forceer 2FA bij het publishen, zowel op GitHub als op npm.
• Maak CI/CD-pipelines met ingebouwde audits verplicht — zeker voor populaire pakketten die door duizenden andere packages worden gebruikt.

Zelfs de meest simpele oplossing zou al enorm helpen:

• Een vertraagde publish van 24 uur voor pakketten die geen gebruikmaken van die 'geavanceerdere' beveiligingen. Opt-out? Prima, maar dan wel met extra checks of vertragingen.

[supersnathan94]

Forceer 2FA bij het publishen, zowel op GitHub als op npm.

Daar gaat het al fout.

2FA op wat. Dit is vaak geen handwerk he? Ook niet echt een persoon die dit doet maar juist een service/machine account.

Sommige packages doen daadwerkelijk epoch releases, dan worden er wel dingen gebundeld voordat ze live gaan, maar je kunt ook gewoon per feature een update doen en dan fix forward aanhouden als strategie.

[R4gnax]

Forceer 2FA bij het publishen

Gaat niet helpen.
Het probleem is dat jouw package de worm in zich genesteld krijgt wanneer een reeds geinfecteerd package terug geinstalleerd wordt in jouw project. Dat gebeurt ook op build servers wanneer er legitieme builds gedraaid worden. Waarvan je dus ook ter goeder trouw de 2FA prompt zou doorlopen en afronden, en de worm onbedoeld zou helpen verspreiden.

[fuzzyIon]

gpgcheck zoals bij sommige linux distros. Maar zodra de geheime sleutel van een developer op straat ligt is het gedaan met de veiligheid.