Сложная компрометация обработчика changed-files в GitHub Actions затрагивает более 23 тыс. репозиториев

Специалисты по информационной безопасности из компании StepSecurity выявили факт компрометации в GitHub Actions, касающейся обработчика changed-files. Это открытое решение автоматизирует запуск сборок и тестов при возникновении определённых событий, таких как push-запросы, создание релизов, а также открытие и закрытие issues и pull-запросов. changed-files используется в более чем 23 тыс. репозиториев, которые применяют GitHub Actions в контексте непрерывной интеграции для мониторинга изменений файлов и директорий.

Согласно данным OpenNET, в репозиторий changed-files было внедрено изменение с коммитом 0e58ed8, которое внедрило вредоносный код в файл index.js под соусом улучшения работы с файлами блокировок. При запуске changed-files этот вредоносный код мог собирать ключи доступа и другие конфиденциальные данные из окружения сборки. Для передачи данных за пределы сборочного окружения использовался лог сборки, который в публичных репозиториях доступен всем.

Разработчики, использующие changed-files, должны немедленно провести аудит своей инфраструктуры и проверить открытые логи интеграции на базе GitHub Actions на наличие утечек конфиденциальной информации. В случае работы с скомпрометированной версией настоятельно рекомендуется изменить ключи доступа и проверить возможные инциденты безопасности в своих системах. На данный момент GitHub уже заблокировал репозиторий changed-files, однако зловредные обновления были доступны для скачивания в течение примерно 14 часов. Подозрения на наличие вредоносного изменения можно подтвердить по упоминанию “bash” в файле index.js.

Коммит был создан от имени бота renovate, который предназначен для автоматизации обновления зависимостей. Вероятно, бот был использован для сокрытия следов, так как коммит оказался непроверенным и не принадлежал ни одной из веток в репозитории changed-files. Подобные коммиты могут указывать на добавление изменений не в основной репозиторий, а в его форк. Например, если осуществить прямой доступ через основной репозиторий на GitHub, коммиты из форков остаются доступными для просмотра.

Интересно, что атакующему удалось внедрить вредоносный коммит почти во все git-теги и релизы проекта changed-files, не отображая это в git-логе соответствующих веток. Один из возможных способов, как он это сделал, может заключаться в создании форка репозитория, добавлении в него вредоносного кода и обновлении всех тегов в основном репозитории с учетом нового SHA-хэша форка. По мнению другого разработчика, атакующий мог добавить коммит в ветку main, перенаправить все теги на эту ветку, а затем откатить главную ветку на предыдущий коммит.