Pentesting CI/CD Методологія

Reading time: 7 minutes

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks

VCS

VCS означає система контролю версій (Version Control System), ця система дозволяє розробникам керувати своїм вихідним кодом. Найпоширеніша — git, і зазвичай ви знайдете компанії, що використовують її на одній з наступних платформ:

  • Github
  • Gitlab
  • Bitbucket
  • Gitea
  • Gitblit
  • Cloud providers (they offer their own VCS platforms)

CI/CD Pipelines

CI/CD pipelines дають змогу розробникам автоматизувати виконання коду для різних цілей — збірки, тестування та деплою додатків. Ці автоматизовані робочі процеси тригеряться певними діями, такими як code pushes, pull requests або заплановані завдання. Вони корисні для оптимізації процесу від розробки до продакшн.

Однак такі системи потрібно виконувати десь, зазвичай з привілейованими обліковими даними для деплою коду або доступу до чутливої інформації.

VCS Pentesting Methodology

note

Навіть якщо деякі VCS платформи дозволяють створювати pipelines, у цьому розділі ми будемо аналізувати лише потенційні атаки на контроль за вихідним кодом.

Платформи, що містять вихідний код вашого проєкту, містять чутливу інформацію, тому потрібно дуже уважно ставитися до дозволів, наданих у цій платформі. Ось деякі поширені проблеми у VCS платформах, якими нападник може зловживати:

  • Leaks: Якщо ваш код містить leaks у комітах і нападник має доступ до репо (бо воно публічне або він має доступ), він може виявити ці leaks.
  • Access: Якщо нападник може доступитися до акаунту на VCS платформі, він може отримати більшу видимість і дозволи.
  • Register: Деякі платформи просто дозволяють зовнішнім користувачам створювати акаунт.
  • SSO: Деякі платформи не дозволяють реєстрацію, але дозволяють будь-кому зайти з валідним SSO (наприклад, нападник може використати свій github акаунт, щоб увійти).
  • Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... існує кілька типів токенів, які користувач може вкрасти, щоб отримати доступ до репозиторію.
  • Webhooks: VCS платформи дозволяють генерувати webhooks. Якщо вони не захищені невидимими секретами, нападник може ними зловживати.
  • Якщо секрету немає, нападник може зловживати webhook третьої сторони.
  • Якщо секрет знаходиться в URL, відбувається те саме і нападник також отримує секрет.
  • Code compromise: Якщо зловмисник має якийсь вид write доступу до репозиторіїв, він може спробувати впровадити шкідливий код. Щоб це зробити, можливо, доведеться обійти branch protections. Ці дії можуть виконуватися з різними цілями:
    • Скомпрометувати main branch, щоб скомпрометувати production.
    • Скомпрометувати main (або інші гілки), щоб скомпрометувати машини розробників (оскільки вони зазвичай виконують тестування, terraform чи інше в репо на своїх машинах).
  • Compromise the pipeline (див. наступний розділ)

Pipelines Pentesting Methodology

Найпоширеніший спосіб визначити pipeline — використовувати CI configuration file, розміщений у репозиторії, який будує pipeline. Цей файл описує порядок виконуваних jobs, умови, що впливають на потік, та налаштування середовища збірки.
Ці файли зазвичай мають послідовну назву та формат, наприклад — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), і YAML-файли GitHub Actions під .github/workflows. Після тригера job pipeline пулить код із вибраного джерела (наприклад, commit / branch) і виконує команди, вказані в CI configuration file, проти цього коду.

Отже, кінцева мета нападника — якимось чином скомпрометувати ці конфігураційні файли або команди, що вони виконують.

tip

Деякі hosted builders дозволяють контриб’юторам вибирати Docker build context та Dockerfile path. Якщо контекст контролюється нападником, ви можете вказати його поза репо (наприклад, ".."), щоб інжектити файли хоста під час збірки і витягувати секрети. Див.:

{{#ref}} docker-build-context-abuse.md {{#endref}}

PPE - Poisoned Pipeline Execution

Poisoned Pipeline Execution (PPE) шлях експлуатує дозволи в SCM репозиторії для маніпуляції CI pipeline та виконання шкідливих команд. Користувачі з необхідними дозволами можуть змінювати CI configuration files або інші файли, які використовуються job-ом pipeline, щоб включити шкідливі команди. Це "отруює" CI pipeline, і в результаті виконуються ці шкідливі команди.

Щоб зловмисник успішно провів PPE атаку, йому потрібно:

  • Мати write access to the VCS platform, оскільки зазвичай pipelines тригеряться при push або pull request. (Див. VCS pentesting methodology для підсумку способів отримати доступ).
  • Зверніть увагу, що іноді external PR рахується як "write access".
  • Навіть якщо він має write permissions, йому потрібно переконатися, що він може змінити CI config file або інші файли, від яких залежить конфіг.
  • Для цього можливо доведеться обійти branch protections.

Існує 3 варіанти PPE:

  • D-PPE: Direct PPE відбувається, коли актор модифікує CI config файл, який буде виконано.
  • I-DDE: Indirect PPE відбувається, коли актор модифікує файл, на який покладається CI config (наприклад make file або terraform config).
  • Public PPE or 3PE: Іноді pipelines можуть бути тригеровані користувачами, які не мають write access у репо (і навіть не є частиною org), тому що вони можуть надіслати PR.
  • 3PE Command Injection: Зазвичай CI/CD pipelines будуть встановлювати environment variables з інформацією про PR. Якщо цим значенням може керувати нападник (наприклад, title of the PR) і воно використовується в небезпечному місці (наприклад при виконанні sh commands), нападник може впровадити туди команди.

Exploitation Benefits

Знаючи 3 варіанти отруєння pipeline, подивимося, що може отримати нападник після успішної експлуатації:

  • Secrets: Як було згадано раніше, pipelines потребують привілеїв для своїх job-ів (отримати код, зібрати його, задеплоїти...) і ці привілеї зазвичай зберігаються в secrets. Ці secrets зазвичай доступні через env variables або файли всередині системи. Тому нападник завжди намагатиметься ексфільтрувати якомога більше secrets.
  • Залежно від платформи pipeline нападник може вимагати вказати secrets у конфігах. Це означає, що якщо нападник не може змінити CI configuration pipeline (I-PPE, наприклад), він зможе ексфільтрувати тільки ті secrets, які має цей pipeline.
  • Computation: Код виконується десь; залежно від місця виконання нападник може виконати подальший pivot.
  • On-Premises: Якщо pipelines виконуються on-premises, нападник може опинитися в внутрішній мережі з доступом до додаткових ресурсів.
  • Cloud: Нападник може отримати доступ до інших машин у хмарі, а також може ексфільтрувати IAM roles/service accounts tokens, щоб отримати додатковий доступ у cloud.
  • Platforms machine: Іноді jobs виконуються всередині машин платформи pipelines, які зазвичай знаходяться у хмарі й мають немає додаткових доступів.
  • Select it: Іноді платформа pipelines конфігурує кілька машин, і якщо ви можете змінити CI configuration file, ви можете вказати, де запускати шкідливий код. У такому випадку нападник, ймовірно, запустить зворотний shell на кожній можливій машині, щоб спробувати подальшу експлуатацію.
  • Compromise production: Якщо ви всередині pipeline і кінцеву версію збирають і деплоять звідти, ви можете скампрометувати код, який буде запущено у production.

More relevant info

Tools & CIS Benchmark

  • Chain-bench — open-source інструмент для аудиту вашого software supply chain стеку на предмет відповідності безпеці, базований на новому CIS Software Supply Chain benchmark. Аудит фокусується на всьому SDLC процесі, де він може виявити ризики від часу коду до часу деплою.

Top 10 CI/CD Security Risk

Перегляньте цікаву статтю про топ-10 CI/CD ризиків за версією Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

  • На кожній платформі, яку ви можете запускати локально, ви знайдете інструкцію, як запустити її локально, щоб ви могли налаштувати її на свій розсуд для тестування
  • Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat

Automatic Tools

  • Checkov: Checkov — інструмент статичного аналізу коду для infrastructure-as-code.

References

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks