Slik fungerte det massive GitHub-angrepet «Megalodon»

Operasjonen fant sted mellom omtrent 11:36 og 17:48 UTC, noe som tyder på et høyt automatisert system designet for å kompromittere et stort antall repositorier raskt før vedlikeholderne oppdaget endringene.

Slik injiserte angriperne tusenvis av commits så raskt

Kampanjen stolte på automatisering og sosial kamuflasje for å få ondsinnede commits til å se ut som normalt CI-vedlikehold.

Falske CI-boter og engangskontoer

Angriperne opprettet engangs-GitHub-kontoer med tilfeldige brukernavn og forfalskede automasjonsidentiteter som:

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

Disse identitetene fikk commitene til å se ut som om de kom fra rutinemessige automasjonssystemer snarere enn et menneskelig angrep.

Forfalsket commit-metadata

Forfatterdata og meldinger for commits ble utformet for å se legitime ut – ofte likt rutinemessige arbeidsflytoppdateringer eller CI-konfigurasjonsjusteringer. Dette hjalp commitene med å gli inn i normal utviklingsaktivitet og forsinket mistanke.

Målretting mot svak branch-beskyttelse

Kampanjen fokuserte på repositorier der branch-beskyttelsesregler var svake eller fraværende. Uten obligatoriske pull request-godkjenninger eller begrensninger på hvem som kan endre arbeidsflyter, kunne angripere skyve arbeidsflytendringer direkte til depotets standardgren.

Forgiftede GitHub Actions-arbeidsflyter

Hver ondsinnet commit satte inn en GitHub Actions-arbeidsflytfil som inneholdt en Base64-kodet Bash-nyttelast. Når CI-pipelinen kjørte, utførte skriptet seg i GitHub Actions-runneren og begynte å høste legitimasjon.

Denne utformingen betydde at angrepet ofte forble sovende til neste CI-kjøring utløste arbeidsflyten.

Hva nyttelasten forsøkte å stjele

Base64-skriptet innebygd i arbeidsflytene ble designet for å samle inn sensitive data fra CI-miljøet og sende dem til angriperstyrt infrastruktur.

Rapporterte mål inkluderte:

• CI/CD-miljøvariabler
• Skyleverandør-legitimasjon (AWS, Google Cloud, Azure)
• SSH-private nøkler
• API-tokens og applikasjonshemmeligheter
• GitHub Actions OIDC-tokens
• Andre konfigurasjonshemmeligheter eksponert i runner-miljøet

Skadevaren samlet inn miljøvariabler, systeminformasjon og hemmeligheter tilgjengelig for CI-runneren før den eksfiltrerte dem til en kommando-og-kontroll-server.

Fordi CI-pipelines ofte inneholder distribusjonslegitimasjon, kan det å kompromittere et byggemiljø åpne veier til skysinfrastruktur, pakkeregistre og produksjonsdistribusjoner.

Hvorfor stjeling av OIDC-tokens er spesielt farlig

Et hovedmål for Megalodon-nyttelasten var GitHub Actions OIDC-tokens.

Moderne CI/CD-pipelines bruker ofte OpenID Connect (OIDC)-føderasjon for å autentisere seg til skyleverandører uten å lagre langvarig legitimasjon. I stedet ber en arbeidsflyt om et kortvarig identitetstoken som skyleverandører bytter ut mot midlertidige tilgangslegitimasjoner.

Denne tilnærmingen forbedrer sikkerheten ved å eliminere statiske API-nøkler eller tjenestekonto-legitimasjon. Imidlertid introduserer den en ny risiko: Hvis en angriper kan stjele tokenet under pipeline-kjøring, kan de midlertidig etterligne CI-jobbens identitet.

Fordi disse tokenene er betrodd av skyidentitetssystemer, kan et stjålet token potensielt byttes mot midlertidig skytilgang med samme tillatelser som er gitt til distribusjonspipelinen.

Det betyr at en kompromittert CI-arbeidsflyt kan føre til:

• tilgang til skysinfrastruktur
• kapring av distribusjonspipeline
• henting av hemmeligheter fra skytjenester

Selv om OIDC-tokens utløper raskt, kan tillatelsene knyttet til dem fortsatt gjøre kortvarig tilgang svært verdifull for angripere.

Hvorfor angrepet betydde noe

Megalodon-kampanjen illustrerer et skifte i forsyningskjedeangrep bort fra å endre applikasjonskode og mot kompromittering av automasjonsinfrastruktur.

Ved å målrette CI-arbeidsflyter i stedet for kildekode, kan angripere:

• stjele legitimasjon automatisk når pipelines kjører
• få tilgang til distribusjonssystemer og skymiljøer
• forbli skjult innenfor rutinemessige automasjonsendringer

Fordi tusenvis av repositorier er avhengige av CI-pipelines med kraftig legitimasjon, kan en enkelt arbeidsflytendring eksponere hemmeligheter på tvers av mange nedstrømssystemer.

Var Megalodon forbundet med GitHub VS Code-utvidelsesbruddet?

Omtrent samtidig avslørte GitHub et separat sikkerhetshendelse som involverte en forgiftet Visual Studio Code-utvidelse installert på en ansatts enhet. Den ondsinnede utvidelsen gjorde det mulig for angripere å få tilgang til omtrent 3.800 interne GitHub-repositorier før kompromitteringen ble inneholdt.

Det bruddet ble sporet til et kompromittert utviklermiljø og involverte høsting av legitimasjon gjennom en trojanisert utvidelse distribuert via VS Code-markedet.

Noen sikkerhetsrapporter merker seg likheter i timing og taktikk mellom den hendelsen og andre forsyningskjedeangrep rettet mot utviklerverktøy. Imidlertid har offentlige bevis ikke bekreftet at det interne GitHub-bruddet direkte muliggjorde Megalodon-kampanjen.

Foreløpig er de to hendelsene best forstått som separate men samtidige forsyningskjedesikkerhetshendelser som påvirker utviklerøkosystemet.

Den bredere lærdommen for CI/CD-sikkerhet

Megalodon demonstrerer hvor raskt automatisering kan skalere et forsyningskjedeangrep på tvers av tusenvis av repositorier. Ved å kombinere etterlignede boter, automatiserte commits og forgiftede CI-arbeidsflyter, forvandlet angripere rutinemessig byggeinfrastruktur til et system for høsting av legitimasjon.

Hendelsen forsterket flere defensive prioriteringer for programvaretbyggeteam:

• strenge branch-beskyttelsesregler
• obligatoriske vurderinger for arbeidsflytendringer
• minimale tillatelser for CI-jobber
• nøye overvåking av automasjonskontoer og arbeidsflytoppdateringer

Ettersom utviklingspipelines i økende grad kontrollerer skydistribusjoner og produksjonsinfrastruktur, har sikkerheten til CI/CD-arbeidsflyter blitt en kritisk del av programvareforsyningskjedeforsvaret.