Pentesting CI/CD Metodologija

Reading time: 8 minutes

VCS

VCS znači Version Control System, ovi sistemi dozvoljavaju developerima da upravljaju svojim source code-om. Najčešći je git i obično ćete kompanije naći koje ga koriste na jednoj od sledećih platformi:

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

CI/CD Pipelines

CI/CD pipelines omogućavaju developerima da automatizuju izvršavanje koda za razne svrhe, uključujući build, testiranje i deploy aplikacija. Ovi automatizovani workflow-i su okidači određenim akcijama, kao što su code pushes, pull requests ili zakazani zadaci. Korisni su za pojednostavljenje procesa od development-a do produkcije.

Međutim, ovi sistemi moraju da se izvršavaju negde i obično sa privileged credentials da bi deploy-ovali kod ili pristupili osetljivim informacijama.

VCS Pentesting Methodology

Platforme koje sadrže source code vašeg projekta sadrže osetljive informacije i ljudi moraju biti veoma pažljivi sa permissions koje se dodeljuju unutar te platforme. Ovo su neki uobičajeni problemi preko VCS platformi koje napadač može zloupotrebiti:

• Leaks: Ako vaš kod sadrži leaks u commit-ovima i napadač može da pristupi repo-u (jer je public ili zato što ima pristup), mogao bi otkriti te leaks.
• Access: Ako napadač može da pristupi nalogu unutar VCS platforme mogao bi steći veću vidljivost i permissions.
• Register: Neke platforme će samo dozvoliti eksternim korisnicima da kreiraju nalog.
• SSO: Neke platforme neće dozvoliti registraciju, ali će dozvoliti bilo kome da se prijavi sa validnim SSO (tako da napadač može koristiti svoj github nalog da uđe, na primer).
• Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... postoji više vrsta tokena koje korisnik može ukrasti da bi na neki način pristupio repo-u.
• Webhooks: VCS platforme dozvoljavaju generisanje webhooks. Ako nisu zaštićeni sa nevidljivim secret-ima, napadač ih može zloupotrebiti.
• Ako nema secret-a na mestu, napadač može zloupotrebiti webhook treće strane
• Ako je secret u URL-u, isto se dešava i napadač tada takođe ima secret
• Code compromise: Ako zlonamerni akter ima neku vrstu write pristupa nad repos-ima, može pokušati da inject-uje malicious code. Da bi bio uspešan, možda će morati da zaobiđe branch protections. Ove akcije se mogu izvesti sa različitim ciljevima:
  • Kompromitovati main branch da bi kompromitovao production.
  • Kompromitovati main (ili druge brancheve) da kompromituje developer-ove mašine (pošto oni obično izvršavaju testove, terraform ili druge stvari unutar repo-a na svojim mašinama).
• Compromise the pipeline (pogledati sledeći odeljak)

Pipelines Pentesting Methodology

Najčešći način definisanja pipeline-a je korišćenjem CI configuration file hostovanog u repository-ju koji pipeline build-uje. Ovaj fajl opisuje redosled izvršenih job-ova, uslove koji utiču na tok, i podešavanja build okruženja.
Ovi fajlovi obično imaju konzistentno ime i format, na primer — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), i GitHub Actions YAML fajlovi locirani pod .github/workflows. Kada se okine, pipeline job pull-uje kod sa izabranog source-a (npr. commit / branch), i izvršava komande navedene u CI configuration file-u nad tim kodom.

Dakle, krajnji cilj napadača je na neki način kompromitovati te configuration fajlove ili komande koje oni izvršavaju.

PPE - Poisoned Pipeline Execution

The Poisoned Pipeline Execution (PPE) path exploits permissions in an SCM repository to manipulate a CI pipeline and execute harmful commands. Users with the necessary permissions can modify CI configuration files or other files used by the pipeline job to include malicious commands. This "poisons" the CI pipeline, leading to the execution of these malicious commands.

For a malicious actor to be successful performing a PPE attack he needs to be able to:

• Have write access to the VCS platform, as usually pipelines are triggered when a push or a pull request is performed. (Check the VCS pentesting methodology for a summary of ways to get access).
• Note that sometimes an external PR count as "write access".
• Even if he has write permissions, he needs to be sure he can modify the CI config file or other files the config is relying on.
• For this, he might need to be able to bypass branch protections.

There are 3 PPE flavours:

• D-PPE: A Direct PPE attack occurs when the actor modifies the CI config file that is going to be executed.
• I-DDE: An Indirect PPE attack occurs when the actor modifies a file the CI config file that is going to be executed relays on (like a make file or a terraform config).
• Public PPE or 3PE: In some cases the pipelines can be triggered by users that doesn't have write access in the repo (and that might not even be part of the org) because they can send a PR.
• 3PE Command Injection: Usually, CI/CD pipelines will set environment variables with information about the PR. If that value can be controlled by an attacker (like the title of the PR) and is used in a dangerous place (like executing sh commands), an attacker might inject commands in there.

Exploitation Benefits

Knowing the 3 flavours to poison a pipeline, lets check what an attacker could obtain after a successful exploitation:

• Secrets: As it was mentioned previously, pipelines require privileges for their jobs (retrieve the code, build it, deploy it...) and these privileges are usually granted in secrets. These secrets are obično dostupni preko env variables ili fajlova unutar sistema. Zbog toga će napadač uvek pokušati da eksfiltruje što više secrets-a.
• Depending on the pipeline platform the attacker might need to specify the secrets in the config. This means that is the attacker cannot modify the CI configuration pipeline (I-PPE for example), he could only exfiltrate the secrets that pipeline has.
• Computation: Kod se izvršava negde; u zavisnosti od mesta izvođenja, napadač može imati mogućnost daljeg pivot-a.
• On-Premises: Ako se pipelines izvršavaju on premises, napadač može završiti u internoj mreži sa pristupom većim resursima.
• Cloud: Napadač može pristupiti drugim mašinama u cloudu ali takođe može eksfiltrirati IAM roles/service accounts tokens iz njega da bi dobio dalji pristup unutar clouda.
• Platforms machine: Ponekad se job-ovi izvršavaju unutar pipelines platform mašina, koje obično postoje unutar clouda bez dodatnog pristupa.
• Select it: Ponekad će pipelines platform biti konfigurisala više mašina i ako možete modifikovati CI configuration file možete naznačiti gde želite da pokrenete malicious code. U tom slučaju, napadač će verovatno pokrenuti reverse shell na svakoj mogućoj mašini da pokuša dalje eksploatisati.
• Compromise production: Ako ste unutar pipeline-a i finalna verzija se build-uje i deploy-uje iz njega, možete kompromitovati kod koji će se izvršavati u produkciji.

More relevant info

Tools & CIS Benchmark

• Chain-bench is an open-source tool for auditing your software supply chain stack for security compliance based on a new CIS Software Supply Chain benchmark. The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time.

Top 10 CI/CD Security Risk

Check this interesting article about the top 10 CI/CD risks according to Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

• On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it
• Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat

Automatic Tools

• Checkov: Checkov is a static code analysis tool for infrastructure-as-code.

References

• https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422