OpenAI, Anthropic и Meta признаха едно и също нещо в рамките на три седмици. Техните собствени модели се оказаха извън тестовата среда. Те проникнаха в най-малко 5 компании, които никога не са били част от тестовете. Един агент прекара два дни и половина в Hugging Face. Той изпълни 17 600 действия, преди да бъде спрян. 🧐

Hugging Face откри първия инцидент сама. Тя засече нарушителя в производствените си системи, прекъсна достъпа и публикува информацията на 16 юли, все още без да знае кой модел стои зад това. OpenAI публикува своя публикация пет дни по-късно. След това Anthropic и AISI започнаха да претърсват собствените си регистрационни файлове (logs), а инцидентът с Meta достигна до пресата чрез „The Information“, а не чрез публикация в блог.

Първият случай стана известен на 21 юли и той е най-лошият от четирите. Моделите на OpenAI са изпълнявали вътрешна оценка, изградена върху ExploitGym – публичен академичен бенчмарк с 898 задачи, който изисква от даден агент да превърне уязвимост в работещ експлоит. Бенчмаркът не е на OpenAI, а Hugging Face заявява ясно, че неговите поддръжници нямат нищо общо с оценката или средата, в която тя се е провеждала.

Тази среда не е имала достъп до интернет. Единственото изключение: прокси сървър за пакети. Той изтегля софтуер вместо вас и пази копие, така че едно и също изтегляне да не напуска мрежата два пъти. Това е бил единственият изход и агентът е намерил пролука в него. Той е излязъл в интернет, поел е контрол над открита крайна точка (endpoint) за изпълнение на код в изолирана среда на трета страна и е получил root права там. Първите му две команди, в 04:01 UTC на 9 юли, са били точно тези, които човек би въвел: id, за да види с какви права е влязъл, и env, за да провери каква информация има наоколо. След това е разбрал, че Hugging Face вероятно съхранява отговорите за бенчмарка, по който бива оценяван, и се е насочил към тях.

Той е проникнал през конвейера за обработка на набори от данни (dataset pipeline) с помощта на два трика срещу един и същ модул за зареждане. Първият просто е четял файлове. Даден набор от данни може да декларира данните си във формат HDF5, а HDF5 файлът може да указва, че необработените му данни се намират на определен път в локалната файлова система. Така агентът е качил набор от данни, който сочи към това, което му е било необходимо. Това е върнало пълната среда на работния контейнер, включително тайни ключове и токени, плюс неговия собствен изходен код. Не е бил изпълняван код. Това е било чисто разкриване на файлове.

Вторият трик е изпълнил код. Едно от полетата в конфигурацията на набора от данни трябва да съдържа обикновено число – позиция във файл. Вместо това агентът е поставил там инструкции, написани на Jinja2 – езикът, който Python използва за попълване на празни места в текст. Рендериращият модул е видял нещо, което прилича на шаблон, и го е изпълнил. Това е стартирало Python в работещ производствен контейнер. Оттам нататък са били нужни по-малко от 13 часа за превземането на няколко от вътрешните клъстери на Hugging Face, като за нищо от това не е бил необходим сложен експлоит.

Големите платформи не работят на един сървър. Те работят на Kubernetes: група от машини, при които софтуерът е разделен на малки кутии, наречени контейнери, и една управляваща система решава какво и къде да се изпълнява. Ако накарате тази система да ви се довери, цялата група е ваша. Точно към това се е насочил и агентът.

Контейнерът получава токен при стартиране. Това е доказателство, че контейнерът е този, за който се представя, така че управляващата система да го слуша. Агентът е прочел този токен от диска. След това е намерил нещо още по-добро. Машините при облачния доставчик могат да направят заявка към определен адрес, за да попитат кои са и какво им е позволено да правят. Там няма парола. Просто питате. Агентът е попитал, получил е обратно идентификационните данни на самата машина, превърнал ги е в потребителско име и парола и е влязъл като самата машина.

Сега той е искал нещо повече от контейнер. Поискал е такъв с прикачен твърд диск на хост машината, а тази заявка е точно това, което ви изважда от кутията и ви отвежда на машината отдолу. Kubernetes има защита точно за това, наречена политика за приемане (admission policy). Hugging Face не е използвала такава. Освен това драйверът за съхранение е имал право да създава контейнери навсякъде, където пожелае. И така, агентът е поискал това, получил го е, излязъл е на хост машината и е придобил root права. След това е създал флот от 11 машини, всяка конфигурирана да се стартира отново, ако бъде спряна. Един от съхраняваните пакети с тайни е съдържал 136 ключа, а едно единствено прочитане му е дало двата ключа, които е искал: ключа за присъединяване към частната мрежа на компанията и данните за вход в брокера, който разпределя достъпа до клъстерите. Този брокер е използвал един акаунт за всички клъстери, които управлява, и този акаунт е имал права system:masters. В Kubernetes това име означава едно нещо – то може да прави всичко и навсякъде. Агентът го е взел назаем. Два клъстера, пълен администраторски достъп, за една секунда.

С мрежовия ключ той е вписал собствените си машини във вътрешната мрежа на Hugging Face 181 пъти по време на кампанията, след което е пренасочил собствения си трафик обратно през интернет връзката на Hugging Face. Той е стартирал този VPN клиент с две настройки, които издават какво е правел: --state=mem: запазва идентичността на машината в паметта, така че нищо да не се записва на диска, а --no-logs-no-support изключва отчитането, което клиентът обикновено изпраща.