En esta serie de entradas, repasaremos algunas técnicas para realizar pentesting sobre entornos en Azure. Esta primera parte cubrirá algunos aspectos fundamentales, teniendo como premisa que tienes conocimientos de como funciona una nube pública, y luego repasaremos algunos vectores de ataque conocidos.
Bien, lo primero que debemos saber es que Azure tiene en su catalogo más de 300 servicios, que te permiten montar básicamente toda tu plataforma tecnológica en la nube sin depender de ningún componente on-premise.
Cuando una organización decide utilizar una carga de trabajo en Azure, existen servicios que son altamente probables que necesiten ser expuestos a internet (por ejemplo, una aplicación web), y que nos servirá como punto de partida para realizar nuestras pruebas. Hay que tener en cuenta además, que a través de Azure AD, es posible también gestionar la autenticación y autorización a los recursos, por lo que una buena etapa de enumeración es clave para poder ganar acceso.
Dicho esto, comencemos.
Importante: Este escenario es demostrativo. Atacar algún activo sin consentimiento, puede ser considerado ilegal. Utilice este conocimiento bajo su propio riesgo.
Comprendiendo la jerarquía en Azure
Un concepto importante que debemos conocer es como está estructurada la jerarquía de la gestión de recursos en Azure. En el nivel más alto tenemos al componente IAM, que para este caso es Azure AD. Tengamos en cuenta que el rol con mayor nivel de privilegios es el de Global Admin.
A partir de ahí, los recursos se crean dentro de suscripciones, que están organizadas en grupos de administración, los cuales a su vez tienen un grupo de gestión raíz. Dentro de una suscripción, existen grupos de recursos, en donde finalmente se crean los activos/servicios que necesitamos. Para mejor comprensión, se muestra el siguiente diagrama:
Es importante también indicar que los servicios en la nube pueden conectarse a servicios on-premise a través de capacidades como Express Route o Azure VPN Gateway, pero en estas entradas no vamos a hablar sobre estos servicios.
Comprendiendo la estructura de control de acceso basado en roles
De igual manera, otro concepto importante que se necesita entender para realizar pentesting sobre Azure, es como funciona la estructura de usuarios dentro de la plataforma, y como se gestiona el acceso a los diferentes recursos. Ya habíamos mencionado que el rol con mayor privilegio es el Global admin, pero ¿qué más debo comprender?
Lo primero es entender que en la gestión de accesos tenemos tres componentes «principales»:
Security principals: Este es un término general para referenciar a un objeto que puede tener un privilegio dentro de Azure, por ejemplo: un usuario. Existen varios security principals, como usuarios, grupos, service principals o managed identity.
Quizá los conceptos de usuario y grupo nos quedan claro aun sin definirlos, pero los dos últimos no. Para simplificar, diremos que un service principal es una identidad de aplicación que necesita acceso a los recursos de Azure, mientras que un managed identity es una identidad asignada a un servicio propio de Azure que necesita acceder a otros recursos (por ejemplo, MVs, AKS, etc).
Role definitions: Corresponde a la colección de permisos definidos en Azure. Existen 3 grandes categorías: Lector (Reader), Colaborador (Contributor) y Propietario (Owner), que dan diferentes permisos sobre la lectura o escritura de los recursos. Aunque estos son las definiciones básicas, existen muchos roles definidos que están acotados a un determinado servicio, por ejemplo VM Contributor, solo tiene alcance sobre máquinas virtuales, y no puede acceder a otros servicios.
Aunque Microsoft ofrece muchas definiciones de roles predeterminadas, se pueden crear roles personalizados.
Role assignment: Es la forma de como se asignan los roles definition a los security principals, teniendo en cuenta la jerarquía de los recursos. Incluso a nivel de AD existen roles que pueden gestionar los usuarios, tales como Global Admin o User Administrator.
¿Por donde comenzar?
Como se indicó previamente, existen servicios que son más probables que se encuentren expuestos que otros, por lo que debemos partir de ahí. Intentar comprometer una BD SQL interna, o un Keyvault, podría no ser un objetivo ideal en este punto.
¿Qué herramientas debo tener a la mano?
Aunque existen muchas herramientas que pueden ayudarnos en un proceso de pentesting sobre Azure, listamos aquellas que consideramos útiles, y que servirán para los escenarios mostrados en estos artículos:
- Herramientas generales: wget, curl, Powershell, Postman, Remote Desktop, etc
- Herramientas de pentest genéricas: gobuster, nmap, dnscan, hydra, etc
- Herramientas de pentest para Azure: evilginx2, AADInternals, Cloud Enum, Microburst, Lava, PowerZure, BloodHound, Koboko
Como podrás notar no hemos hecho referencia a las herramientas que permiten acceder a los servicios de Azure de manera directa, pero es importante que puedas saber que existen multiples formas de acceder, entre ellas tenemos:
- Azure Portal
- Azure CLI
- Az Powershell
- Azure Rest APIs
En los próximos artículos utilizaremos algunas de estas herramientas de acceso. Sin embargo, es muy util que tengas instalado en tu equipo Az Powershell. La instalación es sencilla, y se puede hacer a través de los siguientes comandos:
PS C:\> Install-Module -Name Az
PS C:\> Connect-AzAccount
PS C:\> Import-Module AzAdemás, es útil también tener instalados los módulos de gestión de Azure AD:
PS C:\> Install-Module -Name AzureAD
PS C:\> Connect-AzureAD
Ahora sí, ya con los conceptos claros y nuestro arsenal preparado, podemos iniciar nuestro trabajo de enumeración.
Enumerando servicios en Azure:
Para empezar nuestro proceso de pentest, utilizaremos la herramienta enum_cloud. Puedes encontrarla aquí: https://github.com/initstring/cloud_enum
Al ejecutar solo necesitaremos indicarle el nombre del dominio que queremos enumerar. Esta herramienta también permite escanear servicios expuestos de AWS y GCP, pero por ahora nos enfocaremos en Azure
Otra herramienta útil es Microburst, que puedes descargar desde aquí: https://github.com/NetSPI/MicroBurst.
Como hemos podido notar, existen muchos servicios que contienen sufijos predeterminados por Microsoft, entre los cuales destacamos:
| Sufijo de dominio | Servicio asociado |
| .blob.core.windows.net | Cuenta de almacenamiento – Blob |
| .file.core.windows.net | Cuenta de almacenamiento – Archivos |
| .queue.core.windows.net | Cuenta de almacenamiento – Colas |
| .azurewebsites.net | App Services |
| .database.windows.net | Bases de datos MSSQL |
| .cloudapp.azure.com | DNS de IP pública asignada a un cliente específico |
| .documents.azure.com | Cosmos DB |
| .azure-api.net | Servicios de API |
| azurecontainer.io | Contenedores (Instancias) |
| azurecr.io | Contenedores (Registro) |
Bien, por ahora dejaremos esta entrada acá, no sin antes compartir dos temas importantes:
- Azure tiene muchos servicios de seguridad, por lo que en un contexto real, es altamente probable que una organización haya implementado muchos de ellos. Antes de comenzar con la fase de explotación es importante tener un entendimiento general de estos servicios.
2. Hacer pentesting sobre servicios en Azure está permitido por Microsoft, teniendo en cuenta las reglas de juego, las cuales se pueden consultar en el siguiente link: https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement?rtc=3. Antes de iniciar tu proceso de pentest, es ideal que puedas darle una lectura para saber qué tipo de vectores están prohibidos.
Es todo por ahora. Nos vemos en la próxima entrada.