Способ хранения артефактов сборки на платформе GitHub Actions может позволить злоумышленникам внедрить вредоносный код в программные проекты с рабочими процессами CI/CD (Continuous Integration and Continuous Delivery), которые не выполняют должной фильтрации при загрузке артефактов. Исследователи в области кибербезопасности выявили несколько популярных скриптов загрузки артефактов, используемых тысячами репозиториев, которые уязвимы к этой проблеме.
"Мы обнаружили, что при передаче артефактов между различными рабочими процессами существует серьезный риск отравления артефактов - метод, при котором злоумышленник заменяет содержимое легитимного артефакта модифицированным вредоносным артефактом, чтобы запустить атаку на цепочку поставок", - заявили исследователи из компании Legit Security, анализируя проблему.
Чтобы атаковать CI/CD-конвейер уязвимого проекта, который загружает и потребляет артефакты, созданные другими рабочими процессами, злоумышленнику достаточно форкнуть репозиторий, содержащий эти рабочие процессы, и изменить их в локальной копии таким образом, чтобы они генерировали неавторизованные артефакты, а затем вернуть запросы на привлечение в исходный репозиторий, который не должен принимать эти запросы.
Логический изъян в API хранения артефактов
GitHub Actions - это CI/CD-платформа для автоматизации сборки и тестирования программного кода. Сервис является бесплатным для публичных репозиториев и включает в себя бесплатное время выполнения рабочих операций и место для хранения данных в частных репозиториях. Он широко используется проектами, которые используют GitHub для размещения и управления своими репозиториями исходного кода.
1 секунда из 27 секундОбъем 0%
Рабочие процессы GitHub Actions - это автоматизированные процессы, заданные в файлах .yml с использованием синтаксиса YAML, которые выполняются при возникновении определенных триггеров или событий, например, при фиксации нового кода в репозитории. Артефакты сборки - это скомпилированные двоичные файлы, журналы и другие файлы, полученные в результате выполнения рабочего процесса и его отдельных заданий. Эти артефакты сохраняются в ведрах, и каждому рабочему процессу назначается определенное ведро, из которого он может загружать и позже выгружать файлы.
Эталонный "экшен" (скрипт), предоставляемый GitHub для загрузки артефактов, не поддерживает загрузку артефактов из разных рабочих процессов, но повторное использование артефактов, созданных в разных рабочих процессах, в качестве исходных данных для последующих шагов сборки является распространенным вариантом использования в программных проектах. Поэтому разработчики создают свои собственные сценарии, которые опираются на GitHub Actions API и используют более сложную фильтрацию для загрузки артефактов, например созданных определенными файлами рабочего процесса, определенными пользователями, определенными ветками и т. д.
Проблема, обнаруженная Legit Security, заключается в том, что API не различает артефакты, загруженные из форк-репозиториев и базовых репозиториев, поэтому если скрипт загрузки фильтрует артефакты, сгенерированные определенным файлом рабочего процесса из определенного репозитория, API будет обслуживать последнюю версию артефактов, сгенерированных этим файлом, но это может быть вредоносная версия, автоматически созданная в результате операции pull request из форк версии репозитория.
"Проще говоря, в уязвимом рабочем процессе любой пользователь GitHub может создать ветку, в которой будет создан артефакт", - говорят исследователи. "Затем этот артефакт внедряется в процесс сборки исходного репозитория и изменяет его результаты. Это еще одна форма атаки на цепочку поставок программного обеспечения, когда результат сборки изменяется злоумышленником".
Исследователи обнаружили четыре пользовательских действия, разработанных сообществом для загрузки всех уязвимых артефактов. Один из них указан в качестве зависимости в более чем 12 000 репозиториев.
Ржавый пример
Одним из репозиториев, использующих такие пользовательские скрипты в одном из рабочих процессов, является официальный репозиторий языка программирования Rust. Уязвимый рабочий процесс под названием ci.yml отвечает за сборку и тестирование кода репозитория и использует пользовательское действие для загрузки артефакта libgccjit.so (файл библиотеки Linux), который предоставляется сторонним репозиторием. Генерация рабочего процесса.
Все, что нужно сделать злоумышленнику, - это форкнуть сторонний репозиторий, модифицировать рабочий процесс этого репозитория, чтобы создать вредоносную версию библиотеки, и отправить запрос на извлечение в исходный репозиторий для создания артефакта. Если рабочий процесс Rust впоследствии представит отравленную версию библиотеки, злоумышленник сможет выполнить вредоносный код в репозитории Rust, используя разрешения рабочего процесса.
"После эксплуатации злоумышленник может изменять ветки репозитория, запросы на выгрузку, проблемы, релизы и все сущности, доступные для разрешений токена рабочего процесса", - заявили исследователи.
Пользователям необходимо внедрить более строгую фильтрацию загружаемых артефактов
GitHub отреагировал на сообщение Legit, добавив в API дополнительные возможности фильтрации, которые разработчики могут использовать для более точной идентификации артефактов, созданных конкретным запущенным экземпляром рабочего процесса (идентификатор запуска рабочего процесса). Однако это изменение нельзя внедрить в существующие реализации, не сломав рабочие процессы, поэтому пользователям придется обновить свои рабочие процессы с более строгой фильтрацией, чтобы быть защищенными.
Еще одно средство защиты - фильтровать загружаемые артефакты по хэшу коммита, который их создал, или полностью исключить артефакты, созданные с помощью pull request'ов, используя опцию exclude_pull_requests. Legit Security также связалась с автором обнаруженного уязвимого скрипта загрузки пользовательских артефактов.
"Когда речь идет о безопасности цепочек поставок, основное внимание всегда уделялось предотвращению распространения вредоносного кода, поэтому каждый раз, когда вы вносите изменения в репозиторий, создаете запрос на получение или делаете запрос на изменение, GitHub имеет множество встроенных средств контроля проверки", - рассказал CSO главный технический директор Legit Security Лиав Каспи. "Кто-то должен одобрить ваш код, кто-то должен объединить его, так что кто-то вовлечен в процесс. Мы пытаемся найти методы, использующие логические проблемы, на которые любой может повлиять без проверки, и я думаю, что это один из таких методов. Если бы кто-то знал об этом, он мог бы внедрить артефакт без какого-либо одобрения".
Как правило, говорит Каспи, рабочий процесс CI-конвейера автоматически запускает запрос на извлечение, чтобы протестировать код перед его ручной проверкой, и если запрос на извлечение содержит артефакты, которые необходимо собрать, то рабочий процесс их соберет. По его словам, искушенный злоумышленник может создать запрос на сборку артефакта, а затем удалить его, закрыв коммит, и весь шум активности, присутствующий в современных репозиториях исходного кода, скорее всего, останется незамеченным, и это останется незамеченным.
