Una de las funcionalidades que ofrece CloudTrail es la capacidad de registrar como eventos todas aquellas acciones realizadas por un usuario, rol o servicio de AWS. Sin embargo, la propia naturaleza de este servicio hace posible el uso de CloudTrail para pivotar a otras cuentas de AWS.
Supongamos que nosotros, como pentesters (aunque el escenario que explicaremos a continuación también aplica en el caso de un atacante) tenemos acceso a un conjunto de claves de AWS API pertenecientes a la cuenta 12345678901; lo primero que debemos hacer es enumerar los permisos asociados a dichas claves. Para el caso que nos ocupa, resulta de particular interés la forma en que los roles que pueden ser asumidos por un usuario están descritos en la política o políticas asociadas a nuestro par de claves.
En esta política se especifica claramente el ID de la cuenta y el rol que nuestro usuario puede asumir.
A pesar de que podemos intuir que, en este caso, nuestro usuario podría asumir roles en múltiples cuentas de AWS, no hay nada que nos proporcione información acerca del ID de la cuenta donde se encuentran dichos roles ni de los roles en sí mismos, detalles que necesitamos conocer para poder asumir el rol. Es aquí donde entra en juego el uso de CloudTrail para pivotar a otras cuentas de AWS.
El requisito principal para poder seguir esta vía es que nuestro usuario debe tener asociado el permiso cloudtrail:LookupEvents.
¿Por qué es posible obtener este tipo de información? Esto se debe a que si la acción de asumir un rol está configurada como un evento en CloudTrail, al asumir dicho rol se almacenarán los detalles de la acción en cualquier trail que esté configurado para capturar estos eventos. Por lo tanto, podemos hacer peticiones a CloudTrail en busca de eventos exitosos del tipo assumeRole con el objetivo de encontrar otras cuentas de AWS a las que acceder y sobre las cuales, anteriormente, no teníamos conocimiento. Esto lo podemos lograr con el siguiente comando de CLI:
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole --region [nombre_de_la_región] | jq '.Events | .[] | .Username as $username | .CloudTrailEvent | fromjson | {timestamp: .eventTime, user: $username, assumedRole: .requestParameters.roleArn}'Lo primero que llama la atención del resultado del comando ejecutado es que alguien ha intentado utilizar la cuenta del usuario raíz para asumir un rol, lo cual no está permitido por AWS y, por lo tanto, dicha acción ha fallado. Sin embargo, vemos diferentes usuarios (user1 y deploybot) que han asumido correctamente diversos roles, cuyos nombres e identificadores de cuentas a las que pertenecen aparecen claramente detallados. Si, por ejemplo, el usuario al que pertenece nuestro par de claves es deploybot, ahora conocemos un nuevo rol que podemos asumir, ya que disponemos de los datos necesarios para realizar dicha acción.
Asumiendo dicho rol, habremos pivotado a la cuenta 112233445566 (recordemos que nuestra cuenta inicial era 12345678901) y, con un poco de suerte, también habremos logrado realizar una escalada de privilegios. Lo que podamos hacer en esta nueva cuenta de AWS dependerá de los permisos asignados a nuestro usuario en la misma.
Más información:
Comentarios recientes