Actualmente los usuarios de Azure tienen la posibilidad de conectarse a sus servidores de bastionado mediante conexiones SSH y RDP con un cliente nativo o usando la interfaz web. Sin embargo, existe la posibilidad de realizar ataques contra VMs de Azure a través de Azure Bastion y su cliente nativo.
Según la documentación de Microsoft, existen dos opciones mediante las que un usuario puede establecer una conexión con el cliente nativo hacia un servidor de bastionado. La que puede ser utilizada por un atacante es aquella en la que se pueden indicar un mayor número de opciones referentes a la conexión:
az network bastion tunnel --name "" --resource-group "" --target-resource-id "" --resource-port "" --port ""
Al ejecutar el comando anterior, Azure CLI crea un túnel y se pone a la escucha en un puerto local. Es al conectarse a este puerto local con el cliente nativo cuando el usuario gana acceso a la VM interna a través del protocolo utilizado (por ejemplo, RDP).
Fuente de la imagen: Codyburkard.com
Para comprender el proceso de ataque, primero es necesario ver cómo tiene lugar el flujo de trabajo del cliente nativo:
Fuente de la imagen: Codyburked.com
Tras recibir un comando vía API para iniciar una nueva sesión, Azure Bastion lleva a cabo tres acciones:
- Crea una conexión TCP desde el servidor de bastionado hacia la VM del cliente, en el puerto especificado en la petición API.
- Crea una nueva clave de sesión asociada a dicho puerto.
- Acepta una nueva conexión websocket usando la clave de sesión, y transfiere toda la información de la conexión websocket a la conexión TCP de la VM interna.
Del lado del cliente, Azure CLI hace lo siguiente:
- Escucha en un puerto local.
- Acepta nuevas conexiones en dicho puerto, y por cada conexión hace llamadas a la API del servicio de bastionado para iniciar una nueva sesión, tal y como se describió anteriormente.
- Crea un nuevo hilo que transfiere toda la información recibida en la nueva conexión hacia el túnel websocket el servidor de bastionado.
Así pues, al habilitar esta configuración los usuarios finales se pueden comunicar directamente con la VM interna a través de una conexión websocket, un proceso completamente diferente al de un servidor de bastionado tradicional, el cual se comunica tan solo a través del protocolo del servicio utilizado para el acceso remoto (RDP o SSH, en este caso).
Además, el hecho de poder especificar un puerto implica que los servicios de la VM interna pueden ser escaneados usando Azure Bastion, y que los puertos que estén exponiendo servicios vulnerables pueden ser accedidos y explotados por cualquier persona que solicite una sesión de bastionado para una VM concreta.
No obstante, para poder llevar a cabo ataques contra VMs de Azure a través de Azure Bastion el usuario en cuestión debe contar con una serie de permisos y requisitos previos:
- Debe existir un rol Azure RBAC de lectura asignado a la VM.
- Debe existir un rol Azure RBAC de lectura asignado a la NIC asociada con la dirección IP privada.
- Debe existir un rol Azure RBAC de lectura asignado al servicio Azure Bastion.
- La red debe incluir rutas que permitan que la subred de Azure Bastion se comunique con la VM, ya sea en la misma VNet o mediante VNet peering.
Las recomendaciones para evitar este tipo de ataques pasan por deshabilitar el soporte para el cliente nativo de los servicios de bastionado. Sin embargo, si esto no es posible, se pueden tomar las siguientes acciones que mitigan el problema en cierta medida:
- Asegurarnos de que la subred en la que Azure Bastion está desplegado tiene un grupo de seguridad de red (NSG) asociado, de manera que se limite la conectividad a los puertos 3389 y 22.
- Limitar el número de usuarios que tienen acceso RBAC de lectura a un recurso privilegiado, como por ejemplo el grupo de administración raíz.
- Incluir una regla de NSG en la subred de bastionado que limite la conectividad a una dirección IP específica o pequeños rangos de subredes.
Más información
