Непрерывная интеграция и непрерывное развертывание (CI/CD) pipelineОни играют ключевую роль в упрощении разработки программного обеспечения. Тем не менее, поскольку эти pipelines становятся все более важными, императив защищать их от уязвимостей становится все более выраженным. Это углубленное расследование фокусируется на решении важного риска, выявленного в OWASP Top-10 CI/CD Риски безопасности: отравление Pipeline Исполнение (СИЗ).
Что такое отравление Pipeline Исполнение (СИЗ)
По данным OWASP Top-10 CI/CD Риски безопасности, «Отравленные Pipeline Типы (средства индивидуальной защиты) риск относится к способности злоумышленника с доступом к системам контроля версий – и без доступа к среде сборки – манипулировать процессом сборки путем внедрения в сборку вредоносного кода/команд pipeline конфигурацияпо существу «отравление» pipeline и запуск вредоносного кода как часть процесса сборки»
В двух словах: Отравленный Pipeline Исполнение (PPE) производится, когда злоумышленник может изменить pipeline логика.
Есть два варианты:
- Прямые СИЗ (Д-СИЗ): В сценарии D-PPE злоумышленник изменяет файл конфигурации CI в репозитории, к которому у них есть доступ, либо отправив изменение непосредственно в незащищенную удаленную ветку репозитория, либо отправив PR с изменением из ветки или форка. Поскольку КИ pipeline выполнение определяется командами в измененном файле конфигурации CI, вредоносные команды злоумышленника в конечном итоге запускаются на узле сборки после завершения сборки. pipeline срабатывает.
- Косвенные СИЗ (I-СИЗ): В некоторых случаях возможность D-PPE недоступна противнику, имеющему доступ к SCM репозиторий (например, если pipeline настроен на получение файла конфигурации CI из отдельной защищенной ветки в том же репозитории). В таком случае, вместо того, чтобы отравлять pipeline сам злоумышленник внедряет вредоносный код в файлы, на которые ссылается pipeline (например: сценарии, на которые ссылаются изнутри pipeline Файл конфигурации)
В обоих случаях, GitHub выполнит измененный pipeline без необходимости предварительного рассмотрения или одобрения.
Раннее обнаружение СИЗ
Как мы можем обнаружить этот тип уязвимости?
Давайте посмотрим этот пример pipeline :
name: PR CI
on:
pull_request:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
jobs:
pr_build_test_and_merge:
runs-on: ubuntu-latest
steps:
# checkout PR code
- name: Checkout repository
uses: actions/checkout@v4
# Simulation of a compilation
- name: Building ...
run: |
echo $MY_SECRET
mkdir ./bin
touch ./bin/mybin.exe
# Simulation of running tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh "${{ github.event.pull_request.user.login }}" "${{ github.workflow }}"
echo Tests executed. И содержимое фиктивного сценария оболочки (runtests.sh):
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0pipeline довольно прост: его цель — предоставить рецензенту некоторые предварительные подсказки для Pull Request (PR) процесс принятия:
- Это будет срабатывать pull_request (т.е. всякий раз, когда создается PR)
- Он проверяет PR-код (т. е. предоставленный код)
- Это сделает сборку
- Он будет запускать тесты предоставленного кода (например, путем выполнения сценария оболочки).
Шаги №3 (выполнение сборки) и №4 (запуск теста) завершатся неудачей, если код не компилируется или не проходит тесты. Таким образом, эти шаги являются необходимым, но недостаточным условием для принятия ПР. В случае успеха администратор репо приступит к проверке предоставленного кода и на основании этого примет/отклонит/комментирует PR.
Ксигени-сканер
Ксигени предоставляет CLI («Ксигени-сканер»), который можно встроить в pipeline или запустите в командной строке. Сканер Xygeni обработает pipelines для проверки на наличие уязвимостей и, если предоставлен GitHub PAT, он подключится к GitHub для обнаружения уязвимостей на уровне организации/репозитория.
Инвентарь Ксигени
Когда мы запускаем Xygeni Scanner в этом репозитории, он обнаруживает полезный набор ресурсов ( Инвентарь Ксигени). Инвентарь будет заполнен множеством различных типов CI/CD активы, Таких как:
- SCM Система где хранится репо
- SCM Плагины установлен/используется
- Репозиторий кода саму трезвость
- SCM Организация где находится репо
- CI/CD Pipelineи Джобс
- CI/CD Система работает pipelines
- IaC Ресурсы определено в репо
- Внешний Зависимости
- и т.д..
В нашем примере мы можем отфильтровать инвентарь по определенному типу активов (SCM- и активы, связанные с CICD), поэтому мы можем видеть, что:
- SCM система — GitHub Cloud
- Репо хранится в облаке GitHub и принадлежит определенной организации GitHub.
- Есть два pipelines работает на GitHub (CI/CD система)
- Каждая pipeline содержит один конкретный шаг
Выбрав вышеуказанное pipeline мы можем увидеть некоторые уязвимости:
- At pipeline уровне, он уязвим для обоих Напрямую и Косвенные СИЗ.
Мы можем увидеть детали этих отравленных. Pipeline Уязвимости выполнения
Xygeni обнаруживает, что это уязвим для D-PPE потому что он срабатывает на Pull Request событие и нет никаких дополнительных элементов управления безопасностью, поэтому любой пользователь репозитория может изменить pipeline и эти изменения будут выполнены без какого-либо рассмотрения или одобрения.
В том же смысле Xygeni также обнаруживает, что это уязвим для I-PPE из-за вызова сценария оболочки из pipeline: любой пользователь репозитория может изменить сценарий оболочки, и эти изменения будут выполнены без какого-либо рассмотрения или одобрения.
Хотите узнать больше?
Использование СИЗ
Чтобы использовать СИЗ, давайте рассмотрим сценарий, в котором есть два типа пользователей репо:
- An внутренний пользователь (внутренний разработчик, работающий над этим репозиторием) с разрешениями на запись в репо
- An внешний пользователь (аутсорсинговый разработчик, работающий над этим репозиторием, но с разрешениями на чтение в репозитории), т.е. ему не разрешено разветвлять репо и он вынужден работать над форком.
Давайте представим, что оба являются злоумышленниками (или выдают себя за злоумышленника). Репо содержит какой-то секрет, и оба хотят украсть секрет репо и отправить его на сервер, контролируемый хакером. Для этого они воспользуются Отравленным Pipeline Уязвимости выполнения pipeline.
В обоих случаях (внешний и внутренний пользователь) они открывают Pull Request с теми же изменениями:
- pipeline и сценарий оболочки изменены в прочитать секрет из окружающей среды и отправить его на сервер, контролируемый хакером
Модификации могут быть следующими:
Оба пользователя создадут Pull Request с изменениями. При создании ПР GitHub выполнит обе модификации. (без необходимости предварительного рассмотрения или одобрения), что приводит к следующему:
То же самое для пользователей записи и чтения, в обоих случаях выполняются D-PPE и I-PPEс той разницей, что читающий пользователь не имеет доступа к секретам. (!!!!)
Эта причина в том, что, в случае PR, исходящего из форка, GitHub не разрешает доступ к секретам репо. Хотя читающий пользователь не может читать секреты, он/она все равно может запускать любую другую программу. Типичным примером атаки является создание PR, которые загружают крипто-майнер, поэтому исполнитель GitHub запускает крипто-майнер при выполнении отравленного майнера. pipeline.
Конечно, это небезопасная среда! Что может сделать администратор репо, чтобы избежать этого?
После некоторого поиска в Google администратор репо решает изменить pipeline быть вызванным на pull_request_target событие. Почему? Потому что pipelineсрабатывание pull_request_target не позволяет выполнить pipeline поправки, т.е. несмотря на любые изменения пользователя, «оригинал» pipeline будет выполнен.
Следуя нашему примеру, атака будет такой же, как и раньше. Что будет потом после этого pipeline модификация?
Как и ожидалось, D-PPE не выполняется но поскольку I-PPE все еще существует, читающий пользователь теперь может получить доступ к секрету репо!!!
В чем причина того, что читающий пользователь теперь имеет доступ к секретам? Хотя pipeline не может быть изменен, все еще можно изменить сценарий оболочки. Когда pipeline срабатывает при pull_request_target, он будет выполнен в привилегированном режиме so это также будет сценарий оболочки, в результате чего сценарий оболочки получает доступ к секретам репозитория!!
Профилактические Mеры
GitHub предоставляет некоторые меры для защиты от вредоносных PR.
Правила защиты филиалов
С помощью GitHub вы можете определить правила защиты ветвей для выбранных ветвей.
Для ваших защищенных ветвей вы можете указать политику, которая требует pull request перед слиянием (а также дополнительные условия, такие как необходимое количество согласований, отзывов владельцев кода и т. д.)
Несколько условий, заслуживающих особого внимания:
- Разрешить указанным субъектам обходить требуемые pull requests».
- Не разрешать обход вышеуказанных настроек
Хотя большинство условий добавляют строгости политике, эти условия смягчают политику, что может повлечь за собой открытые двери для злонамеренных действий, например, в случае кражи учетных данных «привилегированными» субъектами.
Ограничить разрешения GITHUB_TOKEN (наименьшие привилегии)
Ограничьте разрешения токена GitHub только необходимыми; таким образом, даже если злоумышленникам удастся скомпрометировать ваши pipeline, они мало что смогут сделать.
Избегайте интерполяции строк, используя pipeline переменные окружения
Всякий раз, когда вы используете некоторые входные переменные в своем pipeline, имейте в виду, что по умолчанию они должны рассматриваться как «ненадежные» данные (их содержимое контролируется конечным пользователем). Видеть Безопасность ненадежных действий и рабочих процессов и Изучите действия Github.
Вы всегда должны использовать переменные среды для вставки входных переменных внутри скриптов вместо использования интерполяции строк.
Требования к выполнению рабочего процесса и утверждению
Для пакетов что такое варган? репозитории, GitHub позволяет указать как работать с «внешними» пиарами.
Настройки организации GitHub («Организация >> Настройки >> Действия >> Общие») позволяют указать, как управлять внешними PR:
По умолчанию GitHub потребует одобрения PR для первоначальных участников, что усложнит атаки с использованием вредоносных запросов. Тем не менее, злоумышленник может завоевать доверие мейнтейнеров проекта, например, внеся невинный вклад pull request перед настоящей атакой.
В этом смысле Третий вариант (Требуется одобрение всех внешних соавторов) добавляет более высокий уровень контроля.
Для пакетов частная репозиториях, GitHub также обеспечивает полезный контроль как на уровне организации, так и на уровне репозитория.
Запуск рабочих процессов из Pull Requests(не отмечено по умолчанию) позволяет пользователям запускать рабочие процессы из PR-форка (используя GITHUB_TOKEN с разрешениями только на чтение и без доступа к секретам). Выбрав эту опцию вместе с последней («Требовать одобрения для рабочих процессов вилочных PR»), вы можете применить политику, аналогичную частным репозиториям (как показано выше).
Как мы видели в эксплойте PPE от читающего пользователя, разрешение запуска рабочих процессов из форка pull requests небезопасно!!
Остальные варианты («Отправка токенов записи в рабочие процессы из форка pull requests(Основной ключ) и Отправка секретов и переменных в рабочие процессы из for pull requests») снизить уровень безопасности применяется к форку PR.
Вы можете определить эту политику ветвления либо на уровне организации, либо на уровне репо. Если политика отключена на уровне организации, ее нельзя включить на уровне репо. Но если политика включена на уровне организации, ее можно отключить на уровне репо.
Краткое содержание
Мы надеемся, что вы увидели последствия наличия некоторых pipeline уязвим к отравлению Pipeline Исполнение. Это слишком легко commit уязвимый pipeline, и сложно написать безопасный.
Поэтому очень важно использовать сканер Xygeni, чтобы быть в курсе таких уязвимостей.
Вы не сможете устранить уязвимость, если не будете знать о ее существовании!!
Но… Есть еще нерешенный вопрос… Как избежать I-PPE?
Это будет темой нашего следующего поста 🙂… Косвенное отравление Pipeline Исполнение (И-СИЗ) !!
