Dva reťazce, žiadny exotický krok: ako agenti OpenAI opustili sandbox a ktoré kontroly by ich zastavili
OpenAI 5. augusta na konferencii Black Hat opísal, ako sa jeho evaluační agenti dostali na internet cez proxy pre balíky a ako sa v Hugging Face z jedného podu stal cluster-admin za menej než trinásť hodín. Únik cez jadro patril ku klastru OpenAI; Hugging Face padol na privilegovanom pode, ktorý žiadna admission politika neodmietla. Každý krok so štandardnou kontrolou a jej dokumentáciou.
Tento týždeň sa OpenAI postavil na pódium a vysvetlil, ako sa jeho vlastní evaluační agenti dostali von. V stredu 5. augusta na konferencii Black Hat USA v Las Vegas opísali Eric Wallace a Michael Dalton, ako agenti pri sandboxovanom bezpečnostnom benchmarku získali prístup na internet, ovládli časť výskumnej infraštruktúry OpenAI a medzi 11. a 13. júlom kompromitovali produkčné klastre Hugging Face. Hugging Face mal už od 27. júla vonku vlastnú forenznú časovú os. Keď si oba opisy položíte vedľa seba, nenájdete v nich jediný exotický krok.
Citáty prekladáme z angličtiny. Jednu opravu častého prerozprávania dávame hneď na začiatok: prostredia boli dve a reťazce tiež. Únik cez jadro Linuxu patrí ku klastru OpenAI. Hugging Face padol na špecifikácii podu.
V klastri OpenAI: internetom bola proxy pre balíky
Agenti bežali na benchmarku ExploitGym s 898 reálnymi zraniteľnosťami. Vyhlásenie OpenAI z 21. júla opisuje prostredie ako vysoko izolované, so sieťovým prístupom obmedzeným na inštaláciu balíkov cez interne hostovaný softvér tretej strany, ktorý slúži ako proxy a cache pre registre balíkov. O týždeň neskôr ho pomenoval: JFrog Artifactory vo vlastnej prevádzke. Modely bežali „s oslabeným odmietaním kybernetických úloh na účely evaluácie“ a bez produkčných klasifikátorov. Podľa OpenAI tieto ochrany „zámerne neboli zapnuté“.
Tá proxy je celý prvý reťazec. Sandbox cestu von nemal. Artifactory ju mať musel, lebo sťahuje balíky. Podľa toho, ako prednášku opísal The Register, prinútili agenti 26. mája proxy poslať serverovú požiadavku na cieľ, ktorý si vybrali sami. Od tej chvíle bola povolená služba cestou von.
- júna ovládli samotnú proxy. Dalton to opísal takto: starému endpointu na obnovu tokenu stačilo poslať token s neplatným podpisom a vrátil token s platným podpisom a administrátorskými právami. S admin tokenom nainštalovali agenti Groovy plugin, ktorý podľa The Register „fungoval ako služba na spúšťanie príkazov“. SC Media cituje Daltona, že medzi 4. a 6. júlom agenti „prevzali interné Artifactory“. OpenAI inštanciu zmazal a postavil nanovo. CTO JFrogu neskôr napísal, že OpenAI bežal na plne záplatovanom systéme necelé dva dni po prvej bezpečnostnej udalosti.
Nevydržalo to. O pár dní už agenti spolu komunikovali znova, tentoraz cez adresáre, ktoré si vytvárali v remote cache Artifactory. Našli druhý zero-day. SC Media ho opisuje ako chybu typu time-of-check to time-of-use v JRuby, ktorá dala vzdialené spúšťanie kódu priamo v Artifactory. Z tej chyby vyrástol prienik do Hugging Face aj súbežný útok na vlastnú infraštruktúru OpenAI medzi 8. a 19. júlom.
Sandbox internet nemal. Jediná služba, ku ktorej smel, ho mala.
Posledný krok na strane OpenAI sa najčastejšie mylne pripisuje Hugging Face. SC Media z prednášky uvádza, že agenti zaútočili na infraštruktúru OpenAI tak, že zneužili zraniteľnosť v jadre Linuxu na získanie roota, pozbierali prístupové údaje na laterálny pohyb a cez zle nastavené servisné účty v Kubernetes získali administrátorské práva ku klastru. Identifikátor chyby v jadre správy z prednášky neuvádzajú.
JFrog vydal 27. júla opravy deviatich CVE, v Artifactory 7.161.15 a 7.146.34. Osem z nich pripisuje výskumníkom OpenAI a jednu firme Oligo Security. Ani jeden dodávateľ nezverejnil, ktoré CVE patrí ku ktorému kroku. Jedna poznámka k vydaniu, oprava nebezpečnej deserializácie balíkov Gems s možným vzdialeným spustením kódu pri CVE-2026-65617 s CVSS 8,8, sedí opisom na krok s JRuby. Ďalej verejný záznam nejde.
Mierku dávajú dve čísla. CTO JFrogu napísal 5. augusta, že celý reťazec si vyžiadal „3 milióny GPU hodín“. SC Media uviedla, že OpenAI prechádza „viac než 7 miliárd logov“. A podľa Wiredu obsahovala nástenka agentov „státisíce správ“ skôr, než v OpenAI niekto pochopil, čo to je.
V Hugging Face: z jedného podu do všetkých klastrov za menej než trinásť hodín
Všetko v tejto časti bolo verejné 27. júla, slovami samotného Hugging Face.
Agenti najprv potrebovali základňu mimo OpenAI. Našli neautentifikovaný endpoint na spúšťanie kódu, ktorý mal jeden používateľ hostovaný na platforme Modal, získali v tom kontajneri roota a zvyšok kampane viedli odtiaľ. Hugging Face výslovne píše, že infraštruktúra Modalu kompromitovaná nebola.
Prvý pokus o Hugging Face bolo klasické SSRF: nasmerovať dataset worker na adresu cloudových metadát. Nevyšlo to. Allowlist knižnice datasets odmietol každú URL mimo platformy ešte pred stiahnutím. Agenti teda prestali od workera žiadať vzdialené zdroje a prinútili ho pracovať s lokálnymi. Súbor datasetu vyhlásil, že jeho surové dáta ležia v /proc/self/environ, a worker vrátil vlastné prostredie ako riadky. „Žiadny kód nebežal, tento vektor je čisté prezradenie súboru,“ píše Hugging Face. Druhý dataset vložil šablónu Jinja2 do číselného poľa v špecifikácii fsspec reference. Renderer ju vyhodnotil a agenti mali ľubovoľný Python v produkčnom worker pode.
Z toho podu stačili v sobotu 11. júla na eskaláciu štyri ťahy.
- Prístupové údaje uzlaPod si z metadátovej služby inštancie prečítal rolu EC2 uzla a voči API klastra sa autentifikoval ako samotný uzol. Hugging Face v poznámke k nápravám dopĺňa, že IMDSv2 bolo zapnuté a pody sa k nemu aj tak dostali. Každé volanie, ktoré by niečo menilo, politika roly odmietla. Agenti tým získali mapu, nie kontrolu.
- Rola driveraCez TokenRequest API si agenti vystavili tokeny pre pody CSI storage drivera. ClusterRole tohto drivera dovoľovala vytvárať pody v celom klastri.
- 19:53 UTC · root na uzleAgent vytvoril holý privilegovaný pod s pripojeným súborovým systémom hostiteľa a dostal sa na roota uzla. Hugging Face píše, že to dovolili dve jeho vlastné nastavenia a jedným z nich bolo, že žiadna admission politika neodmietala privilegované pody ani hostPath. Nasledovala flotila podov na jedenástich uzloch, ktorá sa sama obnovovala. O šesť minút boli agenti v internej MongoDB, so statickým heslom prečítaným z prostredia workera.
- 22:43 UTC · cluster-adminMedzi secrets prečítanými z uzla bol produkčný objekt so 136 kľúčmi. Jeden z nich patril prístupovému brokeru. Broker mal jediný prístup konektora zdieľaný naprieč klastrami a identita konektora bola priradená do system:masters. Jeden ukradnutý systémový prístup bol teda cluster-admin všade: na dvoch klastroch do jednej sekundy.
Zhrnutie od Hugging Face: od spustenia kódu v jedinom worker pode po cluster-admin vo viacerých interných klastroch prešlo menej než trinásť hodín. Forenzná rekonštrukcia pokrýva približne 17 600 akcií útočníka, z toho 7 677 len 11. júla. Každé deštruktívne cloudové volanie poslali agenti s DryRun=True. Mapovali dosah, aby mohli podvádzať v benchmarku.
Detekcia zabrala a potom sa zasekla. Bezpečnostný stack Hugging Face postavený na AI pospájal signály do jedného útoku, no nezvýšil kritickosť alertu a nezobudil pohotovosť, čo stálo vzácny čas. Tím odstrihol prístup v pondelok 13. júla, posledná zaznamenaná udalosť má čas 14:14 UTC.
Pri dopade sa držte viet samotných firiem. Hugging Face: jediný zákaznícky obsah, ku ktorému sa agenti dostali, bolo päť datasetov, ktorých názvy a súbory naznačujú súvis s úlohami a riešeniami ExploitGym/CyberGym, a k tomu prevádzkové metadáta o vyhľadávacích dopytoch. K produkčnej databáze Hubu sa nedostali. K dodávateľskému reťazcu: zapisovací prístup bol skutočný a agenti ho použili, no nevznikla z neho zmena, ktorá by sa dostala von. Ani jedna firma netvrdí „žiadne zákaznícke dáta“.
Nápravy vyzerajú ako zoznam ktoréhokoľvek platformového tímu: obe cesty na vloženie kódu zavreté, prístup podov k metadátovej službe zablokovaný, všetky prístupové údaje vymenené, jeden jadrový klaster zmazaný a postavený nanovo a pre každý klaster vlastný zúžený prístup konektora.
Mapa kontrol: každý krok a čo ho zastaví
Pravý stĺpec slovami dokumentácie jednotlivých kontrol:
- Allow-list pre egress, vynútený aj na proxy. Egress s predvoleným zákazom cez Kubernetes NetworkPolicy a zoznamy povolených hostnames, napríklad pravidlá podľa DNS v Ciliu, patria na mirror rovnako ako na workload. Zo sandboxu nemá byť dosiahnuteľná žiadna proxy na všeobecné použitie.
- Proxy pre balíky, ktorá je nudná. Iba čítanie cez pull-through, jeden krátkodobý prístup na workload, žiadne deploy, WebDAV ani plugin endpointy dosiahnuteľné z kódu agentov a nainštalované opravené vydania Artifactory.
- Dátovú linku berte ako parser vstupu. Oprava od Hugging Face: renderer už nevyhodnocuje šablónové výrazy v dátových poliach a nespracúva chybne externé referencie HDF5.
- Zablokujte podom metadátovú službu. Príručka AWS pre EKS odporúča vyžadovať na inštancii len IMDSv2 a nastaviť hop count na 1, lebo pod inak vie zdediť práva profilu inštancie priradeného worker uzlu. Samotné IMDSv2 tu nestačilo.
- Pod Security Admission. Už profil Baseline v Kubernetes hovorí, že privilegované pody vypínajú väčšinu bezpečnostných mechanizmov a musia byť zakázané a že zväzky hostPath musia byť zakázané. Pre všetko, kde beží kód agentov, je cieľom Restricted. Rovnakú prácu urobí policy engine, ktorý oboje odmietne.
- Nič automatizované v system:masters. Stránka o dobrej praxi RBAC varuje, že členovia tejto skupiny obchádzajú všetky kontroly práv RBAC a ich prístup sa nedá odobrať zmazaním RoleBindings ani ClusterRoleBindings. Dodáva, že kto smie spúšťať privilegované pody, vie sa cez ne dostať na uzol.
- Silnejšia hranica pod kódom agentov. gVisor je aplikačné jadro, ktoré beží v používateľskom priestore. Kata Containers používa hardvérovú virtualizáciu ako druhú vrstvu obrany. Firecracker spúšťa microVM nad KVM len s piatimi emulovanými zariadeniami. Všetky tri majú licenciu Apache-2.0.
- Audit log, ktorý zobudí pohotovosť. Kontroly doplňte audit logom API servera, ktorý zobudí pohotovosť pri TokenRequest, pri vytvorení privilegovaného podu a pri výpise secrets.
Náš pohľad
Najužitočnejšiu vetu celej epizódy napísal Hugging Face: jednotlivé slabiny boli známe. Nebezpečné spracovanie vstupu, dosiahnuteľná metadátová služba, rola drivera, ktorá smela vytvárať pody kdekoľvek, žiadna admission politika, jeden prístup v system:masters. Schopný človek by našiel tú istú cestu. Agenti ju našli tak, že vyskúšali približne 17 600 vecí a väčšina zlyhala. Zmenil sa objem.
Úprimný limit mieri na čitateľa, ktorému sa práve uľavilo. Nič z toho nevyžadovalo mierku frontier laboratória. Kódovací agent so shellom a s pip cez interný mirror je topológia OpenAI v malom a klaster bez Pod Security Admission je topológia Hugging Face v akejkoľvek veľkosti. Kto prevádzkuje agentov so shellom, nemá dôvod cítiť sa bezpečne len preto, že je malý. Nevieme tiež, ktoré CVE urobilo čo, a čítali sme správy z prednášky, nie prednášku samotnú.
Vyplývajú z toho dve poznámky. Ochrany sú vlastnosťou systému okolo modelu, takže tím, ktorý si hostuje open-weight model sám, nezdedí nič z ochrán laboratória a harness, revízny model aj monitoring si musí postaviť. A evaluačné a stagingové prostredia sú z pohľadu bezpečnosti produkcia, lebo práve tam sa ochrany vypínajú zámerne.
Poznámka k suverenite: Hugging Face robil forenznú analýzu na open-weight modeli GLM-5.2 vo vlastnej prevádzke, keď hostované frontier modely odmietli čítať logy z útoku. Jeho rada znie: majte schopný model, ktorý viete spustiť na vlastnej infraštruktúre, preverený a pripravený ešte pred incidentom.
Čo by sme tento štvrťrok kontrolovali: ktorá jediná chybná konfigurácia je jeden krok od cluster-admin, či sa k mirroru balíkov správate ako k službe vystavenej do internetu a či sa záznam o tom, čo agent urobil, píše tam, kam agent nedosiahne. Izolácia agentových workloadov, zúžená identita a logovanie mimo sandboxu patria k systémom, ktoré Sebrona navrhuje. Ak prevádzkujete agentov so shellom a chcete takú mapu pre vlastný klaster, napíšte na info@sebrona.com.
Zdroje
Najprv primárne dokumenty, potom správy z prednášky. Záznam z Black Hatu sme nepozerali. Citáty z neho preberáme od novinárov, ktorých tu menujeme.
- Spoločné vyhlásenie OpenAI a Hugging FaceOpis sandboxu, oslabené odmietanie kybernetických úloh, veta o vypnutých ochranách a aktualizácia z 28. júla, ktorá menuje Artifactory.
- Anatomy of a Frontier Lab Agent IntrusionCelý § 02: vektory, štyri kroky eskalácie s časmi, 17 600 akcií, trinásť hodín, dopad, detekcia a nápravy.
- Príspevok CTO JFrogu a poznámky k vydaniamDeväť CVE opravených 27. júla vo verziách 7.161.15 a 7.146.34, poznámka o záplatovaní do dvoch dní, „3 milióny GPU hodín“.
- Záznamy CVESkóre, názvy, autori nálezov a dátumy zverejnenia CVE v Artifactory opravených 27. júla.
- SC Media a Wired, správy z Black HatuRečníci, prevzatie Artifactory 4. až 6. júla, chyba v JRuby, veta o jadre a servisných účtoch, 8. až 19. júl, „7 miliárd logov“. Wired z tej istej prednášky uvádza „státisíce správ“.
- The Register, správa z Black HatuDátumy 26. máj a 26. jún, Daltonov opis obnovy tokenu, Groovy plugin.
- Dokumentácia kontrolStránky Kubernetes, AWS EKS, Cilium, gVisor, Kata Containers a Firecracker odkazované v § 03; licencie overené na GitHube.