A Megalodon támadás 6 óra alatt 5 561 GitHub repót érintett

Egy Megalodon névre keresztelt GitHub CI/CD ellátási lánc támadás új mércét állított fel az automatizált, nagyszabású tárolórepozitórium-feltörések terén. Egyetlen hat órás időablakban a támadók 5 718 rosszindulatú kódfrissítést juttattak be 5 561 GitHub-repóba, hamis identitások segítségével olyan munkafolyamat-fájlokat injektálva, amelyek csendben szivárogtatják ki a felhőalapú hitelesítő adatokat, SSH-kulcsokat és forráskód-titkokat. A kampány rendkívüli sebessége és volumene azt jelzi, hogy a pipeline-alapú támadások ipari méretűvé váltak, és meghaladják a legtöbb csapat valós idejű észlelési és reagálási képességét.

Hogyan működött a Megalodon támadás: hamis identitások és automatizált munkafolyamat-injektálás

A Megalodon mögött álló támadók nem zero-day exploitokra vagy végfelhasználói gépekre célzott kifinomult kártevőkre támaszkodtak. Ehelyett a GitHub CI/CD infrastruktúrájának megbízható jellegét aknázták ki. Hamis közreműködői identitások létrehozásával pull requesteket nyújtottak be, vagy közvetlenül módosították a munkafolyamat-konfigurációs fájlokat – pontosabban azokat a YAML-fájlokat, amelyeket a GitHub Actions az automatizált build és deployment folyamatok meghatározására használ.

Ha egy rosszindulatú munkafolyamat-fájl bekerül egy repóba, automatikusan végrehajtódik, amikor a pipeline elindul – jellemzően push eseményekkor vagy pull request összevonásakor. Ez a végrehajtás a GitHub saját runner környezetében történik, amely gyakran hozzáfér a repó titkaihoz, környezeti változóihoz és a felhőszolgáltatókhoz kapcsolódó tokenekhez. A Megalodon munkafolyamatai ezt a hozzáférési ablakot arra használták, hogy az adatokat kiszivárigtassák – feltehetően a támadók által irányított infrastruktúrára –, mielőtt bármely repó-karbantartónak lehetősége lett volna átnézni a változtatást.

A kampány meghatározó jellemzője az automatizálás. Közel 5 720 különálló kódpush végrehajtása több mint 5 500 repóban hat óra alatt nem manuális munka eredménye. Ehhez olyan szkriptelt eszközökre van szükség, amelyek képesek azonosítani a célpontokat, hitelesíteni magukat hamis identitásokkal, hiteles kinézetű munkafolyamat-módosításokat készíteni, és azokat párhuzamosan beküldeni. Az automatizálás ilyen szintje azt jelenti, hogy a támadási felület gyorsabban bővült, mint ahogy bármilyen emberi felügyeleti csapat nyomon tudta volna követni.

Milyen hitelesítő adatokat loptak el, és miért fontos ez a fejlesztők számára

Minden rosszindulatú munkafolyamat hasznos terhe a hitelesítő adatok begyűjtése volt. A célpontok között szerepeltek felhőszolgáltatói hitelesítő adatok – leggyakrabban AWS, GCP és Azure hozzáférési kulcsok, amelyeket GitHub Secretsként tároltak, vagy a munkafolyamat környezeti változóiban hivatkoztak rájuk. Szintén célponttá váltak a szerver-hozzáféréshez vagy szolgáltatások közötti hitelesítéshez használt SSH privát kulcsok, valamint a forráskódba vagy konfigurációs fájlokba ágyazott egyszerű szöveges titkok.

Ezek a hitelesítő adattípusok láncszerű kockázatot hordoznak. Egy ellopott AWS hozzáférési kulcs, amely széleskörű jogosultságokkal rendelkező IAM szerepkörhöz tartozik, lehetővé teheti a támadó számára, hogy infrastruktúrát indítson el, adattárakat szivárogtasson ki, vagy perceken belül oldalirányban mozogjon a kapcsolódó szolgáltatások között. Az SSH-kulcsok tartós hozzáférést biztosíthatnak a termelési szerverekhez még jóval azután is, hogy az eredeti betörést észlelték és a GitHub-repót megtisztították. Ezeknek az adatoknak az értéke messze meghaladja magukat a repókat.

Ez nem csupán hipotetikus kockázati minta. Az év elején egy CISA-vállalkozó AWS-kulcsokat és egyszerű szöveges jelszavakat tett közzé egy nyilvános GitHub-repóban, ami jól szemlélteti, hogy a fejlesztési környezetekben elkövetett hitelesítő adat-kezelési hibák még a dedikált biztonsági felhatalmazással rendelkező szervezeteket is érintik. A Megalodon csupán ipari méretűvé tette ugyanazt az exploit útvonalat, amelyet az egyéni emberi hibák már ismételten bebizonyítottak.

Érdemes megjegyezni, hogy maguk a hitelesítő adat-lopó eszközök és pipeline-ok is célpontokká válhatnak. A közelmúltbeli Bitwarden CLI ellátási lánc támadás megmutatta, hogy még a fejlesztők által a titkok kezelésére használt eszközök is kompromittálhatók az upstream folyamatokban, ami azt jelenti, hogy a bizalmi lánc egyetlen repón vagy pipeline-konfiguráción túlra is kiterjed.

Védelmi mélység fejlesztői csapatok számára: titkoskezelés, titkosított kommunikáció és hozzáférés-vezérlés

A Megalodon számos olyan gyengeséget aknázott ki, amelyek egyaránt jellemzők a nyílt forráskódú és a privát repókra. Kezelésükhöz rétegzett megközelítés szükséges egyetlen vezérlő helyett.

Először is, a titkokat soha nem szabad egyszerű szövegként tárolni munkafolyamat-fájlokban, környezeti konfigurációs fájlokban vagy forráskódban. A GitHub titkosított Secrets funkciója alapszintet nyújt, de ezeknek a titkoknak szintén a minimális jogosultság elvét kell követniük. Egy staging környezetbe telepítő munkafolyamatnak nincs szüksége termelési adatbázis hitelesítő adataira. A titkok szoros hatókörű kezelése korlátozza a hatókört egy munkafolyamat kompromittálódása esetén.

Másodszor, az ágvédelmi szabályok és a munkafolyamat-fájl módosításaihoz szükséges kötelező felülvizsgálók emberi ellenőrzési pontot teremtenek, amelyet az automatizált támadásoknak meg kell kerülniük. Ha legalább egy jóváhagyott felülvizsgálatot kell megkövetelni a .github/workflows/ fájlok bármilyen módosítása előtt, az lelassíthatja vagy megakadályozhatja a Megalodon által alkalmazott gyors automatizált injektálást.

Harmadszor, a harmadik féltől származó GitHub Actions-ök adott commit SHA-khoz való rögzítése a lebegő tagek helyett megakadályoz egy különálló, de kapcsolódó támadási vektort, amelyben a kompromittált action-kiadók csendben frissítik a taget, hogy rosszindulatú kódra mutasson. Ez volt a mechanizmus több közelmúltbeli GitHub Actions ellátási lánc incidensnél.

Végül, az audit naplózás és az anomáliadetektálás a munkafolyamat-futtatásokon felszínre hozhat váratlan kimenő hálózati kapcsolatokat vagy szokatlan titkos hozzáférési mintákat. A GitHub audit napló API-ja és harmadik féltől származó CI/CD biztonsági eszközök segíthetnek ezeknek a jeleknek a felszínre hozásában.

Hogyan auditálja GitHub-repóit és CI/CD pipeline-jait most

Ha szervezete aktív CI/CD pipeline-okkal rendelkező GitHub-repókat tart fenn, néhány azonnali lépés prioritást érdemel.

Tekintse át az összes fájlt a .github/workflows/ könyvtárban, különösen a nemrég hozzáadott vagy módosított bejegyzéseket, főleg azokat, amelyeket Ön által nem ismert közreműködők adtak hozzá. Ellenőrizze kifejezetten a munkafolyamat-fájlok commit előzményeit, ne csak az alapértelmezett ág nézetét.

Váltsa le azokat a titkokat, amelyek aktívak voltak a támadás időszakában, vagy amelyekről nem tudja magabiztosan megerősíteni, hogy nem kerültek nyilvánosságra. Felhőalapú hitelesítő adatok esetén tekintse át a szolgáltatói oldali hozzáférési naplókat a szokatlan API-hívások szempontjából ugyanabban az időablakban.

Auditálja, hogy mely repó-közreműködők és alkalmazások rendelkeznek írási hozzáféréssel. A hamis identitású támadások a kód pushok lehetőségétől függenek, ezért a közreműködői jogosultságok szigorítása és a munkafolyamat-módosításokhoz szükséges felülvizsgálatok engedélyezése eltávolít egy kulcsfontosságú belépési pontot.

Végül fontolja meg egy dedikált titokszkenner eszköz bevezetését, amely minden commitnál lefut, és még azelőtt elfogja a hitelesítő adatokat, hogy azokat valaha is becommitálnák egy repóba. Számos nyílt forráskódú és kereskedelmi lehetőség integrálódik közvetlenül a GitHubbal.

Mit jelent ez az Ön számára

A Megalodon kampány szemléletes példa arra, hogy a CI/CD pipeline-ok miért váltak elsődleges támadási felületté. Azok a fejlesztők és biztonsági csapatok, akik az alkalmazásbiztonságnál másodlagosként kezelik a pipeline biztonságát, szélesre tárt utat hagynak a legérzékenyebb hitelesítő adataik felé.

Kezdjen egy titok-audittal ezen a héten. Tekintse át, ki módosíthatja a munkafolyamat-fájljait, váltsa le azokat a hitelesítő adatokat, amelyeket nem tud biztonsággal ellenőrizni, és engedélyezze az ágvédelmet az alapértelmezett ágon, ha még nem tette meg. A Megalodon támadás sebessége azt jelenti, hogy mire egy riasztás lefut, a kiszivárogtatás már megtörténhetett. A megelőzés és a hozzáférés hatókörének szűkítése az egyetlen megbízható védelem.