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:
+26
-26
@@ -4,7 +4,7 @@
|
||||
|
||||
## Step Functions
|
||||
|
||||
For more information about this AWS service, check:
|
||||
Para más información sobre este servicio de AWS, consulta:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-stepfunctions-enum.md
|
||||
@@ -12,24 +12,24 @@ For more information about this AWS service, check:
|
||||
|
||||
### Task Resources
|
||||
|
||||
Estas técnicas de escalada de privilegios requieren usar algunos recursos de Step Functions de AWS para realizar las acciones de escalada de privilegios deseadas.
|
||||
Estas técnicas de escalada de privilegios requerirán el uso de algunos recursos de AWS Step Functions para llevar a cabo las acciones de escalada de privilegios deseadas.
|
||||
|
||||
Para comprobar todas las acciones posibles, puedes ir a tu propia cuenta de AWS, seleccionar la acción que quieras usar y ver los parámetros que está utilizando, como en:
|
||||
Para revisar todas las acciones posibles, puedes ir a tu propia cuenta de AWS, seleccionar la acción que quieras usar y ver los parámetros que está usando, como en:
|
||||
|
||||
<figure><img src="../../../images/telegram-cloud-photo-size-4-5920521132757336440-y.jpg" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
O también puedes consultar la documentación de la API de AWS y revisar la documentación de cada acción:
|
||||
O también puedes ir a la documentación API de AWS y revisar la documentación de cada acción:
|
||||
|
||||
- [**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`
|
||||
|
||||
Un atacante con los permisos **`states:TestState`** y **`iam:PassRole`** puede probar cualquier state y pasarle cualquier rol de IAM sin crear ni actualizar una máquina de estados existente, lo que potencialmente permite el acceso no autorizado a otros servicios de AWS con los permisos del rol. Combinados, estos permisos pueden conducir a acciones no autorizadas extensas, desde manipular flujos de trabajo para alterar datos hasta filtraciones de datos, manipulación de recursos y escalada de privilegios.
|
||||
Un atacante con los permisos **`states:TestState`** y **`iam:PassRole`** puede probar cualquier state y pasarle cualquier rol IAM sin crear o actualizar una state machine existente, potencialmente permitiendo acceso no autorizado a otros servicios de AWS con los permisos de esos roles. Combinados, estos permisos pueden conducir a acciones no autorizadas extensas, desde manipular flujos de trabajo para alterar datos hasta filtraciones de datos, manipulación de recursos y escalada de privilegios.
|
||||
```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]
|
||||
```
|
||||
Los siguientes ejemplos muestran cómo probar un estado que crea una clave de acceso para el usuario **`admin`** aprovechando estos permisos y un rol permisivo del entorno AWS. Este rol permisivo debería tener asociada alguna política de alto privilegio (por ejemplo **`arn:aws:iam::aws:policy/AdministratorAccess`**) que permita al estado ejecutar la acción **`iam:CreateAccessKey`**:
|
||||
Los siguientes ejemplos muestran cómo probar un estado que crea una access key para el usuario **`admin`** aprovechando estos permisos y un rol permisivo del entorno AWS. Este rol permisivo debe tener asociada alguna política de alto privilegio (por ejemplo **`arn:aws:iam::aws:policy/AdministratorAccess`**) que permita que el estado ejecute la acción **`iam:CreateAccessKey`**:
|
||||
|
||||
- **stateDefinition.json**:
|
||||
```json
|
||||
@@ -59,23 +59,23 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
|
||||
"status": "SUCCEEDED"
|
||||
}
|
||||
```
|
||||
**Impacto potencial**: Ejecución y manipulación no autorizada de flujos de trabajo y acceso a recursos sensibles, lo que podría derivar en brechas de seguridad significativas.
|
||||
**Impacto potencial**: Ejecución y manipulación no autorizada de workflows y acceso a recursos sensibles, lo que podría conducir a brechas de seguridad significativas.
|
||||
|
||||
### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
|
||||
|
||||
Un atacante con **`states:CreateStateMachine`** y **`iam:PassRole`** podría crear una máquina de estados y asignarle cualquier rol de IAM, permitiendo acceso no autorizado a otros servicios de AWS con los permisos del rol. A diferencia de la técnica de escalada previa (**`states:TestState`** y **`iam:PassRole`**), esta no se ejecuta por sí sola; también necesitarás tener los permisos **`states:StartExecution`** o **`states:StartSyncExecution`** (**`states:StartSyncExecution`** **no está disponible para workflows estándar**, **solo para express state machines**) para poder iniciar una ejecución sobre la máquina de estados.
|
||||
Un atacante con la **`states:CreateStateMachine`**& **`iam:PassRole`** podría crear una state machine y asignarle cualquier rol IAM, permitiendo acceso no autorizado a otros servicios de AWS con los permisos del rol. A diferencia de la técnica privesc anterior (**`states:TestState`** & **`iam:PassRole`**), esta no se ejecuta por sí sola; también necesitarás los permisos **`states:StartExecution`** o **`states:StartSyncExecution`** (**`states:StartSyncExecution`** es **no está disponible para workflows estándar**, **solo para express state machines**) para iniciar una ejecución sobre la state machine.
|
||||
```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>]
|
||||
```
|
||||
Los siguientes ejemplos muestran cómo crear una state machine que crea una access key para el usuario **`admin`** y exfiltra dicha access key a un S3 bucket controlado por el atacante, aprovechando estos permisos y un rol permisivo del entorno AWS. Este rol permisivo debería tener asociada alguna política de alto privilegio (por ejemplo **`arn:aws:iam::aws:policy/AdministratorAccess`**) que permita a la state machine realizar las acciones **`iam:CreateAccessKey`** y **`s3:putObject`**.
|
||||
Los siguientes ejemplos muestran cómo crear una state machine que crea una access key para el usuario **`admin`** y exfiltra dicha access key a un bucket de S3 controlado por el atacante, aprovechando estos permisos y un rol permisivo del entorno AWS. Este rol permisivo debería tener asociada alguna política de alto privilegio (por ejemplo **`arn:aws:iam::aws:policy/AdministratorAccess`**) que permita a la state machine realizar las acciones **`iam:CreateAccessKey`** y **`s3:putObject`**.
|
||||
|
||||
- **stateMachineDefinition.json**:
|
||||
```json
|
||||
@@ -123,7 +123,7 @@ aws stepfunctions create-state-machine --name MaliciousStateMachine --definition
|
||||
"creationDate": "2024-07-09T20:29:35.381000+02:00"
|
||||
}
|
||||
```
|
||||
- **Comando** ejecutado para **iniciar una ejecución** de la máquina de estado creada previamente:
|
||||
- **Comando** ejecutado para **iniciar una ejecución** de la máquina de estados creada anteriormente:
|
||||
```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]
|
||||
> El bucket S3 controlado por el atacante debería tener permisos para aceptar una acción s3:PutObject desde la cuenta de la víctima.
|
||||
> El bucket S3 controlado por el atacante debe tener permisos para aceptar una acción s3:PutObject desde la cuenta víctima.
|
||||
|
||||
**Impacto potencial**: Ejecución y manipulación no autorizada de workflows y acceso a recursos sensibles, lo que puede conducir a brechas de seguridad significativas.
|
||||
**Impacto potencial**: Ejecución no autorizada y manipulación de flujos de trabajo y acceso a recursos sensibles, pudiendo conducir a brechas de seguridad significativas.
|
||||
|
||||
### `states:UpdateStateMachine` & (no siempre requerido) `iam:PassRole`
|
||||
### `states:UpdateStateMachine` & (not always required) `iam:PassRole`
|
||||
|
||||
Un atacante con el permiso **`states:UpdateStateMachine`** podría modificar la definición de una state machine, pudiendo añadir estados adicionales sigilosos que podrían terminar en una escalada de privilegios. De este modo, cuando un usuario legítimo inicie una ejecución de la state machine, este nuevo estado malicioso y sigiloso se ejecutará y la escalada de privilegios tendrá éxito.
|
||||
Un atacante con el permiso **`states:UpdateStateMachine`** podría modificar la definición de una máquina de estados, pudiendo añadir estados adicionales y sigilosos que podrían terminar en una escalada de privilegios. De este modo, cuando un usuario legítimo inicie una ejecución de la máquina de estados, este nuevo estado malicioso y sigiloso se ejecutará y la escalada de privilegios tendrá éxito.
|
||||
|
||||
Dependiendo de lo permisivo que sea el IAM Role asociado a la state machine, un atacante se enfrentaría a 2 situaciones:
|
||||
Dependiendo de cuán permisivo sea el rol de IAM asociado a la máquina de estados, el atacante se enfrentaría a 2 situaciones:
|
||||
|
||||
1. **IAM Role permisivo**: Si el IAM Role asociado a la state machine ya es permisivo (por ejemplo tiene adjunta la policy **`arn:aws:iam::aws:policy/AdministratorAccess`**), entonces el permiso **`iam:PassRole`** no sería necesario para escalar privilegios, ya que no sería necesario actualizar también el IAM Role; con modificar la definición de la state machine es suficiente.
|
||||
2. **IAM Role no permisivo**: En contraste con el caso anterior, aquí un atacante también requeriría el permiso **`iam:PassRole`** ya que sería necesario asociar un IAM Role permisivo a la state machine además de modificar la definición de la state machine.
|
||||
1. **Rol de IAM permisivo**: Si el rol de IAM asociado a la máquina de estados ya es permisivo (por ejemplo, tiene adjunta la policy **`arn:aws:iam::aws:policy/AdministratorAccess`**), entonces el permiso **`iam:PassRole`** no sería necesario para escalar privilegios, dado que no sería preciso actualizar también el rol de IAM: basta con modificar la definición de la máquina de estados.
|
||||
2. **Rol de IAM no permisivo**: En contraste con el caso anterior, aquí el atacante también requeriría el permiso **`iam:PassRole`**, ya que sería necesario asociar un rol de IAM permisivo a la máquina de estados además de modificar la definición de la máquina de estados.
|
||||
```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>]
|
||||
```
|
||||
Los siguientes ejemplos muestran cómo actualizar una máquina de estados legítima que solo invoca una función HelloWorld de Lambda, con el fin de añadir un estado extra que agrega al usuario **`unprivilegedUser`** al **`administrator`** IAM Group. De esta forma, cuando un usuario legítimo inicie la ejecución de la máquina de estados actualizada, este nuevo estado malicioso y sigiloso se ejecutará y la escalada de privilegios será exitosa.
|
||||
Los siguientes ejemplos muestran cómo actualizar una máquina de estados legítima que solo invoca una función HelloWorld Lambda, para añadir un estado extra que añade al usuario **`unprivilegedUser`** al Grupo IAM **`administrator`**. De este modo, cuando un usuario legítimo inicie una ejecución de la máquina de estados actualizada, se ejecutará este nuevo estado malicioso y sigiloso y la escalada de privilegios tendrá éxito.
|
||||
|
||||
> [!WARNING]
|
||||
> Si la state machine no tiene asociada una IAM Role permisiva, también se requeriría el permiso **`iam:PassRole`** para actualizar la IAM Role y así asociar una IAM Role permisiva (por ejemplo una con la **`arn:aws:iam::aws:policy/AdministratorAccess`** policy adjunta).
|
||||
> Si la máquina de estados no tiene asociado un rol IAM permisivo, también sería necesario el permiso **`iam:PassRole`** para actualizar el rol IAM con el fin de asociar un rol IAM permisivo (por ejemplo, uno con la política **`arn:aws:iam::aws:policy/AdministratorAccess`** adjunta).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Legit State Machine" }}
|
||||
@@ -218,7 +218,7 @@ Los siguientes ejemplos muestran cómo actualizar una máquina de estados legít
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
- **Comando** ejecutado para **actualizar** **la state machine legítima**:
|
||||
- **Comando** ejecutado para **actualizar** **la máquina de estados legítima**:
|
||||
```bash
|
||||
aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorldLambda --definition file://StateMachineUpdate.json
|
||||
{
|
||||
@@ -226,6 +226,6 @@ aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-eas
|
||||
"revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f"
|
||||
}
|
||||
```
|
||||
**Potential Impact**: Ejecución y manipulación no autorizadas de flujos de trabajo y acceso a recursos sensibles, lo que podría conducir a brechas de seguridad significativas.
|
||||
**Impacto potencial**: Ejecución y manipulación no autorizadas de flujos de trabajo y acceso a recursos sensibles, lo que podría conducir a brechas de seguridad significativas.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user