Az adatlopás útvonala
A támadó először egy hibásan konfigurált, nyilvánosan elérhető Amazon S3-tároló révén jutott hozzá belépési adatokhoz, amelyek egy IAM (azonosítás- és jogosultságkezelő) felhasználóhoz tartoztak. Ez a felhasználó mind olvasási, mind írási joggal bírt az AWS Lambda szolgáltatáshoz, illetve korlátozott jogokkal az Amazon Bedrockhoz. Az S3-ban ezenkívül Retrieval-Augmented Generation (RAG) adatokat is tároltak, amelyek a támadás későbbi fázisában kulcsfontosságúnak bizonyultak.
Ennek következtében a támadó könnyedén elkezdhette automatizált támadássorozatát. Először adminisztrátori felhasználókat próbált meg elérni többszöri névváltoztatással – például sysadmin, netadmin –, de ezekkel nem boldogult. Végül Lambda-funkciók kódját módosította, kihasználva a sérült felhasználó UpdateFunctionCode és UpdateFunctionConfiguration jogosultságait, és ezzel sikerült adminisztrátori jogosultságot szereznie.
MI által generált támadókód és jelek
A támadókód jelentős része szerb megjegyzésekkel volt tele, ami az elkövető származására utalhat. A kód minden IAM-felhasználót és a hozzájuk tartozó kulcsokat listázott, továbbá új kulcsokat generált a támadóknak, majd felsorolta az S3-tárolókat teljes tartalmukkal. Nemcsak kifinomult hibakezelést tartalmazott, hanem a Lambda végrehajtási idejét is 3 másodpercről 30 másodpercre növelte. Ez, valamint az egész támadás gyorsasága, egyértelműen MI-generált támadószoftver jelenlétére utal.
Ugyanekkor a támadók több AWS-fiókot is célba vettek, és hamis, valamint valódi fiókazonosítókat is generáltattak. Az MI gyakran véletlenszerű karaktersorozatokat is megadhat (például 123456789012), ami újabb bizonyíték az MI-használatra.
Automatizált jogosultságeszkaláció és adatlopás
Összesen 19 AWS-identitást sikerült kompromittálniuk, ami 6 különböző IAM-szerepkört, 14 különböző munkamenetet és további 5 IAM-felhasználót jelentett. Az újonnan létrehozott adminisztrátorfiókkal érzékeny adatokat szereztek meg: Secrets Manager titkokat, SSM-paramétereket, CloudWatch-naplókat, Lambda-forráskódokat, belső S3-adatokat és CloudTrail-eseményeket is.
Ezután a támadó az Amazon Bedrockhoz fordult, és több felhőben futó MI-modellt is elindított: Claude, DeepSeek, Llama, Amazon Nova Premier, Amazon Titan Image Generator és Cohere Embed. A Bedrock-modellek tömeges, szokatlan használata egyértelműen riasztó jel minden vállalatnak. A szakértők szerint az ilyen helyzetek megelőzésére jóval szigorúbb felügyelet és SCP-szabályozás szükséges.
Mire mentek a megszerzett erőforrásokkal?
A támadó ezt követően EC2 gépképekre keresett, amelyek mélytanulási feladatokra alkalmasak. Az S3-tárolót ideiglenes számítási feladatokhoz is elkezdte használni, ahol feltűnt egy olyan szkript is, amely egy nem létező GitHub-repozitóriumot hív meg. Ez a nagy nyelvi modellekre jellemző hallucináció újabb példája.
Ugyanekkor egy nyilvánosan elérhető JupyterLab-szervert is elindított a 8888-as porton, amely hátsó ajtót kínált a szerverhez AWS-jogosultság nélkül is. Az instanciát azonban öt perc után megszüntették, ismeretlen okból. Nem világos, a támadó MI-modellek tanítását vagy számítási kapacitás eladását tervezte-e.
Védekezési javaslatok a felhőben
Az ilyen támadások megakadályozása érdekében szigorúan törekedni kell a legkevesebb jogosultság (least privilege) elvének alkalmazására minden IAM-felhasználó és -szerepkör esetén. Emellett kiemelten fontos az UpdateFunctionConfiguration és PassRole jogok korlátozása a Lambda esetében, a kritikus UpdateFunctionCode-engedélyeket pedig csak azoknak a fiókoknak adni, amelyek feltétlenül igénylik a kódfrissítést.
Kulcsfontosságú, hogy az S3-tárolók érzékeny adatai – beleértve a modellekhez felhasznált RAG-adatokat – ne legyenek nyilvánosak; ez nemcsak ezekre, hanem minden egyéb MI-modellre is igaz. Az Amazon Bedrock esetében a modellindítás naplózását is ajánlott bekapcsolni, hogy az illetéktelen MI-használat azonnal látható legyen.
Amazon válasza és a tanulság
Az Amazon szerint a szolgáltatásaik változatlanul és hibamentesen működtek az incidens során, a problémát egy hibásan nyilvánossá tett S3-tároló okozta. Arra hívják fel a figyelmet, hogy minden ügyfél kövesse a biztonsági előírásokat, ne ossza meg nyilvánosan az elérési kulcsokat, mindig csak a szükséges jogokat adja, rendszeresen rotálja a hozzáféréseket, biztonságosan kezelje az azonosítókat, és kapcsolja be a GuardDutyt és a hasonló monitorozást, hogy csökkentse a jogosulatlan tevékenységek kockázatát.
