Pentesting CI/CD Methodology

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 stands for Version Control System, ця система дозволяє розробникам керувати своїм вихідним кодом. Найпоширеніша — git, і ви зазвичай знайдете компанії, що використовують його на одній з наступних platforms:

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

CI/CD Pipelines

CI/CD pipelines дозволяють розробникам автоматизувати виконання коду з різними цілями, включно зі збіркою, тестуванням та деплоєм додатків. Ці автоматизовані робочі процеси тригеряться певними діями, такими як push-і, pull request-и або заплановані задачі. Вони корисні для оптимізації шляху від розробки до production.

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

VCS Pentesting Methodology

note

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

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

  • Leaks: Якщо ваш код містить leaks у комітах і attacker може отримати доступ до repo (бо він публічний або тому що attacker має доступ), він може виявити ці leaks.
  • Access: Якщо attacker може получити доступ до аккаунта всередині VCS platform — він може отримати більшу видимість і дозволи.
  • Register: Деякі платформи просто дозволяють зовнішнім користувачам створювати акаунти.
  • SSO: Деякі платформи не дозволяють реєстрацію, але дозволяють будь-кому увійти з валідним SSO (тому attacker, наприклад, може використати свій github акаунт для входу).
  • Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... існує кілька типів токенів, які користувач може вкрасти, щоб отримати доступ до repo.
  • Webhooks: VCS platforms дозволяють генерувати webhooks. Якщо вони не захищені невидимими secrets — attacker може ними зловживати.
  • Якщо секрет відсутній, attacker може зловживати webhook-ом третьої сторони.
  • Якщо secret знаходиться в URL, те ж саме відбувається, і attacker також отримує secret.
  • 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), а також GitHub Actions YAML файли під .github/workflows. Коли тригериться job pipeline, він pull-ить код із вибраного джерела (наприклад commit / branch) і виконує команди, вказані в CI configuration file, відносно цього коду.

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

PPE - Poisoned Pipeline Execution

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

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

  • Мати write access до 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 — коли actor безпосередньо модифікує CI config файл, який буде виконуватись.
  • I-DDE: Indirect PPE — коли actor модифікує файл, на який CI config покладається (наприклад Makefile або terraform config).
  • Public PPE or 3PE: У деяких випадках pipelines можуть бути тригерені користувачами, які не мають write access до repo (і навіть які можуть не бути частиною org), бо вони можуть надіслати PR.
  • 3PE Command Injection: Зазвичай CI/CD pipelines будуть встановлювати env variables з інформацією про PR. Якщо attacker може контролювати це значення (наприклад заголовок PR) і воно використовується у небезпечному місці (наприклад при виконанні sh команд), attacker може інжектити туди команди.

Exploitation Benefits

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

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

More relevant info

Tools & CIS Benchmark

  • Chain-bench — open-source tool для аудиту вашого software supply chain stack на відповідність безпеці, базований на новому 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 — static code analysis tool для 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