Egyszerű trükkel juthatnak el a káros cuccok
Jeevan Jutla kutató bemutatta, hogyan lehet az npx skills add parancs segítségével az egész Skill-könyvtárat bemásolni a repóba. Ha egy rosszindulatú Skill tartalmaz egy *.test.ts fájlt, azt a Jest és a Vitest felismeri és automatikusan futtatja, amikor az npm test parancsot használod – vagy amikor az IDE mentéskor automatikusan lefuttatja a teszteket. Így már azelőtt működésbe léphet a kártevő, hogy bármilyen érdemi ellenőrzés elindulna, ráadásul a kimenet sem mutat semmi gyanúsat. Konténerizált pipeline-ban a process.env tartalmazhat telepítési tokeneket, felhőhozzáférést – lényegében minden érzékeny adatot.
Az ilyen támadási vektor nem új keletű: a káros npm postinstall scriptek és pytest pluginek évek óta visszaélnek a telepítés utáni, bizalmon alapuló folyamatokkal. Ami az Anthropic Skilleknél riasztóbbá teszi, hogy ezek a csomagok eleve olyan mappákba kerülnek, amelyeket szokás commitelni a verziókövetőbe, és így automatikusan továbbterjednek minden, a klónozott projekten dolgozó munkatársra – illetve minden tesztelő pipeline-ra.
Három audit, egy vakfolt
Nemrég egymás után három nagy audit is zajlott a Skill-ökoszisztémában. Az első, január 15-én közzétett jelentés 31 132 egyedi Anthropic Skillt vizsgált, és azt találta, hogy a Skillek 26,1%-ában volt legalább egy sérülékenység; ezek közül 13,3% adatlopást, 11,8% jogosultságemelést tett lehetővé. Az olyan Skillek, amelyek végrehajtható scripteket is csomagoltak, 2,1-szer gyakrabban rejtettek sérülékenységet a tisztán utasításokat tartalmazókhoz képest.
Később a Snyk szkennere 3984 Skill vizsgálatával azt találta, hogy 13,4%-ban volt legalább egy kritikus biztonsági probléma. A kutatók 76 bizonyítottan káros Skillt azonosítottak, ezek közül nyolc még ekkor is nyilvánosan elérhető volt a ClawHubon.
Végül megjelent a Cisco eszköze, közvetlenül bekötve olyan fejlesztői környezetekbe, mint a VS Code vagy a Cursor – de tesztfájlokat ez sem vizsgál, mivel alapból az ügynökinterakcióra koncentrál, nem a fejlesztői eszköztárra.
A három fő szkenner tehát egyaránt vak a tesztfájlokra: egyik sem nézi, hogy ezek is teljes jogosultságokkal futnak a tesztelés során.
Az akcióláncolat és hogyan jut át minden védelmen
A támadás úgy néz ki, hogy az npx skills add letölti a teljes Skill-repó tartalmát egy .agents/skills// mappába. Az egyetlen kizárás a .git, a metadata.json és az aláhúzással (_) kezdődő fájlok; minden más lementésre kerül. A főbb JavaScript-tesztfuttatók (Jest, Vitest) ráadásul a dot: true beállítással még a .agents/ mappán belüli fájlokat is megtalálják, ami alapértelmezett viselkedés. Egy támadó egy tetszőlegesen ártatlannak tűnő tesztfájllal (.test.ts, vagy akár conftest.py Pythonban) simán kiolvassa a környezeti változókat, kulcsokat, majd elküldi egy külső szerverre – mindez automatikusan történik, láthatatlanul, akár sikeres, akár sikertelen a teszt.
Mindebből fakadóan az Anthropic Skillek megosztására tervezett .agents/skills/ mappa gyakran bekerül a verziókövetésbe; a GitHub alapértelmezett .gitignore-ja sem zárja ki. Ez szabad utat ad, hogy minden fejlesztő, aki klónozza és tesztet futtat, elindítsa a támadást.
Túl szűk a figyelt felület
A szkennelők kizárólag az ügynök telepítési szintjén figyelik a fenyegetéseket – vagyis megnézik, mit utasít a Skill az ügynöknek, de teljesen figyelmen kívül hagyják, hogy a fejlesztői eszköztárral futtatható fájlok ugyanabban a könyvtárban vannak.
Vállalati környezetben egy ügynök gyakran rendszergazdai jogosultságokat, OAuth-tokeneket vagy akár API-kulcsokat is elér. Ha ezek a környezeti változókban élnek, akkor egy rosszindulatú tesztfájl minden hozzáférést át tud venni anélkül, hogy magát az ügynököt kellene kompromittálnia.
A hibát súlyosbítja, hogy a szkennerek általában csak a Skill telepítésekor vizsgálnak; utána, ha a Skill szerzője egy újabb, ártó szándékú tesztfájlt ad hozzá, az ellenőrzés már elmarad.
Auditok, amiket nem néznek meg
A biztonsági csapatok gyakran abban bíznak, hogy ha egy lehetőség nincs a jelentésükben, az nem létezik. Pedig a Skill-szkennerek csak a SKILL.md-t és az ügynök által meghívott scripteket ellenőrzik, minden más kimarad. Továbbra is, tavalyi adatok alapján az automatizált auditok jó része sem tér ki a tesztfájlokra.
Ajánlás: a fejlesztői tesztfuttatókat (Jest, Vitest, Mocha, Pytest) konfiguráld úgy, hogy kizárják a .agents/ könyvtárat. Egy sor a beállításokban elég, hogy ne fussanak le a veszélyes tesztek: például Jest esetén /agents/ a testPathIgnorePatterns-be.
Ezen túl javasolt automatikus CI-ellenőrzést futtatni minden Skill-telepítésnél, amely kiszűri a .agents/ mappából a gyanús fájlokat (pl. *.test.*, conftest.py, *.config.*). Ha ilyen fájl bekerül, blokkolja a merge-elést, vagy külön review-t ír elő.
A Skill forrását mindig adott commit hash-hez kell rögzíteni, nem az aktuális master vagy main ághoz. Így az első használatkor nem lehet később észrevétlenül módosítani, és rosszindulatú tartalmat becsempészni.
További kérdések, amelyeket fel kell tenni a Skill-szkenner szolgáltatónak
Öt kérdés minden Skill-szkenner vásárlás előtt:
1. Pontosan mely könyvtárakat és fájlokat analizálnak?
2. A tesztfájlokat is veszélyként kezelik?
3. Tudják-e jelezni, ha a Skill gyanús (teszteket, buildscriptet tartalmaz)?
4. Tudnak-e segíteni a projektútvonalak szűkítésében, hogy a tesztfuttató csak a saját kódot érje el?
5. Van-e nyilvános, nagy mintán végzett auditjuk? (Például Snyk: 3984 Skill – ilyen referencia fontos.)
A Skill-szkenner modellje nem hibás, csak hiányos
Az Anthropic Skill-ökoszisztéma ugyanazokat a gyermekbetegségeket mutatja, mint annak idején az npm supply chain: a gyors növekedés miatt a biztonsági infrastruktúra lemaradt. Több tízezer Skill közül minden negyedik sebezhető, néhány ezer közül is tucatnyi bizonyíthatóan káros; dokumentált támadásokra is sor került már.
Mindebből fakadóan a szkenner nem rossz – csak nem teljes: a fenyegetések figyelése a Skill ügynökszintjén megáll. A végső támadás viszont nem az ügynökön keresztül, hanem a fejlesztői tesztfuttatón jut be, amelyet semmi sem ellenőriz. Ha az Anthropic Skill-szkennerek nem bővítik gyorsan a figyelt felületet, a fejlesztői csapatoknak maguknak kell beépíteniük a védekezést.
