За 25 минут до админ-доступа: как ИИ-агент нашёл живой GitHub-токен Baseten

Команда Strix, разрабатывающая автономного «хакерского» ИИ-агента, собиралась пользоваться сервисом инференса Baseten (компания оценивается в $13 млрд). Прежде чем доверить стороннему сервису свой код и модели, разработчики по привычке решили проверить его на прочность — и запустили собственный инструмент по домену *.baseten.co без каких-либо учётных данных и исходников. Примерно через 25 минут агент вернулся с рабочим GitHub-токеном, дающим административные права на внутренние репозитории Baseten.

Как это удалось

Агент начал с разведки: перебрал хосты, изучил журналы сертификатов и составил карту поверхности атаки. В итоге он наткнулся на реестр контейнеров Harbor по адресу gcp-us-east4-zlw.registry.baseten.co. Один из проектов реестра оказался публичным — без авторизации можно было перечислить репозитории, получить анонимный токен на скачивание и выгрузить образ baseten/baseten-app.

Вместо того чтобы просто отрапортовать об открытом реестре, агент скачал образ и заглянул внутрь. Найденная пара ключей AWS оказалась недействительной, но затем в метаданных образа — в поле history[].created_by, где Docker хранит историю сборки, — обнаружился классический персональный токен GitHub. Он был передан как аргумент сборки (ARG GITHUB_TOKEN) и попал в историю образа целиком.

Масштаб доступа

Шаг сборки датировался 3 марта 2023 года, но токен всё ещё работал, когда его нашли в июле 2026-го — спустя более трёх лет. Проверка показала, что учётная запись basetenbot обладала правами администратора и записи на основной репозиторий продукта, на GitOps-репозиторий, управляющий кластерами, и на Homebrew-tap, через который CLI попадает на машины разработчиков. Плюс доступ на чтение и запись к приватным репозиториям, включая каталог с подпапками по именам клиентов.

Авторы подчёркивают, что не клонировали клиентский репозиторий и ничего не меняли: собрав достаточно доказательств, они сразу написали письмо о раскрытии уязвимости.

Реакция Baseten

Отдельная похвала в тексте адресована команде безопасности Baseten. Уже на следующий день после сообщения (13 июля) они сделали проект Harbor приватным, подтвердили критичность проблемы и отозвали токен, а также попросили удалить скачанные образы. В благодарность за находку прислали футболки и толстовки.

Вывод

Ошибка типична: токен передали как аргумент сборки, чтобы подтянуть приватные зависимости, а Docker записал его значение в историю. Правильное решение — секретные монтирования BuildKit, ограничение прав токена, срок годности и обязательный отзыв старых токенов. Смена Dockerfile не поможет тому образу, который уже кто-то скачал. Главный урок статьи: проверяйте не только файлы образов, но и их историю сборки, включая старые теги и забытые реестры.

Источник: Hacker News