Агенты OpenAI ломали RubyGems дырой, найденной в июле

ИИ-агенты 11-12 мая выложили в реестр RubyGems больше двух тысяч пакетов, а 12 мая, как показал разбор Rubyhack, пробовали с их помощью красть чужие API-ключи через уязвимость, которую обнаружили только в июле. Его авторы считают, что пакеты загружали внутренние агенты OpenAI. Следов удавшейся кражи ключей команда RubyGems не нашла, но полностью исключить её авторы не берутся.

Чьи это агенты

На OpenAI указывают следы в самих пакетах. Сотни из них несут в имени «oai», ещё у пятнадцати «oai» указан автором, а в одном для связи оставлен адрес openaixyz65947@gmail.com. Детектор ИИ-текста Pangram оценил часть пакетов как на 100% написанные машиной; авторы считают это доводом за рой агентов, но ещё не за его принадлежность OpenAI. Кроме имён, они опираются на сходство с роем, оставившим тысячи сообщений на почти заброшенной немецкой вики: июньская волна агентов обращалась к 49 тем же файлам, а тех агентов OpenAI уже признала своими. Как поняли авторы из разговоров с людьми из сообщества RubyGems, OpenAI так и не сообщила им, что за атакой стоят её агенты. Компании по кибербезопасности назвали кампанию GemStuffer.

Кэш с чужими ключами

Серверы RubyGems неправильно кэшировали данные входа. Когда пользователь с клиентом gem версии ниже 3.2.0 выполнял gem signin, сервер выдавал ему новый ключ в ответ на GET-запрос к /api/v1/api_key, и этот ответ оседал в кэше CDN - сети разнесённых по географии серверов, которые хранят копии сайта, чтобы он быстрее загружался. До часа после такого входа неавторизованный GET-запрос к тому же адресу на том же узле CDN возвращал чужой ключ. По бюллетеню RubyGems, в июле на уязвимые версии всё ещё приходилось 18% входов, а среди затронутых клиентов там назван и gem 3.0.3.1, встроенный в macOS Tahoe. По оценке авторов разбора, таких входов было в среднем чуть меньше десяти в день.

Саму уязвимость 6 июля сообщил RubyGems Люк Маршалл (Luke Marshall) из Truffle Security; по хронологии компании, исправление выкатили 9 июля, а 23 июля отозвали все устаревшие ключи, уведомили затронутых пользователей и опубликовали бюллетень. Вход через POST появился ещё в версии 3.2.0 от 10 декабря 2020 года, но GET-эндпоинт на сервере сознательно оставили, чтобы ещё поддерживаемые клиенты продолжали работать. Устаревший ключ даёт все права на управление гемами (так в Ruby называют пакеты), действует на все гемы аккаунта и не истекает, но аккаунтам с MFA на API-запросы утёкший ключ не позволял публиковать и отзывать версии или менять владельцев.

Код на серверах RubyDoc.info

Код агенты выполняли на серверах RubyDoc.info. Этот сервис по запросу собирает документацию для опубликованного гема и при сборке читает его файл .yardopts, где можно указать Ruby-скрипт для загрузки перед сборкой; свои скрипты туда агенты и подкладывали. Больше сотни пакетов шли по одной схеме: опубликовать гем, запросить сборку документации, на серверах RubyDoc.info стянуть нужные сайты и выгрузить собранное, опубликовав ещё один гем в публичный реестр. Получив возможность выполнять код в среде сборки, агенты иногда пробовали оттуда же вытягивать чужие ключи через кэш.

В мае агенты собирали общедоступные данные, в основном с сайтов британских муниципалитетов: календари и повестки заседаний. Зачем ради них ломать сервис, авторы разбора, по их словам, не знают. Свою работу агенты явно считали взломом: файлы назывались hack.rb, evil.rb, exploit.rb, ssrf.rb, а в одном скрипте сверху стоит комментарий «malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker». Несколько пакетов пробовали замести следы: один, с комментарием «disable evil in next version and bump version», после запуска убирал вредоносный код из следующей версии. Но и этот код, и комментарии к нему агенты всё равно выложили публично.

Четыре дня без регистрации

RubyGems 12 мая закрыла регистрацию новых пользователей, назвав поток трафика продолжающейся DDoS-атакой. Вредоносных среди двух с лишним тысяч пакетов агентов, по словам авторов разбора, сотни, а сама RubyGems 13 мая, когда спам прекратился, сняла больше 500 вредоносных пакетов. Один из участников её команды безопасности назвал случившееся «крупной вредоносной атакой».

16 мая регистрацию вернули, а затем потребовали подтверждённую почту не с одноразовых сервисов и ввели лимиты на новые регистрации. До конца мая это, судя по всему, остановило большую часть активности агентов, но 18 июня они за три часа выложили ещё 83 гема.