La auditoría de los servicios en la nube se ha convertido en una tarea esencial y se requiere un esfuerzo significativo para evaluar la seguridad de los recursos disponibles.

En el caso de AWS, hemos publicado varios post y, para comenzar con Azure, Pentesting Azure Applications (y sus scripts), el libro publicado por Matt Burrough, es de lectura obligatoria para los expertos en seguridad centrados en la nube.

Tal y como explico en este podcast de SecurePodcast, algunos análisis en la nube son iguales a las pruebas de seguridad tradicionales y otros, son muy distintas. Algunos tipos de pruebas que podrían llevarse a cabo:

• Pruebas en la nube: pruebas de sistemas tradicionales que simplemente se alojan en un entorno de nube. Por ejemplo, esto puede ser sistemas virtualizados que se han trasladado de la nube local a la nube o podrían ser aplicaciones web que están alojadas en la nube donde solo las aplicaciones en sí se consideran dentro del alcance de la nube. No se considera la infraestructura.
• Pruebas dentro de la nube: prueba a sistemas dentro de la nube y que no están expuestos públicamente, por ejemplo, un servidor que aloja una aplicación que tiene un firewall que impide el acceso directo y, en su lugar se accede a ellos a través de un bastión host. Además, consideraríamos los riesgos asociados con una aplicación comprometida que permite que un atacante acceda a la infraestructura de backend.
• Prueba de la consola en la nube: pruebas sobre la configuración de la consola o el portal.Se analizan las cuentas de usuario que se han configurado, sus permisos, las listas de control de acceso, etc. Esto es efectivamente una revisión de la configuración y bien podría estar impulsado por el cumplimiento. También es una forma eficiente de determinar los caminos potenciales de escalamiento de privilegios.

En el blog de SheHacksPurple explican que el primer paso para cualquier PenTest es establecer su Alcance, Metas y Reglas de Compromiso. Antes de realizar cualquier tipo de prueba, se debe tener un acuerdo firmado por el cliente .

Reglas de compromiso: no se puede atacar a otros tenants de otros clientes o a Azure Service Fabric (la infraestructura subyacente de Microsoft que hace Azure). Se pueden realizar pruebas manuales y exploraciones y acordar las fechas y horarios de prueba antes de realizarlas. Se debe informar a Azure que se van realizar dichas actividades de seguridad y se debe recibir un reconocimiento antes de comenzar. No es obligatorio que se informe a Microsoft antes de un PenTest, pero para la mayoría de los proveedores es recomendable solicitar permiso. Informar a Azure no toma más de algunos minutos y puede simplificar mucho las pruebas sucesivas. Definitivamente vale la pena hacerlo.

Reglas para realizar el pentesting en Azure

• No se puede probar la infraestructura propia de Azure. Esto es una violación del acuerdo de usuario de Azure y Microsoft podría ponerse en contacto para cancelar el servicio contratado.
• No se debe probar nada fuera del alcance del cliente.
• Se debe habilitar el Azure Security Centre (ASC).
• Es recomendable mirar la pestaña "Recomendaciones" de Azure Security Center, donde se informarán todos los problemas (de red, errores de configuración, fallas de parches, más) que aún no hayamos detectado. Es una buena idea empezar por aquí. Esta es una lista de todo lo que no cumple con la política, en orden de importancia.
• ¿Hay un conjunto de políticas y configuración que la organización podría elegir como "segura"? Por ejemplo, ¿existe una política que indique todo el almacenamiento debe estar cifrado en reposo)? Si es así, ¿Cuáles son esos ajustes? ¿Están bien configurados? ¿Qué nivel de cumplimiento tienen?
• ¿La protección contra amenazas (almacenamiento y bases de datos), el monitoreo y la auditoría están configurados en cada recurso posible?
• Se debe observar la red del mismo modo que se haría con una red tradicional. ¿Qué modelo de seguridad de red se está utilizando?
• ¿Existe una lista blanca habilitada de máquinas virtuales? Esto se llama Adaptive Application Controls y esta "defensa avanzada en la nube" deberían estar activada para todos los servidores.
• ¿Se está utilizando un SIEM? ¿Se está monitoreando? ¿Qué tipo de cobertura está recibiendo? ¿Se está alimentando ASC con los datos recolectados?
• ¿Se está utilizando un WAF? ¿Cómo está configurado? ¿Cómo se prueba?
• ¿Se utiliza alguna otra herramienta de seguridad de terceros (IPS / IDS / HIPS / Balanceador / Otro)? Si es así, ¿se están obteniendo cobertura completa de todos los activos que están cubiertos por esta prueba? ¿Están bien configurados?
• Si se están evaluando aplicaciones web dentro de Azure, API y funciones (serverless), se deberían aplicar todas las reglas y pruebas de seguridad habituales, estén en Azure o no.
• Si la organización utiliza Azure DevOps, se deben agregar varias pruebas de seguridad, incluido el kit de Azure Secure DevOps. Este kit es muy estricto y probablemente no se pasará en las primeras pruebas, así que los desarrolladores deben estar preparados para estar un poco decepcionados. Hay muchas herramientas de seguridad en el Azure Marketplace, agregar una de ellas ya no es suficiente.
• Se debe observar la sección de Detección de Amenazas del Centro de seguridad y verificar que no haya ataques activos o recientes. En cualquier caso se debe investigar las posibles consecuencias.

Si se quiere utilizar una herramienta, se puede probar Azurite que fue desarrollado para ayudar a los pentesters y auditores durante las actividades de enumeración y reconocimiento dentro del entorno de la nube pública de Microsoft Azure.
Azurite fue desarrollado por MWR Labs y, para entender su funcionamiento, Apostolos Mastoris ha escrito la guía A Penetration Tester's Guide to the Azure Cloud [PDF].

Azurite se compone de dos scripts de Powershell: Azurite Explorer y Azurite Visualizer. Estos scripts se utilizan para recopilar, de forma pasiva, información detallada de los componentes principales dentro de una implementación que se revisará fuera de línea, y visualizar la asociación entre los recursos mediante una representación interactiva. Una de las características principales de la representación visual es proporcionar una manera rápida de identificar los Network Security Groups (NSG) inseguros en una configuración de subred o máquina virtual.

Aquí se puede ver un reporte de ejemplo de un análisis a una infraestructura de Azure.

Cristian de la Redacción de Segu-Info