Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md']

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

@@ -1,4 +1,4 @@
-# Pentesting CI/CD कार्यप्रणाली
+# Pentesting CI/CD Methodology
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,51 +6,51 @@
 
 ## VCS
 
-VCS का अर्थ है **Version Control System**, यह सिस्टम developers को **उनके source code को manage करने** की अनुमति देता है। सबसे सामान्य एक है **git** और अक्सर आप कंपनियों को निम्नलिखित **platforms** में से किसी एक पर इसका उपयोग करते हुए पाएंगे:
+VCS का मतलब **Version Control System** है, यह systems developers को अपना **source code manage** करने की सुविधा देते हैं। सबसे common **git** है और आप आमतौर पर कंपनियों को इसे निम्न **platforms** में से किसी एक पर इस्तेमाल करते हुए पाएंगे:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Cloud providers (they offer their own VCS platforms)
+- Cloud providers (वे अपनी खुद की VCS platforms ऑफर करते हैं)
 
 
 ## CI/CD Pipelines
 
-CI/CD pipelines developers को कोड के execution को **automate** करने में मदद करते हैं — build, test और deploy applications जैसे कार्यों के लिए। ये automated workflows συγκεκριμένες actions द्वारा **trigger** होते हैं, जैसे code pushes, pull requests, या scheduled tasks. ये development से production तक के process को streamline करने में उपयोगी हैं।
+CI/CD pipelines developers को विभिन्न उद्देश्यों के लिए **code execution automate** करने की सुविधा देते हैं, जिसमें applications का building, testing, और deploying शामिल है। ये automated workflows **specific actions** से **trigger** होते हैं, जैसे code pushes, pull requests, या scheduled tasks। ये development से production तक की process को streamline करने में उपयोगी हैं।
 
-हालाँकि, इन systems को कहीं **execute** करना पड़ता है और अक्सर उन्हें **privileged credentials to deploy code or access sensitive information** की आवश्यकता होती है।
+हालांकि, इन systems को कहीं न कहीं **execute** होना होता है और आमतौर पर code deploy करने या sensitive information access करने के लिए **privileged credentials** की जरूरत होती है।
 
 ## 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.
+> भले ही कुछ VCS platforms इस section के लिए pipelines बनाने की अनुमति देते हों, हम केवल source code के control पर संभावित attacks का विश्लेषण करेंगे।
 
-जो platforms आपके project का source code रखती हैं उनमें संवेदनशील जानकारी होती है और लोगों को इस platform के अंदर दिए गए permissions के साथ बहुत सावधान रहना चाहिए। VCS platforms में attacker द्वारा abusing के लिए कुछ आम समस्याएँ हैं:
+जो platforms आपके project का source code रखते हैं, उनमें sensitive information होती है और लोगों को इस platform के अंदर दी गई permissions के साथ बहुत सावधान रहना चाहिए। VCS platforms में ये कुछ common problems हैं जिनका attacker abuse कर सकता है:
 
-- **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**: अगर कोई attacker VCS platform के अंदर किसी account तक **access** प्राप्त कर लेता है तो वह **ज़्यादा visibility और permissions** हासिल कर सकता है।
-- **Register**: कुछ platforms बाहरी users को सिर्फ 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 generate करने की अनुमति देती हैं। अगर वे **नॉन-प्रोटेक्टेड** हैं और किसी non visible secret से सुरक्षित नहीं हैं तो **attacker उनका दुरुपयोग कर सकता है**।
-- अगर कोई secret मौजूद नहीं है, attacker तीसरे पक्ष के platform के webhook का दुरुपयोग कर सकता है
-- अगर secret URL में मौजूद है, वही स्थिति लागू होती है और attacker के पास secret भी हो जाएगा
-- **Code compromise:** अगर malicious actor के पास repos पर किसी तरह का **write** access है, तो वह **malicious code inject** करने की कोशिश कर सकता है। सफल होने के लिए उसे शायद **branch protections bypass** करने की आवश्यकता होगी। ये क्रियाएँ विभिन्न उद्देश्यों के साथ की जा सकती हैं:
+- **Leaks**: अगर आपके code में commits के अंदर leaks हैं और attacker repo access कर सकता है (क्योंकि यह public है या क्योंकि उसके पास access है), तो वह leaks खोज सकता है।
+- **Access**: अगर attacker VCS platform के अंदर किसी account तक **access** कर सकता है, तो उसे **more visibility and permissions** मिल सकती हैं।
+- **Register**: कुछ platforms external users को account create करने की अनुमति देते हैं।
+- **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 generate करने की अनुमति देते हैं। अगर वे non visible secrets से **protected** नहीं हैं, तो **attacker उन्हें abuse कर सकता है**।
+- अगर कोई secret मौजूद नहीं है, तो attacker third party platform के webhook का abuse कर सकता है
+- अगर secret URL में है, तो वही होता है और attacker के पास secret भी होता है
+- **Code compromise:** अगर किसी malicious actor के पास repos पर किसी तरह का **write** access है, तो वह **malicious code inject** करने की कोशिश कर सकता है। सफल होने के लिए उसे शायद **branch protections bypass** करनी पड़ें। ये actions mid में अलग-अलग goals के साथ किए जा सकते हैं:
 - main branch को compromise करके **production compromise** करना।
-- main (या अन्य branches) को compromise करके **developers machines compromise** करना (क्योंकि वे अक्सर repo के अंदर test, terraform या अन्य चीजें अपने machines पर execute करते हैं)।
-- **Compromise the pipeline** (अगला सेक्शन देखें)
+- main (या other branches) को compromise करके **developers machines compromise** करना (क्योंकि वे आमतौर पर अपनी machines पर repo के अंदर test, terraform या अन्य चीजें execute करते हैं)।
+- **pipeline compromise** करना (अगला section देखें)
 
 ## Pipelines Pentesting Methodology
 
-एक pipeline define करने का सबसे सामान्य तरीका है **CI configuration file hosted in the repository** जिसे pipeline build करता है। यह file executed jobs के order, flow को प्रभावित करने वाली conditions, और build environment settings का वर्णन करती है.\
-ये files आम तौर पर एक सुसंगत नाम और format रखती हैं, उदाहरण के लिए — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), और GitHub Actions YAML files जो .github/workflows के अंतर्गत होते हैं। जब trigger होता है, pipeline job **selected source (उदाहरण: commit / branch)** से **code को pull** करता है, और CI configuration file में specified commands को उस code पर **run** करता है।
+Pipeline define करने का सबसे common तरीका है, repository में hosted एक **CI configuration file** का उपयोग करना, जिसे pipeline build करती है। यह file executed jobs का order, flow को affect करने वाली conditions, और build environment settings describe करती है।\
+इन files का आमतौर पर consistent name और format होता है, उदाहरण के लिए — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), और .github/workflows के अंदर स्थित GitHub Actions YAML files। Trigger होने पर, pipeline job selected source (जैसे commit / branch) से code **pulls** करता है, और उस code के खिलाफ CI configuration file में specified commands **run** करता है।
 
-इसलिए attacker का अंतिम लक्ष्य किसी भी तरह से उन configuration files या जिन commands को वे execute करते हैं उन्हें somehow **compromise** करना होता है।
+इसलिए attacker का ultimate goal somehow **इन configuration files** या **उनके द्वारा execute किए जाने वाले commands** को **compromise** करना है।
 
 > [!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:
+> कुछ hosted builders contributors को Docker build context और Dockerfile path चुनने देते हैं। अगर context attacker-controlled है, तो आप build के दौरान host files ingest करने और secrets exfiltrate करने के लिए इसे repo के बाहर (जैसे "..") सेट कर सकते हैं। देखें:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,40 +58,59 @@ CI/CD pipelines developers को कोड के execution को **automate**
 
 ### PPE - Poisoned Pipeline Execution
 
-Poisoned Pipeline Execution (PPE) path SCM repository में permissions का exploitation करता है ताकि CI pipeline को manipulate करके हानिकारक commands execute करवाई जा सकें। जिन users के पास आवश्यक permissions होते हैं वे CI configuration files या pipeline job द्वारा उपयोग की जाने वाली अन्य files को modify करके malicious commands शामिल कर सकते हैं। यह CI pipeline को "poison" कर देता है, जिससे ये malicious commands execute हो जाते हैं।
+Poisoned Pipeline Execution (PPE) path SCM repository में permissions का exploit करके एक CI pipeline को manipulate करता है और harmful commands execute करता है। आवश्यक permissions वाले users CI configuration files या pipeline job द्वारा उपयोग की जाने वाली अन्य files को malicious commands शामिल करने के लिए modify कर सकते हैं। यह CI pipeline को "poison" करता है, जिससे इन malicious commands का execution होता है।
 
-किसी malicious actor को PPE attack सफलतापूर्वक करने के लिए निम्न होना चाहिए:
+एक malicious actor के लिए सफल PPE attack perform करने के लिए उसे सक्षम होना चाहिए:
 
-- VCS platform पर **write access** होना, क्योंकि आम तौर पर pipelines तब trigger होती हैं जब push या pull request होता है। (VCS pentesting methodology सेक्शन में access पाने के तरीकों का सार देखें).
-- ध्यान दें कि कभी-कभी एक **external PR भी "write access"** माना जाता है।
-- भले ही उसके पास write permissions हों, उसे सुनिश्चित करना होगा कि वह **CI config file या वे अन्य files जिन्हें config rely करता है** को modify कर सके।
-- इसके लिए वह शायद **branch protections bypass** करना सक्षम होना चाहिए।
+- VCS platform पर **write access** हो, क्योंकि आमतौर पर pipelines push या pull request होने पर trigger होती हैं। (access पाने के तरीकों के सार के लिए VCS pentesting methodology देखें)।
+- ध्यान दें कि कभी-कभी एक **external PR को "write access"** माना जाता है।
+- भले ही उसके पास write permissions हों, उसे यह सुनिश्चित करना होगा कि वह CI config file या उन other files को modify कर सकता है जिन पर config rely करती है।
+- इसके लिए, उसे शायद **branch protections bypass** करने में सक्षम होना पड़े।
 
 PPE के 3 flavours हैं:
 
-- **D-PPE**: एक **Direct PPE** attack तब होता है जब actor वह CI config file modify करता है जो execute होने वाली है।
-- **I-DDE**: एक **Indirect PPE** attack तब होता है जब actor उस **file** को modify करता है जिस पर CI config file जो execute होने वाली है **rely** करती है (जैसे make file या terraform config)।
-- **Public PPE or 3PE**: कुछ मामलों में pipelines उन users द्वारा trigger की जा सकती हैं जिनके पास repo में write access नहीं होता (और जो org का हिस्सा भी नहीं हो सकते) क्योंकि वे PR भेज सकते हैं।
-- **3PE Command Injection**: आम तौर पर, CI/CD pipelines **environment variables set** करती हैं जिनमें **PR के बारे में information** होती है। अगर वह value attacker द्वारा control की जा सकती है (जैसे PR का title) और उसे किसी **dangerous place** में **use** किया जाता है (जैसे **sh commands** execute करना), तो attacker वहाँ **commands inject** कर सकता है।
+- **D-PPE**: एक **Direct PPE** attack तब होता है जब actor उस CI config file को **modify** करता है जो execute होने वाली है।
+- **I-DDE**: एक **Indirect PPE** attack तब होता है जब actor उस **file** को **modify** करता है जिस पर execute होने वाली CI config file **rely** करती है (जैसे make file या terraform config)।
+- **Public PPE or 3PE**: कुछ मामलों में pipelines ऐसे users द्वारा **trigger** की जा सकती हैं जिनके पास repo में write access नहीं होता (**और जो शायद org का हिस्सा भी नहीं हैं**) क्योंकि वे PR भेज सकते हैं।
+- **3PE Command Injection**: आमतौर पर, CI/CD pipelines PR के बारे में **information** के साथ environment variables **set** करेंगी। अगर उस value को attacker control कर सकता है (जैसे PR का title) और इसे किसी **dangerous place** में **use** किया जाता है (जैसे **sh commands** execute करना), तो attacker वहाँ commands **inject** कर सकता है।
 
 ### Exploitation Benefits
 
-PPE के 3 flavours जानने के बाद, आइए देखें कि successful exploitation के बाद attacker क्या हासिल कर सकता है:
+Pipeline को poison करने के 3 flavours जानने के बाद, देखते हैं कि successful exploitation के बाद attacker क्या प्राप्त कर सकता है:
 
-- **Secrets**: जैसा पहले बताया गया था, pipelines अपने jobs के लिए **privileges** चाहती हैं (code retrieve करना, build करना, deploy करना...) और ये privileges आम तौर पर **secrets** में दिए जाते हैं। ये secrets आम तौर पर **env variables या system के अंदर files** के माध्यम से उपलब्ध होते हैं। इसलिए attacker हमेशा जितने अधिक secrets exfiltrate कर सकेगा उतना करेगा।
-- pipeline platform पर निर्भर करते हुए attacker को **config में secrets specify** करने पड़ सकते हैं। इसका अर्थ है कि अगर attacker CI configuration pipeline को modify नहीं कर सकता (**I-PPE** उदाहरण के लिए), तो वह केवल उन secrets को ही exfiltrate कर सकता है जो उस pipeline के पास हैं।
-- **Computation**: कोड कहीं execute होता है, उस execution स्थान पर attacker आगे pivot कर सकता है।
-- **On-Premises**: अगर pipelines on premises execute होती हैं, तो attacker internal network में पहुँच सकता है और और resources तक access हासिल कर सकता है।
-- **Cloud**: attacker अन्य machines in the cloud तक पहुँच सकता है और साथ ही IAM roles/service accounts **tokens** exfiltrate करके cloud के अंदर और access प्राप्त कर सकता है।
-- **Platforms machine**: कभी-कभी jobs **pipelines platform machines** के अंदर execute होती हैं, जो आम तौर पर cloud में होती हैं और जिनके पास अक्सर और अधिक access नहीं होता।
-- **Select it:** कभी-कभी **pipelines platform कई machines configure** कर सकता है और अगर आप **CI configuration file modify** कर सकते हैं तो आप **indicate कर सकते हैं कि आप malicious code कहाँ चलाना चाहते हैं**। ऐसी स्थिति में attacker संभवतः हर possible machine पर reverse shell चलाकर उसे और exploit करने की कोशिश करेगा।
-- **Compromise production**: अगर आप pipeline के अंदर हैं और final version वहीं से build और deploy होती है, तो आप production में चलने वाले code को compromise कर सकते हैं।
+- **Secrets**: जैसा पहले बताया गया, pipelines को अपने jobs के लिए **privileges** चाहिए (code retrieve करना, build करना, deploy करना...) और ये privileges आमतौर पर **secrets** में **granted** होते हैं। ये secrets आमतौर पर **env variables या system के अंदर files** के जरिए accessible होते हैं। इसलिए attacker हमेशा जितने हो सकें उतने secrets exfiltrate करने की कोशिश करेगा।
+- Pipeline platform पर निर्भर करते हुए attacker को **config में secrets specify** करने की जरूरत पड़ सकती है। इसका मतलब है कि अगर attacker CI configuration pipeline (**I-PPE** उदाहरण के लिए) modify नहीं कर सकता, तो वह केवल उस pipeline के पास मौजूद secrets ही **exfiltrate** कर सकता है।
+- **Computation**: Code कहीं न कहीं execute होता है, और यह कहाँ execute होता है उसके अनुसार attacker आगे pivot कर सकता है।
+- **On-Premises**: अगर pipelines on premises execute होती हैं, तो attacker एक **internal network** में पहुंच सकता है जहाँ उसके पास **more resources** का access होगा।
+- **Cloud**: attacker **cloud में अन्य machines** access कर सकता है, लेकिन IAM roles/service accounts **tokens** exfiltrate करके cloud के अंदर **further access** भी प्राप्त कर सकता है।
+- **Platforms machine**: कभी-कभी jobs **pipelines platform machines** के अंदर execute होंगे, जो आमतौर पर एक cloud के अंदर होते हैं जहाँ **no more access** होता है।
+- **Select it:** कभी-कभी **pipelines platform ने कई machines configure** की होंगी, और अगर आप **CI configuration file modify** कर सकते हैं, तो आप यह **indicate** कर सकते हैं कि malicious code कहाँ run करना है। इस स्थिति में, attacker शायद हर संभव machine पर reverse shell चलाएगा ताकि आगे exploit करने की कोशिश कर सके।
+- **Compromise production**: अगर आप pipeline के अंदर हैं और final version इससे build और deploy होता है, तो आप उस code को **compromise** कर सकते हैं जो production में run होने वाला है।
+
+### Dependency & Registry Supply-Chain Abuse
+
+CI/CD pipeline को compromise करना या उससे credentials चुराना attacker को **pipeline execution** से **ecosystem-wide code execution** तक ले जा सकता है, dependencies या release tooling को backdoor करके:
+
+- **Install-time code execution via package hooks**: package version publish करें जो `preinstall`, `postinstall`, `prepare`, या इसी तरह के hooks जोड़ता हो, ताकि payload dependency installation के दौरान developer workstations और CI runners पर automatically run हो।
+- **Secondary execution paths**: भले ही targets `--ignore-scripts` के साथ install करें, malicious package फिर भी `bin` field में एक **common CLI name** register कर सकता है, जिससे attacker-controlled wrapper `PATH` में symlink हो जाता है और command use होने पर बाद में execute होता है।
+- **Runtime bootstrapping**: एक छोटा installer installation के दौरान दूसरा runtime या toolchain download कर सकता है (उदाहरण के लिए Bun या packed interpreter) और फिर उसके साथ main payload launch कर सकता है, जिससे local dependency requirements से बचा जा सके।
+- **Credential harvesting from build environments**: एक बार code CI के अंदर run हो जाए, तो environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs, और local tooling जैसे `gh auth token` check करें। GitHub Actions पर, runner-specific secrets और artifacts भी देखें।
+- **Workflow injection with stolen GitHub tokens**: ऐसा token जिसमें **`repo` + `workflow`** permissions हों, branch create करने, `.github/workflows/` के अंदर malicious file commit करने, उसे trigger करने, produced artifacts/logs collect करने, और फिर temporary branch/workflow run delete करने के लिए पर्याप्त है ताकि traces कम हों।
+- **Wormable registry propagation**: stolen npm tokens को **publish** permissions और यह जांचने के लिए validate करें कि वे 2FA bypass करते हैं या नहीं। अगर करते हैं, तो writable packages enumerate करें, उनके tarballs download करें, `setup.mjs` जैसा loader inject करें, उसे execute करने के लिए `preinstall` set करें, patch version bump करें, और republish करें। इससे एक CI compromise downstream auto-execution में अन्य environments तक फैल जाता है।
+
+#### Practical checks during an assessment
+
+- Release automation में `package.json` में added package-manager hooks, unexpected `bin` entries, या ऐसे version bumps की review करें जो केवल release artifact बदलते हों।
+- जांचें कि CI long-lived registry credentials को `~/.npmrc` जैसी plaintext files में store करता है या short-lived OIDC या trusted publishing का उपयोग करता है।
+- Verify करें कि CI में उपलब्ध GitHub tokens workflow files लिख सकते हैं या branches/tags create कर सकते हैं।
+- अगर compromised package का संदेह हो, तो केवल Git repository नहीं बल्कि published tarball inspect करें, क्योंकि malicious loader/runtime केवल published artifact में मौजूद हो सकता है।
+- CI के अंदर unexpected package-manager execution की तलाश करें, जैसे `npm ci` की जगह `npm install`, unexpected Bun downloads/execution, या transient branches से generated नए workflow artifacts।
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) एक open-source tool है जो आपके software supply chain stack का security compliance के लिए auditing करता है based on एक नए [**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 तक के risks को उजागर कर सकता है।
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) एक open-source tool है जो नए [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) के आधार पर आपके software supply chain stack की security compliance auditing के लिए है। यह auditing पूरे SDLC process पर केंद्रित है, जहाँ यह code time से deploy time तक risks reveal कर सकता है।
 
 ### Top 10 CI/CD Security Risk
 
@@ -99,16 +118,18 @@ Cider के अनुसार top 10 CI/CD risks पर यह interesting art
 
 ### Labs
 
-- हर platform के लिए जिसे आप locally चला सकते हैं, वहां आप पाएंगे कि इसे स्थानीय रूप से कैसे लॉन्च करना है ताकि आप इसे अपनी इच्छानुसार configure करके परीक्षण कर सकें
+- जिन प्रत्येक platform पर आप locally run कर सकते हैं, वहाँ आपको इसे locally launch करने का तरीका मिलेगा ताकि आप इसे अपनी इच्छानुसार configure करके test कर सकें
 - 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 के लिए।
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** infrastructure-as-code के लिए एक static code analysis tool है।
 
 ## 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)
+- [The npm Threat Landscape: Attack Surface and Mitigations](https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/)
+- [Checkmarx Security Update: April 22, 2026](https://checkmarx.com/blog/checkmarx-security-update-april-22/?p=108469)
 
 
 {{#include ../banners/hacktricks-training.md}}