В реестре RubyGems нашли более 155 пакетов, которые использовались не для доставки вредоносного кода, а как тайник в RubyGems для уже собранных данных. Цель кампании пока неясна, но сам прием выглядит неприятно знакомо: публичный пакетный реестр снова проверяют на прочность, и для российских команд это прямой сигнал смотреть не только на то, что уезжает в CI, но и на то, что из него публикуется наружу.
О кампании под названием GemStuffer сообщает Dark Reading со ссылкой на исследование компании Socket. По данным исследователей, злоумышленник публиковал пакеты с однотипными, шумными и довольно автономными скриптами. Эти скрипты ходили на публичные порталы местных органов власти в Великобритании, в том числе районов Ламбет, Уондсворт и Саутуарк в Лондоне, собирали открытые данные вроде календарей заседаний, списков повесток и ссылок на комитеты, а затем запаковывали результат обратно в .gem-архивы и отправляли их в реестр через встроенные API-ключи.
Технически схема выглядит почти изящно, хотя исполнение, судя по описанию, далеко не уровня аккуратной скрытной операции. В одних образцах полезная нагрузка создавала временное окружение с учетными данными RubyGems в каталоге /tmp, подменяла HOME, локально собирала gem и пушила его на rubygems.org. В других вариантах злоумышленник даже не пользовался стандартным gem CLI, а отправлял архив напрямую в API RubyGems. После этого оставалось просто скачать собственный пакет из реестра и извлечь собранные данные. Никакого отдельного C2-сервера, никакой классической инфраструктуры управления, только реестр пакетов в роли почтового ящика с функцией хранения.
Самая странная часть истории в том, что добыча выглядит скучной даже по меркам автоматизированного скрейпинга. Речь идет не о закрытых базах, не о токенах, не о конфигурациях облака, а о публично доступных страницах британских муниципалитетов. Пакеты при этом почти не скачивали, а в самих публикациях не было привычной попытки заманить разработчика «полезной» библиотекой с вредной начинкой. Отсюда и главный вопрос: это подготовка к чему-то более серьезному, техническая обкатка механики, спам-кампания в пакетном реестре или просто демонстрация того, что тайник в RubyGems работает на практике? Socket не дает окончательного ответа и перечисляет сразу несколько версий, от proof-of-concept-червя до теста злоупотребления инфраструктурой реестра.
Контекст у этой истории вполне понятный. За последний год рынок уже насмотрелся на атаки на цепочку поставок в open source: кампании с червеподобным распространением, заражения через npm, PyPI и другие экосистемы, эксперименты с отравлением моделей и зависимостей. На этом фоне GemStuffer выделяется не масштабом ущерба, а сменой роли самого реестра. Обычно пакетный менеджер рассматривают как канал доставки вредоносной зависимости вниз по цепочке. Здесь же реестр используют в обратную сторону: как площадку для вывоза и временного хранения данных. Для защиты это неудобный сценарий, потому что многие команды умеют мониторить установку пакетов, но гораздо хуже контролируют публикацию пакетов из CI, со станций разработчиков и из сервисных аккаунтов.
Феросс Абухадижe, основатель и CEO Socket, прямо говорит, что техника была умной, а реализация — шумной. В переводе на практический язык это обычно означает не зрелую операцию, которая годами живет незаметно, а тест, автоматизацию или спам с низким порогом входа. Но расслабляться тут не из-за чего. Если злоумышленник проверяет, можно ли использовать публичный реестр как транспортный слой, следующая версия может оказаться тише, лучше автоматизированной и привязанной уже не к открытым муниципальным сайтам, а к внутренним данным компании, которая случайно разрешила публикацию gem-пакетов откуда попало.
Для разработчиков и ИБ-команд практические выводы довольно приземленные. Socket советует проверить каталог /tmp на потенциально затронутых машинах, если есть подозрение, что такие пакеты вообще попадали в окружение, и отдельно разобраться с вектором доставки: эти gem-пакеты не самораспространяются, значит, они должны были оказаться на хосте через конкретный процесс или пользователя. Еще важнее пересмотреть исходящую публикацию в публичные реестры. Если ваш CI не занимается выпуском Ruby-пакетов, исходящие gem push из него лучше просто запретить. То же касается сервисных аккаунтов и рабочих станций разработчиков: у команды должен быть короткий список систем, которым вообще разрешено публиковать артефакты наружу, и понятная политика, какие именно пакеты они могут выпускать. Иначе тайник в RubyGems останется не экзотикой из новости, а готовым шаблоном для следующего злоупотребления.
Главный вывод здесь неприятно простой: пакетные реестры окончательно перестали быть просто складами зависимостей. Они уже стали частью операционной поверхности атаки, а теперь еще и пробуются в роли канала вывода данных. Для индустрии это плохая новость в хорошем тайминге: чем раньше команды начнут относиться к публикации пакетов как к чувствительной операции уровня production-деплоя, тем меньше шансов, что следующий тайник в RubyGems окажется не шумным экспериментом, а рабочим элементом атаки на реальный бизнес.