Megalodon-attacken: En massiv supply chain-attack mot GitHub

Operationen pågick mellan ungefär 11:36 och 17:48 UTC, vilket tyder på ett högt automatiserat system utformat för att kompromettera ett stort antal repositories snabbt innan underhållarna upptäckte ändringarna.

Hur angriparna injicerade tusentals commits så snabbt

Kampanjen byggde på automatisering och social kamouflage för att få de skadliga commitsen att se ut som normal CI-underhållning.

Falska CI-robotar och engångskonton

Angriparna skapade engångskonton på GitHub med slumpmässiga användarnamn och förfalskade automationidentiteter som:

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

Dessa identiteter fick commitsen att se ut att komma från rutinmässiga automationssystem snarare än en mänsklig angripare.

Förfalskad commit-metadata

Författardata och meddelanden i commitsen utformades för att se legitima ut – ofta liknande rutinmässiga arbetsflödesuppdateringar eller CI-konfigurationsjusteringar. Detta hjälpte commitsen att smälta in i normal utvecklingsaktivitet och försenade misstankar.

Utnyttjande av svaga branchskydd

Kampanjen fokuserade på repositories där branchskyddsregler var svaga eller saknades. Utan obligatoriska pull request-granskningar eller begränsningar för vem som kan ändra arbetsflöden kunde angriparna pusha arbetsflödesändringar direkt till repositoryts standardgren.

Förgiftade GitHub Actions-arbetsflöden

Varje skadlig commit infogade en GitHub Actions-arbetsflödesfil som innehöll en Base64-kodad Bash-nyttolast. När CI-pipelinen exekverades kördes skriptet i GitHub Actions-runtern och började skörda inloggningsuppgifter.

Denna design innebar att attacken ofta förblev vilande tills nästa CI-körning utlöste arbetsflödet.

Vad nyttolasten försökte stjäla

Det Base64-kodade skriptet som bäddats in i arbetsflödena var utformat för att samla in känslig data från CI-miljön och skicka den till angriparnas infrastruktur.

Rapporterade mål inkluderade:

• CI/CD-miljövariabler
• Molnleverantörsuppgifter (AWS, Google Cloud, Azure)
• SSH-privata nycklar
• API-token och applikationshemligheter
• GitHub Actions OIDC-token
• Andra konfigurationshemligheter exponerade i runner-miljön

Skadeprogrammet samlade in miljövariabler, systeminformation och hemligheter tillgängliga för CI-runtern innan det exfiltrerade dem till en command-and-control-server.

Eftersom CI-pipelines ofta innehåller distributionsuppgifter kan en komprometterad byggmiljö öppna vägar till molninfrastruktur, paketregister och produktionsdistributioner.

Varför stöld av OIDC-token är särskilt farlig

Ett huvudmål för Megalodons nyttolast var GitHub Actions OIDC-token.

Moderna CI/CD-pipelines använder ofta OpenID Connect (OIDC)-federation för att autentisera till molnleverantörer utan att lagra långlivade uppgifter. I stället begär ett arbetsflöde en kortlivad identitetstoken som molnleverantörer byter ut mot tillfälliga åtkomstuppgifter.

Detta tillvägagångssätt förbättrar säkerheten genom att eliminera statiska API-nycklar eller tjänstkontouppgifter. Det introducerar dock en ny risk: om en angripare kan stjäla token under pipeline-exekvering kan de tillfälligt utge sig för att vara CI-jobbets identitet.

Eftersom dessa token är betrodda av molnidentitetssystem kan en stulen token potentiellt bytas mot tillfällig molnåtkomst med samma behörigheter som distributionspipelinen.

Det innebär att ett komprometterat CI-arbetsflöde kan leda till:

• molninfrastrukturåtkomst
• kapning av distributionspipeline
• hämtning av hemligheter från molntjänster

Även om OIDC-token löper ut snabbt kan de behörigheter som är kopplade till dem fortfarande göra kortvarig åtkomst mycket värdefull för angripare.

Varför attacken var betydelsefull

Megalodon-kampanjen illustrerar en förskjutning i supply chain-attacker bort från att ändra applikationskod och mot kompromettering av automationsinfrastruktur.

Genom att rikta in sig på CI-arbetsflöden i stället för källkod kan angripare:

• stjäla uppgifter automatiskt när pipelines körs
• få tillgång till distributionssystem och molnmiljöer
• förbli dolda i rutinmässiga automationsändringar

Eftersom tusentals repositories är beroende av CI-pipelines med kraftfulla uppgifter kan en enda arbetsflödesändring exponera hemligheter över många system.

Var Megalodon kopplad till GitHub:s VS Code-tilläggsintrång?

Ungefär samtidigt avslöjade GitHub en separat säkerhetsincident som involverade ett förgiftat Visual Studio Code-tillägg installerat på en anställds enhet. Det skadliga tillägget gjorde det möjligt för angripare att få åtkomst till cirka 3 800 interna GitHub-repositories innan intrånget stoppades.

Det intrånget spårades till en komprometterad utvecklarmiljö och involverade stöld av inloggningsuppgifter via ett trojaniserat tillägg som distribuerades via VS Code-marknadsplatsen.

Vissa säkerhetsrapporter noterar likheter i timing och taktik mellan den incidenten och andra supply chain-attacker som riktar sig mot utvecklingsverktyg. Offentliga bevis har dock inte bekräftat att det interna GitHub-intrånget direkt möjliggjorde Megalodon-kampanjen.

Tills vidare är de två incidenterna bäst att förstå som separata men samtidiga supply chain-säkerhetshändelser som påverkade utvecklarekosystemet.

Den bredare läxan för CI/CD-säkerhet

Megalodon visar hur snabbt automation kan skala en supply chain-attack över tusentals repositories. Genom att kombinera imiterade robotar, automatiserade commits och förgiftade CI-arbetsflöden förvandlade angripare rutinmässig bygginfrastruktur till ett system för stöld av inloggningsuppgifter.

Incidenten underströk flera försvarsprioriteringar för mjukvaruteam:

• strikta branchskyddsregler
• obligatoriska granskningar av arbetsflödesändringar
• minimala behörigheter för CI-jobb
• noggrann övervakning av automationskonton och arbetsflödesuppdateringar

I takt med att utvecklingspipelines i allt högre grad kontrollerar molndistributioner och produktionsinfrastruktur har säkerheten för CI/CD-arbetsflöden blivit en kritisk del av supply chain-försvaret.