CISA kiszivárgott GovCloud-kulcsai: mit tegyenek a szakemberek?

Egy CISA megbízott szándékosan töltött fel AWS GovCloud kulcsokat egy nyilvános GitHub-repóba. Az alábbiakban az offenzív és defenzív elemzés olvasható — és a belőle következő konkrét lépések.

Biztonsági hírek és elemzések

Kinek: Biztonsági szakemberek

A CISA kiszivárgott GovCloud kulcsai: Mit tegyenek a szakemberek?

Közzététel: Ez a bejegyzés nem tartalmaz affiliate linkeket. Minden hivatkozott forrás szabadon elérhető.

Egy CISA-alvállalkozó szándékosan töltötte fel az AWS GovCloud hozzáférési kulcsokat — az ügynökség egyéb titkainak széles gyűjteményével együtt — egy nyilvános GitHub-tárhelyre. Brian Krebs tudósításának idején a CISA még az érintett hitelesítő adatok érvénytelenítésén dolgozott. A történet nem politikai természetű. Ez egy esettanulmány belső fenyegetésről, secrets-kezelési kudarcról és a kormányzati alvállalkozói ökoszisztémákon belüli politika és gyakorlat közötti szakadékról.

Mi történt valójában

Három dolgot kell egyértelműen kimondani erről az incidensről, mielőtt bármilyen elemzésbe fognánk.

A cselekmény szándékos volt. Ez nem félrekonfigurálás. Nem egy fejlesztőről van szó, aki véletlenül commitolt egy .env fájlt. Úgy tűnik, az alvállalkozó tudatosan döntött úgy, hogy érzékeny anyagot tölt fel egy nyilvános repozitóriumba. Ez a különbség alapvetően meghatározza, hogy a szervezetek hogyan modellezik a belső fenyegetést — a szokásos automatizált védvonal ugyanis, legyen az pre-commit hook, titkos adat szkenner vagy CI/CD pipeline-ellenőrzés, hibák kiszűrésére készült, nem szándékos rosszindulat kezelésére. Egy elszánt belső fenyegető, aki ismeri ezeket a kontrollokat, simán ki tudja kerülni őket.

Az AWS GovCloud kulcsok nem általános felhő-hitelesítő adatok. A GovCloud környezeteket kifejezetten olyan amerikai kormányzati munkaterhelésekhez tervezték, amelyeknek meg kell felelniük a FedRAMP High és az ITAR előírásainak. Az ilyen környezetekhez tartozó kulcsok potenciálisan olyan adatokat és munkaterheléseket tesznek elérhetővé, amelyek szabályozási és nemzetbiztonsági következményekkel járnak — ez egy hagyományos AWS kereskedelmi fiók kompromittálódásánál egyszerűen nem áll fenn. A káros hatás terjedelme kategorikusan más.

A visszavonási késedelem önmagában is megállapítás. A hitelesítő adatok nagyléptékű rotálása szövetségi környezetekben operatív szempontból továbbra is rendkívül nehézkes. Annak megértése, hogy miért — örökölt függőségek, tisztázatlan szolgáltatásfiók-tulajdonjog, az éles rendszerek meghibásodásától való félelem — legalább annyira fontos, mint annak puszta elismerése, hogy ez így van.

Offenzív biztonsági elemzés

A GitHub mint elsődleges OSINT-támadási felület

A nyilvános GitHub régóta elsődleges gyűjtési réteg az offenzív OSINT szakmai módszertanában. Az olyan eszközök, mint a truffleHog és a gitleaks, pontosan azért léteznek, mert felhős titkok rendszeresen kerülnek nyilvános repókba. A CISA-incidens egy magas láthatóságú megnyilvánulása egy olyan problémának, amellyel az offenzív elemzők engedélyezett vizsgálatok során folyamatosan találkoznak.

A reális fenyegetési modell: egy nemzetállami vagy opportunista szereplő, aki folyamatos GitHub-monitoringot végez a kormányhoz kötődő szervezetek ellen — ez megalapozott feltételezés a dokumentált threat actor TTP-k ismeretében — még azelőtt összegyűjtötte volna ezeket a kulcsokat, mielőtt a CISA tudomást szerzett a kitettségről. A Krebs-riport a nyilvánosan látható jel; a tényleges kihasználási ablak korábban nyílt meg.

A GitHub OSINT nem kiegészítő gyűjtési módszer. Ez egy elsődleges támadási felület a kezdeti hozzáférési felderítésben, és olyan, amelyet még a jól finanszírozott célpontok is következetesen képtelenek kontrollálni.

Belső fenyegetés mint kezdeti hozzáférési vektor

A MITRE ATT&CK dokumentálja az Initial Access via Valid Accounts (T1078) technikát mint az intrusion set-ek között leggyakrabban megfigyelt eljárások egyikét. Egy jogos hozzáféréssel rendelkező alvállalkozó, aki szándékosan kihelyezi a hitelesítési adatokat, előpozícionálja azokat bárki számára, aki megtalálja őket. Ez az incidens élőben mutatja meg, hogyan omlik össze a perimeter-modell belső cselekvés hatására — nem azért, mert valaki áttört egy tűzfalon, hanem mert valaki, akinek jogosult hozzáférése volt, a főbejáraton adta ki a kulcsokat.

Azokat a fenyegetési modelleket, amelyek a külső támadókat lényegesen nagyobb súllyal kezelik, mint a belső szereplőket, érdemes újragondolni ezen incidens tükrében.

Defenszív Biztonsági Elemzés

A Titkosítási Anyagok Kezelése Továbbra Is Megoldatlan Nagyvállalati Szinten

A hosszú élettartamú, statikus AWS kulcsok — amelyek bekerülhetnek egy repository-ba — olyan architekturális örökség, amelyet a korszerű felhőbiztonsági megközelítésnek fel kellett volna számolnia. Az AWS támogatja a részletes IAM szerepköröket, az AWS STS-en keresztüli rövid élettartamú hitelesítő adatokat, valamint a példány- és feladatszintű szerepkör-átvételt, ami a statikus hozzáférési kulcsok szükségességét a legtöbb architekturális mintában kiküszöböli. Az a tény, hogy statikus kulcsok egyáltalán léteztek és egy alvállalkozó számára elérhetők voltak, arra utal, hogy a szervezet titkosítási anyagok kezelésére vonatkozó architektúrája nem tartott lépést a fejlődéssel.

A CISA saját felhőbiztonsági útmutatója — amelyet az NSA-val és az ODNI-vel közösen adtak ki — kifejezetten javasolja a statikus, hosszú élettartamú felhős hitelesítő adatok mellőzését. A CISA publikált műszaki referenciaarchitektúrája és a szervezet látszólagos belső gyakorlata közötti feszültséget érdemes nevén nevezni.

Az Alvállalkozói Hozzáférések Irányítása

Az alvállalkozói kockázat az egyik legtartósabb hiányosság a szövetségi és vállalati biztonsági programokban. Az alvállalkozók jellemzően nem a minimálisan szükséges, hanem a praktikusan megadható hozzáférési szintet kapják. A legkisebb jogosultság elvének alvállalkozókra való alkalmazása nemcsak a jogosultságok korlátozását jelenti, hanem annak monitorozását is, hogy ezeket a jogosultságokat mire használják — és annak biztosítását, hogy a hitelesítő anyagok elkülönítettek, auditálhatók és igény szerint rotálhatók legyenek.

A Federal Acquisition Regulation (FAR) 4.19-es alfejezete és a vonatkozó kiberbiztonsági záradékok alapkövetelményeket állapítanak meg. A szabályozási megfelelés és az operatív biztonság azonban nem ugyanaz. Egy alvállalkozó teljesítheti a FAR kiberbiztonsági záradékait, és még mindig kisétálhat a hitelesítő adatokkal.

A Detektálási Mérnöki Hiányosságok

Rendelkezik-e a szervezete monitorozással a felhőkörnyezetéhez tartozó hitelesítő adatok nyilvános repository-beli kiszivárgásának észlelésére? A GitHub titkos adat szkennelése értesíti a repository tulajdonosát, de nem értesíti proaktívan azt a szervezetet, amelynek hitelesítő adatai kiszivárogtak, ha nem ők a repository tulajdonosai. Azok a szervezetek, amelyek kizárólag a GitHub natív szkennelésére támaszkodnak, egy komoly vakfolttal rendelkeznek.

A defenszív csapatoknak érdemes folyamatos monitorozási eszközöket értékelni — kereskedelmi megoldásokat (GitGuardian, SpectralOps) vagy nyílt forrásúakat (truffleHog CI-ban, illetve periodikus nyilvános repository szkennelés) — amelyek nemcsak a belső repository-kat fedik le, hanem azokat a nyilvános repository-kat is, ahol hitelesítő adatokra utaló minták felbukkanhatnak. Ez nem más, mint befelé irányított OSINT: saját titkosaink felkutatása a nyilvános infrastruktúrán, mielőtt egy ellenséges fél megtenné helyettünk.

Elemző teendők listája

Védelmi csapatok:

1. Azonnal végezzék el a statikus hitelesítő adatok auditját. Vegyék számba az összes hosszú élettartamú AWS hozzáférési kulcsot — és azok Azure-, illetve GCP-beli megfelelőit — a teljes környezetben. Minden egyes esetben mérjék fel, hogy kiváltható-e szerepkör-alapú, rövid élettartamú hitelesítő adatokkal. A GovCloud- és az éles környezetek kerülnek előre.

2. Vezessenek be titkosítóadat-szkennelést a pipeline több fázisában. A gitleaks és a truffleHog beépíthető pre-commit hook-okba és CI/CD rendszerekbe. Egy elszánt bennfentest nem tartanak vissza, de csökkentik a véletlen kitettséget, és auditálható nyomokat hagynak maguk után.

3. Terjesszék ki a monitoringot a nyilvános GitHub-ra. A saját repository-kontrolljuk önmagában nem elegendő. Rendszeresen szkenneljék a nyilvános GitHub-ot a szervezetükhöz köthető hitelesítőadat-mintákra.

4. Vizsgálják felül a vállalkozói hozzáférések hatókörét. Minden aktív vállalkozói kapcsolat esetén ellenőrizzék a minimális jogosultsági elvnek megfelelő hozzáférés-kiosztást, győződjenek meg arról, hogy a hitelesítő adatok egyedileg azonosíthatók és nem megosztottak, és erősítsék meg, hogy létezik dokumentált off-boarding folyamat azonnali hitelesítőadat-visszavonással.

5. Teszteljék a hitelesítőadat-rotációt nagy léptékben. Tartsanak asztali vagy purple team gyakorlatot a következő forgatókönyv köré: 50 nyilvánosan kitett service account kulcsot fedeztünk fel. Mennyi ideig tart a teljes rotáció, és mi megy tönkre? Ez a válasz adja meg a valós kitettségi ablakot.

Offenzív és threat intel szakemberek:

1. Adják hozzá a GovCloud kulcsmintáinak egyeztetését a GitHub OSINT módszertanukhoz. Kormányzati vállalkozók vagy szervek ellen folytatott felhatalmazott vizsgálatok során a nyilvános repository-ban fennálló kitettség életképes kezdeti hozzáférési vektor, amely szisztematikus tesztelést indokol.

2. Frissítsék a bennfentes fenyegetési modelleket. Ez az incidens szemléletesen mutatja, hogy a bennfentes fenyegetések nem igényelnek kifinomult technikai képességet — csupán jogosult hozzáférést és egy döntést. Azok a modellek, amelyek a bennfenteseket alacsonyabb valószínűségű fenyegetésként kezelik a külső támadókhoz képest, felülvizsgálatra szorulnak.

3. Használják fel ezt az incidenst a red team jelentésekben. Amikor titkosítóadat-kezelési fejlesztéseket javasolnak ügyfeleknek, ez magas hitelességű hivatkozási pontot nyújt a technikai kockázatot elvontan kezelő vezetői közönség számára.

A CISA nem egy tökéletes belső biztonsággal rendelkező monolit. Egy emberi munkaerőre támaszkodó, vállalkozóktól függő, erőforrás-korlátok között működő ügynökség, amely ugyanolyan rendszerszintű hibáknak van kitéve, mint bármely nagy szervezet. Ez nem kifogás — ez diagnózis. Ha a CISA a maga mandátumával és láthatóságával még mindig statikus felhő-hitelesítő adatokat üzemeltet, amelyeket egyetlen vállalkozó is nyilvánosságra hozhat, akkor minden hasonló architektúrát alkalmazó szervezetnek ugyanez a sebezhetősége áll fenn. A kongresszusi vizsgálat esetleg politikai változásokat eredményez. Kezdjék a saját környezetük operatív változtatásaival.