# Pentesting CI/CD Methodology

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

<figure><img src="../images/CLOUD-logo-letters.svg" alt=""><figcaption></figcaption></figure>

## VCS

VCS का मतलब है **Version Control System**, यह सिस्टम डेवलपर्स को उनके **source code को manage** करने की अनुमति देता है। सबसे आम है **git** और आप आमतौर पर कंपनियों को निम्नलिखित **platforms** में से किसी एक का उपयोग करते हुए पाएँगे:

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


## CI/CD Pipelines

CI/CD pipelines डेवलपर्स को कोड के निष्पादन को **automate** करने में सक्षम बनाते हैं — जैसे build, test, और deploy करने के लिए। ये automated workflows विशिष्ट क्रियाओं द्वारा **triggered** होते हैं, जैसे code pushes, pull requests, या scheduled tasks. ये development से production तक के प्रक्रिया को आसान बनाने में उपयोगी होते हैं।

हालाँकि, इन सिस्टम्स को कहीं ना कहीं **execute** करना होता है और आम तौर पर इसके लिए **privileged credentials** की आवश्यकता होती है ताकि code deploy किया जा सके या sensitive information तक पहुँच प्राप्त की जा सके।

## 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.

जिस platform में आपके प्रोजेक्ट का source code होता है, वह संवेदनशील जानकारी रखता है और लोगों को इस platform के अंदर दिए गए permissions के साथ बहुत सावधान रहना चाहिए। VCS platforms में कुछ सामान्य समस्याएँ हैं जिनका attacker दुरुपयोग कर सकता है:

- **Leaks**: अगर आपके code में commits में leak मौजूद हैं और attacker repo तक पहुँच सकता है (क्योंकि वह public है या उसे access मिला हुआ है), तो वह उन leaks को खोज सकता है।
- **Access**: अगर attacker VCS platform के अंदर किसी account तक **access** प्राप्त कर लेता है तो वह और भी अधिक **visibility और permissions** प्राप्त कर सकता है।
- **Register**: कुछ platforms बाहरी उपयोगकर्ताओं को बस एक account बनाने की अनुमति देते हैं।
- **SSO**: कुछ platforms users को register करने की अनुमति नहीं देते, लेकिन valid SSO के साथ किसी को भी access करने दे सकते हैं (तो एक attacker अपने github account का उपयोग करके प्रवेश कर सकता है, उदाहरण के लिए)।
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... कई प्रकार के tokens होते हैं जिन्हें एक user चुरा सकता है ताकि किसी तरह repo तक access प्राप्त किया जा सके।
- **Webhooks**: VCS platforms webhooks जनरेट करने की अनुमति देते हैं। अगर वे non visible secrets के साथ **protected** नहीं हैं तो एक **attacker उनका दुरुपयोग कर सकता है**।
- अगर कोई secret मौजूद नहीं है, तो attacker third party platform के webhook का दुरुपयोग कर सकता है
- अगर secret URL में है, तो भी वही होता है और attacker के पास वह secret भी होगा
- **Code compromise:** अगर किसी malicious actor के पास repos पर किसी प्रकार का **write** access है, तो वह **malicious code inject** करने की कोशिश कर सकता है। सफल होने के लिए उसे शायद **branch protections को bypass** करना पड़ेगा। ये क्रियाएँ विभिन्न उद्देश्यों के साथ की जा सकती हैं:
- main branch को compromise करके **production को compromise** करना।
- main (या अन्य branches) को compromise करके **developers के machines को compromise** करना (क्योंकि वे आम तौर पर repo के अंदर test, terraform या अन्य चीजें अपने machines पर execute करते हैं)।
- **Compromise the pipeline** (अगला सेक्शन देखें)

## Pipelines Pentesting Methodology

pipeline को define करने का सबसे आम तरीका है **CI configuration file जो repository में hosted** होती है जिसे pipeline build करता है। यह फाइल executed jobs का क्रम, flow को प्रभावित करने वाली conditions, और build environment settings का वर्णन करती है.\
ये फाइलें आमतौर पर एक सुसंगत नाम और फॉर्मेट रखती हैं, उदाहरण के लिए — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), और GitHub Actions YAML फाइलें जो .github/workflows के अंतर्गत होती हैं। जब triggered होता है, तो pipeline job **code को pull करता है** चुने गए स्रोत से (जैसे commit / branch), और उस code के खिलाफ CI configuration file में निर्दिष्ट commands को **run** करता है।

इसलिए attacker का अंतिम लक्ष्य किसी न किसी तरीके से उन configuration files या उन **commands** को **compromise** करना होता है जो वे execute करते हैं।

### PPE - Poisoned Pipeline Execution

Poisoned Pipeline Execution (PPE) पथ SCM repository में permissions का दुरुपयोग कर एक CI pipeline को manipulate करने और हानिकारक commands execute करवाने का फायदा उठाता है। जिन users के पास आवश्यक permissions होते हैं वे CI configuration files या pipeline job द्वारा उपयोग की जाने वाली अन्य फाइलों को modify कर सकते हैं ताकि malicious commands शामिल हो सकें। यह CI pipeline को "poison" कर देता है, जिससे ये malicious commands execute होते हैं।

एक malicious actor के लिए PPE attack सफल करने के लिए उसे निम्न बातें करनी होंगी:

- VCS platform पर **write access** होना चाहिए, क्योंकि आम तौर पर pipelines तब triggered होते हैं जब push या pull request किया जाता है। (Access प्राप्त करने के तरीकों के लिए VCS pentesting methodology देखें).
- ध्यान दें कि कभी-कभी एक **external PR भी "write access"** माना जा सकता है।
- भले ही उसके पास write permissions हों, उसे यह सुनिश्चित करना होगा कि वह **CI config file या उन दूसरी फाइलों को modify कर सके जिन पर config निर्भर करता है**।
- इसके लिए उसे शायद **branch protections को bypass** करने की आवश्यकता पड़े।

PPE के 3 flavour हैं:

- **D-PPE**: एक **Direct PPE** attack तब होता है जब actor उस CI config फाइल को **modify** कर देता है जो execute होने वाली है।
- **I-DDE**: एक **Indirect PPE** attack तब होता है जब actor उस **file** को **modify** करता है जिस पर CI config फाइल निर्भर करती है (जैसे एक make file या terraform config)।
- **Public PPE or 3PE**: कुछ मामलों में pipelines उन users द्वारा trigger किए जा सकते हैं जिनके पास repo में write access नहीं है (और जो शायद org का हिस्सा भी न हों) क्योंकि वे एक PR भेज सकते हैं।
- **3PE Command Injection**: आम तौर पर, CI/CD pipelines **environment variables सेट करते हैं** जिनमें PR के बारे में जानकारी होती है। अगर उस value को attacker नियंत्रित कर सकता है (जैसे PR का title) और उसे किसी **dangerous जगह** पर **use** किया जाता है (जैसे sh commands execute करना), तो attacker वहाँ **commands inject** कर सकता है।

### Exploitation Benefits

pipeline को poison करने के 3 flavour जानने के बाद, आइए देखें कि successful exploitation के बाद attacker क्या प्राप्त कर सकता है:

- **Secrets**: जैसा कि पहले बताया गया था, pipelines अपने jobs के लिए **privileges** की आवश्यकता होती है (code retrieve करने के लिए, build करने के लिए, deploy करने के लिए...) और ये privileges आमतौर पर **secrets** में दिए जाते हैं। ये secrets आम तौर पर **env variables या सिस्टम के अंदर फाइलों** के माध्यम से accessible होते हैं। इसलिए attacker हमेशा अधिक से अधिक secrets exfiltrate करने की कोशिश करेगा।
- pipeline platform पर निर्भर करते हुए attacker को **config में secrets specify** करने पड़ सकते हैं। इसका मतलब है कि अगर attacker CI configuration pipeline को modify नहीं कर सकता (**I-PPE** जैसा उदाहरण), तो वह केवल उन secrets को ही exfiltrate कर सकता है जो उस pipeline के पास हैं।
- **Computation**: कोड कहीं न कहीं execute होता है, और जहाँ execute होता है उसके आधार पर attacker आगे pivot कर सकता है।
- **On-Premises**: अगर pipelines on-premises execute होते हैं, तो attacker एक **internal network** में पहुँच सकता है जहाँ अधिक resources उपलब्ध हो सकते हैं।
- **Cloud**: attacker अन्य cloud machines तक पहुँच सकता है और साथ ही इसके IAM roles/service accounts **tokens** को exfiltrate करके cloud के अंदर और अधिक access प्राप्त कर सकता है।
- **Platforms machine**: कभी-कभी jobs pipeline platform machines के अंदर execute होते हैं, जो आमतौर पर किसी cloud में होते हैं और जिनके पास अधिक access नहीं होता।
- **Select it:** कभी-कभी **pipeline platform कई machines** configure करता है और अगर आप CI configuration file को modify कर सकते हैं तो आप **यह निर्दिष्ट कर सकते हैं कि आप malicious code कहाँ चलाना चाहते हैं**। ऐसी स्थिति में attacker शायद हर संभव machine पर reverse shell चलाकर आगे exploit करने की कोशिश करेगा।
- **Compromise production**: अगर आप pipeline के अंदर हैं और final version वहीं से build और deploy होता है, तो आप production में चलने वाले code को compromise कर सकते हैं।

## More relevant info

### Tools & CIS Benchmark

- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) एक open-source tool है जो आपके software supply chain stack का security compliance के हिसाब से audit करने के लिए है, यह एक नए [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) पर आधारित है। auditing पूरे SDLC process पर केन्द्रित होती है, जहाँ यह code time से लेकर deploy time तक के जोखिमों को उजागर कर सकती है।

### Top 10 CI/CD Security Risk

Cider के अनुसार top 10 CI/CD risks पर यह रोचक article देखें: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)

### Labs

- हर platform पर जिसे आप locally चला सकते हैं, आपको यह मिलेगा कि इसे locally कैसे लॉन्च करना है ताकि आप इसे अपनी पसंद के अनुसार configure करके टेस्ट कर सकें
- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)

### Automatic Tools

- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** एक static code analysis tool है 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](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}}