Pentesting CI/CD Methodology
VCS
VCS означає Система контролю версій, ці системи дозволяють розробникам керувати своїм вихідним кодом. Найпоширенішою є git, і ви зазвичай знайдете компанії, які використовують його на одній з наступних платформ:
Github
Gitlab
Bitbucket
Gitea
Хмарні постачальники (вони пропонують власні платформи VCS)
Пайплайни
Пайплайни дозволяють розробникам автоматизувати виконання коду (для будівництва, тестування, розгортання... цілей) після виникнення певних подій: пуш, PR, cron... Вони дуже корисні для автоматизації всіх етапів від розробки до виробництва.
Однак ці системи потребують виконання десь і зазвичай з привілейованими обліковими даними для розгортання коду.
Методологія тестування на проникнення VCS
Навіть якщо деякі платформи VCS дозволяють створювати пайплайни, для цього розділу ми будемо аналізувати лише потенційні атаки на контроль вихідного коду.
Платформи, які містять вихідний код вашого проекту, містять чутливу інформацію, і людям потрібно дуже обережно ставитися до наданих дозволів всередині цієї платформи. Ось деякі загальні проблеми на платформах VCS, які може використовувати зловмисник:
Витоки: Якщо ваш код містить витоки в комітах і зловмисник може отримати доступ до репозиторію (через те, що він є публічним або через те, що він має доступ), він може виявити витоки.
Доступ: Якщо зловмисник може отримати доступ до облікового запису на платформі VCS, він може отримати більше видимості та дозволів.
Реєстрація: Деякі платформи дозволять зовнішнім користувачам створювати обліковий запис.
SSO: Деякі платформи не дозволять користувачам реєструватися, але дозволять будь-кому отримати доступ за допомогою дійсного SSO (тому зловмисник може використовувати свій обліковий запис github, наприклад).
Облікові дані: Ім'я користувача + пароль, особисті токени, ssh-ключі, токени Oauth, куки... існує кілька видів токенів, які користувач може вкрасти для доступу до репозиторію якимось чином.
Веб-гачки: Платформи VCS дозволяють генерувати веб-гачки. Якщо вони не захищені невидимими секретами, зловмисник може їх використовувати.
Якщо секрету немає, зловмисник може використовувати веб-гачок сторонньої платформи
Якщо секрет знаходиться в URL, те саме стосується і зловмисника, який також має секрет
Компрометація коду: Якщо зловмисник має якийсь вид запису до репозиторії, він може спробувати впровадити шкідливий код. Для успішності йому може знадобитися обхід захисту гілок. Ці дії можуть бути виконані з різними цілями в голові:
Компрометувати основну гілку для компрометації виробництва.
Компрометувати основну (або інші гілки), щоб компрометувати машини розробників (оскільки вони зазвичай виконують тестування, terraform або інші речі всередині репозиторію на своїх машинах).
Компрометація пайплайну (див. наступний розділ)
Методологія тестування на проникнення пайплайнів
Найпоширеніший спосіб визначення пайплайну - це використання файлу конфігурації CI, розміщеного в репозиторії, який будує пайплайн. Цей файл описує порядок виконання завдань, умови, які впливають на потік, та налаштування середовища збірки. Ці файли зазвичай мають стале ім'я та формат, наприклад — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) та файли YAML дій GitHub Actions, розташовані в .github/workflows. При спрацюванні пайплайну завдання витягує код з обраного джерела (наприклад, коміт / гілка) та виконує команди, вказані в файлі конфігурації CI, проти цього коду.
Отже, кінцевою метою зловмисника є якимось чином компрометувати ці файли конфігурації або команди, які вони виконують.
PPE - Отруєне виконання пайплайну
Шлях Отруєного виконання пайплайну (PPE) використовує дозволи в репозиторії SCM для маніпулювання CI пайплайном та виконання шкідливих команд. Користувачі з необхідними дозволами можуть змінювати файли конфігурації CI або інші файли, які використовуються завданням пайплайну для включення шкідливих команд. Це "отруює" CI пайплайн, що призводить до виконання цих шкідливих команд.
Для успішного виконання атаки PPE зловмисник повинен:
Мати права на запис до платформи VCS, оскільки пайплайни зазвичай спрацьовують при виконанні пушу або запиту на злиття. (Перевірте методологію тестування на проникнення VCS для підсумку способів отримання доступу).
Зверніть увагу, що іноді зовнішній PR вважається "правами на запис".
Навіть якщо він має права на запис, він повинен бути впевнений, що може змінити файл конфігурації CI або інші файли, від яких залежить конфігурація.
Для цього він може потребувати можливості обхіду захисту гілок.
Існує 3 смаки PPE:
D-PPE: Пряма атака PPE відбувається, коли зловмисник змінює файл конфігурації CI, який буде виконаний.
I-DDE: Непряма атака PPE відбувається, коли зловмисник змінює файл, від якого залежить файл конфігурації CI, який буде виконаний (наприклад, файл make або конфігурація terraform).
Публічне PPE або 3PE: У деяких випадках пайплайни можуть бути спровоковані користувачами, які не мають прав на запис у репозиторій (і які можуть навіть не бути частиною організації), оскільки вони можуть надіслати PR.
Впровадження команд 3PE: Зазвичай пайплайни CI/CD будуть встановлювати змінні середовища з інформацією про PR. Якщо це значення може контролюватися зловмисником (наприклад, заголовок PR) і використовується в небезпечному місці (наприклад, виконання sh команд), зловмисник може впровадити команди туди.
Переваги експлуатації
Знаючи 3 смаки отруєння пайплайну, давайте перевіримо, що зловмисник може отримати після успішної експлуатації:
Секрети: Як вже зазначалося, пайплайни вимагають привілеїв для своїх завдань (отримання коду, збірка, розгортання...) і ці привілеї зазвичай надаються в секретах. Ці секрети зазвичай доступні через змінні середовища або файли всередині системи. Тому зловмисник завжди спробує витягнути якомога більше секретів.
Залежно від платформи пайплайну зловмисник може потребувати вказати секрети в конфігурації. Це означає, що якщо зловмисник не може змінити конфігурацію пайплайну CI (I-PPE, наприклад), він може лише витягнути секрети, які має цей пайплайн.
Обчислення: Код виконується десь, залежно від того, де він виконується, зловмисник може мати можливість просунут
Додаткова важлива інформація
Інструменти та стандарт CIS
Chain-bench - це відкритий інструмент для аудиту стеку вашого програмного забезпечення для відповідності до стандартів безпеки на основі нового стандарту CIS для ланцюга постачання програмного забезпечення. Аудитування зосереджене на всьому процесі SDLC, де воно може виявити ризики від часу написання коду до часу розгортання.
Топ-10 ризиків безпеки CI/CD
Перевірте цікаву статтю про топ-10 ризиків CI/CD за версією Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/
Лабораторії
На кожній платформі, яку можна запустити локально, ви знайдете інструкції щодо запуску локально, щоб налаштувати її так, як вам потрібно для тестування.
Лабораторія Gitea + Jenkins: https://github.com/cider-security-research/cicd-goat
Автоматичні інструменти
Checkov: Checkov - це інструмент статичного аналізу коду для інфраструктури-як-коду.
Посилання
Last updated
