Egy mesterséges intelligencia által generált biztonsági javítás új sérülékenységet vitt a Snowflake egyik nyilvános GitHub-tárolójába. A hibát később egy különálló autonóm AI-biztonsági ügynök fedezte fel, ki is használta, majd olyan hitelesítő adatokat szerzett meg, amelyekkel hozzáférést kapott a Snowflake belső Jira-környezetének egy részéhez.
Az eset nem ellenőrizetlen támadás vagy kiberbűnözői művelet eredménye volt. A Wiz engedélyezett biztonsági kutatás keretében, a Snowflake HackerOne sérülékenység-bejelentési programján keresztül végezte a vizsgálatot.
Az eseménysor mégis különösen szemléletesen mutat rá egy új szoftverbiztonsági problémára: az AI-rendszerek ma már a sérülékenységi életciklus mindkét oldalán jelen vannak. Az egyik rendszer olyan kódot javasolhat, amely akaratlanul biztonsági hibát hoz létre, míg egy másik AI ugyanezt a hibát akár gépi sebességgel felismerheti és ki is használhatja.
A Wiz augusztus 17-én hozta nyilvánosságra az esetet. A vállalat szerint Red Agent nevű autonóm biztonsági rendszere önállóan azonosított egy script injection sérülékenységet a snowflakedb/snowflake-connector-net GitHub-tárolóban, működő exploitot fejlesztett hozzá, majd a GitHub Actions runnerből megszerzett hitelesítő adatok segítségével hozzáfért belső Snowflake Jira-projektekhez.
A kiszivárgott token állítólag olvasási jogosultságot biztosított mérnöki, biztonsági megfelelőségi és bug bounty projektekhez.
A Snowflake a Wiz jelentésének napján kijavította a sérülékeny workflow-t, a kapcsolódó hitelesítő adatot pedig másnap visszavonta és lecserélte.
A Snowflake auditnaplóinak vizsgálata szerint nem találtak arra utaló jelet, hogy a sérülékenység fennállásának öt napja alatt a Wizen kívül bárki más hozzáfért volna az érintett végponthoz.
Az esetet még érdekesebbé teszi, hogy a problémás módosítást a GitHub Copilot Autofix társszerzőként jegyezte – vagyis egy olyan AI-eszköz, amelyet kifejezetten biztonsági hibák javításának támogatására fejlesztettek.
AI-val támogatott módosítás hozta létre a sérülékenységet
A hiba a jira_issue.yml nevű GitHub Actions workflow-ban jelent meg, amelyet a Snowflake nyilvános .NET connector repository-ja használt.
Június 18-án a 1218-as pull request – „SNOW-2069227: Update jira workflows” – módosította a GitHub issue-címek feldolgozását.
A korábbi megoldás az issue címét először egy köztes környezeti változóba helyezte, majd strukturált argumentumként adta át a jq számára.
Ez biztonságosabb megközelítés volt, mert a nem megbízható bemenet nem került közvetlenül abba a shell scriptbe, amelyet a GitHub Actions futtatott.
A módosított változat ehelyett közvetlenül a run: blokkba illesztette az alábbi kifejezést:
${{ github.event.issue.title }}
Ez első pillantásra apró változtatásnak tűnhet, biztonsági szempontból azonban alapvető különbséget jelent.
A GitHub Actions a ${{ }} kifejezéseket még a run: lépés végrehajtása előtt feloldja. Emiatt az issue címe közvetlenül bekerült a generált shell scriptbe, nem pedig inert adatként került átadásra a végrehajtás során.
Egy támadó így shell metakaraktereket, idézőjeleket vagy speciálisan kialakított karakterláncokat helyezhetett az issue címébe, módosítva a generált script szintaxisát és további parancsokat injektálva.
A kód ugyan megpróbálta sed segítségével escape-elni az idézőjeleket, de ez túl későn történt: a shell injection már azelőtt megtörtént, hogy az escape-elési parancsok lefutottak volna.
Egyetlen megfelelően elhelyezett aposztróf elég lehetett ahhoz, hogy a támadó kilépjen a környező stringből és végrehajtható shell utasításokat illesszen be.
Ez a GitHub Actions egyik jól dokumentált biztonsági kockázata.
A GitHub dokumentációja kifejezetten figyelmeztet arra, hogy olyan értékeket, mint:
- issue címek;
- pull request tartalmak;
- branch nevek;
- címkék;
- e-mail-címek
nem megbízható bemenetként kell kezelni.
A GitHub azt javasolja, hogy ezeket az értékeket ne közvetlenül inline shell scriptekbe illesszék, hanem köztes környezeti változókon vagy erre tervezett Actions komponenseken keresztül dolgozzák fel.
Érdekesség, hogy a Snowflake workflow-ja pontosan ezt a biztonságos mintát használta a Copilot által támogatott módosítás előtt.
Bármely GitHub-felhasználó elérhette a sérülékeny workflow-t
A hiba nem korlátozódott megbízható Snowflake fejlesztőkre.
A workflow akkor futott le, amikor valaki új GitHub issue-t nyitott.
Mivel a repository nyilvános volt, gyakorlatilag bármely GitHub-felhasználó aktiválhatta a workflow-t egy megfelelően kialakított issue címmel.
A támadónak nem volt szüksége:
- Snowflake fejlesztői hozzáférésre;
- belső GitHub jogosultságokra;
- Jira hozzáférésre;
- korábbi kompromittálásra.
A Wiz azt is megállapította, hogy a workflow-ban szereplő feltételes ellenőrzés valójában nem biztosított érdemi védelmet.
A feltétel azt próbálta ellenőrizni, hogy egy pull requesthez tartozó felhasználó megegyezik-e a whitesource-for-github-com[bot] accounttal.
A workflow azonban issue eseményt, nem pull request eseményt kezelt.
Ebben a kontextusban a github.event.pull_request értéke null volt.
A feltétel ezért lényegében azt ellenőrizte, hogy egy null érték nem egyezik-e meg a megadott bottal – ami természetesen igaz lett.
Így minden külső felhasználó átjutott a látszólagos biztonsági ellenőrzésen.
A veszélyes kombináció tehát a következő volt:
- nyilvános esemény indíthatta a workflow-t;
- a támadó által kontrollált adat közvetlenül shell scriptbe került;
- a futtatási környezet érzékeny credentialökhöz fért hozzá.
A Wiz szerint Red Agentje június 23-án, mindössze öt nappal a sérülékeny módosítás után azonosította a hibát.
Az autonóm AI saját sikertelen exploitját is kijavította
A kutatás egyik legérdekesebb része, hogy a Wiz Red Agent nem állt meg a problémás YAML-kód felismerésénél.
Az AI maga dolgozott ki egy olyan issue címet, amelynek célja az volt, hogy kitörjön a shell parancsból, majd a GitHub Actions runner hitelesítő adatait külső rendszerre továbbítsa.
Az első próbálkozás sikertelen volt.
A payload a shell komment karakterét használta a hátralévő parancs figyelmen kívül hagyására, ez azonban egy szükséges záró zárójelet is eltávolított, így a Bash szintaktikai hibával leállt.
A Wiz beszámolója szerint az AI:
- elemezte a hibát;
- felismerte a hibás shell szintaxist;
- módosította saját payloadját;
- újra megpróbálta a támadást.
A második exploit már működött.
A GitHub által hosztolt Actions runner kifelé irányuló kapcsolatot hozott létre, amely Base64-kódolt formában tartalmazta:
- a Jira API tokent;
- a Jira-felhasználó e-mail-címét;
- a Jira alap URL-jét.
A Wiz által megfigyelt forráscím egy Azure-ban futó runnerhez tartozott.
A megszerzett token a Snowflake [email protected] felhasználójához kapcsolódott, és hitelesíteni lehetett vele a vállalat Atlassian környezetében.
A Wiz szerint az identitás olvasási jogosultsággal rendelkezett több belső területhez, köztük:
- mérnöki projektekhez;
- security compliance projektekhez;
- sérülékenység-kezelési projektekhez;
- bug bounty programhoz kapcsolódó információkhoz.
A kutatók kizárólag a credential jogosultságainak ellenőrzéséhez és a lehetséges hatás megállapításához használták a hozzáférést.
A Wiz szerint a proof-of-concept során megszerzett valamennyi információt később törölték.
Bár a kutatás engedélyezett volt, a technikai támadási lánc egy valódi támadó számára is életképes lehetett volna:
rosszindulatú GitHub issue → command injection → CI/CD runner kompromittálása → secret exfiltration → belső Jira hozzáférés.
A Snowflake órákon belül kijavította a hibát
A Wiz június 23-án jelentette a sérülékenységet a Snowflake HackerOne programján keresztül, a 3819931-es jelentésszámon.
A biztonsági csapat Slack-értesítést is kapott.
A Snowflake még aznap kijavította a workflow-t az 1dc7766 commitban és az 1402-es pull requestben.
A javítás visszaállította a korábbi, biztonságosabb mintát:
- a nem megbízható issue címe ismét környezeti változóba került;
- a strukturált adatok létrehozásához
jq --arghasználatára tértek vissza.
A Jira tokent június 24-én visszavonták és lecserélték.
A Snowflake azonnal megkezdte az esemény kivizsgálását, és közlése szerint nem talált jogosulatlan hozzáférésre utaló bizonyítékot.
Az auditnaplókban észlelt anomális lekérdezéseket össze tudták kapcsolni a Wiz engedélyezett kutatásához használt infrastruktúrával.
A Snowflake közleményében megköszönte a Wiz felelős bejelentését és együttműködését.
CVE-azonosítót nem rendeltek a problémához, mivel ez nem a GitHub Actions platform hibája volt, hanem a Snowflake saját workflow-konfigurációjában létrejött sérülékenység.
Miért volt értékes a Jira token?
A CI/CD rendszerek szükségszerűen sokféle credentialt kezelnek.
Kommunikálniuk kell például:
- forráskód-tárolókkal;
- package registrykkel;
- cloud platformokkal;
- ticketing rendszerekkel;
- deployment infrastruktúrával;
- egyéb automatizált szolgáltatásokkal.
Ezért a workflow runnerek rendkívül értékes célpontok.
A Snowflake esetében a sérülékeny job egy Jira API tokenhez fért hozzá, amelyet a workflow automatizálása használt.
Amint a támadó tetszőleges parancsokat tudott futtatni ugyanabban a jobban, a secret gyakorlatilag megszerezhetővé vált.
A CI-logokban alkalmazott secret masking sem akadályozta volna meg ezt.
A masking elsődleges célja, hogy a hitelesítő adatok véletlenül ne jelenjenek meg olvasható formában a logokban.
Ha azonban a támadó kódot futtat a runneren, akkor a secretet:
- átalakíthatja;
- Base64-be kódolhatja;
- HTTP requestbe építheti;
- DNS-en keresztül továbbíthatja;
- más rendszerbe küldheti.
A GitHub ezért azt javasolja, hogy minden workflow credential:
- minimális jogosultságot kapjon;
- szükség esetén rövid életű legyen;
- rendszeresen rotálják;
- csak az adott job számára szükséges erőforrásokhoz férjen hozzá.
A Snowflake-eset jól mutatja, hogy ugyanez az elv a külső SaaS-tokenekre – például Jira credentialökre – is érvényes.
A Copilot Autofix javaslatot ad, nem biztonsági garanciát
A GitHub Copilot Autofix a CodeQL által azonosított biztonsági problémákhoz próbál automatikusan javítási javaslatot generálni.
A rendszer elemzi:
- a riasztást;
- a környező forráskódot;
- a repository kontextusát;
majd egy potenciális javítást készít.
Fontos azonban, hogy a Copilot Autofix nem önálló jóváhagyó rendszer.
A GitHub dokumentációja szerint az általa létrehozott módosítások:
javaslatok, amelyeket a fejlesztőknek át kell tekinteniük, tesztelniük és jóvá kell hagyniuk.
Ez az eset ezért nem pusztán „AI által létrehozott sérülékenységként” értelmezhető.
A hibás módosítás a repository normál fejlesztési és review folyamatán is átment.
Vagyis két probléma találkozott:
- az AI nem ismerte fel az eredeti kód mögötti biztonsági trust boundaryt;
- a fejlesztési review sem észlelte, hogy egy már meglévő védelmi mintát távolítottak el.
A korábbi implementáció szándékosan köztes környezeti változót használt.
Az AI ezt valószínűleg felesleges kerülőútnak vagy egyszerűsíthető megoldásnak tekintette, miközben a „bonyolultabb” kód éppen egy biztonsági tulajdonságot biztosított.
Ez egyre gyakoribb problémává válhat az AI-alapú kódgenerálásnál.
Egy modell könnyen lecserélhet egy látszólag verbose megoldást elegánsabbnak tűnő kódra anélkül, hogy felismerné:
a többletstruktúra valójában security boundary.
A hagyományos tesztelés könnyen nem veszi észre a CI/CD sérülékenységeket
A CI/CD workflow-k sok szervezetnél furcsa köztes kategóriába esnek.
Technikailag kódok, mégis gyakran egyszerű konfigurációként kezelik őket.
Ezért nem feltétlenül kapnak ugyanolyan:
- threat modellingot;
- security review-t;
- támadói inputtesztelést;
mint egy internetre kötött alkalmazás.
Egy funkcionális teszt például ellenőrizheti, hogy egy normál GitHub issue megfelelően létrehoz-e Jira ticketet.
De ritkán teszteli automatikusan az olyan címeket, amelyek:
- idézőjeleket;
- új sorokat;
- shell command substitutiont;
- speciális metakaraktereket
tartalmaznak.
A reviewer pedig gyakran az üzleti funkciót nézi:
„Működik az issue → Jira automatizálás?”
nem pedig azt:
„Mi történik, ha egy támadó kontrollál minden karaktert az issue címében?”
Az AI miatt napokra zsugorodhat a sérülékenységek felfedezési ideje
A Snowflake sérülékenység mindössze öt napig létezett, mielőtt a Wiz AI-ügynöke megtalálta és működő exploittal validálta.
Ez az eset egyik legfontosabb tanulsága.
Korábban egy szervezet esetleg abban bízhatott, hogy egy kevéssé feltűnő workflow hiba hosszú ideig rejtve marad.
Az autonóm biztonsági ügynökök ezt az időablakot drasztikusan csökkenthetik.
Képesek:
- folyamatosan átvizsgálni nyilvános repositorykat;
- trust boundaryket elemezni;
- attacker-controlled bemeneteket követni;
- potenciális exploitot fejleszteni;
- futtatni;
- az eredményt elemezni;
- majd sikertelenség esetén automatikusan újrapróbálni.
A Red Agent nem egyszerű statikus scannerként működött.
Amikor az első payload hibát generált, nem csak jelentette a problémát.
Értelmezte a hibát, javította saját exploitját és ismét megpróbálta a támadást.
Ez már sokkal inkább hasonlít automatizált penetration testerhez – vagy rossz kezekben automatizált támadóhoz.
Egy új AI kontra AI biztonsági ciklus alakul ki
Az eset leegyszerűsítve így foglalható össze:
egy AI létrehozta a hibát, egy másik AI pedig kihasználta.
A teljes eseménylánc azonban ennél összetettebb:
- egy AI-rendszer módosítást generált vagy társszerzőként részt vett benne;
- a fejlesztési folyamat elfogadta a változtatást;
- a módosítás eltávolított egy meglévő biztonsági mintát;
- nyilvános GitHub esemény indíthatta a credentialökkel futó workflow-t;
- egy hibás feltétel nem korlátozta megfelelően a hozzáférést;
- egy második AI azonosította a sérülékenységet;
- exploitot fejlesztett hozzá;
- az első hibás próbálkozást elemezte és kijavította;
- megszerezte a credentialt;
- ember által működtetett vulnerability disclosure folyamat akadályozta meg a tényleges károkozást.
Az eset tehát nem azt mutatja, hogy az AI önállóan működik az emberi rendszerektől függetlenül.
Éppen ellenkezőleg: azt mutatja, hogy az AI felgyorsítja mind a szoftverfejlesztést, mind a sérülékenységkutatást, miközben a jogosultságokat és a végső döntéseket továbbra is emberek és szervezeti folyamatok határozzák meg.
Ezért a puszta „human review” egyre kevésbé lehet elég.
Az emberi ellenőrzést ki kell egészíteni:
- policy-as-code szabályokkal;
- automatizált security tesztekkel;
- least-privilege credentialökkel;
- workflow fájlok fokozott védelmével;
- runner egress kontrollal;
- megfelelő audit logginggal.
Mit kell változtatniuk a fejlesztői csapatoknak?
Az AI által készített kódot nem kell automatikusan veszélyesebbnek tekinteni az ember által írt kódnál.
De az AI provenance hasznos kockázati jelzés lehet.
Kiemelt review szükséges, ha AI által generált változtatás érinti:
- autentikációt;
- shell parancsokat;
- workflow triggereket;
- secretkezelést;
- jogosultságokat;
- CI/CD konfigurációt;
- deployment folyamatokat.
GitHub Actions módosításakor minden esetben fel kell tenni néhány alapvető kérdést:
- Ki tudja elindítani ezt a workflow-t?
- Mely inputokat kontrollálhat egy külső felhasználó?
- Mikor történik a
${{ }}expression expansion? - Milyen credentialök érhetők el a job számára?
- Hová kommunikálhat a runner?
- Mi történik, ha valaki command executiont szerez?
A nem megbízható értékeket nem szabad közvetlenül shell scriptbe illeszteni.
Ha inline script használata elkerülhetetlen, az adatot köztes környezeti változóba kell helyezni, majd megfelelő quoting mellett feldolgozni.
Strukturált JSON-adatokat string concatenation helyett olyan parserrel érdemes létrehozni, mint például a jq.
Az issue-k, pull requestek vagy kommentek által külső felhasználók számára indítható joboknak lehetőleg nem szabad érzékeny credentialöket kapniuk.
A privilegizált secretkezelést külön, kontrollált jobokra érdemes szétválasztani.
A legfontosabb tanulság
A Snowflake gyorsan reagált, a credentialt lecserélték, és a rendelkezésre álló auditadatok szerint kizárólag a Wiz fért hozzá az érintett környezethez az engedélyezett kutatás során.
Ezért az eset végül sikeres responsible disclosure, nem pedig igazolt rosszindulatú adatvédelmi incidens lett.
A szélesebb tanulság azonban komoly.
Az AI ma már jelen van:
- a kódírásban;
- a security remediationben;
- a code review-ban;
- a vulnerability discoveryben;
- az exploitfejlesztésben;
- az automatikus validációban.
Ez azt jelenti, hogy a sérülékenységek létrejötte és felfedezése közötti idő tovább csökkenhet.
Egy AI képes lehet egy látszólag meggyőző biztonsági javítással eltávolítani egy meglévő védelmet.
Egy másik AI pedig napokon belül felismerheti a hibát, command executionné alakíthatja és credentialt szerezhet vele.
A Snowflake esetében a második AI egy engedélyezett biztonsági kutató rendszeréhez tartozott.
A következő lehet, hogy már nem fog.
