У нашій попередній публікації про CI/CD Pipelines, ми бачили як зламати CI/CD сценарій, який імовірно був захищений.
Давайте згадаємо нашу думку з попереднього допису: ми почали з деяких pipeline що було вразливим до Непряме отруєння Pipeline Виконання (І-ЗІЗ) і, щоб виправити це, ми вирішили розділити pipeline на два:
- 1st pipeline (Build CI), безпечний для D-PPE та I-PPE, перевірить PR-код, створить збірку та згенерує артефакт.
- 2nd pipeline (Тестовий CI), також безпечний для D-PPE та I-PPE, перевірить базовий код (щоб уникнути модифікації скриптів оболонки) та виконає оригінальні скрипти для артефакту.
- Синхронізація тестового CI 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 атестація є частиною дані представляє доказ подіїУ реальному світі ми зазвичай називаємо це сертифікати.
Наприклад, коли лабораторія аналізує вашу кров, дані про аналіз записуються та засвідчуються. Результати аналізу крові перевірявся та простежується.
Ближче до нашої ІТ-сфери, можна здогадатися, яким би був переклад цього процесу, наприклад, у процес компіляції.
Інформація про середовище та інструменти сервера компіляції, матеріали (вихідний код) та продукти/артефакти (двійковий код) буде частиною такої атестації.
Очевидно, що засвідчення має бути видане уповноваженим засвідчувачем (автентифікованим та непідданим сумніву), щоб забезпечити достовірність.
Ймовірно, дехто з вас думає... а що ж таке різниця між підписами та засвідченнями?
Підписи коду та засвідчення
На високому рівні, a підпис створюється за допомогою пари ключів та артефакту. Пара ключів складається з відкритого та закритого ключа.
Користувач підписує артефакт за допомогою закритого ключа, а інші можуть перевірити підпис за допомогою відкритого ключа. Закритий ключ має зберігатися в таємниці, але відкритий ключ широко розповсюджується.
Можна використовувати підписи довести, що власник закритого ключа використав закритий ключ для підписання артефакту.
Signatures не доводити
- Користувача намір підписати артефакт (їх могли обдурити), або
- Намір користувача зробити будь-які конкретне твердження щодо артефакту
З Атестації, замість того, щоб підписувати артефакт безпосередньо, користувачі створюють певний вид документ Що вловлює їхній намір за підписанням артефакту та будь-якого конкретні твердження зроблено як частина цього підпису.
Структура атестації In-toto
Найпоширеніша рамка - це Структура атестації in-toto
- визначає standard формат для атестацій що пов'язують суб'єктів, описувані артефакти, з автентифікованими метаданими про артефакт
- надає набір попередньо визначені предикати для передачі автентифікованих метаданих по всьому ланцюгу постачання програмного забезпечення
Давайте детальніше розглянемо формат атестації.
An Атестація це документ із цифровим підписом що містить Заяви.
Команда Заява є середнім шаром атестації, що пов'язує її з певним Тема та однозначно визначаючи типи Присудок:
- Тема: криптографічно захищене посилання на артефакт (зазвичай через хеш), та
- Предикатинабір конкретних претензій Твердження про цей артефакт називається твердженням. Ці твердження можна використовувати для вираження (а згодом і доведення) чого завгодно! Вони можуть представляти ручне схвалення, походження артефакту, результати автоматизованого тестування, журнал аудиту тощо!
Коли ця заява криптографічно підписана, вона називається Атестація
Таким чином, наприклад, Аліса створює твердження про артефакт і підписує його, використовуючи свій закритий ключ, створюючи засвідчення.
- Тоді Боб може перевірити підпис у цій Атестації, що дозволяє йому довіряти твердженням всередині.
Потім Боб може використовувати ці твердження вирішити чи дозволяти використання цього артефакту.
Чи можуть атестації допомогти вирішити проблему отруєння артефактами?
Після цього вступу до атестацій, давайте повернемося до нашої проблеми. Як атестації можуть допомогти нам вирішити нашу проблему, тобто уникнути отруєння артефактами?
Зловмисник зміг створити артефакт, минаючи «офіційний» механізм, тобто використовуючи свої pipeline для створення артефакту.
Було б чудово, якби ми могли довести, що завантажені артефакти були створені за допомогою офіційного... pipelineЦе лише один приклад того, що ми могли б назвати «точками втручання», але може бути багато інших.
Як видно на зображенні вище, точок втручання кілька. Таким чином, споживач pipeline (Тестовий ДІ у нашому прикладі) повинен оцінити цілісність процесу збірки а також цілісність самого артефакту.
У нашому прикладі отруєний артефакт був створений шляхом введення нового (отруєного) 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's сіль команда зберігає атестацію в бухгалтерська книга (також відомий як реєстр атестації, запис у нашому випадку, але ви можете використовувати будь-який інший). Зробивши це, споживач 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
Процес перевірки оцінює:
- Команда Артефакт sha256sum є дійсним (тобто є підтвердження щодо цього «предмета»), та
- Команда атестація належним чином засвідчена (він був згенерований за допомогою відповідного закритого ключа)
Цей процес перевірки може оцінити, чи є як артефакт, так і атестація дійсними.
Але, як ви пам'ятаєте, у нашому випадку артефакт був згенерований «шкідливою» програмою 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 у подальших публікаціях блогу.
