Кампания Gheist похищает секреты из приватных репозиториев GitHub через логи Actions
Злоумышленники используют украденные токены с правом записи, добавляют вредоносный workflow и забирают его логи, после чего удаляют запуск. Защита GitHub от подозрительных workflow действует для публичных репозиториев на github.com, но не распространяется на приватные репозитории и GitHub Enterprise Server.
Исследователи Wiz обнаружили автоматизированную кампанию Gheist, нацеленную на секреты в репозиториях GitHub. Получив украденный токен с правом записи, атакующие создают ветку и добавляют GitHub Actions workflow, который выводит доступные секреты в журнал выполнения. Затем журнал скачивают через API GitHub, а запуск workflow удаляют через несколько секунд.
По данным Wiz, атаки уже затронули приватные репозитории и среды GitHub Enterprise. Компания отслеживает Gheist с 15 сентября; название кампании связано со строкой user agent «gheist», которую инструмент отправляет при обращениях к API GitHub. Исследователи обнаружили более 13 500 созданных веток в более чем 850 скомпрометированных аккаунтах.
Для каждого доступного репозитория инструмент создаёт ветку вида ci-sync-<шесть случайных символов> и коммит с сообщением «ci: sync config». В ней появляется файл .github/workflows/sync-check.yml. Workflow кодирует секреты в base32 и печатает результат в логах. GitHub обычно маскирует секреты в журналах, однако маскировка не гарантируется, если значение было преобразовано; закодированная строка не совпадает с исходным секретом и, по оценке Wiz, выводится полностью.
Один из вариантов инструмента запускает задания для всех окружений развертывания, поэтому в логи могут попасть и секреты, ограниченные конкретными окружениями. Wiz указывает, что к таким данным нередко относятся учётные данные для production-сред.
Удаление ветки или запуска не устраняет последствия: секреты к тому времени уже могли быть скачаны. Поскольку данные забирают через инфраструктуру GitHub, а не отправляют на внешний сервер, традиционная фильтрация исходящих соединений здесь не поможет.
С 28 июля GitHub приостанавливает подозрительные workflow до одобрения пользователем с правом записи, но эта мера, согласно документации компании, пока действует только для публичных репозиториев на github.com и недоступна в GitHub Enterprise Server. Wiz сообщает, что все проверенные публичные запуски Gheist ожидали одобрения и не выполнили вредоносную нагрузку. Для приватных репозиториев такого барьера нет.
В середине октября в кампании появился код для self-hosted runners — собственных машин организаций, обрабатывающих задания GitHub Actions. Он пытается найти на машине различные учётные данные, включая закрытые ключи, переменные окружения, AWS-учётные данные и токены Kubernetes. В Wiz считают этот компонент ошибочным и не зафиксировали его успешного выполнения.
Организациям, обнаружившим признаки Gheist, Wiz рекомендует искать ветки ci-sync-*, файл .github/workflows/sync-check.yml и удалённые вскоре после завершения запуски workflow. Все секреты, которые мог прочитать скомпрометированный репозиторий, следует заменить, а токен, создавший ветку, — отозвать.