Megalodon-angrebet: 5.700 ondsindede commits ramte 5.500 GitHub-repositorier på seks timer

Operationen fandt sted mellem cirka 11:36 og 17:48 UTC, hvilket tyder på et stærkt automatiseret system designet til hurtigt at kompromittere et stort antal repositorier, før vedligeholdere opdagede ændringerne.

Sådan injicerede angriberne tusindvis af commits så hurtigt

Kampagnen var afhængig af automatisering og social camouflage for at få ondsindede commits til at ligne normal CI-vedligeholdelse.

Falske CI-bots og engangskonti

Angriberne oprettede engangs-GitHub-konti med tilfældige brugernavne og forfalskede automatiseringsidentiteter såsom:

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

Disse identiteter fik commits til at se ud, som om de kom fra rutinemæssige automationssystemer snarere end et menneskeligt angreb.

Forfalsket commit-metadata

Forfatterdata og beskeder for commits blev konstrueret til at se legitime ud – ofte lignede de rutinemæssige workflow-opdateringer eller CI-konfigurationsjusteringer. Dette hjalp med at få commits til at blande sig i almindelig udviklingsaktivitet og forsinkede mistanke.

Målretning af svage branch-beskyttelser

Kampagnen fokuserede på repositorier, hvor branch-beskyttelsesregler var svage eller fraværende. Uden obligatoriske pull-request-gennemgange eller begrænsninger på, hvem der kan ændre workflows, kunne angribere skubbe workflow-ændringer direkte til repositoryets standardgren.

Forgiftede GitHub Actions-workflows

Hver ondsindet commit indsatte en GitHub Actions-workflow-fil med en Base64-kodet Bash-nyttelast. Når CI-pipelinen kørte, udførte scriptet inde i GitHub Actions-runneren og begyndte at høste legitimationsoplysninger.

Dette design betød, at angrebet ofte forblev sovende, indtil den næste CI-kørsel udløste workflowet.

Hvad nyttelasten forsøgte at stjæle

Det Base64-kodede script, der var indlejret i workflows, var designet til at indsamle følsomme data fra CI-miljøet og sende dem til angriberkontrolleret infrastruktur.

Rapporterede mål omfattede:

• CI/CD-miljøvariabler
• Cloud-udbyder-legitimationsoplysninger (AWS, Google Cloud, Azure)
• SSH-private nøgler
• API-tokens og applikationshemmeligheder
• GitHub Actions OIDC-tokens
• Andre konfigurationshemmeligheder, der er eksponeret i runner-miljøet

Malwaren indsamlede miljøvariabler, systeminformation og hemmeligheder, der er tilgængelige for CI-runneren, før den eksfiltrerede dem til en kommando-og-kontrol-server.

Fordi CI-pipelines ofte indeholder implementeringslegitimationsoplysninger, kan kompromittering af et byggemiljø åbne veje til cloud-infrastruktur, pakkeregistre og produktionsimplementeringer.

Hvorfor tyveri af OIDC-tokens er særligt farligt

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

Moderne CI/CD-pipelines bruger ofte OpenID Connect (OIDC) sammenkædning til at godkende til cloud-udbydere uden at gemme langlivede legitimationsoplysninger. I stedet anmoder et workflow om et kortvarigt identitetstoken, som cloud-udbydere bytter til midlertidige adgangslegitimationsoplysninger.

Denne tilgang forbedrer sikkerheden ved at eliminere statiske API-nøgler eller servicekonto-legitimationsoplysninger. Det introducerer imidlertid en ny risiko: Hvis en angriber kan stjæle tokenet under pipeline-udførelse, kan de midlertidigt efterligne CI-jobets identitet.

Fordi disse tokens er betroet af cloud-identitetssystemer, kan et stjålet token potentielt byttes til midlertidig cloud-adgang med de samme tilladelser, som implementeringspipelinen har.

Det betyder, at et kompromitteret CI-workflow kan føre til:

• cloud-infrastrukturadgang
• kapring af implementeringspipeline
• hentning af hemmeligheder fra cloud-tjenester

Selvom OIDC-tokens udløber hurtigt, kan de tilladelser, der er knyttet til dem, stadig gøre kortvarig adgang meget værdifuld for angribere.

Hvorfor angrebet var vigtigt

Megalodon-kampagnen illustrerer et skift i supply-chain-angreb væk fra at ændre applikationskode og i retning af kompromittering af automationsinfrastruktur.

Ved at målrette CI-workflows i stedet for kildekode kan angribere:

• stjæle legitimationsoplysninger automatisk, når pipelines kører
• få adgang til implementeringssystemer og cloud-miljøer
• forblive skjult inde i rutinemæssige automationsændringer

Fordi tusindvis af repositorier er afhængige af CI-pipelines med kraftfulde legitimationsoplysninger, kan en enkelt workflow-ændring eksponere hemmeligheder på tværs af mange downstream-systemer.

Var Megalodon forbundet med GitHub VS Code-udvidelsesindbruddet?

Omkring samme tidspunkt afslørede GitHub en separat sikkerhedshændelse, der involverede en forgiftet Visual Studio Code-udvidelse installeret på en medarbejders enhed. Den ondsindede udvidelse gjorde det muligt for angribere at få adgang til cirka 3.800 interne GitHub-repositorier, før kompromitteringen blev inddæmmet.

Det indbrud blev sporet til et kompromitteret udviklermiljø og involverede høst af legitimationsoplysninger gennem en trojaniseret udvidelse distribueret via VS Code-markedspladsen.

Nogle sikkerhedsrapporter noterer ligheder i timing og taktik mellem denne hændelse og andre supply-chain-angreb, der målretter udviklingsværktøjer. Offentlige beviser har dog ikke bekræftet, at det interne GitHub-indbrud direkte muliggjorde Megalodon-kampagnen.

For nu forstås de to hændelser bedst som separate, men samtidige supply-chain-sikkerhedshændelser, der påvirker udvikler-økosystemet.

Den bredere lektion for CI/CD-sikkerhed

Megalodon demonstrerer, hvor hurtigt automatisering kan skalere et supply-chain-angreb på tværs af tusindvis af repositorier. Ved at kombinere efterlignede bots, automatiserede commits og forgiftede CI-workflows forvandlede angribere rutinemæssig bygningsinfrastruktur til et legitimationsopsamlingssystem.

Hændelsen forstærkede flere defensive prioriteter for softwareteams:

• strenge branch-beskyttelsesregler
• obligatoriske gennemgange for workflow-ændringer
• minimale tilladelser for CI-job
• omhyggelig overvågning af automationskonti og workflow-opdateringer

Efterhånden som udviklingspipelines i stigende grad kontrollerer cloud-implementeringer og produktionsinfrastruktur, er sikkerheden af CI/CD-workflows blevet en kritisk del af software-supply-chain-forsvaret.