tgoop.com/sec_devops/620
Last Update:
GitHub Actions Exploitation
Мы редко пишем про векторы атак и уязвимости, связанные с GitHub Actions, так как в России платформа по понятным причинам не используется. С другой стороны у нас есть читатели и не из России, а за каждой конкретной атакой скрываются полезные концептуальные идеи и универсальные принципы. Поэтому когда мы нашли блог SynAcktiv, где они делятся увлекательными атаками на GitHub Actions, мы были просто обязаны этим поделиться.
Итак, рассмотрим одну из интересных атак. Атака на цепочку поставок CI через инструменты безопасности, а именно через Dependabot, сканер уязвимых зависимостей!
1) Атакующий создаёт форк репозитория, куда собирается заинжектить вредонос.
2) Затем он тригерит работу Dependabot, который делает pull request (PR) в созданный форк, предлагая обновить библиотеку до безопасной версии. При этом создаётся новый форк от Dependabot для слияния. На этом этапе авторы нашли способ изменить то, что именно добавляется в PR от Dependabot, и внедрить вредоносный код (посредством излечение секрета бота через self-hosted runners и коммуникации с Dependabot API). Хотя это уже звучит угрожающе, при внимательном ревью PR вредоносные файлы все равно могут быть обнаружены, поэтому давайте продолжим цепочку эксплуатации.
3) Далее атакующий берёт новый PR, созданный Dependabot, и вместо слияния со своим форком отправляет его в основной бранч репозитория жертвы (main). GitHub позволяет изменить цель PR, перенаправив его из одного бранча в другой. В этом случае, хотя PR и был создан ботом, авторство будет приписано атакующему, так как он инициировал действия, а не сам Dependabot.
В обычной ситуации на этом всё должно было бы закончиться, но не в случае с авторами репозитория spring-security. Они намудрили с actions на GitHub, разрешив автоматическое слияние PR, если github.actor == 'dependabot[bot]'. Проблема в том, что в контексте GitHub github.actor — это не автор бранча, а последний пользователь, совершивший действие с PR!
4) Атакующий вызывает Dependabot повторно в своём PR в main, после чего уязвимый workflow автоматически сливает PR, включая вредоносный код.
Фикс в данном случае - использовать github.event.pull_request.user.login, а не github.actor, который выдает именно автора PR как и ожидается.
SynAcktiv также поддерживает собственный инструмент octoscan для анализа безопасности GitHub Actions, куда они уже добавили файндинги со своих ресерчей.
Среди других статей от них мы также рекомендуем ознакомиться с Introduction, где авторы разбирают базовые аспекты атакующего на GitHub Actions, а также со статьей про Untrusted Input.
Здесь важно понимать, что данная проблема не является уникальной для GitHub; аналогичные проблемы и векторы атак могут возникнуть в любом элементе цепочки поставок. Обратите внимание на причины, которые привели к появлению уязвимости:
- Наличие вызовов в платформе GitHub, название которых говорит совсем не о том, как их воспринимает конечный пользователь с позиции "здравого смысла".
- Использование вызовов авторами, не до конца разобравшимися в их логике работы.
- Автоматический обход ревью, основанный на неочевидных скриптах, которые могут быть использованы широким кругом лиц...
А если вы еще пока далеки от темы CI/CD Security, но хотите с легкостью понимать, о чем здесь идет речь, вот вам awesome ci-cd attacks, где есть и Threat Matrix, use cases, инструменты и многие другие ресерчи.
#cicd
BY Security Wine (бывший - DevSecOps Wine)
Share with your friend now:
tgoop.com/sec_devops/620