Megalodon-attacken drabbar 5 561 GitHub-repon på sex timmar
En GitHub CI/CD-leveranskedjeattack vid namn Megalodon har satt ett nytt riktmärke för automatiserad, storskalig kompromittering av repon. Under ett enda sextimarsfönster tryckte angripare upp 5 718 skadliga koduppdateringar i 5 561 GitHub-repon, med hjälp av falska identiteter för att injicera workflowfiler utformade för att i det tysta tömma molnuppgifter, SSH-nycklar och källkodshemligheter. Kampanjens rena hastighet och volym signalerar ett skifte mot industrialiserade pipeline-attacker som överstiger de flesta teamens förmåga att upptäcka eller reagera i realtid.
Hur Megalodon-attacken fungerade: Falska identiteter och automatiserad workflowinjektion
Angriparna bakom Megalodon förlitade sig inte på zero-day-exploits eller sofistikerad skadlig kod levererad till slutanvändarnas maskiner. Istället utnyttjade de det betrodda i GitHubs egna CI/CD-infrastruktur. Genom att konstruera falska bidragsgivaridentiteter skickade de in pull requests eller modifierade workflow-konfigurationsfiler direkt – specifikt de YAML-filer som GitHub Actions använder för att definiera automatiserade bygg- och driftsättningspipelines.
När en skadlig workflowfil har hamnat i ett repo körs den automatiskt varje gång pipelinen triggas, typiskt sett vid push-händelser eller sammanslagningar av pull requests. Körningen sker inuti GitHubs eget körarmiljö, som ofta har åtkomst till repots hemligheter, miljövariabler och tokens kopplade till molnleverantörer. Megalodon-workflowsen utnyttjade det åtkomstfönstret för att filtrera ut data till antagligen angriparkontrollerad infrastruktur, innan någon repoansvarig hade anledning att granska ändringen.
Kampanjens utmärkande egenskap är dess automatisering. Att genomföra nästan 5 720 separata kodpushningar i mer än 5 500 repon på sex timmar är inte ett manuellt arbete. Det kräver skriptade verktyg som kan identifiera mål, autentisera med falska identiteter, skapa trovärdigt utseende workflowmodifieringar och skicka in dem parallellt. Denna nivå av automatisering innebär att attackytan expanderade snabbare än något mänskligt övervakningsteam kunde följa.
Vilka uppgifter stals och varför det spelar roll för utvecklare
Nyttolasten i varje skadlig workflow var insamling av autentiseringsuppgifter. Målen inkluderade molnleverantörers uppgifter, vanligast AWS-, GCP- och Azure-åtkomstnycklar lagrade som GitHub Secrets eller refererade inuti workflow-miljövariabler. SSH-privata nycklar som används för serveråtkomst eller autentisering mellan tjänster ingick också, liksom eventuella klartext-hemligheter inbäddade i källkod eller konfigurationsfiler.
Dessa typer av autentiseringsuppgifter medför kaskaderande risker. En stulen AWS-åtkomstnyckel kopplad till en IAM-roll med breda behörigheter kan ge en angripare möjlighet att starta upp infrastruktur, filtrera ut datalager eller röra sig lateralt in i anslutna tjänster på några minuter. SSH-nycklar kan ge ihållande åtkomst till produktionsservrar långt efter att det ursprungliga intrånget upptäckts och GitHub-repot städats upp. Värdet av dessa uppgifter sträcker sig långt bortom repona i sig.
Detta är inte ett hypotetiskt riskmönster. Tidigare i år exponerade en CISA-underleverantör AWS-nycklar och klartext-lösenord i ett publikt GitHub-repo, vilket visar att bristfällig hantering av autentiseringsuppgifter i utvecklingsmiljöer drabbar även organisationer med dedikerade säkerhetsuppdrag. Megalodon industrialiserade helt enkelt samma utnyttjandeväg som individuella mänskliga misstag redan upprepade gånger har demonstrerat.
Det är också värt att notera att verktyg och pipelines för stöld av autentiseringsuppgifter i sig är mål. Den nyliga leveranskedjeattacken mot Bitwarden CLI visade att även de verktyg utvecklare använder för att hantera hemligheter kan kompromitteras uppströms, vilket innebär att förtroenderkedjan sträcker sig bortom ett enskilt repo eller en enskild pipelinekonfiguration.
Djupgående försvar för utvecklingsteam: Hemlighetshantering, krypterad kommunikation och åtkomstkontroller
Megalodon utnyttjade flera svagheter som är vanliga i både öppen källkod och privata repon. Att hantera dem kräver ett skiktat tillvägagångssätt snarare än en enstaka kontroll.
För det första bör hemligheter aldrig lagras som klartext inuti workflowfiler, miljökonfigurationsfiler eller källkod. GitHubs krypterade Secrets-funktion ger en grundnivå, men dessa hemligheter bör också följa principen om minsta möjliga behörighet. Ett workflow som driftsätter till en staging-miljö behöver inte uppgifter till produktionsdatabasen. Att begränsa hemligheters räckvidd minskar skaderadien när ett workflow kompromitteras.
För det andra skapar regler för grenskydd och obligatoriska granskare för ändringar i workflowfiler en mänsklig kontrollpunkt som automatiserade attacker måste kringgå. Att kräva minst en godkänd granskning innan ändringar i .github/workflows/-filer kan bromsa eller blockera den typ av snabb automatiserad injektion som Megalodon förlitade sig på.
För det tredje förhindrar fastlåsning av tredjeparts GitHub Actions till specifika commit-SHA:er snarare än flytande taggar en separat men relaterad attackvektor, där komprometterade actionpublicister i det tysta uppdaterar en tagg för att peka på skadlig kod. Detta har varit mekanismen i flera nyliga GitHub Actions-leveranskedjeincidenter.
Slutligen kan granskningsloggning och anomalidetektering av workflowkörningar avslöja oväntade utgående nätverksanslutningar eller ovanliga mönster för hemlighetstillgång. GitHubs granskningslogg-API och tredjeparts CI/CD-säkerhetsverktyg kan hjälpa till att synliggöra dessa signaler.
Hur du granskar dina GitHub-repon och CI/CD-pipelines nu
Om din organisation underhåller GitHub-repon med aktiva CI/CD-pipelines är ett par omedelbara åtgärder värda att prioritera.
Granska alla filer under .github/workflows/ efter nyligen tillagda eller modifierade poster, särskilt sådana som lagts till av bidragsgivare du inte känner igen. Kontrollera commit-historiken för workflowfiler specifikt, inte bara standardgrensvisningen.
Rotera alla hemligheter som var aktiva under attackperioden eller som du inte med säkerhet kan bekräfta inte har exponerats. För molnuppgifter, granska åtkomstloggar hos leverantören för ovanliga API-anrop under samma tidsfönster.
Granska vilka bidragsgivare och applikationer till repot som har skrivrättigheter. Falsk-identitetsattacker är beroende av möjligheten att pusha kod, så att begränsa bidragsgivarbehörigheter och aktivera obligatoriska granskningar för workflowändringar tar bort en viktig ingångspunkt.
Överväg slutligen att använda ett dedikerat verktyg för hemlighetsskanning som körs vid varje commit och fångar upp autentiseringsuppgifter innan de någonsin committats till ett repo. Flera alternativ med öppen källkod och kommersiella alternativ integreras direkt med GitHub.
Vad detta innebär för dig
Megalodon-kampanjen är en praktisk illustration av varför CI/CD-pipelines har blivit en primär attackyta. Utvecklare och säkerhetsteam som betraktar pipeline-säkerhet som sekundär jämfört med applikationssäkerhet lämnar en bred öppen väg till sina mest känsliga autentiseringsuppgifter.
Börja med en hemlighetsrevision den här veckan. Granska vem som kan ändra dina workflowfiler, rotera uppgifter du inte kan verifiera som rena, och aktivera grenskydd på din standardgren om du inte redan gjort det. Hastigheten på Megalodon-attacken innebär att när en avisering utlöses kan exfiltreringen redan vara klar. Förebyggande och begränsning av åtkomst är de enda tillförlitliga försvaren.
