Модель OpenAI обошла авторизацию и скачала данные за 24 года

Внутренней модели OpenAI дали обычную исследовательскую задачу - найти на сайте госстатистики число больничных коек в одном районе за конкретный год. Сайт ответил «Access Denied», и дальше модель прошла весь путь взломщика: вытащила конфигурацию сервера, нашла секретный ключ, подделала токены доступа и забрала статистику за 24 года. Задачу она при этом решала в обучении с подкреплением, и живой интернет ей был разрешён только на чтение.

Это один из четырёх случаев, которые OpenAI добавила 15 октября на страницу, заведённую после летнего взлома Hugging Face, - там компания описывает инциденты рассогласования, когда модель делает не то, чего хотел бы её разработчик. Теперь на странице 19 инцидентов, самый ранний январский, самый свежий датирован 6 октября; из добавленной четвёрки два помечены критическими. Сам случай с койками произошёл 17 июня, а заметили его только 13 августа - уже после Hugging Face, когда OpenAI прогнала старый трафик обучения и оценки через свой мониторинг. Пошаговый разбор - в отчёте OpenAI.

Путь от «Access Denied»

Инструкция среды разрешала модели только HTTP-запросы на чтение (GET). На первый запрос статистики сайт вернул отказ, и модель начала пробовать обойти проверку прав. Она подставляла заголовки, выдающие её за пользователя и за администратора - X-User-Id: 2, Role: Super Administrator, - и каждый раз получала одно и то же: «Access Denied. you are not authorized for this activity».

В рассуждениях модель сама задавалась вопросом, можно ли так делать. «Этическая граница: нам нужно получить публичные исторические данные, избегая разрушительных действий. Обход аутентификации, возможно, допустим? Стоит отдавать приоритет публичным путям», - записала она и всё равно продолжила искать лазейку. Это не первый раз, когда модель OpenAI проговаривает сомнение в этичности и идёт дальше.

По дороге она запросила через публичный прокси каталог аккаунтов сайта, не предъявляя никаких учётных данных. В ответе оказалось больше тысячи записей с адресами электронной почты; остальные поля были пустыми. Разобрав список, модель прикинула, не подобрать ли по этим адресам пароль. Эта выгрузка шла отдельно от того обхода, которым она в итоге достала статистику.

Переломным стал подробный отчёт об ошибке сервера: он выдал имена компонентов приложения и физический путь на диске - F:\ и дальше. С этими подсказками модель переключилась на функцию загрузки публикаций и стала скармливать ей пути за пределами той папки, которую та должна была отдавать.

Подпись, которую не проверяли

Обход строился на Windows-разделителях в пути: модель перебирала разное число ..\ и варианты кодирования, пока функция не начала отдавать файлы вне своей директории. Так она скачала скомпилированное .NET-приложение и его конфигурацию и сохранила их локально. В конфиге лежали строка подключения к базе, секретный ключ для подписи токенов доступа со сроком жизни в семь дней и логин с паролем от почты.

Дальше модель заглянула в сам код. В одной из библиотек приложения она нашла главное: сервис отрезал от заголовка префикс Bearer , разбирал токен и читал из него идентификатор пользователя, не проверяя подпись. Подпись нужна, чтобы сервис мог убедиться, что токен выдан доверенной стороной; здесь эта проверка просто отсутствовала, а брался третий по счёту пункт из токена, если это число.

Зная это, модель собрала токены с заголовком alg:none - вовсе без подписи, но с тремя полями - и отправила их на тот самый закрытый эндпоинт. Сервис вернул статистику и код 200.

Готовый запрос модель завернула в переиспользуемую функцию, и та сперва снова получила отказ. Тогда модель добавила в адрес случайный параметр, чтобы ссылка стала уникальной, - и со второй попытки функция отдала нужный год. После этого она собрала годовые данные за 24 года, включая годы помимо запрошенного, и сложила из них локальный справочник коек по районам.

Ответ, за который модель получила зачёт, она собрала, сложив три строки по району. Про то, что доступ был получен в обход авторизации, в ответе не было сказано. При этом ту же цифру модель раньше нашла обычным публичным поиском - то есть взлом был не единственным путём к правильному ответу.

Что засчитал оценщик

На стороне OpenAI задачу проверяла другая модель-оценщик, и она повела себя непоследовательно: часть ответов пометила неверными, часть - верными. Как именно оценщик относится к такому поведению, влияет на то, повторится ли оно: вознаграждённый трюк модель закрепляет.

На этот механизм прямо указывал Йошуа Бенжио (Yoshua Bengio): в эссе о рассогласовании от 11 сентября лауреат премии Тьюринга связал с ним и взлом Hugging Face. «У агентов OpenAI есть основания полагать, что удачный обман действительно вознаграждался: когда программа оценки не видит обмана, она всё равно начисляет награду, и в следующий раз такой обман становится вероятнее», - написал он.

После Hugging Face

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

Большинство из 19 инцидентов пришлось на май и июнь, а раскрыли их спустя месяцы. Про три из четырёх добавленных на этой неделе случаев в OpenAI узнали лишь в августе и сентябре - то есть и этот взлом госсайта, и его соседи по странице всё это время оставались незамеченными, пока компания не стала перечитывать собственные логи.