De Megalodon GitHub-aanval: een grootschalige supply-chain aanval via CI/CD-pijplijnen

De operatie vond plaats tussen ongeveer 11:36 en 17:48 UTC, wat wijst op een sterk geautomatiseerd systeem dat in korte tijd een groot aantal repositories kon compromitteren, nog voordat beheerders de wijzigingen opmerkten.

Hoe aanvallers in korte tijd duizenden commits konden injecteren

De campagne vertrouwde op automatisering en sociale camouflage om kwaadaardige commits eruit te laten zien als normaal CI-onderhoud.

Nep CI-bots en wegwerpaccounts

Aanvallers maakten wegwerp-GitHub-accounts aan met willekeurige gebruikersnamen en vervalste automatiseringsidentiteiten, zoals:

• build-bot
• auto-ci
• ci-bot
• pipeline-bot

Deze identiteiten deden de commits overkomen als afkomstig van routinematige automatiseringssystemen in plaats van een menselijke aanvaller.

Vervalste commit-metadata

Commit-auteursgegevens en -berichten werden zo opgesteld dat ze legitiem leken – vaak in de vorm van routineuze workflow-updates of CI-configuratiewijzigingen. Dit hielp de commits op te gaan in normale ontwikkelactiviteiten en vertraagde de argwaan.

Doelwit: zwakke branch-bescherming

De campagne richtte zich op repositories waar branch-beschermingsregels zwak of afwezig waren. Zonder verplichte pull-request-reviews of beperkingen op wie workflows kan wijzigen, konden aanvallers workflowwijzigingen rechtstreeks naar de standaardbranch van de repository pushen.

Vergiftigde GitHub Actions-workflows

Elke kwaadaardige commit voegde een GitHub Actions-workflowbestand in met een Base64-gecodeerde Bash-payload. Wanneer de CI-pijplijn werd uitgevoerd, draaide het script in de GitHub Actions-omgeving en begon het met het verzamelen van inloggegevens.

Dit ontwerp betekende dat de aanval vaak slapend bleef tot de volgende CI-run de workflow activeerde.

Wat de payload probeerde te stelen

Het Base64-gecodeerde script in de workflows was ontworpen om gevoelige gegevens uit de CI-omgeving te verzamelen en naar de infrastructuur van de aanvallers te sturen.

Gemelde doelwitten waren onder andere:

• CI/CD-omgevingsvariabelen
• Cloudprovider-inloggegevens (AWS, Google Cloud, Azure)
• SSH-privésleutels
• API-tokens en applicatiegeheimen
• GitHub Actions OIDC-tokens
• Andere configuratiegeheimen die beschikbaar zijn in de runner-omgeving

De malware verzamelde omgevingsvariabelen, systeeminformatie en geheimen die toegankelijk waren voor de CI-runner, en stuurde deze door naar een command-and-control-server.

Omdat CI-pijplijnen vaak implementatiecredentials bevatten, kan het compromitteren van een buildomgeving toegang openen tot cloudinfrastructuur, pakketregisters en productie-implementaties.

Waarom het stelen van OIDC-tokens bijzonder gevaarlijk is

Een belangrijk doel van de Megalodon-payload was GitHub Actions OIDC-tokens.

Moderne CI/CD-pijplijnen gebruiken vaak OpenID Connect (OIDC)-federatie om te authenticeren bij cloudproviders zonder langdurige credentials op te slaan. In plaats daarvan vraagt een workflow een kortdurend identiteitstoken aan dat cloudproviders omwisselen voor tijdelijke toegangscredentials.

Deze aanpak verbetert de beveiliging door statische API-sleutels of service-account-credentials te elimineren. Het introduceert echter een nieuw risico: als een aanvaller het token tijdens de pijplijnuitvoering kan stelen, kan hij of zij tijdelijk de identiteit van de CI-taak aannemen.

Omdat deze tokens worden vertrouwd door cloud-identiteitssystemen, kan een gestolen token mogelijk worden ingewisseld voor tijdelijke cloudtoegang met dezelfde rechten als de implementatiepijplijn.

Dit betekent dat een gecompromitteerde CI-workflow kan leiden tot:

• toegang tot cloudinfrastructuur
• kapen van implementatiepijplijnen
• ophalen van geheimen uit clouddiensten

Hoewel OIDC-tokens snel verlopen, kunnen de bijbehorende rechten kortetermijntoegang zeer waardevol maken voor aanvallers.

Waarom de aanval er toe deed

De Megalodon-campagne illustreert een verschuiving in supply-chain-aanvallen, weg van het wijzigen van applicatiecode en naar het compromitteren van automatiseringsinfrastructuur.

Door zich te richten op CI-workflows in plaats van broncode, kunnen aanvallers:

• automatisch credentials stelen wanneer pijplijnen worden uitgevoerd
• toegang krijgen tot implementatiesystemen en cloudomgevingen
• verborgen blijven in routinematige automatiseringswijzigingen

Omdat duizenden repositories afhankelijk zijn van CI-pijplijnen met krachtige credentials, kan een enkele workflowwijziging geheimen blootleggen in veel downstream-systemen.

Was Megalodon verbonden met het GitHub VS Code-extensielek?

Rond dezelfde tijd onthulde GitHub een afzonderlijk beveiligingsincident met een vergiftigde Visual Studio Code-extensie die op een apparaat van een medewerker was geïnstalleerd. De kwaadaardige extensie stelde aanvallers in staat om toegang te krijgen tot ongeveer 3.800 interne GitHub-repositories voordat de inbreuk werd ingedamd.

Die inbreuk was terug te voeren op een gecompromitteerde ontwikkelomgeving en betrof het stelen van credentials via een getrojaniseerde extensie die via de VS Code-marktplaats was verspreid.

Sommige beveiligingsrapportages merken overeenkomsten op in timing en tactieken tussen dat incident en andere supply-chain-aanvallen gericht op ontwikkelingshulpmiddelen. Openbaar bewijs heeft echter niet bevestigd dat de interne GitHub-inbreuk direct de Megalodon-campagne mogelijk heeft gemaakt.

Voorlopig kunnen de twee incidenten het beste worden begrepen als afzonderlijke maar gelijktijdige supply-chain-beveiligingsgebeurtenissen die het ontwikkelaar-ecosysteem treffen.

De bredere les voor CI/CD-beveiliging

Megalodon laat zien hoe snel automatisering een supply-chain-aanval kan opschalen over duizenden repositories. Door geïmiteerde bots, geautomatiseerde commits en vergiftigde CI-workflows te combineren, veranderden aanvallers routinematige build-infrastructuur in een credential-harvesting-systeem.

Het incident versterkte verschillende defensieve prioriteiten voor softwareteams:

• strikte branch-beschermingsregels
• verplichte reviews voor workflowwijzigingen
• minimale rechten voor CI-taken
• zorgvuldige monitoring van automatiseringsaccounts en workflow-updates

Nu ontwikkelingpijplijnen steeds vaker cloudimplementaties en productie-infrastructuur beheren, is de beveiliging van CI/CD-workflows een cruciaal onderdeel geworden van de verdediging van de software-supply-chain.