Кампания Gheist оставила более 13 500 вредоносных веток в репозиториях свыше 850 скомпрометированных аккаунтов GitHub. Атака превращает украденный токен разработчика в пропуск к секретам CI/CD и облачным учётным данным — а значит, компрометация токенов GitHub для команды может оказаться началом инцидента уже за пределами самого репозитория. О схеме сообщает Dark Reading.
Исследователи Wiz отслеживают активность с 15 сентября; на 24 октября операция оставалась активной и менялась. Злоумышленники используют действующий GitHub-токен, создают во всех доступных ему репозиториях ветки с именем вида ci-sync-XXXXXX, а затем добавляют workflow GitHub Actions по пути .github/workflows/sync-check.yml. Коммит маскируют под рутинную настройку CI сообщением ci: sync config. Автор коммита при этом выглядит как владелец токена, а подписи у коммита нет.
Workflow запускается после push и пытается вывести в лог переменные окружения и секреты репозитория. Результат кодируется в Base32, забирается через GitHub API, а сам запуск удаляется через несколько секунд. В запросах фигурирует user agent gheist — от него и пошло название кампании. Для защитных средств это неприятная конструкция: секреты покидают инфраструктуру через легитимный API GitHub, без отдельного домена злоумышленника или подозрительного исходящего соединения, которое можно просто заблокировать на прокси.
Токены, по оценке Wiz, поступают главным образом из двух источников: инфостилеров на рабочих машинах и предыдущих компрометаций цепочек поставки ПО. Дальше работает неприятная математика прав доступа. Токен, выданный человеку или сервису для обычной работы с кодом, способен разрешить создать ветку и выполнить workflow; тот получает доступ к секретам, которые CI передаёт для сборки и деплоя. Поэтому кража одного токена может стать не утечкой исходников, а переходом к ключам облака, реестрам контейнеров или инфраструктуре доставки.
GitHub ввёл защиту от злоупотреблений workflow в публичных репозиториях в июле, однако она не закрывает сценарий с уже скомпрометированной корпоративной учётной записью. Wiz зафиксировала успешные атаки на приватные репозитории и корпоративные среды. В некоторых случаях атакующие перебирали токены нескольких пользователей и автоматизационных аккаунтов, клонировали приватные проекты, а затем добавляли вредоносный workflow. В течение нескольких часов после этого облачные учётные данные той же организации использовались для перечисления секретов в AWS Secrets Manager.
Масштаб последствий пока не выглядит как единая автоматизированная кампания по дальнейшей монетизации всех найденных секретов. По оценке исследователей, затронуто примерно с десяток компаний; устойчивого автоматического злоупотребления за пределами массового клонирования репозиториев и базовой кражи учётных данных они не увидели. Но это не повод списывать Gheist на шум вокруг GitHub. Уже сам факт, что приватность репозитория не спасает при наличии токена с записью, — полезная поправка к слишком оптимистичной модели угроз.
Для команд практический минимум здесь довольно конкретен. Стоит проверить ветки ci-sync- с шестью символами в конце, особенно если единственное изменение — файл sync-check.yml, а сообщение коммита — ci: sync config. В журнале аудита GitHub полезно искать запуски workflow в таких ветках, удалённые менее чем через минуту после завершения, и запросы с user agent gheist. При обнаружении признаков атаки нужно не только удалить ветку: отозвать скомпрометированный токен, ротировать секреты репозитория и проверить, какие облачные учётные данные могли быть выданы pipeline.
Компрометация токенов GitHub также требует пересмотра постоянных личных токенов. Для автоматизации безопаснее использовать GitHub Apps или короткоживущие fine-grained токены с минимальным набором прав. Для окружений с production-секретами нужны обязательное ревью изменений workflow и отдельный контроль того, кто может запускать код с доступом к этим секретам. Self-hosted runner после такого инцидента следует рассматривать как потенциально скомпрометированный узел, а не как безобидный исполнитель сборки.
Gheist показывает, что граница между «доступом разработчика к репозиторию» и «доступом к корпоративному облаку» часто проходит лишь по YAML-файлу в CI. Чем больше секретов команда доверяет pipeline, тем важнее считать токен разработчика полноценным привилегированным credential, а не удобным аналогом пароля. Детали исследования и признаки кампании опубликованы в материале .
