Zelfreplicerende worm aanwezig in tienduizenden malafide npm-packages
Tienduizenden malafide npm-packages zijn verspreid die een zelfreplicerende worm bevatten. De packages zijn allen voorzien van een naam gerelateerd aan Indonesisch eten, en wordt daarom ook wel de IndonesianFoods-worm genoemd.
De worm is ontwikkeld om zichzelf automatisch via npm-packages verder te verspreiden, waarschuwt SourceCodeRed. De malware genereert hierbij een willekeurige naam, past package.json-bestanden aan en voegt aan zijn bestandsnaam een willekeurig versienummer toe. Vervolgens publiceert de worm de package. SourceCodeRed wijst op 43.900 packages die de worm bevatten, die zijn gepubliceerd met behulp van 11 verschillende accounts. JFrog wijst zelfs op meer dan 80.000 varianten verspreid vanaf 18 gebruikersaccounts.
Deze werkwijze wordt continu herhaald, waardoor het aantal malafide npm-packages dat de worm bevat snel groeit. Ongeveer iedere zeven seconden wordt een nieuwe package gepubliceerd, waardoor de npm-registry wordt overspoeld met malafide packages. De worm is hierdoor breed verspreid, wat het risico vergroot dat een ontwikkelaar een van de malafide packages per ongeluk installeert en de worm zijn weg weet te vinden naar legitieme software.
Het doel van de campagne is vooralsnog onduidelijk. JFrog waarschuwt dat het echter om een proef kan gaan voor een latere campagne waarbij dezelfde infrastructuur wordt gebruikt voor het afleveren van schadelijke payloads.
- Gebruik waar mogelijk betrouwbare bronnen. (Recursief, dus check ook de imports van de imports!)
- Vertrouw je de bron niet, dan lees je de code door voordat je het importeert.
- Set de versie van je import vast, updates moet je handmatig verifiëren.
- Ga ervan uit dat je toch een keertje per ongeluk malware zal uitvoeren en heb dus mitigaties en herstelplannen.
- Gebruik waar mogelijk betrouwbare bronnen. (Recursief, dus check ook de imports van de imports!)
- Vertrouw je de bron niet, dan lees je de code door voordat je het importeert.
- Set de versie van je import vast, updates moet je handmatig verifiëren.
- Ga ervan uit dat je toch een keertje per ongeluk malware zal uitvoeren en heb dus mitigaties en herstelplannen.
De tijd valt wel mee, eigen registry hosten waarop je de packages proxiet, en daar op laten auditen (kan AI tegenwoordig ook goed). En dat in pipelines douwen, dan hoef je dat niet met de hand te doen.
Wat kennis betreft, beetje devops zou ook verplicht moeten zijn bij het bouwen van een pakket.
- Gebruik waar mogelijk betrouwbare bronnen. (Recursief, dus check ook de imports van de imports!)
- Vertrouw je de bron niet, dan lees je de code door voordat je het importeert.
- Set de versie van je import vast, updates moet je handmatig verifiëren.
- Ga ervan uit dat je toch een keertje per ongeluk malware zal uitvoeren en heb dus mitigaties en herstelplannen.
En de imports van de imports van de import, en de imports van de imports van de imports van de imports, en ...
Het is een kansloze exercitie. Zoals hierboven al is genoemd: mensen harken miljoenen regels code binnen, al dan niet zonder het te weten, en hebben geen flauw idee wat ze binnen halen. SBOM's zijn bij zeer weinig bedrijven volwassen, programmeurs met beveiligingskennis zijn nauwelijks tot niet aanwezig bij reguliere bedrijven en hebben zeker geen tijd om tienduizenden zo niet honderdduizenden regels door te nemen met fuzzers op zoek naar beveiligingsproblemen, en het patchgedrag is veelal niet om over naar huis te schrijven, zeker niet bij de containers die binnen worden gehaald.
Tuurlijk, er moeten continuiteitsplannen aanwezig zijn voor het geval er een malware-aanval plaatsvindt (of net welke contingency), maar ook die zijn bij zeer veel bedrijven niet aanwezig, dan wel niet getest, dan wel niet up to date.
We zijn op een punt aangekomen dat dit de manier van werken is, en dat we de zaken maar moeten accepteren zoals ze zijn. Het is niet anders. De ellende is groot en wijdverbreid. Dan kun je af en toe een bulletin de deur uit doen, zoals b.v. de CISA of het NCSC doet met "wle patchen hoor!", maar dat is een dfruppel op een gloeiende plaat. Iedereen tevreden met de druppel. Nou ja, dan dansen en feesten we vanuit security vrolijk mee, want ja, anders drukt security zo de uitgelaten sfeer tijdens weer een brakke release die naar prod gaat.
- Gebruik waar mogelijk betrouwbare bronnen. (Recursief, dus check ook de imports van de imports!)
- Vertrouw je de bron niet, dan lees je de code door voordat je het importeert.
- Set de versie van je import vast, updates moet je handmatig verifiëren.
- Ga ervan uit dat je toch een keertje per ongeluk malware zal uitvoeren en heb dus mitigaties en herstelplannen.
Defineer betrouwbare bronnen, want dit is een hele lastige.
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Cybersecurity Trainer / Full Stack Developer
Ben je toe aan een nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?