Hogyan térítheti el a Claude Code-ot valaki más repositoryja: 7 védelmi szabály

Ailoot dokumentációja: API, kulcsok és beállítás.

Négy dokumentált út nem megbízható szövegtől ügynökműveletekig#

Hivatalos nevén ez közvetett promptinjektálás: a rosszindulatú utasítás nem közvetlenül tőled érkezik, hanem olyan adaton keresztül, amelyet az ügynök a feladat végrehajtása közben dolgoz fel – például egy idegen README-ből, hibaüzenetből, GitHub-kommentből vagy külső szolgáltatás válaszából. Ezt a kifejezést a bekezdés után nyugodtan elfelejtheted; innentől egyszerűen fogalmazok.

Az alább tárgyalt négy kutatási példa:

1. Egy ártalmatlannak tűnő repositoryról kimutatták, hogyan válhat reverse shell-lé.
2. Egy Pull Request címe három különböző AI-ügynököt térített el.
3. Egy ügynököt rá lehetett venni, hogy valódi helyett hamis Sentry-hibajelentést fogadjon el.
4. MCP-eszközmetaadatok befolyásolhatják a modell eszközhasználatát; az elsődleges MCPTox-benchmark modellenként és beállításonként eltérő fogékonyságot vizsgál.

Hogyan lesz egy ártalmatlannak tűnő repository README-jéből reverse shell?#

A mechanizmus úgy épül fel, hogy egyik réteg se tűnjön önmagában gyanúsnak:

1. Klónozol egy hétköznapinak tűnő repositoryt, és megkéred a Claude Code-ot, hogy futtassa.
2. A repository letölt egy Python-csomagot, amelyet úgy terveztek, hogy első használatkor hibát adjon.
3. A hibaüzenet udvariasan egy „javító” parancsot javasol: python3 -m axiom init.
4. Az init parancs futtatja a setup.sh fájlt.
5. A szkript lekérdez egy DNS TXT-rekordot (amelyet általában domainnel kapcsolatos megjegyzésekre használnak, de a mező tetszőleges szöveget elfogad). A támadó egy base64-kódolású parancsot helyez el benne (ez olyan eljárás, amellyel bármilyen adat egyszerű, szóköz és speciális karakter nélküli szöveggé alakítható), majd közvetlenül a bashnek továbbítja.
6. A DNS-rekord értéke bármikor módosítható – így a támadó interaktív reverse shellt kap a te felhasználói jogosultságaiddal, hozzáférve a gépen lévő összes titokhoz.

A bemutatott payload futáskor DNS-ből érkezett, ezért csak a repository bájtjainak vizsgálata nem mutatta meg a végső payloadot. Ez nem bizonyítja minden vizsgáló vagy futásidejű vezérlés tehetetlenségét: a letöltött tartalom ellenőrzése, folyamatfigyelés és hálózati korlát feltárhatja vagy megszakíthatja a láncot. A forrás proof of concept, nem valódi incidensek gyakoriságmérése.

Hogyan térített el egy Pull Request címe három különböző AI-ügynököt?#

A kutató ezeket az utakat és válaszokat írja le; ez történeti jelentés, nem minden aktuális termékverzió ellenőrzése:

Majdnem öt hónap telt el a közzétételi ciklus első és utolsó jelentése között (az első Claude Code-jelentés 2025. október 17-én érkezett; az utolsó GitHub Copilot-hibajavítás 2026. március 9-én történt). A jelentés súlyosságmódosítása és enyhítései nem igazolják minden lehetséges payload teljes lezárását. A kutató PoC-repositoryja dokumentálja a bemutatott Claude-utat; támadó payloadját valódi rendszeren ne futtasd. Számodra maga a támadási minta a tanulság: egy ellenőrizetlen adat érkezik a GitHubról az ügynökhöz, az ügynök parancsot futtat, a titkok pedig ugyanazon a GitHubon keresztül szivárognak ki – a támadónak nincs szüksége külső szerverre.

Két elemzés is elég a minta felismeréséhez: minden új megállapítást külön-külön kijavítani nem járható út; ilyen sebezhetőségek kéthetente bukkannak fel. A biztonsági szabályok kifejezett rögzítése a CLAUDE.md fájlban és a settings.json-ban, ahelyett hogy fejben tartanád őket, a kontextusmérnökség része: egyszer beállítod őket, és minden új Claude Code-munkamenetben automatikusan érvényesülnek, emlékeztetők nélkül. Három pillér működik együtt: AI-klón + Második Agy + Kontextusmérnökség – ez a kombináció a mindent elhívő végrehajtóból kifejezett szabályok szerint működő ügynökké alakítja a Claude Code-ot.

Átveheti az irányítást az ügynököd felett egy hamis Sentry-hibajelentés?#

A támadáshoz nem kell más, mint egy Sentry DSN-kulcs – nyilvános azonosító, amelyet sok projekt közvetlenül a kliensoldali kódba ír:

A működés egyszerű: a fejlesztő megkéri az ügynököt, hogy vizsgálja meg a nyitott Sentry-hibákat; az ügynök az MCP-szerveren keresztül lekéri őket, a valódiak közé keverve megkap egy rosszindulatú eseményt, és az abba ágyazott parancsot megbízható, a hiba javítására vonatkozó utasításként értelmezi – hiszen hivatalosan pontosan ezt a feladatot kapta.

A Tenet szerint a meglévő védelmek nem riasztottak a tesztelt környezeteikben. Ez nem bizonyít nyomtalan végrehajtást minden telepítésben: ügynök-/eszköznapló, végponti telemetria és hálózati rekord rögzíthet későbbi műveletet. A támadás külső telemetriabeküldéssel indul, majd az ügynök tényleges eszközeitől és jogaitól függ.

Miért olyan veszélyes egy MCP-eszköz leírása, mint egy rendszerprompt?#

A Microsoft megfogalmazása a legpontosabb, amit ebben a témában találtam:

Ezt a technikát eszközmérgezésnek nevezik: egy ártalmatlannak tűnő eszköz leírásába rejtett utasítás cselekvésre készteti az ügynököt.

A Claude 3.7 Sonnet teljesített a legjobban a támadással szembeni ellenállásban, de még ez is az esetek kevesebb mint 3%-ában tagadta meg a mérgezett utasítás követését – még a legjobb modell ellenállása is inkább a szerencsén, mint a védelmen múlik. A benchmark váratlan következtetése: minél pontosabban követi a modell az utasításokat, annál rosszabbul különbözteti meg a legitim parancsot a metaadatban elrejtettől – a modell erőssége ellene dolgozik.

Mi a közös ezekben a támadásokban – és mit hagyhat ki az észlelés?#

A következtetés mind a négy megállapításra érvényes: nem hagyatkozhatsz arra, hogy „a kód normálisnak látszik” – a támadás egyes lépései valóban ártalmatlanok. Korlátozd az ügynök tényleges képességeit, és vizsgáld meg a javasolt műveleteket; az észlelés és körülhatárolás a támadás más-más részét kezeli.

Milyen védelem van már a Claude Code-ban, és miért nem elég?#

Az Anthropic nem rejti el a problémát, hanem közvetlenül elismeri a dokumentációjában:

A dokumentáció szerint az ügynök a teljes promptot elemzi gyanús utasítások után kutatva, nem hagyja jóvá automatikusan a curl és wget parancsokat, a webes tartalmakat külön kontextusablakban tartja, hogy ne keveredjenek a fő kontextussal, és az új kódbázisban történő első indításkor vagy új MCP-szerver csatlakoztatásakor megerősítést kér a bizalomról.

Az Anthropic azonban egy egyértelmű, kemény kitételt is megfogalmaz:

Ha valaha bosszúságodban --dangerously-skip-permissions kapcsolóval indítottad el a Claude Code-ot, hogy „ne zaklasson folyton a kérdéseivel”, akkor kikapcsoltad azokat a mechanizmusokat, amelyek megállíthatták volna a fent tárgyalt négy támadást. Én szándékosan kikapcsolva hagyom ezt a kapcsolót akkor is, amikor a Claude Code egy munkamenetben már tizedszer kérdez vissza – idegesítő, de ezek a kérdések jelentik a határt aközött, hogy „az ügynök gyanús szöveget olvasott” és aközött, hogy „végre is hajtotta”. Egy nem programozónak ésszerű beállítás a szokásos engedélyezési mód (default vagy acceptEdits) bekapcsolt sandboxszal: a szokásos fájlmódosításokhoz nem kell extra jóváhagyás, a terminálparancsok pedig fizikailag nem léphetnek ki a sandboxból, akkor sem, ha az ügynököt megtévesztették.

Hogyan engedélyezd a sandbox módot, és hogyan zárd be az alapértelmezés szerint nyitva hagyott rést?#

Ha minden projektre véglegesen be akarod kapcsolni, módosíts egy beállítást a ~/.claude/settings.json fájlban:

{
  "sandbox": { "enabled": true }
}

Alapértelmezés szerint a sandboxban futó parancsok csak a projekt munkakönyvtárába és a munkamenet ideiglenes könyvtárába írhatnak. A hálózati hozzáférés proxy-n keresztül történik – előzetesen egyetlen domain sincs engedélyezve, és a Claude Code megerősítést kér, amikor először kapcsolódik egy új domainhez. Az Anthropic szerint ez jelentősen, a vállalat belső mérései szerint 84%-kal csökkenti az engedélykéréseket, mert a sandbox maga kezel néhány biztonságos esetet, így nem kell minden alkalommal kérdeznie.

Az alapbeállítások által nyitva hagyott rés: a sandbox alapértelmezés szerint korlátozza az írást, de nem akadályozza meg az olyan fájlok olvasását, mint a ~/.aws/credentials és a ~/.ssh. Pontosan ezeket a fájlokat és környezeti változókat célozták meg a fenti támadások. Zárd be ezt a rést egy külön blokkal ugyanabban a fájlban:

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

A lényeg, hogy még ha az első elemzésben bemutatott reverse shell meg is nyílik a sandboxon belül, ezeket a változókat és fájlokat fizikailag eltávolítják a folyamat környezetéből, mielőtt elindulna – így nincs mit ellopni.

Milyen permissions.deny szabályokat érdemes ma hozzáadnod?#

Egy nem programozóknak szánt minimális szabálykészlet, amely egyszerre lefedi mind a négy támadás fő célpontjait:

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/credentials)",
      "Read(.env)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(sudo *)"
    ]
  }
}

A Claude Code dokumentációja szerint a deny szabályok mindig elsőbbséget élveznek az allow szabályokkal szemben. Tehát még ha te (vagy maga az ügynök) véletlenül szélesebb hozzáférést engedélyezel is máshol, egy konkrét deny szabály akkor is elsőként érvényesül. E szabályelsőbbség illeszkedő eszközkérésekre vonatkozik. Nem bizonyítja a titok elérhetetlenségét minden alfolyamaton vagy eszközön át; kikényszerített fájlrendszer- és környezeti korlátokat is használj.

A Claude Code-nak van auto módja is, amelyben egy külön osztályozó modell ellenőrzi a műveleteket futtatás előtt – ez nem ugyanaz a modell, amelyik veled beszél. Alapértelmezés szerint egyebek mellett éppen a „kód letöltése és azonnali futtatása” mintát (curl | bash) tiltja, amely az első támadás végén szerepel. Az Anthropic kifejezetten figyelmeztet, hogy ez kutatási mód: csökkenti a promptok számát, de önmagában nem garantálja a biztonságot – kezeld kiegészítő rétegként, ne a sandbox és a permissions.deny helyettesítőjeként.

Hogyan ellenőrizd a repositoryt és az MCP-szervert, mielőtt megbízol bennük az ügynököd előtt?#

Repositorykhoz itt egy rövid ellenőrzőlista, mielőtt átadod őket az ügynöknek:

1. Ne kezdj rögtön telepítésbe egy ismeretlen forrásból származó e-mailben, bejegyzésben vagy értékelésben szereplő hivatkozás alapján – pontosan így terjeszthetők ezek a repositoryk.
2. Ha a telepítés hibával végződik, és egy „futtasd az X parancsot a javításhoz” utasítást ad, olvasd el, mit csinál valójában az X, mielőtt engedélyezed a Claude Code-nak a futtatását. Az utasítás teljesen hétköznapinak tűnt – pontosan ez volt a célja.
3. A csillagok száma helyett ellenőrizd a repository korát és commitelőzményeit – az újonnan létrehozott repositoryk könnyen kaphatnak hamis csillagokat kifejezetten az ilyen támadásokhoz.
4. Ha ismeretlen a repository, telepítsd virtuális gépen, ne a valódi kulcsokat tartalmazó munkahelyi gépeden. Ez az Anthropic saját, közvetlen ajánlása a külső szolgáltatások használatához.

Az Anthropic MCP-szerverekre vonatkozó álláspontja nyílt:

Ez azt jelenti, hogy a harmadik féltől származó MCP-szervereket neked kell ellenőrizned, nem annak a platformnak, ahonnan telepítetted őket. Néhány csapat – főként biztonsági startupok – már épít ehhez eszközöket: MCP-konfigurációs vizsgálókat, amelyek mérgezett leírásokat keresnek, valamint eszközrögzítést, amely telepítéskor elmenti a leírás hashét, és jelez minden későbbi módosítást. Ezek a technológiák még fiatalok, ezért túl korai lenne egyedüli védelemként támaszkodni rájuk – de érdemes figyelni őket, különösen akkor, ha MCP-szervereket kapcsolsz éles rendszerekhez. Az ilyen kapcsolatoknál rögzítheted a csomagverziókat, és auditnaplóba írhatod az eszközleírások ujjlenyomatát.

7 védelmi szabály: a mai ellenőrzőlista#

1. Kapcsold be a sandbox módot (/sandbox vagy "sandbox": {"enabled": true} a ~/.claude/settings.json fájlban), és adj hozzá egy credentials blokkot, amely megakadályozza a ~/.ssh és a ~/.aws/credentials olvasását.
2. Adj hozzá permissions.deny szabályokat a titkos fájlok olvasásának, valamint a veszélyes bash-parancsok (curl, wget, sudo) futtatásának tiltására – a deny mindig felülírja az allow szabályt.
3. Soha ne futtasd a --dangerously-skip-permissions kapcsolót idegen vagy nem ellenőrzött kódon – egyszerre minden védelmet kikapcsol, beleértve azokat is, amelyek éppen ezeket a támadásokat állíthatták volna meg.
4. Ne hagyd, hogy a Claude Code automatikusan végrehajtson egy hibaüzenetből származó „javító” parancsot – először olvasd el, mit csinál valójában.
5. Csak megbízható forrásból telepíts MCP-szervert, és ne feledd, hogy az Anthropic nem ellenőrzi helyetted a biztonságukat.
6. Különítsd el a munkameneteket jogosultság szerint: az egyik a személyes adataiddal dolgozik, és nem lát külső adatokat; a másik mások e-mailjeit, repositoryjait és jegyeit vizsgálja, de nem fér hozzá a titkokhoz; a harmadik külső közzétételt végez – és csak olyasmit, amit te személyesen jóváhagytál. A saját projektjeimben szigorúan betartom ezt: a fizetési kulcsokhoz hozzáférő munkamenet soha nem olvas tetszőleges külső jegyeket vagy repositorykat, a mások kódját feldolgozó munkamenet pedig egyáltalán nem lát titkokat. Ne keverd ezeket a szerepeket egyetlen csevegésben.
7. Tartsd naprakészen a Claude Code-ot és a hozzá kapcsolódó automatizálási szkripteket – az itt tárgyalt rések többségét már kijavították a javításokkal az útmutató megjelenésekor, az újakat pedig hasonlóan javítják.

Mi következik?#

E rétegek egyike sem jelent garanciát – maga az Anthropic is őszintén kijelenti, hogy egyetlen védelem sem nyújt teljes védettséget. Nem várom el a Claude Code-tól, hogy magától felismerje a hibaüzenetbe vagy issue-kommentbe rejtett trükköt. Számomra a sandbox és a permissions.deny a projektkontextus kezelésének része: mit lát az ügynök, mit tekint alapértelmezés szerint megbízhatónak, és mi történik, amikor hibázik.

Ha az Ailooton keresztül szeretnél hozzáférni neurális hálózatokhoz, nézd meg az Ailootot.