Megalodon-aanval treft 5.561 GitHub-repo's in zes uur
Een GitHub CI/CD supply chain-aanval genaamd Megalodon heeft een nieuw ijkpunt gezet voor geautomatiseerde, grootschalige compromittering van repositories. In een tijdsbestek van slechts zes uur pushten aanvallers 5.718 kwaadaardige code-updates over 5.561 GitHub-repositories, waarbij ze valse identiteiten gebruikten om workflowbestanden te injecteren die stilzwijgend cloudgegevens, SSH-sleutels en broncodegeheimen wegslepen. De ongeëvenaarde snelheid en omvang van de campagne wijzen op een verschuiving naar geïndustrialiseerde pipeline-aanvallen die het detectie- en reactievermogen van de meeste teams in real time overtreffen.
Hoe de Megalodon-aanval werkte: Valse identiteiten en geautomatiseerde workflow-injectie
De aanvallers achter Megalodon vertrouwden niet op zero-day-exploits of geavanceerde malware die naar eindgebruikers werd gestuurd. In plaats daarvan maakten ze misbruik van het vertrouwde karakter van GitHub's eigen CI/CD-infrastructuur. Door valse bijdrageridentiteiten aan te maken, dienden ze pull requests in of wijzigden ze rechtstreeks workflowconfiguratiebestanden — meer bepaald de YAML-bestanden die GitHub Actions gebruikt om geautomatiseerde build- en deployment-pipelines te definiëren.
Zodra een kwaadaardig workflowbestand in een repository terechtkomt, wordt het automatisch uitgevoerd telkens wanneer de pipeline wordt geactiveerd, doorgaans bij push-events of het samenvoegen van pull requests. Die uitvoering vindt plaats binnen de eigen runner-omgeving van GitHub, die vaak toegang heeft tot repository-secrets, omgevingsvariabelen en tokens die zijn gekoppeld aan cloudproviders. De Megalodon-workflows maakten gebruik van dat toegangsvenster om gegevens naar buiten te sturen, vermoedelijk naar infrastructuur onder controle van de aanvallers, voordat een repository-beheerder reden had om de wijziging te beoordelen.
Het bepalende kenmerk van de campagne is de automatisering. Bijna 5.720 afzonderlijke code-pushes uitvoeren over meer dan 5.500 repositories in zes uur is geen handmatige inspanning. Het vereist gescripte tooling die doelen kan identificeren, kan authenticeren met valse identiteiten, aannemelijk ogende workflowwijzigingen kan opstellen en deze parallel kan indienen. Dit automatiseringsniveau betekent dat het aanvalsoppervlak sneller uitbreidde dan welk menselijk monitoringteam ook kon bijhouden.
Welke gegevens werden gestolen en waarom dat belangrijk is voor ontwikkelaars
De payload van elke kwaadaardige workflow bestond uit het oogsten van inloggegevens. De doelwitten omvatten cloudprovidergegevens — meestal AWS-, GCP- en Azure-toegangssleutels opgeslagen als GitHub Secrets of waarnaar werd verwezen in workflowomgevingsvariabelen. SSH-privésleutels die worden gebruikt voor servertoegang of authenticatie tussen services vielen ook binnen het bereik, samen met eventuele platte-tekstgeheimen die in broncode of configuratiebestanden waren ingesloten.
Die typen inloggegevens brengen cascaderisico's met zich mee. Een gestolen AWS-toegangssleutel gekoppeld aan een IAM-rol met brede rechten kan een aanvaller in staat stellen binnen minuten infrastructuur op te zetten, gegevensopslag te exfiltreren of zijdelings door te dringen naar verbonden diensten. SSH-sleutels kunnen langdurige toegang bieden tot productieservers, lang nadat de oorspronkelijke inbreuk is ontdekt en de GitHub-repository is opgeschoond. De waarde van deze gegevens reikt ver buiten de repositories zelf.
Dit is geen hypothetisch risicopatroon. Eerder dit jaar heeft een CISA-aannemer AWS-sleutels en wachtwoorden in platte tekst blootgesteld op een openbare GitHub-repository, wat aantoont dat onzorgvuldig beheer van inloggegevens in ontwikkelomgevingen zelfs organisaties met een specifiek beveiligingsmandaat treft. Megalodon heeft simpelweg hetzelfde exploitpad geïndustrialiseerd dat individuele menselijke fouten al herhaaldelijk hebben aangetoond.
Het is ook de moeite waard op te merken dat tools en pipelines voor het stelen van inloggegevens zelf doelwitten zijn. De recente Bitwarden CLI supply chain-aanval toonde aan dat zelfs de tools die ontwikkelaars gebruiken om geheimen te beheren stroomopwaarts kunnen worden gecompromitteerd, wat betekent dat de vertrouwensketen verder reikt dan welke afzonderlijke repository of pipelineconfiguratie ook.
Defense-in-depth voor ontwikkelteams: secretsbeheer, versleutelde communicatie en toegangscontroles
Megalodon maakte misbruik van verschillende zwakheden die zowel in open source- als in privérepositories veelvuldig voorkomen. Het aanpakken ervan vereist een gelaagde aanpak in plaats van één enkele maatregel.
Ten eerste mogen geheimen nooit als platte tekst worden opgeslagen in workflowbestanden, omgevingsconfiguraties of broncode. De versleutelde Secrets-functie van GitHub biedt een basisniveau van beveiliging, maar die geheimen moeten ook het principe van minimale rechten volgen. Een workflow die naar een stagingomgeving deployt, heeft geen productiedatabasegegevens nodig. Door geheimen nauwkeurig te beperken, wordt de schaderadius kleiner wanneer een workflow wordt gecompromitteerd.
Ten tweede creëren branch-beschermingsregels en verplichte reviewers voor wijzigingen aan workflowbestanden een menselijk controlepunt dat geautomatiseerde aanvallen moeten omzeilen. Het vereisen van ten minste één goedgekeurde review voordat wijzigingen in .github/workflows/-bestanden worden doorgevoerd, kan de snelle geautomatiseerde injectie waarop Megalodon steunde vertragen of blokkeren.
Ten derde voorkomt het vastpinnen van externe GitHub Actions op specifieke commit-SHA's in plaats van zwevende tags een apart maar verwant aanvalsvector waarbij gecompromitteerde action-publishers stilzwijgend een tag bijwerken zodat deze naar kwaadaardige code verwijst. Dit is het mechanisme geweest bij verschillende recente GitHub Actions supply chain-incidenten.
Tot slot kunnen auditlogboeken en anomaliedetectie op workflowuitvoeringen onverwachte uitgaande netwerkverbindingen of ongebruikelijke toegangspatronen voor geheimen aan het licht brengen. De auditlog-API van GitHub en CI/CD-beveiligingstools van derden kunnen helpen deze signalen zichtbaar te maken.
Hoe u uw GitHub-repositories en CI/CD-pipelines nu kunt controleren
Als uw organisatie GitHub-repositories met actieve CI/CD-pipelines beheert, zijn een aantal directe stappen het prioriteren waard.
Controleer alle bestanden onder .github/workflows/ op recent toegevoegde of gewijzigde vermeldingen, met name die welke zijn toegevoegd door bijdragers die u niet herkent. Controleer de commitgeschiedenis specifiek voor workflowbestanden, niet alleen de standaardbranch-weergave.
Roteer alle geheimen die actief waren tijdens de aanvalsperiode of waarvan u niet met zekerheid kunt bevestigen dat ze niet zijn blootgesteld. Voor cloudgegevens: controleer de toegangslogs aan de providerzijde op ongebruikelijke API-aanroepen tijdens hetzelfde tijdsbestek.
Controleer welke repository-bijdragers en -applicaties schrijftoegang hebben. Aanvallen met valse identiteiten zijn afhankelijk van de mogelijkheid om code te pushen, dus het aanscherpen van bijdragersrechten en het verplicht stellen van reviews voor workflowwijzigingen elimineert een belangrijk toegangspunt.
Overweeg tot slot een speciale tool voor het scannen van geheimen te gebruiken die bij elke commit wordt uitgevoerd, zodat inloggegevens worden onderschept voordat ze ooit aan een repository worden doorgegeven. Verschillende open source- en commerciële opties integreren rechtstreeks met GitHub.
Wat dit voor u betekent
De Megalodon-campagne is een praktische illustratie van waarom CI/CD-pipelines een primair aanvalsoppervlak zijn geworden. Ontwikkelaars en beveiligingsteams die pipelinebeveiliging als secundair beschouwen ten opzichte van applicatiebeveiliging laten een wijd open pad naar hun meest gevoelige inloggegevens.
Begin deze week met een secrets-audit. Controleer wie uw workflowbestanden kan aanpassen, roteer inloggegevens waarvan u niet kunt verifiëren dat ze schoon zijn, en schakel branch-bescherming in op uw standaardbranch als u dat nog niet heeft gedaan. De snelheid van de Megalodon-aanval betekent dat op het moment dat een melding afgaat, de exfiltratie mogelijk al voltooid is. Preventie en nauwkeurige toegangsbeperking zijn de enige betrouwbare verdedigingen.
