Megalodon-angrep rammer 5 561 GitHub-repoer på seks timer
Et GitHub CI/CD-forsyningskjedeangrep kalt Megalodon har satt en ny standard for automatisert, storskala kompromittering av repositorier. I løpet av et enkelt seks-timers vindu presset angriperne 5 718 ondsinnede kodeoppdateringer på tvers av 5 561 GitHub-repositorier, og brukte falske identiteter til å injisere arbeidsflytfiler designet for å stille og rolig tømme skyakkreditiver, SSH-nøkler og kildekodehemmeligheter. Den rene hastigheten og omfanget av kampanjen signaliserer et skifte mot industrialiserte pipeline-angrep som overgår de fleste teamers evne til å oppdage eller reagere i sanntid.
Slik fungerte Megalodon-angrepet: Falske identiteter og automatisert arbeidsflytinjeksjon
Angriperne bak Megalodon baserte seg ikke på zero-day-utnyttelser eller sofistikert skadevare levert til sluttbrukermaskiner. I stedet utnyttet de den betrodde naturen til GitHubs egen CI/CD-infrastruktur. Ved å konstruere falske bidragsyteridentiteter sendte de inn pull-forespørsler eller modifiserte arbeidsflyt-konfigurasjonsfiler direkte – nærmere bestemt YAML-filene som GitHub Actions bruker til å definere automatiserte bygge- og distribusjonspipelines.
Når en ondsinnet arbeidsflytfil havner i et repositorium, kjøres den automatisk hver gang pipelinen utløses – typisk ved push-hendelser eller sammenslåing av pull-forespørsler. Denne kjøringen skjer inne i GitHubs eget kjøremiljø, som ofte har tilgang til repositoriehemmeligheter, miljøvariabler og tokener knyttet til skyleverandører. Megalodon-arbeidsflytene brukte dette tilgangsvinduet til å eksfiltrere data utad, trolig til infrastruktur kontrollert av angriperne, før noen repositorievedlikeholder hadde grunn til å gjennomgå endringen.
Kampanjens definerende kjennetegn er automatiseringen. Å utføre nærmere 5 720 separate kode-pushes på tvers av mer enn 5 500 repositorier på seks timer er ikke en manuell innsats. Det krever skriptbaserte verktøy som kan identifisere mål, autentisere med falske identiteter, lage tilsynelatende plausible arbeidsflytendringer og sende dem inn parallelt. Dette automatiseringsnivået betyr at angrepsflaten vokste raskere enn noe menneskelig overvåkingsteam kunne følge med på.
Hvilke akkreditiver ble stjålet og hvorfor det betyr noe for utviklere
Nyttelasten i hver ondsinnet arbeidsflyt var innhøsting av akkreditiver. Målene inkluderte akkreditiver fra skyleverandører – oftest AWS-, GCP- og Azure-tilgangsnøkler lagret som GitHub Secrets eller referert til inne i arbeidsflytmiljøvariabler. Private SSH-nøkler brukt for servertilgang eller tjeneste-til-tjeneste-autentisering var også i faresonen, i tillegg til eventuelle klarteksthemmeligheter innebygd i kildekode eller konfigurasjonsfiler.
Disse akkreditivtypene medfører kaskaderende risiko. En stjålet AWS-tilgangsnøkkel knyttet til en IAM-rolle med brede tillatelser kan gjøre det mulig for en angriper å starte opp infrastruktur, eksfiltrere datalager eller bevege seg sidelengs inn i tilkoblede tjenester i løpet av minutter. SSH-nøkler kan gi vedvarende tilgang til produksjonsservere lenge etter at det opprinnelige bruddet er oppdaget og GitHub-repositoriet er ryddet opp. Verdien av disse dataene strekker seg langt utover selve repositoriene.
Dette er ikke et hypotetisk risikamønster. Tidligere i år avslørte en CISA-kontraktør AWS-nøkler og klartekstpassord i et offentlig GitHub-repositorium, noe som viste at feil håndtering av akkreditiver i utviklingsmiljøer påvirker selv organisasjoner med dedikerte sikkerhetsmandat. Megalodon industrialiserte rett og slett den samme utnyttelsesveien som individuelle menneskelige feil allerede har demonstrert gjentatte ganger.
Det er også verdt å merke seg at verktøy og pipelines for tyveri av akkreditiver selv er mål. Det nylige Bitwarden CLI-forsyningskjedeangrepet viste at selv verktøyene utviklere bruker til å administrere hemmeligheter kan kompromitteres oppstrøms, noe som betyr at tillitskjeden strekker seg utover ethvert enkelt repositorium eller pipeline-konfigurasjon.
Forsvar i dybden for utviklingsteam: Hemmelighetsadministrasjon, kryptert kommunikasjon og tilgangskontroller
Megalodon utnyttet flere svakheter som er vanlige på tvers av både åpen kildekode- og private repositorier. Å håndtere dem krever en lagdelt tilnærming snarere enn én enkelt kontroll.
For det første bør hemmeligheter aldri lagres som klartekst inne i arbeidsflytfiler, miljøkonfigurasjonsfiler eller kildekode. GitHubs krypterte Secrets-funksjon gir et grunnlag, men disse hemmelighetene bør også følge prinsippet om minste privilegium. En arbeidsflyt som distribuerer til et testmiljø trenger ikke produksjonsdatabaseakkreditiver. Tett scoping av hemmeligheter begrenser skadeomfanget når en arbeidsflyt kompromitteres.
For det andre skaper grenbeskyttelsesregler og påkrevde gjennomgåere for endringer i arbeidsflytfiler et menneskelig kontrollpunkt som automatiserte angrep må omgå. Å kreve minst én godkjent gjennomgang før noen endring av .github/workflows/-filer kan bremse eller blokkere den typen raske automatisert injeksjon som Megalodon baserte seg på.
For det tredje forhindrer fastlåsing av tredjeparts GitHub Actions til spesifikke commit-SHA-er i stedet for flytende tagger en separat, men beslektet angrepsvektor, der kompromitterte action-utgivere stille og rolig oppdaterer en tagg til å peke på ondsinnet kode. Dette har vært mekanismen i flere nylige GitHub Actions-forsyningskjedehendelser.
Til slutt kan revisjonslogging og anomalideteksjon på arbeidsflyt-kjøringer avdekke uventede utgående nettverksforbindelser eller uvanlige mønstre for tilgang til hemmeligheter. GitHubs revisjonslogg-API og tredjeparts CI/CD-sikkerhetsverktøy kan hjelpe med å avdekke disse signalene.
Slik reviderer du GitHub-repositoriene og CI/CD-pipelinene dine nå
Hvis organisasjonen din vedlikeholder GitHub-repositorier med aktive CI/CD-pipelines, er det noen umiddelbare steg som er verdt å prioritere.
Gjennomgå alle filer under .github/workflows/ for nylig lagt til eller modifiserte oppføringer, særlig de som er lagt til av bidragsytere du ikke kjenner igjen. Sjekk commit-historikken for arbeidsflytfiler spesifikt, ikke bare standardgrensysnvisningen.
Rull over alle hemmeligheter som var aktive i løpet av angrepsperioden, eller som du ikke med sikkerhet kan bekrefte at ikke ble eksponert. For skyakkreditiver bør du gjennomgå leverandørsidens tilgangslogger for uvanlige API-kall i samme tidsvindu.
Revider hvilke repositoriebidragsytere og applikasjoner som har skrivetilgang. Angrep med falske identiteter er avhengige av muligheten til å pushe kode, så å stramme inn bidragsytertillatelser og aktivere påkrevde gjennomganger for arbeidsflytendringer fjerner et sentralt inngangspunkt.
Vurder til slutt å ta i bruk et dedikert verktøy for skanning av hemmeligheter som kjøres på hver commit, og fanger opp akkreditiver før de noen gang committes til et repositorium. Flere åpen kildekode- og kommersielle alternativer integreres direkte med GitHub.
Hva dette betyr for deg
Megalodon-kampanjen er en praktisk illustrasjon på hvorfor CI/CD-pipelines har blitt en primær angrepsflate. Utviklere og sikkerhetsteam som behandler pipeline-sikkerhet som sekundær i forhold til applikasjonssikkerhet, etterlater en vid åpen vei til sine mest sensitive akkreditiver.
Start med en hemmelighetsrevisjon denne uken. Gjennomgå hvem som kan endre arbeidsflytfilene dine, rull over akkreditiver du ikke kan verifisere som rene, og aktiver grenbeskyttelse på standardgrenen din hvis du ikke allerede har gjort det. Hastigheten til Megalodon-angrepet betyr at når en varsling utløses, kan eksfiltrasjonen allerede være fullført. Forebygging og scoping av tilgang er de eneste pålitelige forsvarene.
