Mbinu ya Pentesting ya CI/CD

Tip

Jifunze na ufanye mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na ufanye mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na ufanye mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Saidia HackTricks

VCS

VCS inasimama kwa Version Control System, mfumo huu unaruhusu watengenezaji kusimamia source code yao. Ya kawaida zaidi ni git na kwa kawaida utapata makampuni yakitumia moja ya platforms zifuatazo:

  • Github
  • Gitlab
  • Bitbucket
  • Gitea
  • Gitblit
  • Cloud providers (wanatoa platforms zao wenyewe za VCS)

CI/CD Pipelines

CI/CD pipelines huwawezesha watengenezaji ku-automate utekelezaji wa code kwa madhumuni mbalimbali, ikiwemo kuijenga, kui-test, na kui-deploy applications. Workflows hizi za kiotomatiki huchochewa na actions mahususi, kama code pushes, pull requests, au kazi zilizopangwa. Ni muhimu kwa kurahisisha mchakato kutoka development hadi production.

Hata hivyo, mifumo hii inahitaji kutekelezwa mahali fulani na kwa kawaida kwa privileged credentials ili ku-deploy code au kufikia taarifa nyeti.

Mbinu ya Pentesting ya VCS

Note

Hata kama baadhi ya platforms za VCS huruhusu kuunda pipelines kwa sehemu hii tutaichambua tu mashambulizi yanayowezekana dhidi ya udhibiti wa source code.

Platforms zinazohifadhi source code ya project yako zina taarifa nyeti na watu wanahitaji kuwa waangalifu sana na permissions zinazotolewa ndani ya platform hii. Haya ni baadhi ya matatizo ya kawaida katika platforms za VCS ambayo attacker anaweza kutumia vibaya:

  • Leaks: Ikiwa code yako ina leaks kwenye commits na attacker anaweza kufikia repo (kwa sababu ni public au kwa sababu ana access), anaweza kugundua leaks hizo.
  • Access: Ikiwa attacker anaweza kufikia account ndani ya platform ya VCS anaweza kupata mwonekano zaidi na permissions zaidi.
  • Register: Baadhi ya platforms zitaruhusu tu users wa nje kuunda account.
  • SSO: Baadhi ya platforms hazitaruhusu users kujiandikisha, lakini zitaruhusu mtu yeyote kufikia kwa kutumia SSO halali (kwa hiyo 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 ambazo user anaweza kuiba ili kwa namna fulani kufikia repo.
  • Webhooks: Platforms za VCS huruhusu kuunda webhooks. Ikiwa hazijalindwa kwa secrets zisizoonekana an attacker could abuse them.
  • Ikiwa hakuna secret iliyowekwa, attacker anaweza kutumia vibaya webhook ya third party platform
  • Ikiwa secret iko kwenye URL, kitu kimoja hutokea na attacker pia anapata secret hiyo
  • Code compromise: Ikiwa actor mbaya ana aina fulani ya access ya write kwenye repos, anaweza kujaribu kudunga malicious code. Ili awe na mafanikio huenda akahitaji kuepuka branch protections. Vitendo hivi vinaweza kufanywa kwa malengo tofauti akilini:
  • Kuharibu main branch ili kuharibu production.
  • Kuharibu main (au branches nyingine) ili kuharibu machines za developers (kwa kawaida wao hu-execute test, terraform au mambo mengine ndani ya repo kwenye machines zao).
  • Kuharibu pipeline (angalia sehemu inayofuata)

Mbinu ya Pentesting ya Pipelines

Njia ya kawaida zaidi ya kufafanua pipeline ni kwa kutumia CI configuration file iliyohostiwa kwenye repository ambayo pipeline huijenga. File hii hueleza mpangilio wa jobs zinazotekelezwa, conditions zinazoathiri flow, na settings za build environment.
Files hizi kwa kawaida zina jina na format thabiti, kwa mfano — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), na GitHub Actions YAML files zilizo chini ya .github/workflows. Inapochochewa, pipeline job huchukua code kutoka kwenye source iliyochaguliwa (k.m. commit / branch), na huendesha commands zilizobainishwa katika CI configuration file dhidi ya code hiyo.

Kwa hiyo lengo la mwisho la attacker ni kwa namna fulani kuharibu files hizo za configuration au commands wanazotekeleza.

Tip

Baadhi ya hosted builders huruhusu contributors kuchagua Docker build context na Dockerfile path. Ikiwa context inadhibitiwa na attacker, unaweza kuiweka nje ya repo (k.m., “..”) ili kuchukua host files wakati wa build na ku-exfiltrate secrets. Tazama:

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

PPE - Poisoned Pipeline Execution

Njia ya Poisoned Pipeline Execution (PPE) hutumia permissions ndani ya SCM repository ili ku-manipulate CI pipeline na ku-execute commands hatari. Users wenye permissions zinazohitajika wanaweza kurekebisha CI configuration files au files nyingine zinazotumiwa na pipeline job ili kujumuisha commands za uhalifu. Hii “hu-poison” CI pipeline, na kusababisha utekelezaji wa commands hizi za uhalifu.

Ili actor mbaya afanikiwe katika kufanya shambulizi la PPE anahitaji kuwa na uwezo wa:

  • Kuwa na write access kwenye platform ya VCS, kwa kawaida pipelines huchochewa wakati push au pull request inapofanyika. (Angalia VCS pentesting methodology kwa muhtasari wa njia za kupata access).
  • Kumbuka kwamba wakati mwingine external PR huhesabika kama “write access”.
  • Hata akiwa na write permissions, anahitaji kuhakikisha anaweza kurekebisha CI config file au files nyingine ambazo config inategemea.
  • Kwa hili, huenda akahitaji kuwa na uwezo wa kuepuka branch protections.

Kuna aina 3 za PPE:

  • D-PPE: Shambulizi la Direct PPE hutokea wakati actor anarekebisha CI config file ambayo ita-executeiwa.
  • I-DDE: Shambulizi la Indirect PPE hutokea wakati actor anarekebisha file ambayo CI config file itakayotekelezwa inategemea (kama make file au terraform config).
  • Public PPE or 3PE: Katika baadhi ya hali pipelines zinaweza kuchochewa na users ambao hawana write access kwenye repo (na huenda hata wasiwe sehemu ya org) kwa sababu wanaweza kutuma PR.
  • 3PE Command Injection: Kwa kawaida, CI/CD pipelines zitaweka environment variables zenye taarifa kuhusu PR. Ikiwa value hiyo inaweza kudhibitiwa na attacker (kama title ya PR) na inatumika mahali hatari (kama ku-execute sh commands), attacker anaweza ku-dunga commands humo.

Faida za Utekelezaji

Kujua aina 3 za ku-poison pipeline, hebu tuone attacker anaweza kupata nini baada ya exploitation iliyofanikiwa:

  • Secrets: Kama ilivyotajwa hapo awali, pipelines zinahitaji privileges kwa jobs zake (kuchukua code, kuijenga, ku-deploy…) na privileges hizi kwa kawaida hutolewa katika secrets. Secrets hizi kwa kawaida zinaweza kufikiwa kupitia env variables au files ndani ya system. Kwa hiyo attacker atajaribu kila wakati ku-exfiltrate secrets nyingi iwezekanavyo.
  • Kulingana na platform ya pipeline, attacker huenda akahitaji kubainisha secrets kwenye config. Hii inamaanisha kwamba ikiwa attacker hawezi kurekebisha CI configuration pipeline (I-PPE kwa mfano), anaweza ku-exfiltrate tu secrets ambazo pipeline hiyo inazo.
  • Computation: Code hu-executeiwa mahali fulani, kulingana na mahali inapo-executeiwa attacker anaweza kuweza pivot zaidi.
  • On-Premises: Ikiwa pipelines zina-executeiwa on premises, attacker anaweza kuishia kwenye internal network yenye access kwa resources zaidi.
  • Cloud: Attacker anaweza kufikia machines nyingine kwenye cloud lakini pia anaweza ku-exfiltrate IAM roles/service accounts tokens kutoka humo ili kupata access zaidi ndani ya cloud.
  • Platforms machine: Wakati mwingine jobs zita-executeiwa ndani ya pipelines platform machines, ambazo kwa kawaida ziko ndani ya cloud bila access zaidi.
  • Select it: Wakati mwingine pipelines platform itakuwa ime-configure machines kadhaa na kama unaweza kurekebisha CI configuration file unaweza kuashiria unapotaka ku-run code mbaya. Katika hali hii, attacker pengine ata-run reverse shell kwenye kila machine linalowezekana ili kujaribu kulichukua zaidi.
  • Kuharibu production: Ikiwa uko ndani ya pipeline na version ya mwisho hujengwa na ku-deployiwa kutoka humo, unaweza kuharibu code ambayo itakwenda kuishia iki-run kwenye production.

Supply-Chain Abuse ya Dependency & Registry

Kuharibu CI/CD pipeline au kuiba credentials kutoka humo kunaweza kumruhusu attacker kuhama kutoka pipeline execution kwenda ecosystem-wide code execution kwa ku-backdoor dependencies au release tooling:

  • Install-time code execution via package hooks: publish version ya package inayoongeza preinstall, postinstall, prepare, au hooks zinazofanana ili payload i-run kiotomatiki kwenye developer workstations na CI runners wakati wa dependency installation.
  • Secondary execution paths: hata kama targets wana-install kwa --ignore-scripts, malicious package bado inaweza kusajili common CLI name kwenye bin field hivyo wrapper inayodhibitiwa na attacker ina-symlinkiwa ndani ya PATH na baadaye ina-executewa command hiyo inapotumiwa.
  • Runtime bootstrapping: installer ndogo inaweza kupakua second runtime au toolchain wakati wa installation (kwa mfano Bun au packed interpreter) kisha ku-launch main payload nayo, ikiepuka local dependency requirements.
  • Credential harvesting from build environments: mara code inapo-run ndani ya CI, angalia environment variables, ~/.npmrc, ~/.git-credentials, SSH keys, cloud CLI configs, na local tooling kama gh auth token. Kwenye GitHub Actions, pia tafuta runner-specific secrets na artifacts.
  • Workflow injection with stolen GitHub tokens: token yenye permissions za repo + workflow inatosha kuunda branch, ku-commit file mbaya ndani ya .github/workflows/, kuichochea, kukusanya artifacts/logs zilizozalishwa, kisha kufuta temporary branch/workflow run ili kupunguza traces.
  • Wormable registry propagation: stolen npm tokens zinapaswa kuthibitishwa kwa permissions za publish na kama zinapita 2FA. Kama zinapita, enumerate writable packages, pakua tarballs zake, dunga loader kama setup.mjs, weka preinstall ili i-execute, ongeza patch version, na republish. Hii hugeuza compromise moja ya CI kuwa auto-execution ya downstream kwenye mazingira mengine.

Practical checks during an assessment

  • Kagua release automation kwa package-manager hooks zilizoongezwa kwenye package.json, unexpected bin entries, au version bumps zinazobadilisha release artifact pekee.
  • Angalia kama CI huhifadhi registry credentials za muda mrefu kwenye files wazi kama ~/.npmrc badala ya kutumia short-lived OIDC au trusted publishing.
  • Thibitisha kama GitHub tokens zinazopatikana kwenye CI zinaweza kuandika workflow files au kuunda branches/tags.
  • Ikiwa package iliyoharibiwa inashukiwa, kagua published tarball na si Git repository pekee, kwa sababu malicious loader/runtime inaweza kuwepo tu kwenye artifact iliyopublished.
  • Tafuta unexpected package-manager execution ndani ya CI kama npm install badala ya npm ci, unexpected Bun downloads/execution, au new workflow artifacts zinazotokana na transient branches.

Taarifa zaidi zinazohusiana

Tools & CIS Benchmark

  • Chain-bench ni tool ya open-source ya kukagua software supply chain stack yako kwa security compliance kulingana na CIS Software Supply Chain benchmark mpya. Ukaguzi unalenga SDLC process nzima, ambapo unaweza kufichua risks kutoka code time hadi deploy time.

Top 10 CI/CD Security Risk

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

Labs

Automatic Tools

  • Checkov: Checkov ni tool ya static code analysis kwa infrastructure-as-code.

References

Tip

Jifunze na ufanye mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na ufanye mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na ufanye mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Saidia HackTricks