Koliko je GitHub repozitorija pogođeno Megalodon napadom?

Megalodon napad kompromitirao je 5.561 GitHub repozitorij, pri čemu su napadači gurnuli 5.718 zlonamjernih ažuriranja koda kroz te repozitorije u jednom vremenskom prozoru od šest sati.

Koju metodu su napadači koristili za izvođenje Megalodon napada?

Napadači su koristili lažne identitete suradnika za podnošenje zahtjeva za povlačenjem ili izravnu izmjenu GitHub Actions YAML datoteka radnih tijekova, koje su se potom automatski izvršavale unutar GitHub-ovog CI/CD okruženja cjevovoda.

Koje vrste vjerodajnica i podataka su ukradeni tijekom napada?

Zlonamjerni radni tijekovi ciljali su vjerodajnice pružatelja oblačnih usluga kao što su AWS, GCP i Azure pristupni ključevi, SSH privatni ključevi i tajne u obliku čistog teksta ugrađene u izvorni kod ili konfiguracijske datoteke.

Je li se Megalodon napad oslanjao na zero-day eksploite ili malware?

Ne, napadači nisu koristili zero-day eksploite niti sofisticirani malware; umjesto toga, iskoristili su pouzdanu prirodu GitHub-ove vlastite CI/CD infrastrukture ubacivanjem zlonamjernih datoteka radnih tijekova.

Zašto se automatizacija smatra definirajućom karakteristikom Megalodon napada?

Izvršavanje gotovo 5.720 guranja koda kroz više od 5.500 repozitorija za šest sati zahtijevalo je skriptne alate za identifikaciju ciljeva, autentifikaciju i paralelno podnošenje promjena, šireći površinu napada brže nego što su je timovi za ljudsko praćenje mogli pratiti.

Megalodon napad pogodio 5.561 GitHub repozitorij za šest sati

GitHub CI/CD napad na lanac opskrbe nazvan Megalodon postavio je novi standard za automatizirani, masovni kompromis repozitorija. U jednom vremenskom prozoru od šest sati, napadači su gurnuli 5.718 zlonamjernih ažuriranja koda kroz 5.561 GitHub repozitorij, koristeći lažne identitete za ubacivanje datoteka radnih tijekova osmišljenih za tiho ispražnjavanje oblačnih vjerodajnica, SSH ključeva i tajni izvornog koda. Sama brzina i obujam kampanje signaliziraju pomak prema industrijaliziranim napadima na cjevovode koji nadmašuju sposobnost većine timova da u stvarnom vremenu otkriju ili odgovore na prijetnju.

Kako je Megalodon napad funkcionirao: Lažni identiteti i automatsko ubacivanje radnih tijekova

Napadači iza Megalodona nisu se oslanjali na zero-day eksploite ili sofisticirani malware isporučen na krajnje korisničke uređaje. Umjesto toga, iskoristili su pouzdanu prirodu same GitHub CI/CD infrastrukture. Konstruiranjem lažnih identiteta suradnika, podnosili su zahtjeve za povlačenjem (pull requests) ili su izravno modificirali konfiguracijske datoteke radnih tijekova — konkretno YAML datoteke koje GitHub Actions koristi za definiranje automatiziranih cjevovoda za izgradnju i implementaciju.

Jednom kada zlonamjerna datoteka radnog tijeka dospije u repozitorij, automatski se izvršava svaki put kada se cjevovod pokrene — tipično na događajima guranja (push) ili spajanja zahtjeva za povlačenjem. To izvršavanje se odvija unutar GitHub-ovog vlastitog okruženja za pokretanje (runner), koje često ima pristup tajnama repozitorija, varijablama okruženja i tokenima opsegom vezanim uz pružatelje oblačnih usluga. Megalodon radni tijekovi koristili su taj pristupni prozor za eksfiltraciju podataka prema van — vjerojatno prema infrastrukturi pod kontrolom napadača — prije nego što je ikoji održavatelj repozitorija imao razlog pregledati promjenu.

Definirajuća karakteristika kampanje je njena automatizacija. Izvršavanje gotovo 5.720 zasebnih guranja koda kroz više od 5.500 repozitorija za šest sati nije ručni napor. Zahtijeva skriptne alate koji mogu identificirati ciljeve, autentificirati se s lažnim identitetima, izraditi uvjerljive izmjene radnih tijekova i podnositi ih paralelno. Ova razina automatizacije znači da se površina napada proširivala brže nego što ju je ikoji tim za ljudsko praćenje mogao pratiti.

Koje su vjerodajnice ukradene i zašto je to važno za programere

Korisni teret svake zlonamjerne radne linije bila je krađa vjerodajnica. Ciljevi su uključivali vjerodajnice pružatelja oblačnih usluga — najčešće AWS, GCP i Azure pristupne ključeve pohranjene kao GitHub Secrets ili referencirane unutar varijabli okruženja radnog tijeka. SSH privatni ključevi koji se koriste za pristup poslužitelju ili međuservisnu autentifikaciju također su bili u dosegu, zajedno s bilo kojim tajnama u obliku čistog teksta ugrađenim u izvorni kod ili konfiguracijske datoteke.

Te vrste vjerodajnica nose kaskadni rizik. Ukradeni AWS pristupni ključ vezan uz IAM ulogu sa širokim ovlastima može napadaču omogućiti pokretanje infrastrukture, eksfiltraciju pohrana podataka ili bočno kretanje prema povezanim uslugama u roku od nekoliko minuta. SSH ključevi mogu pružiti trajan pristup produkcijskim poslužiteljima dugo nakon što je izvorna provala otkrivena i GitHub repozitorij očišćen. Vrijednost ovih podataka proteže se daleko izvan samih repozitorija.

Ovo nije hipotetski obrazac rizika. Ranije ove godine, CISA izvođač radova izložio je AWS ključeve i lozinke u obliku čistog teksta na javnom GitHub repozitoriju, demonstrirajući da loše upravljanje vjerodajnicama u razvojnim okruženjima pogađa čak i organizacije s namjenskim sigurnosnim mandatima. Megalodon je jednostavno industrijalizirao isti put eksploitacije koji su individualne ljudske pogreške već višestruko demonstrirale.

Vrijedi napomenuti i da su alati i cjevovodi za krađu vjerodajnica sami po sebi mete. Nedavni napad na lanac opskrbe Bitwarden CLI-a pokazao je da čak i alati koje programeri koriste za upravljanje tajnama mogu biti kompromitirani uzvodno, što znači da se lanac povjerenja proteže izvan bilo kojeg pojedinog repozitorija ili konfiguracije cjevovoda.

Obrana u dubinu za razvojne timove: Upravljanje tajnama, šifrirane komunikacije i kontrole pristupa

Megalodon je iskoristio nekoliko slabosti koje su uobičajene u repozitorijima otvorenog koda i privatnim repozitorijima podjednako. Njihovo rješavanje zahtijeva slojeviti pristup umjesto jedne kontrole.

Prvo, tajne se nikada ne smiju pohranjavati kao čisti tekst unutar datoteka radnih tijekova, konfiguracijskih datoteka okruženja ili izvornog koda. GitHub-ova značajka šifriranih Secrets pruža osnovnu liniju, ali te tajne trebaju slijediti i načelo najmanjih privilegija. Radni tijek koji implementira u staging okruženje ne treba produkcijske vjerodajnice baze podataka. Usko opsežne tajne ograničavaju radijus eksplozije kada je radni tijek kompromitiran.

Drugo, pravila zaštite grana (branch protection rules) i obavezni recenzenti za promjene datoteka radnih tijekova stvaraju ljudsku kontrolnu točku koju automatizirani napadi moraju zaobići. Zahtijevanje najmanje jedne odobrene recenzije prije bilo kakve izmjene datoteka u .github/workflows/ može usporiti ili blokirati vrstu brzog automatiziranog ubacivanja na koje se Megalodon oslanjao.

Treće, zakačivanje (pinning) GitHub Actions trećih strana na specifične SHA hash vrijednosti commitova umjesto plutajućih oznaka sprječava odvojen, ali srodan vektor napada u kojem kompromitrani izdavači akcija tiho ažuriraju oznaku da pokazuje na zlonamjerni kod. Ovo je bio mehanizam u nekoliko nedavnih incidenata s lancem opskrbe GitHub Actionsa.

Na kraju, revizijsko zapisivanje i otkrivanje anomalija na pokretanjima radnih tijekova mogu otkriti neočekivane odlazne mrežne veze ili neobične obrasce pristupa tajnama. GitHub-ov API revizijskog zapisivanja i alati trećih strana za CI/CD sigurnost mogu pomoći u otkrivanju tih signala.

Kako odmah revidirati vaše GitHub repozitorije i CI/CD cjevovode

Ako vaša organizacija održava GitHub repozitorije s aktivnim CI/CD cjevovodima, nekoliko je neposrednih koraka koje vrijedi prioritizirati.

Pregledajte sve datoteke u .github/workflows/ radi nedavno dodanih ili izmijenjenih unosa, posebno onih koje su dodali suradnici koje ne prepoznajete. Provjerite povijest commitova za datoteke radnih tijekova posebno — ne samo zadani prikaz grane.

Rotirajte sve tajne koje su bile aktivne tijekom perioda napada ili za koje ne možete pouzdano potvrditi da nisu bile izložene. Za oblačne vjerodajnice, pregledajte zapisnike pristupa na strani pružatelja usluga radi neobičnih API poziva u istom vremenskom okviru.

Revidirajte koji suradnici repozitorija i aplikacije imaju pristup pisanju. Napadi lažnim identitetom ovise o mogućnosti guranja koda, pa sužavanje dozvola suradnicima i omogućavanje obaveznih recenzija za promjene radnih tijekova uklanja ključnu ulaznu točku.

Na kraju, razmislite o usvajanju namjenskog alata za skeniranje tajni koji se pokreće na svakom commitu, hvatajući vjerodajnice prije nego što se ikad commitaju u repozitorij. Nekoliko opcija otvorenog koda i komercijalnih opcija izravno se integrira s GitHubom.

Što ovo znači za vas

Megalodon kampanja praktičan je prikaz zašto su CI/CD cjevovodi postali primarna površina napada. Programeri i sigurnosni timovi koji sigurnost cjevovoda tretiraju kao sekundarnu u odnosu na sigurnost aplikacija ostavljaju široko otvoren put do svojih najosjetljivijih vjerodajnica.

Započnite s revizijom tajni ovog tjedna. Pregledajte tko može modificirati vaše datoteke radnih tijekova, rotirajte vjerodajnice koje ne možete verificirati kao čiste i omogućite zaštitu grana na vašoj zadanoj grani ako to još niste učinili. Brzina Megalodon napada znači da do trenutka kada se alarm aktivira, eksfiltracija može već biti dovršena. Prevencija i opsežno skaliranje pristupa jedine su pouzdane obrane.