В результате масштабной кибератаки, получившей название GhostAction, злоумышленникам удалось получить несанкционированный доступ к 327 аккаунтам пользователей GitHub и внедрить вредоносные сценарии в 817 репозиториев. Исследователи из GitGuardian выявили, что целью атаки была подмена GitHub Actions — инструментов автоматизации, используемых разработчиками для запуска CI/CD-процессов.
Под видом безопасного обработчика с названием "Github Actions Security" в заражённые репозитории добавлялся скрипт, содержащий команду curl. При запуске задачи в среде непрерывной интеграции он отправлял все переменные окружения, включая чувствительные данные, на удалённый сервер, контролируемый злоумышленниками. Таким образом, были скомпрометированы более 3300 секретов — среди них ключи доступа к популярным платформам и хранилищам, таким как PyPI, GitHub, NPM, DockerHub и облачные сервисы.
Расследование началось с анализа подозрительной активности в проекте FastUUID — популярной Python-обёртке для библиотеки UUID на Rust. Этот пакет активно используется в сообществе, особенно как зависимость в LiteLLM, который еженедельно загружается более 5 миллионов раз. 2 сентября в репозиторий FastUUID был добавлен новый commit, содержащий вредоносный GitHub Action, который отправлял токен PyPI на внешний сервер.
К счастью, попытку компрометации удалось обнаружить до того, как злоумышленники успели воспользоваться перехваченными данными — никаких следов публикации вредоносных версий FastUUID на PyPI не обнаружено. Однако аналогичная схема была обнаружена ещё в сотнях других репозиториев, что говорит о системной и хорошо подготовленной атаке.
GitHub, PyPI, NPM и DockerHub уже уведомили владельцев пострадавших проектов. По состоянию на последний анализ, вредоносные коммиты были удалены из около 100 репозиториев, но в общей сложности в публичных репозиториях всё ещё остаются 671 заражённый commit, что представляет серьёзную угрозу для цепочки поставки программного обеспечения.
Важно отметить, что злоумышленники, судя по всему, получили доступ к аккаунтам мэйнтейнеров через фишинг или скомпрометированные учётные данные. Это поднимает серьёзные вопросы о текущем уровне защиты аккаунтов разработчиков, особенно тех, кто управляет популярными и широко используемыми пакетами. Несмотря на наличие двухфакторной аутентификации, которой, вероятно, пользовались не все, атака продемонстрировала уязвимость экосистемы к человеческому фактору.
GitHub Actions, несмотря на свою мощь и удобство в автоматизации процессов, остаются потенциальной точкой входа для атак. Опасность заключается в том, что любой commit в репозиторий, даже выглядящий безобидно, может содержать вредоносную автоматизацию, запускаемую при CI/CD-процессах, и незаметно от пользователей отправлять конфиденциальные данные третьим лицам.
Атака GhostAction также поднимает вопросы о безопасности поставок ПО через публичные репозитории. В условиях, когда даже небольшие зависимости могут стать вектором для масштабного взлома, разработчики должны быть особенно внимательны к изменениям в сторонних пакетах. Использование инструментов для автоматической проверки зависимостей на наличие вредоносного кода становится обязательным шагом в процессе разработки.
Что можно сделать для защиты?
1. Минимизация прав CI/CD-процессов. Не стоит передавать в окружение сборки лишние переменные окружения, особенно содержащие чувствительную информацию. Разграничение доступа и принцип минимально необходимых прав остаются ключевыми мерами.
2. Обязательное использование 2FA. Несмотря на неоднозначные результаты в этой атаке, двухфакторная аутентификация остаётся базовым слоем защиты. Важно применять её ко всем аккаунтам, особенно тем, которые имеют права на запись в репозитории.
3. Проверка всех внешних pull-request'ов. Даже если автор известен, автоматизация принятия изменений может привести к внедрению вредоносного кода. Обязательная ручная проверка и ревью — хорошая практика.
4. Мониторинг исходящего трафика в CI. Настройка фильтров, отслеживающих сетевые запросы, исходящие из среды сборки, может помочь оперативно выявить подозрительную активность.
5. Использование self-hosted решений с усиленным контролем доступа. Хотя и они не являются панацеей, локальные системы, такие как Gitea или GitLab, при должной настройке могут дать больше гибкости и контроля по сравнению с публичными облачными платформами.
Важно понимать, что атака GhostAction — это не единичный случай, а симптом более широкой проблемы: рост числа атак на цепочки поставки программного обеспечения. В 2023 и 2024 годах уже отмечены десятки случаев, когда через зависимости или автоматизацию в CI/CD злоумышленники получали контроль над проектами и распространяли вредоносное ПО.
Такие инциденты демонстрируют необходимость пересмотра методов обеспечения безопасности в процессе разработки. Отказ от "наивного доверия" к автоматизированным процессам и усиление контроля на всех этапах разработки — ключ к предотвращению подобных угроз в будущем.
В заключение, атака GhostAction ясно показала, насколько важно не только использовать безопасные инструменты, но и понимать, как именно они работают. Автоматизация — мощный помощник, но при недостаточном внимании к безопасности — и не менее мощный источник уязвимостей.
