Amikor az AI-asszisztens ellened fordul: így lesz a kódsegédből biztonsági rés
A fejlesztők mind inkább AI-alapú eszközökhöz fordulnak a mindennapi munkájuk során. Legyen szó a Cursorról, az OpenAI Codexről, a Claude Code-ról vagy a GitHub Copilotról, ezek az automatizált segédek felgyorsíthatják a fejlesztést és a kódellenőrzést, ugyanakkor egyre nagyobb támadási felületet is jelentenek a támadók számára.
Ezek az úgynevezett ágens-alapú eszközök különböző módon működnek, de a közös bennük az, hogy mind nagy nyelvi modellekre (LLM-ekre) támaszkodnak, amikor eldöntik, milyen lépéseket tegyenek a fejlesztő nevében. Minél nagyobb autonómiát kap egy ilyen ágens, annál több mindenhez fér hozzá és annál több mindent képes megtenni – ez pedig a kiszámíthatatlanságát is növeli.
Ebben a cikkben bemutatjuk, hogyan használhat ki egy támadó egy egyszerű „watering hole” jellegű támadást, ahol nem megbízható adatokat csempész a rendszerbe, hogy a segítőkészre hangolt AI és az autonómia kombinációját kihasználva távoli kódfuttatást (Remote Code Execution, RCE) érjen el a fejlesztő gépén. Ez egy rövid áttekintése annak a támadási keretrendszernek, amit a 2025. augusztusi Black Hat USA konferencián mutattunk be.
A nagy autonómiával járó kockázatok
Most „számítógép-használó ágensnek” (Computer Use Agent, CUA) nevezünk minden olyan ágenst, amely képes önállóan műveleteket és eszközöket futtatni egy gépen, méghozzá ugyanazokkal a hozzáférésekkel és jogosultságokkal, mint a bejelentkezett felhasználó.
Ezek az ágensek általában LLM-eket használnak a felhasználói kérések, a kód és a parancsok eredményeinek értelmezésére, hogy eldöntsék, mi legyen a következő lépés. Arra tervezték őket, hogy addig ismételjék a műveleteket, amíg a felhasználó kérése teljesül. Ilyen művelet lehet az egér mozgatása vagy kattintás, gépelés, fájlok szerkesztése, sőt, akár parancsok futtatása is.
Az ágenseket autonómia-szintekbe soroljuk az alapján, hogy milyen lehetséges végrehajtási útvonalak állnak nyitva előttük. A CUA-k általában a 3-as szintű ágensek közé tartoznak. Itt egy modell – jellemzően egy LLM, amit gyakran képfelismerő modellekkel is kiegészítenek a képernyő tartalmának megértéséhez – dönti el a következő lépéseket, majd a műveletek eredményét visszaküldi a modellnek. Ez egyfajta végrehajtási ciklust hoz létre, ami rendkívül kiszámíthatatlanná teszi a működést. Lehetetlen előre magabiztosan feltérképezni az adatáramlást és a végrehajtás menetét egy adott kérésnél, hiszen az eredmény szinte minden alkalommal más lehet. Ez a bizonytalanság, kombinálva azzal, hogy az ágensek parancsokat futtathatnak a felhasználó gépén, szélesre tárja a kaput a támadók előtt.
Támadás a Cursor ellen: egy gyakorlati példa
Ahhoz, hogy támadást építsünk fel ezek ellen az ágensek ellen, először meg kell értenünk a képességeiket, az alapvető „beállítottságukat” (alignment) és a tipikus használati eseteiket. Az olyan eszközöket, mint a Cursor (feltéve, hogy az ágens automatikus futtatási funkciója be van kapcsolva), arra tervezték, hogy önállóan elvégezzék a felhasználó feladatait: módosítják a kódbázist, és lefuttatják a szükséges terminálparancsokat.
A Cursor működéséről sokat megtudhatunk, ha elolvassuk a rendszer-promptjait, köztük azt is, ami kifejezetten az eszközök futtatására vonatkozik. Itt feketén-fehéren le van írva, hogy a Cursor kifejezett utasítást kap egy repository pull requestjeinek és hibajegyeinek (issue-k) feldolgozására. Ez az adatforrás alapvetően nem megbízható, hiszen feltételezhetjük, hogy külső közreműködők is nyithatnak pull requesteket és hibajegyeket a repositoryban.
Ennek tudatában kihasználhatjuk az indirekt prompt injection nevű technikát, aminek a lényege, hogy rosszindulatú utasításokat helyezünk el abban a tartalomban, amit a modell később beolvas. Jelen esetben egy GitHub issue-ba vagy pull requestbe csempésszük be a kártékony payloadot.
A demonstrációhoz létrehoztunk egy célpont repositoryt, a PyCronos-t, ami egy fiktív Python adatelemző könyvtár. A célunk az volt, hogy egy olyan injekciót készítsünk, ami egy átlagos fejlesztői munkafolyamat során kódfuttatást tesz lehetővé a repository fejlesztőinek és karbantartóinak gépén.
Tudva, hogy a Cursor képes önállóan terminálparancsokat futtatni, először is el kell készítenünk és el kell rejtenünk egy payloadot, ami végül a célpont gépén fut majd le. Ebben a példában egy egyszerű, reverse shellt létrehozó Powershell szkriptet obfuszkáltunk (tettünk nehezen olvashatóvá), amivel Windows-t használó fejlesztőket céloztunk. Nyílt forráskódú obfuszkátorokkal a szkriptet addig bonyolítottuk, amíg sikeresen megkerülte az alapvető Windows Defender védelmet.
A hipotetikus PyCronos repository megcélzásához létrehoztunk egy pycronos-integration nevű GitHub felhasználót. Ezzel a fiókkal hoztuk létre a win-pycronos repositoryt, ahová a Powershell payloadot elhelyeztük.
Első próbálkozás: Injekció egy GitHub issue-n keresztül
A pycronos-integrations fiókkal most meg kell írnunk az indirekt prompt injection payloadot, hogy rávegyük az áldozat Cursor ágensét a Powershell payloadunk letöltésére és futtatására. Először egy GitHub issue-val próbálkozunk. Lényegében social engineeringet alkalmazunk az issue-t feldolgozó ágensen, hogy rávegyük a kártékony kód futtatására.
A támadó itt létrehoz egy issue-t, ami azt állítja, hogy a könyvtár (nem létező) Windows-integrációja elromlott. A hibajegy szerint egy bizonyos parancsot kell futtatni a hiba reprodukálásához. Míg egy emberi fejlesztő valószínűleg rájönne, hogy ez a funkció nem is létezik, és a parancs egy távoli forrásból tölt le és futtat kódot, egy ágens ezt nem feltétlenül veszi észre.
Ezt a támadási útvonalat először az Anthropic Computer Use Agent demó verzióján teszteltük. (Fontos megjegyezni, hogy ez a kiadás tartalmaz egy biztonsági figyelmeztetést, ami jelzi a prompt injection lehetőségét, és javasolja az ágens kizárólag izolált környezetben való használatát.) Ha a felhasználó egy olyan promptot ad a CUA-nak, hogy „Segíts megoldani a nyitott issue-kat ebben a repositoryban”, az ágens engedelmeskedik. Navigál a hibajegyhez, értelmezi az issue-ról készült képernyőképet, és kimazsolázza belőle a futtatandó parancsot. Ezután a rendelkezésére álló eszközökkel sikeresen végrehajtja azt, amivel a támadó egy reverse shellt kap.
Amikor ugyanezt a támadást a Cursor ellen próbáltuk ki, már nem volt ennyire egyszerű. A Cursor nem a képre hagyatkozik, hanem közvetlenül az issue metaadataiból olvassa ki a szöveget. Itt észreveszi a távoli kód letöltésére és futtatására tett kísérletet, és mielőtt megtagadná a feladatot, tájékoztatja a felhasználót a kockázatokról. Ez azt jelenti, hogy vannak beépített védelmi mechanizmusok (guardrailek), amelyek átvizsgálják magát a GitHub issue-t a potenciálisan kártékony parancsok után kutatva.
Második, sikeres próbálkozás: A payload elrejtése egy Python csomagban
A célunk most az, hogy az injekciónkat ártalmatlanabbnak tüntessük fel, és magából az injekcióból eltávolítsuk a payload letöltésének és futtatásának parancsát. Ezt úgy tehetjük meg, hogy a letöltést egy hamis Python csomagba rejtjük.
A támadó pycronos-integrations repositoryjából létrehozunk egy látszólag ártalmatlan pycronos-windows nevű csomagot. A setup.py fájlba helyezzük el a távoli payload letöltésére és futtatására szolgáló parancsot. Ez a parancs a csomag pip install parancsával együtt fog lefutni.
Ezután létrehozunk egy pull requestet a cél repositoryn, hogy hozzáadjuk ezt a csomagot a projekt meglévő függőségeihez. Amikor a felhasználó megkéri a Cursor ágensét, hogy nézze át a nyitott pull requesteket, az létrehoz egy új branchet, és letölti a változtatásokat, majd futtatja a pip install -r requirements.txt parancsot a módosítások teszteléséhez. Amint az ágens telepíti a kártékony csomagunkat a felhasználó gépén, mi máris megkapjuk a reverse shellt, és közvetlen hozzáférést szerzünk a gépéhez.
Hogyan védekezhetsz? Az „Assume Prompt Injection” szemlélet
Ez a támadás rávilágít arra az alapszabályra, ami az összes hasonló sebezhetőséget lehetővé teszi: egy túlzott jogosultságokkal rendelkező ágens, ami a nem megbízható adatokat (esetünkben a pull requestet és a kártékony csomagot) megbízhatóként kezeli, könnyedén a támadó eszközévé válhat.
Ahogy a „From Prompts to Pwns: Exploiting and Securing AI Agents” című, a Black Hat USA 2025 konferencián tartott előadásunkban is részleteztük, azt javasoljuk, hogy ágens-alapú alkalmazások tervezésekor vagy felülvizsgálatakor indulj ki abból, hogy a prompt injection elkerülhetetlen. Ha egy ágens LLM-ekre támaszkodik a műveletek és eszközhívások eldöntésében, tételezd fel, hogy a támadó képes átvenni az irányítást az LLM kimenete felett, és így minden további lépést is ő kontrollálhat.
- Tesztelés és védelem: Amikor hasonló ágens-alapú alkalmazásokat építesz, használj sebezhetőség-szkennereket, mint például az NVIDIA garak nevű eszközét, amivel tesztelheted az ismert prompt injection problémákat. Az LLM-ek megerősítéséhez érdemes az LLM be- és kimeneteinél NeMo Guardrails-t alkalmazni.
- Autonómia korlátozása: A legbiztonságosabb megközelítés az autonómia mértékének lehető legnagyobb mértékű korlátozása. részesítsd előnyben a konkrét, előre definiált munkafolyamatokat, amelyek megakadályozzák, hogy az ágens tetszőleges terveket hajtson végre.
- Emberi felügyelet: Ha ez nem lehetséges, erősen ajánlott az emberi jóváhagyás (human-in-the-loop) bevezetése bizonyos „kockázatos” parancsok vagy műveletek esetén, különösen, ha potenciálisan nem megbízható adatokkal dolgozik az ágens.
- Izoláció: Ha a teljesen autonóm, emberi felügyelet nélküli munkafolyamatok elengedhetetlenek, akkor a legjobb megoldás az, ha ezeket a lehető legjobban elszigeteljük minden érzékeny eszköztől vagy információtól. Például követeld meg, hogy a teljesen autonóm számítógép-használó ágenseket izolált környezetben, például egy önálló virtuális gépen (VM) futtassák, korlátozott hálózati kimenettel és korlátozott hozzáféréssel a vállalati vagy felhasználói adatokhoz. Egy hasonló, de kevésbé hatékony megközelítés a helyi fejlesztői konténerek használatának kikényszerítése.
- Eszközspecifikus beállítások: Kifejezetten a Cursor esetében léteznek vállalati szintű vezérlők, amelyekkel letiltható az automatikus futtatás, vagy korlátozható a hatóköre azáltal, hogy csak egy engedélyezőlistán szereplő parancsok autonóm végrehajtását teszi lehetővé. Emellett már elérhetőek háttér-ágensek is, amelyekkel a felhasználók a Cursor izolált felhőinfrastruktúráján belül, konténerekben indíthatnak autonóm ágenseket.
Az ágens-alapú kódolási munkafolyamatok óriási lökést adtak a fejlesztési sebességnek az egész iparágban. Ahhoz azonban, hogy ezt az új hatékonyságot biztonságosan ki tudjuk aknázni, a vállalatoknak és a fejlesztőknek meg kell érteniük a lehetséges kockázatokat és megfelelő védekezési stratégiákat kell alkalmazniuk.