hacktricks-cloud/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

Pentesting CI/CD Methodology

{{#include ../banners/hacktricks-training.md}}

VCS

VCS stands for Version Control System, systems hizi zinamruhusu developer ku dhibiti source code yao. Ilikuwa ya kawaida ni git na kawaida kampuni zitakutumia kwenye moja ya platforms zifuatazo:

• Github
• Gitlab
• Bitbucket
• Gitea
• Gitblit
• Cloud providers (wao hutoa VCS platform zao)

CI/CD Pipelines

CI/CD pipelines zinawezesha developers kuendesha kwa njia ya otomatiki execution ya code kwa madhumuni mbalimbali, ikiwemo building, testing, na deploying applications. Workflow hizi za otomatiki hutazamwa na vitendo maalum, kama vile code pushes, pull requests, au scheduled tasks. Zinasaidia kurahisisha mchakato kutoka development hadi production.

Hata hivyo, mifumo hii inahitaji kuendeshwa mahali fulani na mara nyingi kwa credentials zilizo na privileges za juu ili ku-deploy code au kufikia taarifa nyeti.

VCS Pentesting Methodology

Note

Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.

Platforms zinazoshikilia source code ya project yako zinashikilia taarifa nyeti na watu wanapaswa kuwa waangalifu sana na permissions zinazotolewa ndani ya platform hii. Hapa kuna matatizo ya kawaida katika VCS platforms ambayo attacker anaweza kuchochea:

• Leaks: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks.
• Access: Ikiwa attacker anaweza kuingia kwenye account ndani ya VCS platform anaweza kupata uwazi zaidi na permissions.
• Register: Baadhi ya platforms zitaruhusu watumiaji wa nje kuunda account.
• SSO: Baadhi ya platforms hazitaruhusu watumiaji kujisajili, lakini zitawaruhusu mtu yeyote kuingia kwa SSO halali (hivyo attacker anaweza kutumia account yake ya github kuingia kwa mfano).
• Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... kuna aina kadhaa za tokens mtu anaweza kuiba ili kupata access kwa njia mbalimbali kwenye repo.
• Webhooks: VCS platforms zinaweza kuunda webhooks. Ikiwa hazilindwa kwa siri zisizoonekana, attacker anaweza kuzitumia.
• If no secret is in place, the attacker could abuse the webhook of the third party platform
• If the secret is in the URL, the same happens and the attacker also have the secret
• Code compromise: Ikiwa muovu ana aina yoyote ya write access juu ya repos, anaweza kujaribu kuficha malicious code. Ili kufanikiwa anaweza kuhitaji kubypass branch protections. Vitendo hivi vinaweza kufanywa kwa malengo tofauti:
  • Kuiba main branch ili kucompromise production.
  • Kucompromise main (au matawi mengine) ili kucompromise machines za developers (wakati wao mara nyingi huendesha tests, terraform au vitu vingine ndani ya repo kwenye mashine zao).
• Compromise the pipeline (angalia sehemu inayofuata)

Pipelines Pentesting Methodology

Njia ya kawaida ya kufafanua pipeline ni kwa kutumia CI configuration file hosted in the repository pipeline inajenga. File hii inaelezea mpangilio wa jobs zinazotekelezwa, masharti yanayoathiri flow, na mazingira ya build.
Files hizi kwa kawaida zina majina na format zinazofanana, kwa mfano — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), na GitHub Actions YAML files ziko ndani ya .github/workflows. Wakati zinapoanzishwa, pipeline job inapiga code kutoka kwa source iliyochaguliwa (mfano commit / branch), na inakimbiza commands zilizobainishwa ndani ya CI configuration file dhidi ya code hiyo.

Hivyo lengo kuu la attacker ni kwa namna fulani kucompromise hizo configuration files au commands wanazotekeleza.

Tip

Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See:

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

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.

Ili muovu afanikiwe kufanya shambulio la PPE anahitaji:

• Kuwa na write access to the VCS platform, kwani kawaida pipelines zinaanzishwa wakati push au pull request inafanywa. (Angalia VCS pentesting methodology kwa muhtasari wa njia za kupata access).
• Kumbuka kwamba wakati mwingine external PR inachukuliwa kuwa "write access".
• Hata kama ana write permissions, anahitaji kuwa na uhakika anaweza kubadilisha CI config file au files nyingine ambazo config inategemea.
• Kwa hili, anaweza kuhitaji uwezo wa kubypass branch protections.

Kuna aina 3 za PPE:

• D-PPE: A Direct PPE attack hutokea wakati muovu anabadilisha CI config file ambayo itatekelezwa.
• I-DDE: An Indirect PPE attack hutokea wakati muovu anabadilisha faili ambayo CI config inategemea (kama make file au terraform config).
• Public PPE or 3PE: Katika baadhi ya kesi pipelines zinaweza kuanzishwa na watumiaji ambao hawana write access kwenye repo (na ambao huenda si sehemu ya org) kwa sababu wanaweza kutuma PR.
• 3PE Command Injection: Kawaida, CI/CD pipelines zitakuwa zikiteua environment variables na taarifa kuhusu PR. Ikiwa thamani hiyo inaweza kudhibitiwa na attacker (kama title ya PR) na inatumiwa mahali hatari (kama kutekeleza sh commands), attacker anaweza kuingiza commands ndani yake.

Exploitation Benefits

Kutambua aina 3 za ku-chinika pipeline, tuchunguze kile attacker anaweza kupata baada ya kuthibitika:

• Secrets: Kama ilivyotajwa awali, pipelines zinahitaji privileges kwa jobs zao (kuchukua code, kui-build, kui-deploy...) na privileges hizi kawaida huwekwa kama secrets. Secrets hizi kwa kawaida zinapatikana kupitia env variables au files ndani ya system. Kwa hivyo attacker atajaribu kila nakala ku-exfiltrate secrets nyingi iwezekanavyo.
• Kutegemea platform ya pipeline attacker anaweza kuhitaji kutaja secrets katika config. Hii inamaanisha kwamba kama attacker hawezi kubadilisha CI configuration pipeline (I-PPE kwa mfano), anaweza ku-exfiltrate tu secrets ambazo pipeline ina.
• Computation: Code inatekelezwa mahali fulani, kutegemea wapi inatekelezwa attacker anaweza kuweza kupindua zaidi.
• On-Premises: Ikiwa pipelines zinaendeshwa on-premises, attacker anaweza kuingia kwenye internal network na access kwa rasilimali zaidi.
• Cloud: Attacker anaweza kupata machines nyingine kwenye cloud lakini pia anaweza ku-exfiltrate IAM roles/service accounts tokens kutoka hapo ili kupata access zaidi ndani ya cloud.
• Platforms machine: Wakati mwingine jobs zitakuwa zimekimbizwa ndani ya pipelines platform machines, ambazo kwa kawaida ziko ndani ya cloud na havina access zaidi.
• Select it: Wakati mwingine pipelines platform itakuwa ime-configure machines kadhaa na ikiwa unaweza kubadilisha CI configuration file unaweza kuonyesha wapi unataka kukimbiza malicious code. Katika hali hii, attacker atafanya labda reverse shell kwenye kila machine inayowezekana kujaribu kuilazimisha zaidi.
• Compromise production: Ikiwa uko ndani ya pipeline na version ya mwisho inajengwa na ku-deploy kutoka kwake, unaweza kucompromise code ambayo itakuwa inayoendesha production.

More relevant info

Tools & CIS Benchmark

• Chain-bench ni tool ya open-source kwa auditing ya software supply chain stack kwa security compliance kulingana na CIS Software Supply Chain benchmark. Auditing inazingatia mchakato wa SDLC mzima, ambapo inaweza kufichua hatari kutoka wakati wa kuandika code hadi wakati wa ku-deploy.

Top 10 CI/CD Security Risk

Angalia makala hii ya kuvutia kuhusu top 10 CI/CD risks kwa mujibu wa Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

• Kila platform ambayo unaweza kuendesha locally utapata jinsi ya kuianzisha locally ili uweze ku-configure kama unavyotaka kuipima
• Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat

Automatic Tools

• Checkov: Checkov ni tool ya static code analysis kwa 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

{{#include ../banners/hacktricks-training.md}}