Útok Megalodon zasáhl 5 561 GitHub repozitářů za šest hodin
Útok na dodavatelský řetězec CI/CD na GitHubu pojmenovaný Megalodon stanovil nový standard pro automatizované, rozsáhlé kompromitování repozitářů. V jediném šestihodinovém okně útočníci provedli 5 718 škodlivých aktualizací kódu napříč 5 561 GitHub repozitáři, přičemž k vložení souborů workflow navržených k tichému odcizení cloudových přihlašovacích údajů, SSH klíčů a zdrojových tajemství použili falešné identity. Samotná rychlost a rozsah kampaně signalizují posun směrem k průmyslovým útokům na pipeline, které předčí schopnost většiny týmů detekovat je nebo na ně v reálném čase reagovat.
Jak útok Megalodon fungoval: Falešné identity a automatizované vkládání workflow
Útočníci stojící za Megalodonem nespoléhali na zero-day exploity ani na sofistikovaný malware doručovaný na zařízení koncových uživatelů. Místo toho zneužili důvěryhodnou povahu samotné CI/CD infrastruktury GitHubu. Vytvořením falešných identit přispěvatelů odesílali pull requesty nebo přímo upravovali konfigurační soubory workflow — konkrétně YAML soubory, které GitHub Actions používá k definici automatizovaných build a deployment pipeline.
Jakmile se škodlivý soubor workflow ocitne v repozitáři, spustí se automaticky pokaždé, když se pipeline aktivuje — typicky při push událostech nebo při slučování pull requestů. Toto spuštění probíhá uvnitř vlastního runner prostředí GitHubu, které má často přístup k tajemstvím repozitáře, proměnným prostředí a tokenům určeným pro cloudové poskytovatele. Workflow Megalodon využily toto přístupové okno k exfiltraci dat ven — pravděpodobně na infrastrukturu kontrolovanou útočníky — dříve, než měl jakýkoli správce repozitáře důvod změnu přezkoumat.
Definujícím rysem kampaně je její automatizace. Provedení téměř 5 720 odlišných push operací kódu napříč více než 5 500 repozitáři za šest hodin není ruční práce. Vyžaduje to skriptované nástroje schopné identifikovat cíle, ověřovat se pomocí falešných identit, vytvářet věrohodně vypadající úpravy workflow a odesílat je paralelně. Tato míra automatizace znamená, že útočná plocha se rozrůstala rychleji, než mohl jakýkoli lidský monitorovací tým sledovat.
Jaké přihlašovací údaje byly odcizeny a proč to pro vývojáře záleží
Obsah každého škodlivého workflow byl zaměřen na sběr přihlašovacích údajů. Cíle zahrnovaly přihlašovací údaje cloudových poskytovatelů — nejčastěji přístupové klíče AWS, GCP a Azure uložené jako GitHub Secrets nebo odkazované uvnitř proměnných prostředí workflow. V hledáčku byly rovněž SSH soukromé klíče používané pro přístup k serverům nebo meziservisní autentizaci, spolu s jakýmikoli tajemstvími v prostém textu vloženými ve zdrojovém kódu nebo konfiguračních souborech.
Tyto typy přihlašovacích údajů nesou kaskádové riziko. Odcizený přístupový klíč AWS vázaný na IAM roli se širokými oprávněními může útočníkovi umožnit spustit infrastrukturu, exfiltrovat datová úložiště nebo se laterálně přesunout do propojených služeb během minut. SSH klíče mohou poskytovat trvalý přístup k produkčním serverům dlouho poté, co je původní narušení detekováno a GitHub repozitář vyčištěn. Hodnota těchto dat přesahuje daleko za samotné repozitáře.
Toto není hypotetický vzorec rizika. Dříve letos dodavatel CISA vystavil AWS klíče a hesla v prostém textu na veřejném GitHub repozitáři, což ukázalo, že špatné zacházení s přihlašovacími údaji ve vývojových prostředích se týká i organizací s vyhrazeným bezpečnostním mandátem. Megalodon jednoduše zprůmyslnil stejnou cestu exploitu, kterou individuální lidské chyby již opakovaně prokázaly.
Stojí také za zmínku, že nástroje a pipeline pro krádež přihlašovacích údajů jsou samy o sobě cíli. Nedávný útok na dodavatelský řetězec Bitwarden CLI ukázal, že i nástroje, které vývojáři používají ke správě tajemství, mohou být kompromitovány na vyšší úrovni, což znamená, že řetězec důvěry přesahuje jakýkoli jednotlivý repozitář nebo konfiguraci pipeline.
Hloubková obrana pro vývojové týmy: Správa tajemství, šifrovaná komunikace a řízení přístupu
Megalodon zneužil několik slabin, které jsou běžné jak v repozitářích s otevřeným zdrojovým kódem, tak v privátních repozitářích. Jejich řešení vyžaduje vrstvený přístup spíše než jediné opatření.
Za prvé, tajemství by nikdy neměla být uložena v prostém textu uvnitř souborů workflow, konfiguračních souborů prostředí nebo zdrojového kódu. Funkce šifrovaných Secrets GitHubu poskytuje základní úroveň ochrany, ale tato tajemství by měla také dodržovat princip nejmenšího oprávnění. Workflow nasazující do staging prostředí nepotřebuje přihlašovací údaje k produkční databázi. Přesné vymezení rozsahu tajemství omezuje dosah škod při kompromitování workflow.
Za druhé, pravidla ochrany větví a povinní recenzenti pro změny souborů workflow vytvářejí lidský kontrolní bod, který musí automatizované útoky obejít. Vyžadování alespoň jedné schválené recenze před jakoukoliv úpravou souborů .github/workflows/ může zpomalit nebo zablokovat druh rychlé automatizované injekce, na které Megalodon spoléhal.
Za třetí, připnutí akcí GitHub třetích stran na konkrétní commit SHA místo pohyblivých tagů zabraňuje samostatnému, ale souvisejícímu vektoru útoku, kdy kompromitovaní vydavatelé akcí tiše aktualizují tag tak, aby ukazoval na škodlivý kód. Toto byl mechanismus několika nedávných incidentů v dodavatelském řetězci GitHub Actions.
Konečně, audit protokolování a detekce anomálií při spuštění workflow mohou odhalit neočekávaná odchozí síťová připojení nebo neobvyklé vzory přístupu k tajemstvím. Audit log API GitHubu a nástroje třetích stran pro zabezpečení CI/CD mohou pomoci tyto signály odhalit.
Jak nyní auditovat vaše GitHub repozitáře a CI/CD pipeline
Pokud vaše organizace spravuje GitHub repozitáře s aktivními CI/CD pipeline, je vhodné upřednostnit několik okamžitých kroků.
Zkontrolujte všechny soubory ve složce .github/workflows/ na jakékoli nedávno přidané nebo upravené záznamy, zejména ty přidané přispěvateli, které neznáte. Zkontrolujte historii commitů konkrétně pro soubory workflow, nejen výchozí zobrazení větve.
Obměňte veškerá tajemství, která byla aktivní v průběhu útoku, nebo u nichž si nemůžete s jistotou potvrdit, že nebyla vystavena. U cloudových přihlašovacích údajů zkontrolujte protokoly přístupu na straně poskytovatele z hlediska neobvyklých volání API ve stejném časovém okně.
Proveďte audit toho, kteří přispěvatelé repozitáře a aplikace mají přístup k zápisu. Útoky s falešnými identitami závisí na schopnosti odesílat kód, takže zpřísnění oprávnění přispěvatelů a povolení povinných recenzí pro změny workflow odstraní klíčový vstupní bod.
Zvažte nakonec přijetí dedikovaného nástroje pro skenování tajemství, který běží při každém commitu a zachytí přihlašovací údaje dříve, než jsou vůbec commitnuty do repozitáře. Několik open source i komerčních možností se přímo integruje s GitHubem.
Co to znamená pro vás
Kampaň Megalodon je praktickou ukázkou toho, proč se CI/CD pipeline staly primární útočnou plochou. Vývojáři a bezpečnostní týmy, kteří přistupují k zabezpečení pipeline jako k méně důležitému než zabezpečení aplikací, nechávají dokořán otevřenou cestu ke svým nejcitlivějším přihlašovacím údajům.
Začněte tento týden auditem tajemství. Zkontrolujte, kdo může upravovat vaše soubory workflow, obměňte přihlašovací údaje, které nemůžete ověřit jako čisté, a pokud jste tak ještě neučinili, povolte ochranu větví na vaší výchozí větvi. Rychlost útoku Megalodon znamená, že v době, kdy se spustí upozornění, může být exfiltrace již dokončena. Prevence a vymezení rozsahu přístupu jsou jedinými spolehlivými obrannými prostředky.
