Dit is de eerste aflevering in een reeks artikelen over de meest voorkomende vorm van software supply chain-aanvallen: aanvallen waarbij (mis)bruik wordt gemaakt van een openbaar register van softwarecomponenten, bedoeld voor open source-projecten om artefacten te uploaden die met andere gebruikers kunnen worden gedeeld. Wanneer de slechteriken daar kwaadaardige software publiceren, waarbij ze het register gebruiken als middel voor de verspreiding van malware, hebben we te maken met een supply chain-aanval wanneer de slachtofferorganisaties de geïnfecteerde softwarecomponent installeren of uitvoeren.
Om de discussie waar we het over zullen hebben te vereenvoudigen softwarepakketten:, onderdelen in verpakte vorm geproduceerd door derden. Dit omvat niet alleen componenten die worden gebruikt door pakketbeheerders zoals NPM of Poetry, maar ook componenten van het besturingssysteem inclusief bibliotheken en uitvoerbare binaire bestanden, container afbeeldingen, en virtuele machines, of gereedschap uitbreidingen voor ontwikkelings-, bouw- en implementatietools. We hebben overal kwaadaardige pakketten gezien. Cybercriminelen vinden het niet erg: ze zijn blij met de alternatieven die moderne software-infrastructuren bieden en gebruiken het register en de tool die het beste bij hun bedoeling passen. Vergeet dus niet dat softwarepakketten een afkorting zijn voor containerimages, binaire pakketten, open-source repositories en extensies of plug-ins van allerlei soorten (IDE's, CI/CD systemen, buildtools). Allemaal worden ze routinematig aangevallen.
De serie zal 5 afleveringen hebben:
- Wat is het probleem met open source-pakketten? Dit is het thema van dit bericht. Waarom publiceren allerlei soorten criminelen kwaadaardige pakketten? Waarom zou ik me zorgen maken?
- Anatomie van kwaadaardige pakketten: wat zijn de trends? In deze aflevering concentreren we ons op de dreiging die we dag na dag in de gaten houden met ons MEW-systeem. Met veel achtergrondgeluid als gevolg van een groot aantal kwaadaardige pakketten die gebruik maken van typosquatting of afhankelijkheidsverwarring, is een kleiner percentage aanvallen veel verraderlijker en vormt een groter risico. Hoe is het gedrag van de slechte actoren met betrekking tot OS in het recente verleden veranderd? Wat zijn de cijfers? Wat zijn de tactieken, technieken en procedures die worden gebruikt en welke schadelijke acties worden waargenomen?
- Bescherming tegen kwaadaardige open source-pakketten: wat werkt (niet)?. De meeste beveiligingsbewuste professionals hebben ideeën over hoe ze met deze dreiging om moeten gaan. We hebben beveiligingsmanagers zonder aarzeling horen zeggen dat SCA tools vertellen je al wanneer een pakketversie malware is. Of dat ze afhankelijk zijn van bekende, goed beoordeelde softwarecomponenten, waarbij malware snel wordt gedetecteerd en verwijderd. Ze Dat ze open minor/patch-versies gebruiken om automatisch kwetsbaarheidsoplossingen te krijgen, en dat is de juiste, aanbevolen manier om het risico op open source-afhankelijkheden te verlagen, volgens het principe "patch early, patch often". In deze aflevering bespreken we waarom deze ideeën verkeerd zijn en hoe dergelijke misvattingen bijdragen aan de populariteit van dit aanvalsmechanisme en aan een overweldigend risico dat organisaties ervaren. We eindigen met wat wel werkt en wat de inspanning en middelen zijn die erbij betrokken zijn.
- Open source kwaadaardige pakketten: de Xygeni-aanpak. In deze aflevering presenteren we de strategie die we bij Xygeni volgen voor ons Malware Early Warning (MEW)-systeem. Hoe werkt dit meerfasensysteem in realtime wanneer een nieuwe pakketversie wordt gepubliceerd, hoe bewijsmateriaal uit verschillende bronnen wordt verzameld, hoe triage wordt uitgevoerd, welke classificatiecriteria we volgen en waarom er nog enige handmatige analyse nodig is om dit te bevestigen de aard van een kwaadaardig pakketkandidaat? Hoe de feedback van onze interne en registerteams het systeem helpt te leren van eerder verzameld bewijsmateriaal om valse positieven tot een minimum te beperken. We zullen uitleggen hoe we NPM, GitHub, PyPI en andere belangrijke infrastructuren in de open-source open source-ecosystemen helpen de verblijftijd te verkorten.
- Open source exploiteren: wat u van de slechteriken kunt verwachten. De serie eindigt met de nadruk op de nieuwste acties die de tegenstanders omarmen om de aanvallen heimelijker, moeilijker te detecteren, gerichter tegen specifieke industrieën te maken en meer voordeel uit deze klasse aanvallen te halen. Zullen ransomware-aanvallen met dit voertuig worden uitgevoerd? Hoe maken de slechteriken gebruik van AI-tools om geavanceerdere kwaadaardige pakketten af te leveren? Zijn populaire topprojecten in gevaar? Dit is om de lezers een gevoel te geven over deze wapenwedloop en wat ze kunnen verwachten op de korte termijn (tweede helft van 2024) en de middellange termijn (2025). We zullen leren hoe aanvallen zoals de recente XZ-Utils-achterdeur, of de aanval op het leven buiten het land elektronenbouwer in maart 2024 laten zien dat we waakzaam moeten blijven over de manier waarop de tegenstanders zich ontwikkelen.
Laten we het podium openen met de eerste aflevering: wat is er aan de hand met kwaadaardige open-source open source-pakketten?
Wat is het probleem met open source-pakketten?
De afgelopen jaren hebben allerlei soorten overtreders open source-softwareregisters gebruikt om kwaadwillig gedrag te vertonen. Deze activiteiten zijn zo oud als open source, maar hun frequentie is de afgelopen drie jaar geëxplodeerd.
Kwaadaardige componenten publiceren in openbare registers (op afhankelijkheid gebaseerde aanvallen) is een asymmetrische guerrillaoorlog die bedreigingsactoren gebruiken om malware te verspreiden, waarbij gebruik wordt gemaakt van het vertrouwen dat organisaties stellen in open-sourcecomponenten die afkomstig zijn van onbekende ontwikkelaars (denk aan de afhankelijkheid xkcd strip?). Omdat u pakketten vertrouwt en het niet erg vindt om de inhoud van pakketten en hun afhankelijkheden handmatig te controleren, zijn deze aanvallen buitengewoon effectief. En de asymmetrie komt doordat ze grotendeels kunnen worden geautomatiseerd en de slechteriken niet rechtstreeks met het slachtoffer hoeven te communiceren. Ze uploaden het pakket eenvoudigweg naar het openbare register en laten het los.
Schadelijke pakketten in 6 met een factor zes gestegen, en bleef in 2.5 met een factor 2023 groeien. Vorig jaar werden maar liefst 245,000 kwaadaardige pakketten gezien, een cijfer dat het totale aantal van voorgaande jaren samen meer dan verdubbelt. Dit is exponentiële groei! Van de honderden pakketverwijderingen als bevestigde malware in 2021 en de duizenden in 2022 zagen we in 2023 veel meer achtergrondgeluiden, met een vergelijkbaar tempo voor dit jaar. En verborgen in die achtergrond, veroorzaakt door ongekunstelde cybercriminelen die het ‘pad van de minste weerstand’ volgden, bereikte een minderheid van de spraakmakende aanvallen zelfs de krantenkoppen in de algemene media.
Waarom is dit een probleem van zo’n omvang? Er is een overdaad aan vertrouwen over de hele keten. Open-sourcesoftware wordt gedistribueerd met de broncode en vrijgegeven onder een bepaalde licentie. Ja, iedereen kan de broncode inzien; maar wie doet dat in het algemeen? Wie bouwt, nadat hij heeft gecontroleerd of de software geen malware bevat, de software op basis van de bronnen? Wie, voordat hij het verpakte onderdeel (ook bekend als a pakket) stroomafwaarts naar de pakketbeheerder of de buildtool, ervoor zorgt dat het pakket niet vol zit met malware en overeenkomt met de veronderstelde broncode waar het vandaan zou moeten komen?
Waarom staat de infrastructuur zulke gemakkelijke aanvallen toe?
Pakketregisters zijn open en vereisen vaak een minimale verificatie van de identiteit van de uitgever. “Iedereen is welkom om hier zijn software te publiceren!” De lat voor aanvallers ligt laag: ze gebruiken wegwerp-e-mailadressen en wegwerp-GitHubgithub-accounts om honderden kwaadaardige pakketten te creëren in korte, phishing-achtige campagnes. Alleen voor gerichte bronnen is meer verfijning nodig: we zagen zelfs een geloofwaardige GitHub-bronrepository creëren met veel sterren en commits van meerdere nepbijdragers en andere statistieken van populariteit en onderhoud. Krijgen sterrenkijkers en reputatie door nepbijdragen is niet moeilijk te automatiseren. We zagen misbruik op allerlei soorten open software-infrastructuren, niet alleen op malware, zoals de theeprotocol-incident.
Pakketbeheerders zijn ontworpen voor gebruiksgemak en niet voor beveiliging. Ze kunnen scripts vóór en na de installatie uitvoeren (soms is het compileren van native code voor een bibliotheek noodzakelijk). Ook, Pakketbeheerders installeer pakketten uit meerdere bronnen, en soms is de standaard het gebruik van openbare registers. Ze hebben niet gecontroleerd op een mismatch tussen de metadata in het publicatieverzoek en de metadata in het pakket zelf.
Afhankelijkheden zijn genest en vormen een grafiek. In bepaalde ecosystemen zoals Node (JavaScript) stapelen kleine afhankelijkheden zich op in de honderden of duizenden. Eén ding is om strikte controle te hebben over de directe afhankelijkheden die door mijn softwareprojecten worden verklaard, maar transitieve afhankelijkheden zijn moeilijker te controleren. Open source volgde “de vrienden van mijn vrienden zijn mijn vrienden”. Broederschap is de norm in het wilde Verre Oosten! Bedreigingsactoren weten dit en verbergen het kwaadaardige gedrag diep in obscure afhankelijkheden die vaak onbekend zijn. Dit was het geval bij de evenementenstroom incident gericht op de Copay portemonnee.
Dit is hoe open-sourcesoftware vanaf het begin werkte. Het zal niet veel veranderen. Sommige pakketregisters eisen op zijn best tweefactorauthenticatie, en vaak alleen voor de meest populaire pakketten. Sommige registers bieden scopes, een naamruimte die eigendom is van een gecontroleerde organisatie, maar tragisch anderen ondersteunen het niet (PyPI) of maken het optioneel (NPM). Het is interessant om op te merken dat zelfs a eenvoudig screeningschema (gebaseerd op controle van de DNS- of GitHub-repository/organisatie die overeenkomt met de groeps-ID) en making PGP-handtekeningen verplicht voor alle artefacten behalve checksums verwijdert het grootste deel van de “ruis”, typosquatting-achtige kwaadaardige pakketten, en beperkt een groot deel van afhankelijkheid verwarring. Geavanceerde aanvallen zijn mogelijk, maar veel moeilijker, en er zijn er maar een paar zoals de com.github.codingandcoding:maven-compiler-plugin bekend van Maven Central. En niet alle maven-registers volgen dezelfde praktijken!
Beveiligingscontroles op pakketbeheerders kunnen afhankelijkheidsaanvallen belasten, maar belemmeren deze niet. Het probleem met multi-factor authenticatie is dat voor automatisering afgeleide inloggegevens zoals toegangstokens of APIapi-sleutels worden gegenereerd voor accounts die moeten worden gebruikt in APIapi-aanroepen vanuit automatiseringsscripts, zonder dat er een ondersteunende interactieve gebruiker een tweede factor biedt. MFA is goed voor het beschermen van gebruikersaccounts tegen wachtwoordlekken, maar de gegenereerde toegangstokens of APIapi-sleutels moeten worden beschermd terwijl ze actief zijn, anders wordt hun eigenaar nagebootst door de kwaadwillenden. Een groot deel van de pakketgebaseerde supply chain-campagnes begint met een gelekte sleutel/token. Denk maar aan incidenten zoals Grootboek, 3CX, en nog veel meer, waar niet-interactieve inloggegevens voor het eerst werden geëxfiltreerd tijdens een voorlopige inbraak voor het lanceren van de supply chain-aanval.
De reactie op deze dreiging was niet robuust genoeg. In de derde aflevering richten we ons op wat werkte en wat jammerlijk faalde. De industrie moet collectief werken aan de standards, processen, educatie en tooling om risico's voor wereldwijde toeleveringsketens te beperken. Dit is geen probleem dat een enkele organisatie alleen kan oplossen.
Om dit gedeelte te beëindigen, het cruciale misverstand: waar we het over hebben kwaadaardig pakketten, niet kwetsbaar degenen. Kwetsbaarheden komen voort uit ontwerp- of codeerfouten die per ongeluk zijn geïntroduceerd, zonder kwade bedoelingen. Er kan misbruik worden gemaakt van de kwetsbaarheden, maar veel daarvan niet. Schadelijke pakketten zijn altijd opzettelijk en er is 100% misbruik mogelijk als ze worden uitgevoerd. Geen vergelijkbaar risico! Vandaar het is paradoxaal om te zien hoeveel moeite er wordt gedaan om kwetsbaarheden op te sporen en te beperken, en het gebrek aan gelijkwaardige maatregelen voor kwaadaardige componenten.
“Wij nemen veiligheid serieus”
Laten we ons het gebruikelijke voorstellen Acme Corporation. Acme, een belangrijke leverancier van WileCoyote.com, laat het grootste deel van zijn software afkomstig zijn van derden, waarbij meer dan 80% afkomstig is van open-sourceprojecten. Ze produceren software voor intern gebruik, maar leveren ook software voor hun partners, providers en klanten/eindgebruikers. Acme heeft software geschreven in Go, JavaScript, Java, C# en Python, en draait de meeste software in de cloud, onder Kuberneteskubernetes-clusters. Acme bouwt zijn aangepaste images op basis van basisimages uit Docker Hub en andere registers. En ze delen ook een paar bibliotheken, pakketten en containerimages in openbare registers.
Acme neemt beveiliging serieus. Ze zijn zich redelijk bewust van het probleem van open source securityen het risico dat dit met zich meebrengt. Alle ontwikkelaars, systeembeheerders en DevOpsdevops-ingenieurs gebruiken die schattige kleine cryptosleutels als tweedefactorauthenticatie. Alle commits om code-repositories te ondertekenen, branch-beveiliging is ingeschakeld met verplichte code-reviews, CI/CD vergrendeld, geheimen opgeslagen in een geheime kluis, en met een intern register dat gedeeltelijk externe registers spiegelt waar alleen de toegestane, op de witte lijst geplaatste componenten zijn opgeslagen. Het is vereist dat software die door Acme is gebouwd, afhankelijkheden van derden uit dit register moet halen.
Waarschijnlijk passen de meeste organisaties in dit profiel. Beste lezer, die van jou past zeker als je er nog bent, nietwaar?
Dan, op een noodlottige dag, een belangrijke frontend-ontwikkelaar bij Acme liep npm installeer acme-cute-lib, waarbij we vergeten dat @acme/cute-lib de juiste afhankelijkheid was. De exacte fout is niet belangrijk; er kunnen veel dingen fout gaan, zelfs als je uitgaat van perfecte controle over de softwarelevenscyclus. Onze ontwikkelaar wist niet dat een APT-groep zich op Acme richtte en publiceerde een kwaadaardige component onder die naam, op een sluwe manier, zodat het kwaadaardige gedrag alleen wordt geactiveerd wanneer de software op Acme-computers wordt geïnstalleerd. Het pakket werd wekenlang na publicatie niet gedetecteerd.
Er wordt een installatiescript uitgevoerd dat naar inloggegevens zoekt (er zaten veel sappige toegangstokens op de laptop van onze ontwikkelaar), waardoor toegang werd verkregen tot interne softwarebronnen, en de bovengenoemde interne opslagplaats, die uiteraard alleen toegankelijk is via VPN. De kwaadaardige code slaagde erin de bestaande VPN-verbinding te gebruiken en een kwaadaardige component in de tweede fase in het interne register te publiceren, waardoor een gemeenschappelijke bibliotheek met gebruiksfuncties werd aangetast die wordt gedeeld door de meeste door Acme geleverde software.
Weken daarna begonnen andere organisaties die de gepubliceerde tools van Acme gebruikten vreemd verkeer op hun netwerken te zien, waarbij verkeer het protocol van Acme gebruikte maar werd doorgestuurd naar hosts die leken op het Acme-domein. Het verkeer was gecodeerd, maar systeemmonitoringtools vonden toegang tot onverwachte bestanden en de uitvoering van processen die op systeemopdrachten lijken, maar die uiteindelijk gedownloade uitvoerbare bestanden uitvoeren.
De rest is geschiedenis: Acme ontkende eerst dat dergelijk gedrag aan hen te wijten was en dat alle veiligheidsmaatregelen getroffen waren. Pas nadat de cybersec-media begonnen te vragen waarom de bron van het gedetecteerde gedrag afkomstig was van de componenten van Acme, en uit beveiligingsanalyses bleek hoe vol die componenten zaten met heimelijke malware, moest Acme het incident herkennen en een incidentresponsbedrijf inschakelen. Een negatieve marketingcampagne die het zuurverdiende vertrouwen in een seconde ondermijnde. “Acme was één npm-installatie verwijderd van disaster' was een veel voorkomende kop. Daarna volgden rechtszaken en opgezegde contracten.
Ziet u overeenkomsten met bekende incidenten uit het verleden? Acme kreeg in twee fases te maken met een supply chain-incident, waarbij gebruik werd gemaakt van een mix van afhankelijkheidsverwarring/typosquatting aanvallen waarbij een ontwikkelaarswerkstation als bruggenhoofd werd gebruikt voor het infecteren van componenten die terechtkwamen in software die door derden werd gebruikt. Hoe zou dit voorkomen of verzacht kunnen worden?
Waarom vergiftigde pakketten zo populair zijn
Dit hypothetische incident laat zien dat organisaties, zelfs met een redelijke benadering van open-sourcebeveiliging, specifieke maatregelen nodig hebben om te voorkomen dat ze ten prooi vallen aan malware in open-sourcecomponenten. Schematisch kan de dreigingsactor:
- Maak een nieuw pakket (volgens de bekende manieren van typosquatting of afhankelijkheidsverwarring, dit is qua volume het meest bewandelde pad door de slechteriken);
- Probeer een bestaande te infecteren, door deze in de broncode te injecteren, door te proberen deze te vermommen als een bijdrager via pull request, of door social engineering te gebruiken om een beheerder te worden (zoals “Jao Tan” deed in de XZ Backdoor of rechts9ctrl GitHub-gebruiker deed het in de evenementenstroom incident in de herfst van 2018), of door inloggegevens voor een open source-repository te verkrijgen en zich voor te doen als de beheerder;
- Injecteer malware tijdens het bouwen van het pakket, door een kwaadaardig buildscript uit te voeren, of het verstoren van pakketdownloads met man-in-the-middle-onderscheppingen (gelukkig is TLS nu altijd vereist in de meeste registers).
- Injecteer de verpakte component rechtstreeks in het register, meestal door de registerreferenties vast te leggen (het voorkeursalternatief voor veel geavanceerde aanvallen zoals die van Acme, waarbij het gecompromitteerde werkstation in de eerste fase over het interne registertoegangstoken beschikte, bijvoorbeeld in de gebruikelijke .env or ~/.m2/settings.xml: slechte acteurs weten waar ze naar geheimen moeten zoeken). Ook werd misbruik gemaakt van kwetsbaarheden in de registers.
Het vergiftigen van registers met malware vormt de basis voor afhankelijkheidsaanvallen. Niets nieuws onder de zon: de prevalentie ervan is geëxplodeerd, maar dezelfde technieken werken nu als vijf jaar geleden.
Het kwaadaardige pakket kan actief zijn tijdens de installatie, tijdens het bouwen van software of tijdens runtime. En het gedrag varieert van informatie-exfiltratie, bijvoorbeeld het extraheren van geheimen voor een poging in de tweede fase, tot het extraheren van broncode, waarbij extra malware wordt achtergelaten. In de volgende aflevering zullen we de kwaadaardige pakketten ontleden en hoe ze worden gepubliceerd.
Verdere lezing
De volgende aflevering Anatomie van kwaadaardige pakketten: wat zijn de trends? zal zich concentreren op echte gevallen die we dag na dag monitoren met ons Malware Early Warning-systeem. We zullen bekijken welke soorten malware zijn gezien en welke tactieken, technieken en procedures favoriet zijn. We zullen verduistering onderzoeken en hoe ze zich proberen te verbergen voor potentiële recensenten, de ontwijkingstechnieken om detectie te vermijden, en hoe ze evolueren met telemetrie en laterale beweging. Blijf op de hoogte!
Referenties
- Backstabber's Knife Collection: een overzicht van aanvallen op de supply chain van open source-software. M. Ohm et al., mei 2020.
- Open source-malwarebescherming. Whitepaper van Xygeni.
- Software Supply Chain Security Terugblik: vormgeven aan een veiliger 2024. Verslag van Xygeni.
