Вредоносные Ruby Gems и Go Modules крадут секреты и вмешиваются в CI

По данным расследования Socket, группа Ruby gems и Go modules, связанных с GitHub-аккаунтом BufferZoneCorp, была опубликована под видом инструментов для разработчиков, а затем использовалась для кражи секретов и вмешательства в CI/CD workflows.

В этой кампании важен не столько каждый отдельный payload, сколько сам паттерн: «спящие» пакеты, которые сначала выглядят нормально — правдоподобные названия, README-контент, минимум подозрительного поведения, — а затем получают обновления с кражей credentials, подменой workflows, манипуляциями с path/proxy или механизмами persistence на хосте. Если вы полагаетесь на автоматические обновления или добавляете зависимости без тщательной проверки, именно такие изменения могут незаметно попасть в сборку.

Что известно из отчета#

Socket сообщает, что расследовала GitHub-аккаунт BufferZoneCorp, который публиковал набор репозиториев, напрямую соответствующих опубликованным Ruby gems и Go modules. Socket рассматривает это как supply chain-кампанию, нацеленную на разработчиков, CI runners и build-окружения сразу в двух экосистемах.

Со стороны Ruby, как утверждается, основное поведение сводится к сбору credentials и secrets. По данным Socket, проанализированные gems собирают environment variables, содержащие секреты, а также читают локальные credential-данные — например, SSH keys, AWS credentials, конфигурацию GitHub CLI и RubyGems credentials, — после чего отправляют собранную информацию на endpoint для exfiltration.

Со стороны Go Socket описывает несколько отдельных вариантов payload, а не единый сценарий поведения. Сообщается о следующих возможностях:

• Вмешательство в dependency resolution: изменение proxy-related settings, ослабление checksum-защиты и подмена module-related environment configuration, чтобы упростить перехват или саботаж downstream dependency resolution.
• Вмешательство в CI/workflows: подмена GitHub Actions workflows и размещение фальшивых wrappers в путях выполнения workflow.
• Кража данных: exfiltration данных разработчиков и CI.
• Persistence: как минимум в одном случае module добавляет жестко заданный SSH public key в ~/.ssh/authorized_keys.

Socket заявляет, что сообщила о выявленных вредоносных gems и modules в соответствующие registries и отправила запрос на блокировку связанного GitHub-аккаунта. После отчета, по словам Socket, команда Go Security заблокировала отмеченные вредоносные Go modules. На момент публикации Socket Ruby gems и GitHub-аккаунт все еще оставались доступными.

Пакеты и стратегия именования#

В отчете описан набор репозиториев и пакетов, созданных так, чтобы сливаться с обычными dependency graphs за счет имитации легитимных utilities.

С Ruby gems Socket связывает следующие пакеты:

• knot-activesupport-logger
• knot-rails-assets-pipeline
• knot-rspec-formatter-json
• Еще две «спящие» gems, которые на момент анализа, как утверждается, еще не были weaponized (их названия приведены в таблицах отчета)

По оценке Socket, названия этих gems сохраняют близкое визуальное и смысловое сходство с доверенными Ruby- и Rails-инструментами за счет префиксов или небольшого изменения знакомых имен.

К тому же publisher относятся и следующие Go modules (как указано в отчете):

• github.com/BufferZoneCorp/go-metrics-sdk
• github.com/BufferZoneCorp/go-weather-sdk
• github.com/BufferZoneCorp/go-retryablehttp
• github.com/BufferZoneCorp/go-stdlib-ext
• github.com/BufferZoneCorp/grpc-client
• github.com/BufferZoneCorp/net-helper
• github.com/BufferZoneCorp/config-loader
• github.com/BufferZoneCorp/log-core (sleeper module; еще не weaponized)
• github.com/BufferZoneCorp/go-envconfig (sleeper module; еще не weaponized)

Socket также упоминает более поздний репозиторий, который на момент публикации еще не был отправлен в экосистему Go modules, но в его публичном исходном коде уже присутствовала логика reconnaissance, запускающаяся при import. Описанное поведение включает инвентаризацию CI tokens, проверку Docker- и AWS metadata surfaces, а также запись runtime context в logs или локальные diagnostic files.

Главный вывод для практики: проверяйте не только имя пакета, но и publisher, историю версий и diff последних релизов. Для CI/CD стоит отключить бесконтрольные автообновления зависимостей, фиксировать версии, ограничить доступ job к секретам по принципу минимально необходимых прав и настроить отдельный мониторинг изменений в workflows и authorized_keys.

Как работает кража credentials в Ruby (по описанию отчета)#

Socket выделяет один Ruby-образец — knot-activesupport-logger, который подается как helper для логирования Rails/ActiveSupport. В отчете говорится, что он содержит два вредоносных пути выполнения:

1. Выполнение во время установки через extconf.rb при сборке native extension. Это позволяет коду запускаться автоматически в момент установки — еще до того, как разработчик вообще воспользуется каким-либо заявленным API.

2. Runtime-путь, встроенный в custom logger, который, как сообщается, отправляет environment data при первом использовании logger.

Socket описывает install-time-путь как наиболее опасный, потому что он может выполняться именно во время установки, а не при использовании. По данным отчета, код фильтрует environment variables по типичным ключевым словам, связанным с секретами, и читает данные из распространенных путей хранения credentials разработчика.

Практический takeaway: если в проект внезапно появляется новый dev-инструмент с похожим на знакомый пакет названием, отдельно проверьте его maintainer, установочные скрипты и недавние релизные изменения. После обнаружения подобных IOC стоит немедленно ротировать токены CI, SSH-ключи, AWS credentials и другие секреты, доступные на затронутых машинах или раннерах.