Исследователи обнаружили кампанию, в ходе которой скомпрометированные учетные записи GitHub распространяли вредоносное ПО для кражи секретов в тысячах репозиториев. Вредоносный код был выполнен как минимум в 1806 репозиториях, похищая секреты CI/CD и облачные учетные данные.
Компания Aikido Security, обнаружившая и задокументировавшая кампанию, сообщила, что злоумышленники использовали 4837 скомпрометированных учетных записей для открытия тестовых pull-запросов в 61 764 репозиториях, начиная с 10 ноября. Около 92% этих pull-запросов под названием «docs: dependency audit notes» до сих пор открыты, что указывает на то, что большинство владельцев проектов их не заметили.
Однако сами по себе тестовые запросы безвредны и были выполнены только для проверки наличия у скомпрометированных учетных записей прав на запись в этих репозиториях, чтобы злоумышленники могли затем внести коммиты с вредоносным кодом: 1500-строчным shell-скриптом, который собирает секреты GitHub Actions, облачные учетные данные и API-ключи для ИИ-сервисов и инструментов разработчика.
Вредоносный код доставлялся как минимум тремя способами: путем модификации существующих рабочих процессов GitHub Actions, добавления хука postinstall в файл package.json, который запускает его при любой команде npm install, и создания временной ветки с вредоносным рабочим процессом Actions для его выполнения.
«Мы выявили признаки того, что вредоносный код выполнялся как минимум в 1806 репозиториях, но это число может не отражать полного масштаба ущерба», — говорится в отчете исследователей Aikido. «Журнал выполнения был удален в затронутых репозиториях, что означает, что злоумышленник, вероятно, собрал учетные данные и замел следы».
NPM-хук, который обошел защиту GitHub
Механизм защиты GitHub от подобных атак работал так, как задумано, для тех вредоносных кодов, которые он мог обнаружить. Платформа смогла противостоять недавним кампаниям по внедрению вредоносных рабочих процессов, требуя явного одобрения перед их запуском. GitGuardian обнаружил, что все семь запущенных в ноябре вредоносных кодов, все еще видимых в файлах рабочих процессов, находились в состоянии action_required и так и не были запущены.
«GitHub заблокировал формы рабочих процессов, но npm-хук обошел эту блокировку и выполнился», — сказал Гаэтан Ферри, исследователь безопасности в GitGuardian, в анализе.
Это произошло потому, что npm-хук не изменял никаких файлов рабочих процессов. Вместо этого злоумышленник добавил скрытый скрипт в корневой каталог репозитория и одну строку в package.json, которая выполняется при каждой команде npm install. Собственные неизмененные рабочие процессы репозитория выполняли npm install в рамках обычной процедуры сборки.
К четвергу злоумышленник также изменил метод эксфильтрации данных. Последняя версия вредоносного кода отправляет украденные данные только в чат Telegram, а HTTP-обратный вызов теперь указывает на недействительный адрес. Блокировка ранее опубликованных IP-адресов больше не останавливает последние версии.
Что крадет вредоносное ПО
После запуска скрипт получает все секреты репозитория и организации через JSON-дамп объекта секретов рабочего процесса. Он сканирует память процесса выполнения, где секреты хранятся в расшифрованном виде, включая те, на которые рабочий процесс никогда не ссылался, и собирает файлы учетных данных из известных путей, истории командной строки и API-ключи для ИИ-сервисов и инструментов разработчика, таких как OpenAI, Anthropic, Copilot и Cursor.
Скрипт идет дальше: он обменивает токены OIDC на сессии AWS, GCP и Azure, создает новые долгоживущие ключи доступа AWS, подменяет учетные записи служб GCP и использует кэшированные токены обновления Azure для доступа к Microsoft Graph и Key Vault.
Он упаковывает все собранное в сжатый архив и отправляет его злоумышленнику, после чего очищает следы. В большинстве репозиториев злоумышленник откатывал вредоносный коммит в течение минуты и удалял выполнение рабочего процесса и его журналы.
Бэкдоры, переживающие ротацию учетных данных
Скрипт также предпринимает действия для обеспечения злоумышленникам доступа даже после сброса учетных данных. Для AWS он перезаписывает политику доверия предполагаемой роли, чтобы она принимала любую учетную запись AWS, открывая роль для всех, и вызывает API iam:CreateAccessKey для создания долгоживущих ключей для пользователей IAM.
В Azure он внедряет федеративные учетные данные под названием wfx-ci-* в приложения, направляя их обратно в скомпрометированный репозиторий, так что любой рабочий процесс в этом репозитории может аутентифицироваться в Azure без сохраненного секрета, даже после ротации всех токенов.
Если в контролируемом вами репозитории появляются тестовый pull-запрос или любые строки коммитов из этой кампании, считайте, что все секреты, к которым могли получить доступ рабочие процессы этого репозитория, украдены. Смените секреты репозитория и организации, токены реестра пакетов и любые облачные ключи, и помните, что сканирование памяти означает, что список украденного шире, чем то, на что ссылались рабочие процессы.
Затем ищите признаки механизмов сохранения доступа: политики доверия ролей AWS, принимающие любую учетную запись, ключи IAM, созданные после 10 ноября, и федеративные учетные данные Azure с именем wfx-ci-*.
«Убедитесь, что все журналы включены, особенно журналы аудита поведения администраторов облака», — говорит Рами Рахман, старший главный инженер решений в ArmorCode, изданию CSO. «По возможности проверяйте журналы аудита (особенно в AWS и Azure, поскольку сохранение доступа возможно), чтобы убедиться, что вредоносный код не выполнялся».
Вредоносный код wfx-loot также распространялся в опубликованных пакетах: пакет Packagist neuronai-studio 3.14.3 и Go-модули docker-env и gocurl. В Go-модулях вредоносный код находится только в файле рабочего процесса, который инструментарий Go никогда не запускает, поэтому потребители могли не пострадать; машины, установившие версию Packagist, следует считать скомпрометированными.
Примерно пятая часть учетных записей GitHub, использованных для запуска этой кампании, уже была скомпрометирована во время атаки GhostAction в октябре, сообщила GitGuardian. Тем временем исследователи из StepSecurity отследили 173 тестовых pull-запроса до токенов, выданных GitHub App Fly.io.
Fly.io подтвердил, что эти токены были раскрыты, когда в процессе развертывания они остались в файлах .git/config внутри директорий сборки, которые некоторые приложения предоставляли публично, но отметил, что сама Fly.io не была взломана. Массовая отзыв токенов приложения Fly.io со стороны GitHub была частично остановлена, поэтому часть украденного пула токенов может все еще быть действительной.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Lucian Constantin
