From 4f0877985dfc3baee3ff85cf04bbd84499126d66 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 6 Jul 2026 15:54:38 +0000 Subject: [PATCH] Translated ['src/pentesting-ci-cd/argocd-security.md', 'src/pentesting-c --- src/pentesting-ci-cd/argocd-security.md | 219 ++++++++++++++++++ .../pentesting-ci-cd-methodology.md | 103 ++++---- 2 files changed, 271 insertions(+), 51 deletions(-) create mode 100644 src/pentesting-ci-cd/argocd-security.md diff --git a/src/pentesting-ci-cd/argocd-security.md b/src/pentesting-ci-cd/argocd-security.md new file mode 100644 index 000000000..c36b77164 --- /dev/null +++ b/src/pentesting-ci-cd/argocd-security.md @@ -0,0 +1,219 @@ +# Argo CD Security + +{{#include ../banners/hacktricks-training.md}} + +## बेसिक जानकारी + +[Argo CD](https://argo-cd.readthedocs.io/) Kubernetes के लिए एक GitOps continuous delivery platform है। यह Git repositories को watch करता है, Helm, Kustomize, Jsonnet या config management plugins जैसे tools के साथ Kubernetes manifests render करता है, और Git में stored desired state के साथ live cluster state को reconcile करता है। + +Attacker perspective से, Argo CD को **Kubernetes credentials वाले deployment engine** की तरह treat करें। Argo CD का useful compromise इन चीज़ों तक lead कर सकता है: + +- private Git repositories और repository credentials तक access। +- Argo CD द्वारा used Kubernetes cluster secrets तक access। +- `argocd-repo-server` में manifest generation code execution। +- trusted Git repositories, Argo CD applications, या cache manipulation के through unauthorized Kubernetes object deployment। + +## Architecture & Interesting Components + +Common Kubernetes objects and services: +```bash +kubectl get pods,svc,endpoints,ingress -A | grep -iE 'argocd|argo-cd' +kubectl get applications,appprojects,applicationsets -A 2>/dev/null +kubectl get secrets,configmaps -n argocd 2>/dev/null +kubectl get networkpolicy -n argocd 2>/dev/null +``` +दिलचस्प services: + +- **`argocd-server`**: public API, web UI, CLI API, authentication and authorization. +- **`argocd-application-controller`**: desired और live state की तुलना करता है, फिर Kubernetes पर resources लागू करता है। +- **`argocd-repo-server`**: repositories clone करता है, Git data cache करता है, और manifests generate करने के लिए Helm/Kustomize/Jsonnet/plugins चलाता है। Default gRPC port **8081** है। +- **`argocd-redis`**: application, manifest और Git reference data के लिए cache। Default Redis port **6379** है। +- **`argocd-applicationset-controller`**: Git, SCM, clusters और pull requests जैसे generators से Argo CD `Application` objects generate करता है। + +Compromised pod या internal network segment से, internal reachability check करें: +```bash +nc -vz 443 +nc -vz 8081 +nc -vz 6379 +``` +## Public API / UI हमले + +यदि आपके पास Argo CD credentials हैं या कोई exposed instance है, तो normal API surface से शुरू करें: +```bash +argocd login +argocd account get-user-info +argocd account list +argocd proj list +argocd app list +argocd repo list +argocd cluster list +argocd admin settings rbac can +``` +उपयोगी attack paths: + +- **Application write access**: `source.repoURL`, `source.path`, Helm values, Kustomize options, plugin settings या sync options को modify करें ताकि Argo CD attacker-controlled manifests deploy करे। +- **Project misconfiguration**: `AppProject` objects broad `sourceRepos`, broad `destinations`, unsafe `clusterResourceWhitelist`, या weak namespace restrictions allow कर सकते हैं। +- **Repository credential abuse**: repository secrets, GitHub App credentials, SSH keys और tokens trusted repos में push करने या malicious dependencies जोड़ने के लिए allow कर सकते हैं। +- **Cluster credential abuse**: cluster secrets में bearer tokens या exec-provider configuration हो सकती है, जिन्हें Argo CD target clusters में deploy करने के लिए use करता है। +- **Local admin / project tokens**: long-lived Argo CD tokens API के through reuse किए जा सकते हैं, जब तक कि उन्हें revoke या expire न किया जाए। + +जब आपके पास cluster read access हो, तो Kubernetes से configuration enumerate करें: +```bash +kubectl get applications.argoproj.io -A -o yaml +kubectl get appprojects.argoproj.io -A -o yaml +kubectl get applicationsets.argoproj.io -A -o yaml +kubectl get secrets -n argocd -o yaml | grep -nE 'repoURL|sshPrivateKey|password|bearerToken|githubApp|tlsClientCertData|tlsClientCertKey' +kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml +``` +## Trusted Git Repository Abuse + +यदि आप Argo CD द्वारा trusted किसी repository में push कर सकते हैं, तो आप आमतौर पर क्या deploy होगा, इसे influence कर सकते हैं। Impact `AppProject` boundaries और application controller द्वारा उपयोग किए गए service account permissions पर निर्भर करता है। + +Common payload locations: + +- Application path के तहत Raw Kubernetes YAML. +- Helm chart templates और `values.yaml`. +- Kustomize overlays, remote bases और generators. +- Jsonnet या config management plugin input. +- ApplicationSet generator files जो `Application` objects create या update करते हैं। + +जांचें कि app automated sync, pruning, self-heal, sync windows या manual approvals use करता है या नहीं: +```bash +kubectl get applications.argoproj.io -A \ +-o custom-columns='NS:.metadata.namespace,APP:.metadata.name,PROJECT:.spec.project,AUTOSYNC:.spec.syncPolicy.automated,REPO:.spec.source.repoURL,PATH:.spec.source.path,DEST:.spec.destination.server' +``` +## Direct `argocd-repo-server` Abuse + +सार्वजनिक Argo CD API को ही एकमात्र attack surface न मानें। Internal Argo CD components, `argocd-repo-server` से gRPC के जरिए communicate करते हैं। अगर arbitrary pods repo-server तक पहुंच सकते हैं, तो attacker-controlled internal requests वे checks bypass कर सकती हैं जो आमतौर पर `argocd-server` द्वारा enforced होती हैं। + +Practical checks: +```bash +kubectl get svc -n argocd argocd-repo-server -o yaml +kubectl get endpoints -n argocd argocd-repo-server -o wide +nc -vz 8081 +``` +रोचक संकेत: + +- repo-server gRPC endpoint non-Argo CD pods से reachable है। +- NetworkPolicies missing हैं या केवल allow-list egress है, ingress को deny नहीं किया गया है। +- repo-server के पास custom config management plugins, decryption tools, या multiple tenants की repository content तक access है। +- Redis non-Argo CD pods से reachable है, जिससे cache inspection या tampering संभव है, अगर credentials उपलब्ध हों या required न हों। + +## Kustomize Options के माध्यम से Unauthenticated Repo-Server RCE + +July 2026 में, Synacktiv ने Argo CD के `repo-server` में unauthenticated code execution chain disclosed की, जब attacker internal gRPC service तक पहुंच सकता है। यह attack `/repository.RepoServerService/GenerateManifest` और attacker-controlled `KustomizeOptions` पर direct access का abuse करता है। + +Dangerous primitive है repo-server को attacker-controlled repository content clone करने के लिए force करना और Helm support के साथ Kustomize run करना: +```bash +kustomize build --enable-helm --helm-command ./payload.sh +``` +न्यूनतम malicious Kustomize input को Helm processing ट्रिगर करने के लिए चाहिए: +```yaml +helmCharts: +- name: pwn +version: 0.0.1 +``` +यह क्यों काम करता है: + +- `argocd-repo-server` render करने से पहले repository को clone करता है। +- `--helm-command ./payload.sh` cloned repository के relative resolve होता है। +- अगर attacker rendered repository और Kustomize build options को control कर सकता है, तो code execution के लिए shell metacharacter injection की जरूरत नहीं होती। + +Synacktiv की 1 July, 2026 की disclosure के समय, उन्होंने बताया कि इस issue का कोई official fix या CVE नहीं था। इसे पहले एक network-exposure issue की तरह treat करें: exploitation के लिए internal repo-server gRPC port तक reachability चाहिए। + +## Redis Cache Poisoning to Deploy Manifests + +`argocd-repo-server` में code execution के बाद, या valid credentials के साथ Redis तक direct access के बाद, Redis-backed cache entries inspect करें। Argo CD आमतौर पर gzip-compressed JSON values store करता है। + +Interesting key prefixes: +```text +mfst|... # cached rendered manifests +git-refs|... # Git branch/ref to commit mappings +app|... # application resource/cache data +cluster|... # cluster cache information +``` +Synacktiv द्वारा वर्णित cache poisoning attack दो state के हिस्सों का दुरुपयोग करता है: + +1. संबंधित `mfst|...` manifest cache entry को modify करके उसमें attacker-controlled Kubernetes manifest शामिल करना। +2. संबंधित `git-refs|...` mapping को modify करना ताकि Argo CD यह मान ले कि branch move हो गई है और फिर cached revision पर वापस reconcile करे। + +Impact: + +- Auto Sync enabled होने पर, Argo CD poisoned cached manifest को automatically apply कर सकता है। +- Auto Sync के बिना भी, जब कोई user manually application sync करता है, तब payload फिर भी apply हो सकता है। +- Final impact target application's destination और Argo CD को उपलब्ध Kubernetes permissions द्वारा सीमित होता है। + +## ApplicationSet Attacks + +ApplicationSet खास तौर पर sensitive है क्योंकि यह generator output से `Application` objects create या update करता है। + +Review: +```bash +kubectl get applicationsets.argoproj.io -A -o yaml +kubectl get appprojects.argoproj.io -A -o yaml +``` +दिलचस्प patterns: + +- attacker-writable files पढ़ने वाले Git generators जो app names, paths, projects या destinations को control करते हैं। +- public repositories के लिए pull request generators जहाँ untrusted contributors generated applications को influence कर सकते हैं। +- Template fields जो broad destination clusters/namespaces allow करते हैं। +- AppProjects जो `sourceRepos: ["*"]` या broad `destinations` permit करते हैं। +- Generated applications जो automated sync और pruning inherit करते हैं। + +## Post-Exploitation + +Argo CD pod shell से, प्राथमिकता दें: +```bash +env +cat /proc/1/environ 2>/dev/null | tr '\0' '\n' +find /var/run/secrets /app/config -type f -maxdepth 4 2>/dev/null +mount | grep -E 'secret|token|config' +``` +उपयोगी उद्देश्‍य: + +- `REDIS_PASSWORD` या Redis TLS/client material चुराएं। +- mounted secrets या Argo CD Kubernetes secrets से repository credentials निकालें। +- Argo CD द्वारा उपयोग किए जाने वाले cluster credentials पहचानें। +- generated manifests और plugin output पढ़ें, जिनमें injected secrets हो सकते हैं। +- जांचें कि क्या custom plugins, SOPS, Helm secrets, Vault plugins या cloud CLIs decryption keys और cloud credentials expose करते हैं। + +## Detection & Hardening + +महत्वपूर्ण checks: + +- NetworkPolicies के साथ `argocd-repo-server` port **8081** और Redis port **6379** को restrict करें ताकि केवल expected Argo CD components ही उनसे reach कर सकें। +- Helm deployments में verify करें कि network policies वास्तव में create हो रही हैं। Argo CD Helm chart values historically component network policy creation को disabled पर default करते रहे हैं। +- `argocd-server` को authenticated entry point के रूप में रखें। Internal services arbitrary workloads से reachable नहीं होने चाहिए। +- unused config management tools और plugins disable करें। +- `AppProject` `sourceRepos`, `destinations`, namespace permissions और cluster-scoped resources को restrict करें। +- broad repository credentials store करने से बचें, जिनका reuse low-privileged Argo CD user करा सके। +- repo-server requests, Kustomize build options, plugin executions, Redis writes और `mfst|` / `git-refs|` keys तक unexpected access monitor करें। +- compromise के बाद Argo CD local users, project tokens, repository credentials और cluster credentials rotate करें। + +उपयोगी commands: +```bash +kubectl get networkpolicy -n argocd +kubectl get networkpolicy -A | grep -i argocd +kubectl describe networkpolicy -n argocd argocd-repo-server-network-policy 2>/dev/null +kubectl describe networkpolicy -n argocd argocd-redis-network-policy 2>/dev/null +``` +## Static Analysis Note: Typed API Requests in CodeQL + +Go services के लिए जो gRPC/REST handlers use करते हैं, default CodeQL remote sources raw input के typed request objects में unmarshal होने के बाद flows miss कर सकते हैं। Argo CD-style services के लिए एक useful model यह है: + +- Receiver type जैसे `Server` या `Service`. +- First parameter `context.Context` है. +- Second parameter एक typed request object है. + +उस second parameter को remote source के रूप में model करें और `exec.Command` / `exec.CommandContext` arguments के लिए custom sinks जोड़ें। इससे internal API request fields से command execution helpers तक के flows खोजने में मदद मिलती है। + +## References + +- [Synacktiv - Caught in the Octopus Trap: Unauthenticated RCE in Argo CD with CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql) +- [Argo CD docs - Security considerations](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/) +- [Argo CD docs - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/) +- [Argo CD docs - repo-server command reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/) +- [Argo CD - repo-server NetworkPolicy manifest](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml) +- [Argo CD docs - metrics](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/) +- [Argo Helm - chart values reference](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md) +- [Kustomize - Helm chart generator example](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md) diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index d690078c9..3eaae17dc 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -6,51 +6,51 @@ ## VCS -VCS का मतलब **Version Control System** है, यह systems developers को अपने source code को **manage** करने देते हैं। सबसे common **git** है और आम तौर पर companies इसे निम्नलिखित **platforms** में से किसी एक पर इस्तेमाल करती हैं: +VCS का मतलब **Version Control System** है, यह systems developers को अपनी **source code** को **manage** करने देता है. सबसे common एक **git** है और आप आमतौर पर companies को इसे निम्नलिखित **platforms** में से किसी एक पर इस्तेमाल करते हुए पाएंगे: - Github - Gitlab - Bitbucket - Gitea - Gitblit -- Cloud providers (वे अपने खुद के VCS platforms देते हैं) +- Cloud providers (वे अपनी खुद की VCS platforms offer करते हैं) ## CI/CD Pipelines -CI/CD pipelines developers को विभिन्न उद्देश्यों के लिए code के execution को **automate** करने देते हैं, जिनमें applications का building, testing, और deploying शामिल है। ये automated workflows **specific actions** से **trigger** होते हैं, जैसे code pushes, pull requests, या scheduled tasks। ये development से production तक की प्रक्रिया को streamline करने में उपयोगी हैं। +CI/CD pipelines developers को code के execution को विभिन्न उद्देश्यों के लिए **automate** करने देते हैं, जिनमें applications को build, test, और deploy करना शामिल है. ये automated workflows **specific actions** द्वारा **trigger** किए जाते हैं, जैसे code pushes, pull requests, या scheduled tasks. ये development से production तक की process को streamline करने में उपयोगी होते हैं. -हालांकि, इन systems को **कहीं न कहीं execute** होना होता है और आमतौर पर code deploy करने या sensitive information access करने के लिए **privileged credentials** की जरूरत होती है। +हालाँकि, इन systems को कहीं **execute** किया जाना चाहिए और आमतौर पर code deploy करने या sensitive information access करने के लिए **privileged credentials** के साथ। ## VCS Pentesting Methodology > [!NOTE] -> भले ही कुछ VCS platforms इस section के लिए pipelines बनाने दें, हम केवल source code के control पर संभावित attacks का विश्लेषण करेंगे। +> भले ही कुछ VCS platforms इस section के लिए pipelines बनाने की अनुमति देते हों, यहाँ हम केवल source code के control पर संभावित attacks का विश्लेषण करने जा रहे हैं। -जिन platforms में आपके project का source code होता है, उनमें sensitive information भी होती है और लोगों को इस platform के अंदर दिए गए permissions के साथ बहुत सावधान रहना चाहिए। VCS platforms में ये कुछ common problems हैं जिनका attacker abuse कर सकता है: +जिन platforms में आपके project का source code होता है, उनमें sensitive information होती है और लोगों को इस platform के अंदर दी गई permissions के साथ बहुत सावधान रहना चाहिए. ये VCS platforms में कुछ common problems हैं जिनका attacker abuse कर सकता है: -- **Leaks**: अगर आपके code में commits के अंदर leaks हैं और attacker repo access कर सकता है (क्योंकि यह public है या उसके पास access है), तो वह leaks discover कर सकता है। -- **Access**: अगर कोई attacker VCS platform के अंदर किसी account को **access** कर सकता है, तो उसे **ज़्यादा visibility और permissions** मिल सकती हैं। -- **Register**: कुछ platforms external users को account create करने की अनुमति देते हैं। -- **SSO**: कुछ platforms users को register करने नहीं देंगे, लेकिन valid SSO के साथ किसी को भी access करने देंगे (तो attacker अपना github account use करके example के लिए enter कर सकता है)। -- **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 कर सकता है +- **Leaks**: अगर आपके code में commits में leaks हैं और attacker repo access कर सकता है (क्योंकि यह public है या क्योंकि उसके पास access है), तो वह leaks discover कर सकता है। +- **Access**: अगर attacker VCS platform के अंदर किसी account को **access** कर सकता है, तो उसे **more visibility and permissions** मिल सकते हैं. +- **Register**: कुछ platforms बाहरी users को account create करने की अनुमति देंगे। +- **SSO**: कुछ platforms users को register करने की अनुमति नहीं देंगे, लेकिन valid SSO के साथ किसी को भी access करने देंगे (इसलिए एक attacker अपने github account का उपयोग करके enter कर सकता है, उदाहरण के लिए)। +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... ऐसे कई kind of tokens हैं जिन्हें एक user किसी न किसी तरह repo access करने के लिए steal कर सकता है. +- **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 अलग-अलग goals के लिए किए जा सकते हैं: -- main branch को compromise करके **production compromise** करना। -- main (या अन्य branches) को compromise करके **developers machines compromise** करना (क्योंकि वे अक्सर अपनी machines पर repo के अंदर test, terraform या अन्य चीजें run करते हैं)। -- **pipeline compromise** (अगला section देखें) +- **Code compromise:** अगर किसी malicious actor के पास repos पर किसी तरह का **write** access है, तो वह **malicious code inject** करने की कोशिश कर सकता है. सफल होने के लिए उसे **branch protections bypass** करनी पड़ सकती हैं. ये actions अलग-अलग goals के साथ mid में perform किए जा सकते हैं: +- main branch compromise करके **production compromise** करना. +- main (या अन्य branches) compromise करके **developers machines compromise** करना (क्योंकि वे आमतौर पर अपनी machines पर repo के अंदर test, terraform या अन्य चीजें execute करते हैं). +- **pipeline compromise** करना (अगला section देखें) ## Pipelines Pentesting Methodology -Pipeline define करने का सबसे common तरीका है उस **CI configuration file** का use करना जो उस repository में host होती है जिसे pipeline build करती है। यह file executed jobs का order, flow को प्रभावित करने वाली conditions, और build environment settings बताती है।\ -इन files का आम तौर पर नाम और format consistent होता है, उदाहरण के लिए — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), और .github/workflows के अंदर स्थित GitHub Actions YAML files। Trigger होने पर, pipeline job selected source (e.g. commit / branch) से code **pull** करती है, और उस code के खिलाफ CI configuration file में specified commands **run** करती है। +Pipeline define करने का सबसे common तरीका है, repository में hosted एक **CI configuration file** का उपयोग करना, जिसे pipeline build करती है. यह file executed jobs के order, flow को affect करने वाली conditions, और build environment settings को describe करती है.\ +इन files के आम तौर पर consistent नाम और 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 **pull** करती है, और उस code के खिलाफ CI configuration file में specified commands **run** करती है। -इसलिए attacker का ultimate goal somehow इन **configuration files** को **compromise** करना या उनके द्वारा execute किए जाने वाले **commands** को compromise करना है। +इसलिए attacker का ultimate goal somehow **उन configuration files** या **उनके द्वारा execute किए गए commands** को **compromise** करना है। > [!TIP] -> कुछ hosted builders contributors को Docker build context और Dockerfile path चुनने देते हैं। अगर context attacker-controlled है, तो आप build के दौरान host files ingest करने और secrets exfiltrate करने के लिए इसे repo के बाहर (जैसे, "..") set कर सकते हैं। देखें: +> कुछ 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,59 +58,60 @@ Pipeline define करने का सबसे common तरीका है ### PPE - Poisoned Pipeline Execution -Poisoned Pipeline Execution (PPE) path SCM repository में permissions का उपयोग करके CI pipeline को manipulate करता है और harmful commands execute करता है। आवश्यक permissions वाले users CI configuration files या pipeline job द्वारा इस्तेमाल की जाने वाली अन्य files को malicious commands शामिल करने के लिए modify कर सकते हैं। इससे CI pipeline "poison" हो जाती है, और ये malicious commands execute होती हैं। +Poisoned Pipeline Execution (PPE) path एक SCM repository में permissions का exploit करके CI pipeline को manipulate करता है और harmful commands execute करता है. जिन users के पास आवश्यक permissions हैं, वे CI configuration files या pipeline job द्वारा उपयोग की जाने वाली अन्य files को modify करके malicious commands शामिल कर सकते हैं. यह CI pipeline को "poison" करता है, जिससे इन malicious commands का execution होता है। -किसी malicious actor के लिए PPE attack सफल करने हेतु उसे ये करने में सक्षम होना चाहिए: +किसी malicious actor के लिए PPE attack सफलतापूर्वक करने के लिए उसे यह करने में सक्षम होना चाहिए: -- VCS platform पर **write access** होना चाहिए, क्योंकि आम तौर पर pipelines तब trigger होती हैं जब push या pull request किया जाता है। (access पाने के तरीकों के सारांश के लिए VCS pentesting methodology देखें)। -- ध्यान दें कि कभी-कभी **external PR को "write access" माना जाता है**। -- भले ही उसके पास write permissions हों, उसे यह सुनिश्चित करना होगा कि वह CI config file या उन अन्य files को modify कर सकता है जिन पर config निर्भर करती है। -- इसके लिए उसे **branch protections bypass** करनी पड़ सकती हैं। +- VCS platform पर **write access** होना चाहिए, क्योंकि आमतौर पर pipelines push या pull request होने पर trigger होती हैं. (access पाने के तरीकों के summary के लिए VCS pentesting methodology देखें). +- ध्यान दें कि कभी-कभी एक **external PR write access** के रूप में count होता है। +- भले ही उसके पास write permissions हों, उसे यह सुनिश्चित करना होगा कि वह CI config file या उन अन्य files को **modify** कर सके जिन पर config निर्भर है। +- इसके लिए, उसे **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** करता है जिस पर execute होने वाली CI config file **relies on** करती है (जैसे 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 नियंत्रित कर सकता है (जैसे PR का title) और उसे किसी **dangerous place** में **used** किया जाता है (जैसे **sh commands** execute करना), तो attacker वहां **commands inject** कर सकता है। +- **I-DDE**: एक **Indirect PPE** attack तब होता है जब actor उस **file** को **modify** करता है जिस पर execute किया जाने वाला CI config file **depend** करता है (जैसे 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 नियंत्रित कर सकता है (जैसे PR का title) और यह किसी **dangerous place** में **used** होती है (जैसे **sh commands** execute करना), तो attacker वहाँ commands **inject** कर सकता है। ### Exploitation Benefits Pipeline को poison करने के 3 flavours जानने के बाद, देखते हैं कि successful exploitation के बाद attacker क्या हासिल कर सकता है: -- **Secrets**: जैसा पहले बताया गया, pipelines को अपने jobs के लिए **privileges** चाहिए (code retrieve करना, उसे build करना, deploy करना...) और ये privileges आमतौर पर **secrets** में दिए जाते हैं। ये 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** में पहुंच सकता है जहाँ उसे और resources मिल सकते हैं। -- **Cloud**: attacker **cloud में अन्य machines** access कर सकता है, लेकिन उससे IAM roles/service accounts **tokens** exfiltrate करके cloud के अंदर और access भी प्राप्त कर सकता है। -- **Platforms machine**: कभी-कभी jobs **pipelines platform machines** के अंदर execute होंगे, जो आम तौर पर cloud के अंदर होती हैं और जिनमें **और कोई access नहीं** होता। -- **Select it:** कभी-कभी **pipelines platform में कई machines configured** होती हैं और अगर आप CI configuration file **modify** कर सकते हैं, तो आप बता सकते हैं कि malicious code कहाँ run हो। इस स्थिति में attacker शायद हर possible machine पर reverse shell run करेगा ताकि उसे आगे exploit करने की कोशिश कर सके। -- **Compromise production**: अगर आप pipeline के अंदर हैं और final version वहीं से build और deploy होता है, तो आप उस code को compromise कर सकते हैं जो production में चलने वाला है। +- **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** for example) को modify नहीं कर सकता, तो वह केवल वही secrets exfiltrate कर सकेगा जो उस pipeline के पास हैं। +- **Computation**: code कहीं execute होता है, और जहाँ execute होता है उसके अनुसार attacker आगे pivot कर सकता है। +- **On-Premises**: अगर pipelines on premises execute होती हैं, तो attacker एक **internal network** में पहुँच सकता है जहाँ और अधिक resources available हों। +- **Cloud**: attacker cloud में अन्य machines तक पहुँच सकता है, लेकिन वहाँ से IAM roles/service accounts के **tokens exfiltrate** करके cloud के अंदर आगे access भी प्राप्त कर सकता है। +- **Platforms machine**: कभी-कभी jobs **pipelines platform machines** के अंदर execute होंगी, जो आमतौर पर एक cloud के अंदर होती हैं और जिनकी **no more access** होती है। +- **Select it:** कभी-कभी **pipelines platform several machines configured** रखेगा और अगर आप CI configuration file को **modify** कर सकते हैं, तो आप बता सकते हैं कि malicious code कहाँ run करना है. ऐसी स्थिति में attacker संभवतः हर possible 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 करके: +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 पर अपने आप run हो जाए। -- **Secondary execution paths**: भले ही targets `--ignore-scripts` के साथ install करें, malicious package फिर भी `bin` field में एक **common CLI name** register कर सकता है, जिससे attacker-controlled wrapper `PATH` में symlink हो जाता है और command use होने पर बाद में execute होता है। +- **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 होने पर later 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, और `gh auth token` जैसे local tooling देखें। GitHub Actions पर runner-specific secrets और artifacts भी देखें। -- **Workflow injection with stolen GitHub tokens**: **`repo` + `workflow`** permissions वाला token एक branch बनाने, `.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 दूसरे environments में downstream auto-execution में बदल जाता है। +- **Credential harvesting from build environments**: जब code CI के अंदर run होता है, तो environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs, और `gh auth token` जैसे local tooling देखें. GitHub Actions पर, runner-specific secrets और artifacts भी देखें। +- **Workflow injection with stolen GitHub tokens**: एक token जिसके पास **`repo` + `workflow`** permissions हों, branch बनाने, `.github/workflows/` के अंदर malicious file commit करने, उसे trigger करने, produced artifacts/logs collect करने, और फिर temporary branch/workflow run delete करने के लिए पर्याप्त है ताकि traces कम हों। +- **Wormable registry propagation**: चोरी किए गए npm tokens को **publish** permissions और 2FA bypass करने की क्षमता के लिए validate किया जाना चाहिए. अगर वे ऐसा करते हैं, writable packages enumerate करें, उनके tarballs download करें, `setup.mjs` जैसा loader inject करें, उसे execute करने के लिए `preinstall` set करें, patch version bump करें, और republish करें। यह एक CI compromise को अन्य environments में downstream auto-execution में बदल देता है। #### Practical checks during an assessment -- release automation में `package.json` में जोड़े गए package-manager hooks, unexpected `bin` entries, या ऐसे version bumps देखें जो सिर्फ release artifact modify करते हैं। -- जाँचें कि क्या CI long-lived registry credentials को plaintext files जैसे `~/.npmrc` में store करता है, short-lived OIDC या trusted publishing के बजाय। -- verify करें कि CI में उपलब्ध GitHub tokens workflow files write कर सकते हैं या branches/tags create कर सकते हैं। -- अगर किसी compromised package का संदेह है, तो केवल Git repository नहीं, बल्कि published tarball भी inspect करें, क्योंकि malicious loader/runtime सिर्फ published artifact में हो सकता है। -- CI के अंदर unexpected package-manager execution जैसे `npm install` की जगह `npm ci`, unexpected Bun downloads/execution, या transient branches से बने नए workflow artifacts की तलाश करें। +- `package.json` में जोड़े गए package-manager hooks, unexpected `bin` entries, या ऐसे version bumps के लिए release automation review करें जो केवल release artifact को modify करते हैं। +- Check करें कि CI plaintext files जैसे `~/.npmrc` में long-lived registry credentials store करता है या short-lived OIDC या trusted publishing का उपयोग करता है। +- Verify करें कि CI में available GitHub tokens workflow files लिख सकते हैं या branches/tags create कर सकते हैं। +- अगर किसी compromised package का संदेह है, तो published tarball inspect करें, केवल Git repository नहीं, क्योंकि malicious loader/runtime केवल published artifact में मौजूद हो सकता है। +- CI के अंदर unexpected package-manager execution खोजें, जैसे `npm install` के बजाय `npm ci`, unexpected Bun downloads/execution, या transient branches से generated नए workflow artifacts। +- GitOps deployment engines को भी CI/CD targets के रूप में review करें. Argo CD-specific enumeration, repo-server abuse, और Redis cache poisoning attacks [Argo CD Security](argocd-security.md) में covered हैं। ## More relevant info ### Tools & CIS Benchmark -- [**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 कर सकता है। +- [**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 audit करने के लिए है. यह auditing पूरे SDLC process पर focus करती है, जहाँ यह code time से deploy time तक के risks reveal कर सकती है। ### Top 10 CI/CD Security Risk @@ -118,7 +119,7 @@ Cider के अनुसार top 10 CI/CD risks पर यह interesting art ### Labs -- जिस भी platform पर आप locally run कर सकते हैं, वहाँ आपको इसे locally launch करने का तरीका मिलेगा ताकि आप इसे अपनी इच्छा के अनुसार configure करके test कर सकें +- प्रत्येक platform पर जिसे आप locally run कर सकते हैं, आपको इसे locally launch करने का तरीका मिलेगा ताकि आप उसे अपनी इच्छानुसार test करने के लिए configure कर सकें - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) ### Automatic Tools