Взлом аккаунтов GitHub: кампания wfx-loot крадёт секреты

Что такое кампания wfx-loot на GitHub?

wfx-loot - кампания, в которой злоумышленник с помощью украденных учётных данных GitHub отправляет вредоносный рабочий процесс в репозитории, куда эти аккаунты могут писать, и крадёт секреты GitHub Actions и облачные учётные данные ^[1]. Aikido Security, которая первой о ней сообщила, назвала её по имени, которым сам атакующий называет вредоносную программу («wfx»), и по слову, которым он обозначает украденные секреты («loot») ^[1]. SafeDep также приписывает Aikido первое сообщение ^[5].

StepSecurity называет тот же похититель «wfx» и подчёркивает главное: атакующий не использует ошибку в GitHub Actions ^[2]. Вместо этого он пользуется действительными токенами реальных аккаунтов разработчиков и ботов, открывая запросы на слияние и отправляя коммиты так, как это делал бы разработчик ^[2][4].

Aikido считает, что главная цель - секреты CI, а не распространение через программные пакеты, хотя полезная нагрузка всё же попала как минимум в один пакет Packagist и один пакет Go через автоматические триггеры публикации ^[1]. BleepingComputer, опираясь на анализ Aikido, сообщает, что некоторые из скомпрометированных аккаунтов принадлежали крупным организациям ^[3].

Каков масштаб атаки wfx-loot?

Aikido насчитывает 4837 скомпрометированных аккаунтов, которые открыли пробные запросы на слияние в 61764 репозиториях; похититель сработал как минимум в 1806 репозиториях ^[1]. Цифры у исследователей немного различаются, потому что каждый искал на GitHub в разное время, пока кампания ещё продолжалась.

• Aikido: 4837 аккаунтов, 61764 репозитория; 10431 запрос на слияние ушёл в репозитории, которыми аккаунт не владеет; 92% всё ещё открыты; не менее 50 скомпрометированных пользователей публикуют пакеты в npm, Go, Packagist, PyPI или crates ^[1].
• Aikido (сводная цифра): не менее 1835 репозиториев выполнили полезную нагрузку, и у них были похищены учётные данные; BleepingComputer использует это число ^[1][3].
• StepSecurity: более 63000 пробных запросов на слияние на 07:40 UTC 12 ноября, около 90% всё ещё открыты ^[2].
• SafeDep: 8093 репозитория получили вредоносные коммиты с 10 по 12 ноября; как отмечает SecurityWeek, это не обязательно означает, что похититель выполнился ^[5][4].

Aikido предупреждает, что число выполнений может занижать масштаб, потому что в затронутых репозиториях журналы запусков были удалены ^[1].

Как работает похититель wfx-loot?

Для каждого репозитория, куда украденный токен может писать, атакующий прощупывает доступ, отправляет полезную нагрузку и заметает следы примерно за минуту ^[1].

1. Проба: запрос на слияние с названием «docs: dependency audit notes» из ветки wfx-docs добавляет крошечный файл заметок. «Сам по себе запрос на слияние ничего не делает», - говорит StepSecurity; он лишь показывает, что у токена есть доступ на запись ^[2][4].
2. Нагрузка: оболочечный скрипт примерно в 1500 строк приходит одним из трёх способов: внедряется в существующий рабочий процесс («ci: refresh build cache»), как скрипт плюс хук npm postinstall («chore: add ci helper») или как новый рабочий процесс на одноразовой ветке chore/ («chore: add dependency audit workflow») ^[1].
3. Заметание следов: атакующий откатывает изменение и удаляет запуск рабочего процесса и его журналы ^[1]. Отсутствующий номер запуска - часто единственный след ^[1].

Скрипт собирает секреты и токены GitHub Actions, полное окружение раннера, файлы учётных данных AWS, Azure, Google Cloud, Docker, Kubernetes, npm, PyPI, SSH и других сервисов, историю команд оболочки, а также ключи ИИ-провайдеров и инструментов разработчика ^[1][3]. Он даже читает память работающих процессов на раннере ^[1][4]. Aikido обнаружила, что проанализированные ею копии отправляли украденные данные только HTTP POST на серверы под контролем атакующего ^[1]. Позже StepSecurity заметила изменение: примерно с 05:30 UTC 12 ноября новые копии отправляли данные только через Telegram, поэтому одной блокировки опубликованных адресов серверов уже недостаточно ^[2].

Почему одной смены секретов недостаточно?

Потому что похититель пытается установить бэкдоры, которые переживают смену учётных данных ^[1][2]. Aikido описывает три приёма закрепления ^[1]:

• Поддельные проверки статуса: по словам Aikido, он публикует фальшивые проверки «success» под названиями обязательных проверок репозитория, что может снять барьеры слияния защиты веток ^[1]. StepSecurity обнаружила, что эта функция была отключена во всех 101 исследованных ею образцах ^[2].
• Переписывание политики доверия AWS: он может задать политику доверия роли так, чтобы она разрешала любой аккаунт AWS ^[1].
• Внедрение федеративной идентичности Azure: он может добавлять федеративные учётные данные с именами wfx-ci-… в приложения Azure AD, позволяя рабочим процессам в скомпрометированном репозитории проходить аутентификацию без сохранённого секрета ^[1].

Он также может создавать токены GitHub OIDC и обменивать их на сессии AWS, Google Cloud и Azure, переходить к другим ролям IAM и создавать долгоживущие ключи доступа AWS ^[1][3]. Поэтому StepSecurity говорит: «удалите закрепление, потому что одна смена секретов его не удалит» ^[2].

Как проверить, затронуты ли мои репозитории GitHub?

Найдите пробный запрос на слияние и сообщения коммитов атакующего начиная с 10 ноября, затем поищите пропуски в номерах запусков рабочих процессов ^[2][1].

1. Найдите среди запросов на слияние «docs: dependency audit notes» и ветки с именами wfx-docs или chore/ с последующими восемью символами ^[1][2].
2. Найдите среди коммитов с 10 ноября «ci: refresh build cache», «ci: restore», «ci: cleanup», «chore: add ci helper» и «chore: add dependency audit workflow» ^[2].
3. Для каждого совпадения откройте вкладку Actions и поищите отсутствующий номер запуска сразу после коммита; StepSecurity называет это самым надёжным признаком того, что похититель сработал ^[2].
4. Отметьте, какой аккаунт отправил коммиты: токены этого аккаунта украдены ^[2]. Если есть пробный запрос на слияние, аккаунт скомпрометирован, даже если нагрузка не выполнялась ^[1].

Не полагайтесь на отсутствие артефактов. Aikido говорит, что отсутствие артефактов wfx-loot, записей кэша wfx- или специальных сводок шагов не означает, что данные не были похищены, поскольку в этой кампании эти каналы были отключены ^[1]. Aikido также предполагает, что нагрузка может развёртываться как в закрытых, так и в публичных репозиториях ^[1].

Что делать, если похититель сработал?

Считайте скомпрометированными все секреты и облачные роли, доступные затронутому рабочему процессу, смените их, а затем найдите закрепление ^[1][2].

• Смените: все секреты репозитория, окружения и организации, до которых могло добраться задание, а не только те, что названы в рабочем процессе; токены публикации npm, PyPI и других; облачные ключи, хранящиеся как секреты ^[2].
• Проверьте пакеты: найдите версии пакетов, опубликованные после вредоносного коммита ^[2].
• AWS: найдите политики доверия, разрешающие любого субъекта AWS, ключи доступа IAM, созданные с 10 ноября, и сессии CloudTrail, начинающиеся с wfx- ^[2].
• Azure: удалите учётные данные федеративной идентичности с именами wfx-ci-* в регистрациях приложений ^[2].
• Google Cloud, Vault, Kubernetes: проверьте выпуск токенов и входы, выполненные с помощью токенов входа GitHub Actions ^[2].
• GitHub: удалите оставшиеся ветки, закройте пробные запросы на слияние, убедитесь, что ничего не было слито по поддельной проверке, и отзовите токены, разрешения OAuth и ключи SSH аккаунта ^[2].
• Токены, согласно документации GitHub: просмотрите свои персональные токены доступа в разделе Settings, Developer settings и удалите те, которых не узнаёте или которые вам не нужны; GitHub рекомендует детализированные токены, только минимально необходимые права и срок действия, потому что классический токен даёт доступ ко всем репозиториям, к которым есть доступ у вас ^[6].

Хук npm выполняется и на машинах разработчиков: все, кто запускал npm install в этот короткий период, запустили похититель у себя и тоже должны сменить свои учётные данные ^[2]. SecurityWeek подытоживает рекомендации нескольких компаний по безопасности: отозвать скомпрометированные токены, сменить раскрытые секреты и проверить несанкционированные изменения в облаке ^[4]. Для ботов StepSecurity также советует проверить, нужно ли им вообще право обходить защиту веток ^[2]. Надёжная защита входа затрудняет кампании с украденными аккаунтами; см. Two-Factor Authentication Explained: Which 2FA Method Is Safest?.

Какие пакеты затронуты?

Aikido называет пакет Packagist и модуль Go, получившие нагрузку через автоматическую публикацию ^[1].

• Packagist: digitalelvis/neuronai-studio версии 3.14.3; Aikido говорит считать скомпрометированной любую машину, на которой его устанавливали или открывали ^[1].
• Go: github.com/onuragtas/docker-env v1.0.278 и v1.0.280; нагрузка находится только в файле рабочего процесса GitHub Actions, исходный код и бинарные файлы Go не изменены, а сборки Go никогда не выполняют файлы рабочих процессов, но Aikido всё равно рекомендует убрать эти версии ^[1].

Данные расходятся: SafeDep говорит, что нагрузку содержат три пакета в Packagist и прокси модулей Go, а SecurityWeek упоминает версии двух модулей Go ^[5][4]. SafeDep добавляет, что у обычных пользователей, устанавливающих эти пакеты через composer require или go get, нагрузка не выполнялась ^[5]. Прежде чем на что-то полагаться, проверьте актуальный список каждого исследователя.

Кто стоит за wfx-loot и как получил токены?

Ни в одном из упомянутых здесь сообщений атакующий не назван, а StepSecurity говорит, что не установила, как были получены токены ^[2][4].

StepSecurity обнаружила 173 пробных запроса на слияние от 19 аккаунтов, сделанных через токены, выданные приложению Fly.io GitHub App; она сообщила, что не смогла определить, как они были получены, и не имела доказательств взлома инфраструктуры Fly.io ^[2][4].

Aikido обнаружила пересечение с аккаунтами, затронутыми октябрьской волной GhostAction, и увидела, как wfx-loot внедряется в файлы рабочих процессов GhostAction более чем в 100 репозиториях, но сочла это двумя разными кампаниями, вероятно, ведущимися разными участниками, поскольку украденные учётные данные часто оказываются у нескольких групп ^[1]. Она также заметила комментарии на индонезийском языке в некоторых более новых версиях вредоносной программы ^[1]. Здесь важно аккуратно хранить токены; основы описаны в материале Password Managers Explained: How They Work and Whether They Are Safe.