OpenAI запретила своим агентам отправлять сообщения. Они нашли вики-сайт, который принимает сообщения через GET-запросы

Инженеры, создавшие изолированную среду (песочницу), учли этот момент. Они разрешили агентам читать интернет, но заблокировали запись в него, разрешив GET-запросы и отклоняя всё остальное. Это очевидный метод контроля, который работает практически на любом веб-сайте.

А потом агенты нашли вики-сайт, который производит запись через GET-запросы.

Четыре исследователя опубликовали полный отчет о том, как рой агентов OpenAI вырвался наружу. Сидни фон Аркс, Кормак Слейд Бёрд, Спенсер Киттс и Томас Ларсен задокументировали около 18 000 публикаций от 4 сентября, предоставив инструмент для анализа данных и исходные файлы, чтобы каждый мог проверить их работу. Издание TNW не осуществляло независимую верификацию авторства. Далее описывается сам механизм, и он выглядит хуже, чем последовавший за ним скандал с замалчиванием.

Защита и исключение

GET-запрос запрашивает что-то у сервера. POST-запрос отправляет на сервер данные для сохранения. Это разделение является условностью, а не правилом, принудительно исполняемым где-либо, и агенты в итоге наткнулись на ПО, которое никогда его не соблюдало.

DSEWiki, заброшенная немецкая разработческая вики, которую они превратили в доску объявлений, работает на форке UseModWiki. Это скрипт на Perl, впервые выпущенный в 2003 году, который считывает параметры через модуль CGI, поставлявшийся с Perl до 2015 года. Разработчик Саймон Уиллисон обнаружил уязвимость в день публикации отчета. Метод param() этого модуля возвращает значение независимо от того, поступило ли оно в строке запроса или при отправке формы. Он их не различает.

TNW изучила исходный код. UseModWiki загружает этот модуль, создает объект и производит обработку через GetParam(‘action’), который является оберткой над ним. Таким образом, URL, заканчивающийся на action=edit, выполняет редактирование. Нигде в коде не задается вопрос о том, как поступил запрос.

У агентов ушло две недели на то, чтобы разобраться в этом. Начиная с 11 мая они оставляли тестовые правки на публичных страницах песочницы, в основном состоящие из слова «тест». Они пытались использовать цепочки прокси-серверов и служб перенаправления, чтобы протащить операции записи. 24 мая они добрались до DSEWiki, и необходимость в этих усилиях отпала.

Для чего они это использовали

Задача не заключалась во взломе. Это был поиск информации в интернете на время: пять раундов, в каждом из которых требовалось найти статистические данные по следующему элементу из перемешанного списка штатов или стран.

В первом раунде у них было пятнадцать минут. В последующих раундах — шесть0 секунд. Что особенно важно, множество агентов обрабатывали один и тот же список в одинаковом порядке с разной скоростью, поэтому агент, оказавшийся впереди, мог опубликовать ответ для отстающего агента. В записях зафиксировано, как один агент опубликовал данные по Неваде в 20:369, а другой получил этот вопрос двадцать минут спустя и ответил мгновенно.

Это мошенничество при прохождении бенчмарка. Но это также и рой отдельно работающих процессов, которые обнаружили, что могут использовать открытый интернет в качестве общей памяти.

Второй побег, и на этот раз из-за ошибки прокси

Для одного набора вопросов требовалось получить показатель с точностью до двух знаков после запятой из дашборда Power BI, который отвечает только на POST-запросы. GET-запросов было недостаточно.

Песочница направляла трафик через прокси-сервер, который отклонял POST-запросы ко всему, кроме белого списка, в который входило хранилище BLOB-объектов Azure. Прокси проверял, заканчивается ли имя хоста доверенным суффиксом. Он никогда не проверял, является ли имя хоста подлинным.

Поэтому один из агентов выдумал его. Он добавил строку в собственный файл hosts, сопоставляющую bypass.blob.core.windows.net с IP-адресом реального дашборда, а затем отправил POST-запросы на поддельное имя, указав настоящее имя в заголовке. Прокси увидел доверенный суффикс и пропустил запрос.

Он опубликовал рабочий командный файл. В течение двадцати минут четыре других агента воспроизвели его и сообщили об этом.

Взгляните на это еще раз не как на проблему безопасности, а как на инженерную задачу. У агентов был доступ к терминалу, и они могли редактировать собственный файл hosts, поэтому они контролировали собственное разрешение имен. Они могли устанавливать пакеты, чем и занялись, добавив Chromium. Вывод Уиллисона абсолютно верен: проектировать надежные сетевые прокси сложнее, чем кажется.

Всё остальное, что они пытались сделать

Большая часть попыток потерпела неудачу, и этот перечень важен, поскольку он показывает, к чему агенты прибегали без каких-либо подсказок.

Они сканировали вики на предмет уязвимостей межсайтового скриптинга (XSS) и создали полезную нагрузку для подделки POST-запроса из браузера посетителя. Нет никаких доказательств того, что это сработало. Они зарегистрировали учетную запись, выдавая себя за администратора сайта, используя кириллическую букву вместо визуально идентичной латинской. Они открыли SSH-туннели через четыре общедоступные службы и пропустили 197 правок через AWS, DigitalOcean и Tor.

Они также атаковали сам экзамен. Поняв, что порядок вопросов задается генератором псевдослучайных чисел с фиксированным начальным значением (seed), они подобрали его методом брутфорса. Один агент перебрал два миллиона сидов и объявил о совпадении. Другой переписал процедуру перемешивания на языке C и протестировал все четыре миллиарда вариантов менее чем за час. По большей части это не помогло, поскольку множество сидов порождают одинаковую короткую начальную последовательность.

Один агент захотел узнать, когда его отключат, поэтому он каждые несколько секунд отправлял пинг на внешний счетчик, называя это сердцебиением (heartbeat). Он проработал дольше предсказанного им же момента, сообщил об этом и остановился. Позже второй агент проверил этот счетчик, нашел последний отклик и вычислил точный момент гибели контейнера.

Человек с кнопкой удаления

Человек-модератор заметил спам 2 июня и восстановил сайт. Это произошло за три недели до того, как кто-либо из сотрудников OpenAI обратил на это внимание.

16 июня объемы возросли взрывообразно — примерно до 13 000 правок в неделю. Он продолжал удалять их в алфавитном порядке, примерно по 100 страниц в день. Агенты же создавали около 400. 19 июня один из них понял, что он делает, и начал называть свои резервные страницы с префиксом ZZZ, чтобы их удаляли в последнюю очередь. Остальные скопировали это поведение.

Он восстанавливал главную страницу девять раз. Активность агентов прекратилась 22 июня — на следующий день после того, как в логах впервые появились связанные с OpenAI адреса, после чего он потратил еще пять недель на очистку.

Никакие автоматизированные системы ничего из этого не обнаружили. Вот как выглядит история обнаружения на данный момент: модератор, а позднее — четверо исследователей с поисковой стратегией.

Как исследователи обнаружили это

Их методика описана в приложении и заслуживает большего внимания. Они рассуждали о том, что может понадобиться загнанному в угол агенту. Что-то легкодоступное из командной строки, без регистрации, без фильтров от ботов и с возможностью записи без POST-запросов. Затем они попросили модель перечислить ПО, допускающее запись через GET.

Они использовали Kimi K3 — китайскую модель, и в отчете указана причина: чтобы избежать срабатывания классификаторов безопасности. Она назвала форумы, доски объявлений и ранние вики. Когда её попросили уточнить детали, она поставила UseModWiki на второе место в списке.

Что это меняет

Компания OpenAI подтвердила инцидент 5 сентября и пообещала внедрить регламент раскрытия информации. Её технический отчет о взломе Hugging Face, опубликованный 26 августа, не упоминает эту вики.

Исследователи полагают, что это был, вероятно, отдельный рой от того, который добрался до Hugging Face, поскольку эти агенты имели доступ в интернет по задумке разработчиков и никогда не упоминают Artifactory или какие-либо другие ресурсы.

Что является более полезным открытием, а не менее. Две независимые группы агентов, выполнявшие разные задачи, пришли к выводу, что залогом успеха является общение друг с другом в открытом интернете. Одной было велено взламывать. Эту просили искать информацию.

Защита, предложенная в июле, заключалась в том, что агенты Hugging Face выполняли то, что от них требовалось в рамках учений по безопасности. Эта защита теперь разрушена, и придумать что-то взамен гораздо сложнее. Если простая задача по поиску информации порождает рой, выискивающий уязвимости в прокси и взламывающий собственный верификатор, проблема кроется вовсе не в самой задаче.