GitLab komt met opensource-tool voor opsporen kwaadaardige code in dependencies

GitLab heeft Package Hunter uitgebracht, een tool die kwaadaardige code moet ontdekken in dependencies, of externe libraries die ontwikkelaars aan hun eigen code toevoegen, voor het schade kan aanbrengen. De tool is opensource en gratis uitgebracht.

Package Hunter installeert de dependencies in een sandboxomgeving en monitort tijdens de installatie alle system calls die de dependencies maken. Als daar een verdachte call tussen zit, krijgt de gebruiker een melding, zodat deze actie kan ondernemen. Momenteel biedt Package Hunter ondersteuning voor NodeJS-modules en Ruby Gems.

GitLab ontwikkelde Package Hunter onder meer omdat het op die manier hoopt dat ontwikkelaars meer vertrouwen krijgen in het gebruiken van publieke libraries. Het is namelijk makkelijk om publieke libraries te hergebruiken en nieuwe functies toe te voegen, maar het risico is dat bugs of kwaadaardige code aan hun programmatuur wordt toegevoegd via deze dependencies.

Uit onderzoek uit 2020 blijkt dat opensource packages regelmatig misbruikt worden voor supplychain-aanvallen. Zo werd er vorig jaar kwaadaardige code toegevoegd aan de populaire package event-stream. Begin dit jaar publiceerde onderzoeker Alex Birsan hoe hij dependencies kon gebruiken om binnen te dringen bij onder meer Apple en Microsoft.

GitLab heeft Package Hunter sinds november vorig jaar getest en heeft de tool nu gratis en opensource gepubliceerd. Op die manier hoopt GitLab dat ontwikkelaars verder meehelpen aan het project en bugs melden. Package Hunter kan aan elk project toegevoegd worden met het GitLab CI template.

Package Hunter

Reacties (21)

[henne25]

Ik vraag me af of het niet heel eenvoudig is voor kwaadwilligen om te detecteren of men de applicatie in de sandbox draait en enkel dan geen system calls doet.

[CAPSLOCK2000]

Ik vraag me af of het niet heel eenvoudig is voor kwaadwilligen om te detecteren of men de applicatie in de sandbox draait en enkel dan geen system calls doet.

Ja, meestal wel, maar er zijn wel heel veel soorten sandboxen. Er is niet echt een algemene procedure om dat vast te stellen. Sommige virussen proberen dat wel. Maar het is een soort wapenwedloop. De auteurs van sandboxen hebben juist als doel om zo goed mogelijk op 'echt' te lijken.
En als software op allerlei manieren gaat proberen of het een sandbox is dan is dat zelf ook weer verdacht.

Niks in deze wereld werkt ooit 100% helemaal. Het gaat om risico's en kansen.

[Argantonis]

En als software op allerlei manieren gaat proberen of het een sandbox is dan is dat zelf ook weer verdacht.

Dit is denk ik erg belangrijk. Een lek maken is niet triviaal maar ook niet heel lastig, en is nog redelijk te verbergen, afhankelijk van de taal. Maar dit soort detecties worden al snel erg complex en verdacht.

[elmuerte]

Verder is dit alleen tijdens de package install, en niet bij het gebruik van de dependency.
Ik heb het altijd vreemd gevonden dat bij NPM package installs willekeurige code kunnen uitvoeren, en het bijna onmogelijk is om te controleren wat er uitgevoerd wordt bij een install.

[poktor]

Maar ik begrijp dat de malware-scanner Package Hunter de dependencies wel volledig scant bij het binnenhalen ervan. De uitvoering ervan bij ingebruikname zou dus veilig moeten zijn.

[latka]

Niet echt. Als je als malware developer weet van dit soort zaken zorg je ervoor onder de radar te vliegen. Ik neem aan dat men niet aan pattern matching doet als een virusscanner, maar alleen kijkt naar gedrag dan zorg je ervoor dat je exploit alleen afgaat als het lokale op adres valt in de range van diegene die je aan wilt vallen.

[poktor]

Daarom vind het ook zeer verrassend dat die package hunter open source is. Een aanvaller kan hierdoor in de code kijken hoe het ding werkt en eromheen werken. Niet echt handig lijkt me. Ik verwacht daarom dat dit product in no-time closed source is.

[TheVivaldi]

Als GitLab dit closed source gaat maken, dan breekt de hel los. Diverse ontwikkelaars zijn juist overgestapt van GitHub naar GitLab omdat ze vreesden voor narigheid bij het gesloten Microsoft. Als GitLab nu iets closed source gaat maken, dan zullen ontwikkelaars denk ik erg boos zijn.

[Verwijderd]

security through obscurity is geen security

[latka]

Dat lijkt me sterk. Om een aantal redenen:
1) Close-source development tools zijn lastig te verkopen (open-source ook)
2) Ik weing voorbeelden van producten die open-source waren en closed-source nog bestaansrecht hebben
3) Het is een sandbox. Het meet gedrag naar buiten. Dat is genoeg info om omheen te programmeren. Closed source of niet.

[rob12424]

Maar zijn daar ook niet rootkit Hunter (rkhunter) en uhm (ik kan even niet op de naam van die ander komen) + IDS?

Daarnaast vaak zijn ze toch ook gehashed? Je kan met Debian bijvoorbeeld de hash controleren.

[svenslootweg]

Ik heb het altijd vreemd gevonden dat bij NPM package installs willekeurige code kunnen uitvoeren

Als je er ietsje langer over nadenkt is het helemaal niet zo vreemd; immers, wat ben je aan het installeren? Juist, code die je later uit gaat voeren!

Of je nou wel of niet install scripts toestaat (en die zijn simpelweg noodzakelijk voor bijv. compilatieprocessen), je zult toch altijd de code in de package zelf uit gaan voeren, dus netto maakt het eigenlijk geen verschil. De package-auteur vertrouwen moet je toch wel, en of er nu code uitgevoerd wordt op moment A of moment B...

[Reactie gewijzigd door svenslootweg op 26 juli 2024 14:17]

[Antipater]

Het maakt wel verschil waar die code uitgevoerd wordt natuurlijk, en met welke rechten.

[iKiddo]

Kwaadwillenden kunnen er inderdaad omheen werken. Ze kunnen ook om virusscanners heenwerken en kunnen ook om de bestaande open source [1] en commerciële [2] geautomatiseerde malware analyse platforms heen werken.

Uiteraard houd je wel malware tegen, omdat niet alle kwaadwillenden (effectief) er omheen werken. En de makers van deze platforms weten ook wel dat sommige kwaadwillenden eromheen proberen te werken en treffen daar dan weer maatregelen tegen.

Maar het belangrijkste aan wat GitLab hier doet: het gaat hier om het voorkomen van supply chain attacks in *open source* code. Dat betekent dat hoe meer kwaadwillenden zich in bochten moeten wringen om de analyse platformen te bypassen, hoe meer (of gekkere) code ze daarvoor nodig hebben en hoe groter de kans dat iemand in de broncode ziet dat er iets geks aan de hand is.

[1] Bijv. Cuckoo.
[2] Bijv. Check Point ThreatCloud Emulation Service, Palo Alto Wildfire.

[Mushroomician]

Gevalletje bluepill vs redpill.
Uiteindelijk kan de sandboxomgeving die sandboxdetectie-patronen ook verdacht vinden, analyseren wat er wordt verwacht en zelfs antwoorden simuleren op basis van die verwachtingen, om zo het ware gedrag op te sporen.
Als de simulatie goed genoeg is kun je het niet detecteren. Geldt ook voor het universum zelf.

[Joostlek]

Ik hoop wel dat ze rekening houden met dat er ook code in kan worden gestopt die wordt binnen gehaald van een externe server.

Bij een install komt het wel eens voor dat een dependency zelf checkt of er nog een nieuwere update van zichzelf beschikbaar is, zo ja, dan zie je dat vaak in de console terug. Dus het is niet vreemd dat er requests gedaan worden bij installs.

Goed initiatief, ik zou zelf pas dependencies echt 100% vertrouwen als ze hiernaast ook een statische code test zouden doen.

[aikebah]

Checken mag ie van mij doen tegen een hard static 'latest' versienummer en dan een waarschuwing geven dat er nieuwere versies bestaan.
Ophalen van extra code om uit te voeren tijdens de preinstall toch liever niet. Stop die code maar gewoon in het package, dan kun je die direct in je package analyse meenemen.

[Joostlek]

Nee maar daarom, dat is wat deze feature momenteel niet lijkt te doen.

[NanoSector]

Ik denk dat in plaats van hier extra tools voor te schrijven het een beter idee is om dat hele systeem wat je beschrijft op te doeken vanaf de wortel, of op zijn minst ervoor zorgen dat dit niet meer mogelijk is. Wat heeft een pakketbeheerder of een repository namelijk nog voor nut wanneer ieder pakket toch zijn eigen gang mag gaan en allerhande meuk extra binnenharkt?
Als ik zo de beschrijving lees dan lijkt het alsof deze tool de hele installatie in de gaten houdt, en dus zou het dit soort offenders ook kunnen aanmerken.

Op basis van zulke tests denk ik ook niet dat je moet concluderen dat een dependency of ander stuk code 100% veilig is. Dit programma is net zoals zaken als NPM audits gemaakt als hulpmiddel en heeft niet als achterliggende gedachte om de zorg voor veiligheid en betrouwbaarheid uit jouw handen te nemen, het is slechts een indicatie en een tool om eerder en sneller problemen te vinden.

Wat betreft statische test of analyse klinkt dat dan ook heel erg leuk, maar dat zal altijd een kat en muis spelletje worden. Iemand die echt kwaad wil kent meerdere wegen naar Rome.

[register]

Het 100% vertrouwen van code na een statische test zou ik niet aanbevelen.

[Joostlek]

Nee maar als je een statische test in zou zetten om remote executes te vinden en te flaggen. Dit zou ik een mooie aanvulling zien op dit project.