В нашем предыдущем посте о CI/CD Pipelines, мы видели как взломать CI/CD сценарий, который предположительно был защищен.
Давайте вспомним нашу точку зрения в предыдущем посте: мы начали с некоторых pipeline который был уязвим для Косвенное отравление Pipeline Типы (I-PPE), и чтобы это исправить, мы решили разделить pipeline на два:
- 1-й pipeline (Build CI), безопасный для D-PPE и I-PPE, проверит PR-код, выполнит сборку и сгенерирует артефакт.
- 2nd pipeline (Тестовый CI), также безопасный для D-PPE, и I-PPE проверит базовый код (чтобы избежать модификации сценария оболочки) и выполнит исходные сценарии для артефакта.
- Синхронизация тестового ЭК pipeline запускать ПОСЛЕ сборки CI pipeline, мы использовали рабочий процесс_запуск вызывать.
Мы назвали это сценарием №3.
Хотя, как мы уже упоминали в том посте, существуют и другие решения, мы решили реализовать это «решение» по педагогическим причинам, чтобы мы могли глубже изучить уязвимости CI/CD pipelines.
Позже мы увидели, как взломать этот сценарий с помощью отравление артефакта. Это то, что мы называем Отравление артефактом, то есть возможность модифицировать (взламывать) pipeline логику путем изменения pipeline артефакт.
В чем проблема такого подхода? Мы увидели, что проблема возникает, когда любой пользователь «создает» новый pipeline.
Если пользователь открывает PR, содержащий новый pipeline, GitHub выполнит это pipeline (при некоторых условиях, как мы видели в посте).
После этого пользователь может создать новый pipeline с тем же именем, что и Build CI!! Да, это удивительно, но GitHub позволяет создать два pipelineс таким же именем!!
Когда пользователь открывает PR с этими изменениями, новый" pipeline будет казнён (загрузка отравленного артефакта) и развертывание CI pipeline будет выполнен после этого, в результате чего «модифицированный» сценарий оболочки перезапишет «исходный» сценарий оболочки, расположенный в pipeline Рабочее пространство. Итак, это «решение» не позволяет избежать уязвимости I-PPE (как мы видим ниже).
Какие проблемы? По крайней мере, есть пара проблем:
- Первое как быть уверенным, что процесс сборки не был подделан? В этом сценарии злоумышленник смог изменить предполагаемый процесс сборки, используя свой pipeline создать отравленный артефакт.
- Во-вторых, как мы можем оценить происхождение артефакта?
Эти вопросы бросают нас в объятия Аттестации программного обеспечения домен!!
Аттестации программного обеспечения
An засвидетельствование это кусок данным представляющий доказательство события. В реальном мире мы обычно называем их сертификаты.
Например, когда лаборатория проверяет вашу кровь, данные об анализе записываются и сертифицируются. Результаты анализа крови такие проверяемый и прослеживаемый.
Ближе к нашей IT-области можно было бы догадаться, что будет переводом этого процесса, например, в процесс компиляции.
Информация о среде и инструментах сервера компиляции, материалах (исходный код) и продуктах/артефактах (двоичный код) будет частью такой аттестации.
Очевидно, что подтверждение должно быть создано уполномоченным аттестатором (аутентифицированным и неоспоримым), чтобы обеспечить достоверность.
Вероятно, некоторые из вас задумаются.. а в чем тут дело? разница между подписями и заверениями?
Подписи кода и аттестации
На высоком уровне А. подпись создается с использованием пары ключей и артефакта. Пара ключей состоит из открытого ключа и закрытого ключа.
Пользователь подписывает артефакт с помощью закрытого ключа, а затем другие могут проверить подпись с помощью открытого ключа. Закрытый ключ должен храниться в секрете, но открытый ключ широко распространен.
Подписи можно использовать доказать, что владелец закрытого ключа использовал закрытый ключ для подписи артефакта.
Подписи не доказывай
- пользователя намерение подписать артефакт (их могли обмануть) или
- Намерение пользователя совершить какое-либо конкретное утверждение об артефакте
Благодаря более чем Аттестациивместо того, чтобы подписывать артефакт напрямую, пользователи создают своего рода документ которая улавливает их намерение за подписанием артефакта и всего конкретные претензии делается как часть этой подписи.
Структура аттестации In-toto
Наиболее распространенной структурой является Платформа аттестации in-toto
- определяет standard Формат для аттестаций которые связывают субъектов, описываемые артефакты, с аутентифицированными метаданными об артефакте
- предоставляет набор предопределенные предикаты для передачи аутентифицированных метаданных по всей цепочке поставок программного обеспечения
Давайте более подробно остановимся на формате аттестации.
An засвидетельствование - это документ с цифровой подписью который содержит Заявления.
заявление это средний уровень аттестации, привязывающий его к конкретному Тема и однозначно идентифицировать виды сказуемое:
- Тема : к криптографически безопасная ссылка на артефакт (обычно через хэш) и
- Предикаты: набор конкретных требования об этом артефакте называется Утверждением. Эти утверждения можно использовать, чтобы выразить (а затем доказать) все, что вы только можете придумать! Они могут представлять собой одобрение вручную, происхождение артефактов, результаты автоматического тестирования, контрольный журнал и многое другое!
Если данное Заявление подписано криптографически, оно называется засвидетельствование
Таким образом, например, Алиса создает Заявление об артефакте и подписывает его, используя свой закрытый ключ, создавая Свидетельство.
- Тогда Боб сможет проверить подпись в этом Свидетельстве, что позволяет ему доверять утверждениям внутри.
Затем Боб сможет использовать эти утверждения принимать решение разрешить или запретить использование этого артефакта.
Могут ли аттестации помочь решить проблему отравления артефактами?
После этого введения в аттестации давайте вернемся к нашей проблеме. Как аттестации могут помочь нам решить нашу проблему, то есть избежать отравления артефактами?
Злоумышленник смог создать артефакт в обход «официального» механизма, т.е. pipeline для создания артефакта.
Было бы здорово, если бы мы могли доказать, что загружаемые артефакты были созданы с использованием официальной лицензии. pipelineс. Это только один пример того, что мы могли бы назвать «точками вмешательства», но может быть и много других.
Как вы можете видеть на рисунке выше, точек взлома несколько. Таким образом, потребитель pipeline (Тестовый CI в нашем примере) должен оценить целостность процесса сборки так же хорошо как целостность самого артефакта.
В нашем примере отравленный артефакт был создан путем введения нового (отравленного) pipeline это мешает процессу сборки. Но злоумышленник мог иметь возможность:
- изменить код после того, как он был извлечен из SCM для создания вредоносного двоичного файла
- заменить правильный двоичный файл, созданный в результате компиляции, на любой другой вредоносный двоичный файл
- скомпрометировать Реестр Артефактов и загрузить отравленный артефакт, созданный любым другим способом
- и так далее
Как видите, точек «подделки» может быть несколько.
Что здесь важно? Очевидно, чтобы защитить все эти точки «подделки». Но, в конце концов, самое главное что «потребитель» артефакта может оценить целостность артефакта и решить, продолжать ли с ним работать или нет.
Мы можем оценить целостность артефакта двумя способами.
Один из них заключается в оценке происхождение артефакта.
Создав Подтверждение происхождения, мы предоставляем полезные метаданные (должным образом проверенные и неоспоримые) об артефакте. В следующих примерах мы будем использовать Ксигени СОЛЬ (Уровень аттестации программного обеспечения для доверия), компонент для создания, регистрации и проверки аттестаций программного обеспечения.
- name: Building ...
run: |
# mvn will compile and create target/MyApp.war
mvn clean package
- name: Generating provenance
run: |
#!/usr/bin/env bash
shopt -s expand_aliases
alias salt=$PWD/salt_pro/xygeni_salt/salt
echo " "
echo "-----------"
echo "Generating Provenance with CLI ..."
salt at slsa \
--basedir ${GITHUB_WORKSPACE}/target \
--key="${PRIVATE_KEY}" \
--public-key=${GITHUB_WORKSPACE}/Test1_public.pem \
--key-password=${KEY_PASSWD} \
--output-unsigned=${GITHUB_WORKSPACE}/cli_provenance_${PIPELINE}_unsigned.json \
--pipeline ${PIPELINE} --pretty-print \
--file ./MyApp.war
В приведенном выше коде вы можете видеть, что есть шаг, который создает файл war, и второй шаг, который генерирует файл. Подтверждение происхождения. Для этого pipeline использует закрытый ключ, а также включает в подтверждение открытый ключ.
За кулисами Xygeni соль команда сохраняет аттестацию в бухгалтерская книга (он же реестр аттестаций, запись в нашем случае, но можно использовать и любой другой). Сделав это, потребитель pipeline может включать Xygeni Проверка двигателя проверить происхождение артефакта и оценить целостность артефакта.
- name: 'Verifying the attestation'
run: |
#!/usr/bin/bash
echo " "
echo "-------"
# Calculate sha256sum for the artifact
SHA_SUM=$(sha256sum ./MyApp.war | cut -f1 -d ' ')
# Recover the attestation Id from the sha256sum
ATT_ID=$(echo $(salt -q registry search --digest sha256:$SHA_SUM --format json) | jq -r .[-1].gitoidSha256)
echo " "
echo "-------"
# Download the provenance attestation
echo "Downloading the provenance attestation ..."
salt -q reg get --id=$ATT_ID --format=json > ${GITHUB_WORKSPACE}/provenance_kk.signed.json
echo " "
echo "-------"
echo "Verifying provenance ..."
salt verify \
--basedir ${GITHUB_WORKSPACE} \
--attestation=${GITHUB_WORKSPACE}/provenance_kk.signed.json \
--public-key=${GITHUB_WORKSPACE}/Test1_public.pem \
--file ./MyApp.war
В процессе проверки оцениваются:
- артефакт sha256сумма действительна (т.е. имеется свидетельство об этом «предмете»), и
- аттестация надлежащим образом аутентифицирована (он был создан с использованием соответствующего закрытого ключа)
Этот процесс проверки может затем оценить, что и артефакт, и аттестация действительны.
Но, как вы помните, в нашем случае артефакт был сгенерирован «злонамеренным» pipeline (т.е. не оригинал, а модифицированный pipeline). Тогда мы должны пойти дальше и проверить еще один аспект: артефакт был создан «оригиналом» pipeline, а не какой-либо другой.
Для этого просто добавьте простую строку для проверки этого условия, например:
echo " "
echo "-------"
# Download the provenance attestation
echo "Downloading the provenance attestation ..."
salt -q reg get --id=$ATT_ID --format=json > ${GITHUB_WORKSPACE}/provenance_kk.signed.json
WFR=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json |base64 -d | jq -r .predicate.buildDefinition.internalParameters.environment.GITHUB_WORKFLOW_REF)
echo $WFR | grep cicd_top10_3_salt\/.github\/workflows\/build.yml
Эта дополнительная проверка завершится неудачей, если артефакт не был сгенерирован нашим «сейфом». pipeline.
Если артефакт был создан нашим оригиналом pipeline (cicd_top10_3_salt/.github/workflows/build.yml), команда grep завершится успешно, в противном случае она завершится неудачно, что приведет к нарушению pipeline и прерывание дальнейших действий.
«Строитель» pipeline это всего лишь одна точка взлома, которую следует проверить, но, как упоминалось ранее, есть и другие точки взлома, которые нам следует проверить.
Например, что, если исходный код был подделан после извлечения из репозитория и перед командой сборки? В этом случае код, который нужно построить, не совпадает с кодом, хранящимся в SCM.
Проверить эту точку взлома так же просто, как проверять хэши материала на каждом этапе.
SHA_ATT_MATERIAL=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json | base64 -d | jq -r .predicate.attestations[0].predicate.materials[].digest[])
SHA_STEP_MATERIAL=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json | base64 -d | jq -r .predicate.attestations[3].predicate.materials[0].digest[])
Выводы
Таким образом, Аттестация программного обеспечения — это утверждение, сделанное в отношении части программного обеспечения, т. е. заверенное заявление (метаданные) об артефакте программного обеспечения или наборе артефактов программного обеспечения.
Аттестации программного обеспечения — это обобщение необработанного подписывания артефактов/кода. Аттестация — это подписанный документ (в заданном формате, обычно на основе JSON), который связывает метаданные с артефактом. Они представляют собой доказательства, связывающие входные данные (материалы) и выходные данные (производимые артефакты) на каждом этапе сборки.
Аттестации обеспечивают проверяемую запись шагов, выполненных для создания окончательных артефактов программного обеспечения, включая входные материалы для каждого шага и выполняемые команды сборки.
В заключение отметим, что аттестация программного обеспечения — отличный механизм для проверки различных аспектов целостности нашего процесса сборки.
Закончили серию? Не волнуйся! Не стесняйтесь вернуться к 'Отравленные Pipeline Исполнение (СИЗ)' или любой другой пост, который снова вызовет у вас интерес!
Оставайтесь с нами, мы подробно рассмотрим аттестации программного обеспечения и build security в дальнейших сообщениях блога.
