Megalodon-angreb rammer 5.561 GitHub-repos på seks timer
Et GitHub CI/CD-forsyningskædeangreb ved navn Megalodon har sat en ny standard for automatiseret, storskaleret kompromittering af repositories. I et enkelt seks-timers vindue skubbede angriberne 5.718 ondsindede kodeopdateringer ud på tværs af 5.561 GitHub-repositories, idet de benyttede falske identiteter til at injicere workflow-filer designet til lydløst at tappe cloudlegitimationsoplysninger, SSH-nøgler og kildekodehemmeligheder. Kampagnens rene hastighed og omfang signalerer et skift mod industrialiserede pipeline-angreb, der overgår de fleste teams evne til at opdage eller reagere i realtid.
Sådan fungerede Megalodon-angrebet: Falske identiteter og automatiseret workflow-injektion
Angriberne bag Megalodon stolede ikke på zero-day-exploits eller sofistikeret malware leveret til slutbrugermaskiner. I stedet udnyttede de den betroede karakter af GitHubs CI/CD-infrastruktur. Ved at konstruere falske bidragyder-identiteter indsendte de pull requests eller modificerede direkte workflow-konfigurationsfiler – nærmere bestemt de YAML-filer, som GitHub Actions bruger til at definere automatiserede bygge- og implementeringspipelines.
Når en ondsindet workflow-fil lander i et repository, udføres den automatisk, hver gang pipelinen udløses – typisk ved push-hændelser eller sammenflætning af pull requests. Denne udførelse sker inde i GitHubs eget runner-miljø, som ofte har adgang til repository-hemmeligheder, miljøvariabler og tokens knyttet til cloududbydere. Megalodon-workflowsene brugte dette adgangsvindue til at eksfiltrere data udad – sandsynligvis til angriberkontrolleret infrastruktur – inden nogen repository-vedligeholder havde grund til at gennemgå ændringen.
Kampagnens definerende karakteristik er dens automatisering. At udføre næsten 5.720 distinkte kode-pushes på tværs af mere end 5.500 repositories på seks timer er ikke en manuel indsats. Det kræver scriptede værktøjer, der kan identificere mål, autentificere med falske identiteter, udarbejde troværdigt udseende workflow-modifikationer og indsende dem parallelt. Dette automatiseringsniveau betyder, at angrebsfladen udvidede sig hurtigere, end noget menneskeligt overvågningsteam kunne følge med.
Hvilke legitimationsoplysninger blev stjålet, og hvorfor det betyder noget for udviklere
Nyttelasten i hvert ondsindet workflow var indsamling af legitimationsoplysninger. Målene omfattede cloududbyderoplysninger – oftest AWS-, GCP- og Azure-adgangsnøgler gemt som GitHub Secrets eller refereret inde i workflow-miljøvariabler. SSH-privatnøgler brugt til serveradgang eller tjeneste-til-tjeneste-autentificering var ligeledes i søgelyset, sammen med eventuelle klarteksthemmeligheder indlejret i kildekode eller konfigurationsfiler.
Disse legitimationstyper medfører kaskaderisici. En stjålet AWS-adgangsnøgle knyttet til en IAM-rolle med brede tilladelser kan give en angriber mulighed for at oprette infrastruktur, eksfiltrere datalagrene eller bevæge sig lateralt ind i forbundne tjenester på få minutter. SSH-nøgler kan give vedvarende adgang til produktionsservere længe efter, at det oprindelige brud er opdaget, og GitHub-repositoryet er ryddet op. Værdien af disse data rækker langt ud over selve repositories.
Dette er ikke et hypotetisk risikomønster. Tidligere på året udsatte en CISA-kontrahent AWS-nøgler og klartekst-adgangskoder på et offentligt GitHub-repository, hvilket demonstrerede, at dårlig legitimationshåndtering i udviklingsmiljøer påvirker selv organisationer med dedikerede sikkerhedsmandater. Megalodon industrialiserede blot den samme udnyttelsessti, som individuelle menneskelige fejl allerede gentagne gange har demonstreret.
Det er også værd at bemærke, at værktøjer og pipelines til tyveri af legitimationsoplysninger selv er mål. Det nylige Bitwarden CLI-forsyningskædeangreb viste, at selv de værktøjer, udviklere bruger til at administrere hemmeligheder, kan kompromitteres opstrøms – hvilket betyder, at tillids kæden strækker sig ud over ethvert enkelt repository eller pipeline-konfiguration.
Dybdegående forsvar for udviklingsteams: Hemmeligholdsstyring, krypteret kommunikation og adgangskontrol
Megalodon udnyttede flere svagheder, der er almindelige på tværs af både open source- og private repositories. At adressere dem kræver en lagdelt tilgang frem for en enkelt kontrol.
For det første bør hemmeligheder aldrig gemmes som klartekst inde i workflow-filer, miljøkonfigurationsfiler eller kildekode. GitHubs krypterede Secrets-funktion giver et grundlæggende niveau, men disse hemmeligheder bør også følge princippet om mindst mulige privilegier. Et workflow, der implementerer til et staging-miljø, har ikke brug for produktionsdatabaseoplysninger. Stram afgrænsning af hemmeligheder begrænser skadevirkningernes omfang, når et workflow kompromitteres.
For det andet skaber branch-beskyttelsesregler og påkrævede gennemgangspersoner for workflow-filändringer et menneskeligt kontrolpunkt, som automatiserede angreb skal omgå. At kræve mindst én godkendt gennemgang, inden nogen ændring af .github/workflows/-filer kan bremse eller blokere den slags hurtige automatiserede injektion, som Megalodon baserede sig på.
For det tredje forhindrer fastlåsning af tredjeparts GitHub Actions til specifikke commit-SHA'er frem for flydende tags en separat, men beslægtet angrebsvektor, hvor kompromitterede action-udgivere lydløst opdaterer et tag til at pege på ondsindet kode. Dette har været mekanismen bag adskillige nylige GitHub Actions-forsyningskædehændelser.
Endelig kan revisionslogning og anomalidetektion på workflow-kørsler afsløre uventede udgående netværksforbindelser eller usædvanlige mønstre for adgang til hemmeligheder. GitHubs API til revisionslog og tredjeparts CI/CD-sikkerhedsværktøjer kan hjælpe med at synliggøre disse signaler.
Sådan reviderer du dine GitHub-repositories og CI/CD-pipelines nu
Hvis din organisation vedligeholder GitHub-repositories med aktive CI/CD-pipelines, er det værd at prioritere et par umiddelbare trin.
Gennemgå alle filer under .github/workflows/ for nyligt tilføjede eller ændrede poster – særligt dem tilføjet af bidragydere, du ikke genkender. Tjek commit-historikken specifikt for workflow-filer og ikke blot standardgrens-visningen.
Roter eventuelle hemmeligheder, der var aktive i løbet af angrebet, eller som du ikke med sikkerhed kan bekræfte ikke har været eksponeret. For cloudoplysninger bør du gennemgå udbyderens adgangslogge for usædvanlige API-kald i det samme tidsvindue.
Revider hvilke repository-bidragydere og applikationer der har skriveadgang. Angreb med falske identiteter afhænger af evnen til at skubbe kode, så stramning af bidragydertilladelser og aktivering af påkrævede gennemgange for workflow-ændringer fjerner et centralt indgangspunkt.
Overvej endelig at indføre et dedikeret værktøj til scanning af hemmeligheder, der kører ved hvert commit og opfanger legitimationsoplysninger, inden de nogensinde commites til et repository. Adskillige open source- og kommercielle muligheder integrerer direkte med GitHub.
Hvad dette betyder for dig
Megalodon-kampagnen er en praktisk illustration af, hvorfor CI/CD-pipelines er blevet en primær angrebsflade. Udviklere og sikkerhedsteams, der behandler pipeline-sikkerhed som sekundær i forhold til applikationssikkerhed, efterlader en bred åben vej til deres mest følsomme legitimationsoplysninger.
Start med en hemmeligheds-revision denne uge. Gennemgå hvem der kan ændre dine workflow-filer, roter legitimationsoplysninger, du ikke kan verificere som rene, og aktiver branch-beskyttelse på din standardgren, hvis du ikke allerede har gjort det. Hastigheden af Megalodon-angrebet betyder, at eksfiltrering muligvis allerede er fuldført, inden en alarm udløses. Forebyggelse og afgrænsning af adgang er de eneste pålidelige forsvar.
