En esta serie de entradas, repasaremos algunas técnicas para realizar pentesting sobre entornos en Azure. En esta segunda entrada, vamos a ver dos vectores de ataque enfocados a IaaS y PaaS sobre un entorno montado en Azure.
Antes de comenzar, si estás viendo este contenido por primera vez, te recomendamos ir a la primera parte para entender los fundamentos:
https://labitacoradelhacker.com/atacar-a-la-nube-pentesting-en-azure-parte-1
Ahora sí, comencemos:
Importante: En este artículo todavía no se verán ataques sobre Azure AD. Estos ataques se verán en una entrada posterior. Asimismo, los vectores de ataque están orientados a comprometer los servicios de Azure, sin utilizar como punto de partida vulnerabilidades existentes en aplicaciones web o móviles montadas en Azure, ya que no es el objetivo.
1) Máquinas virtuales expuestas
Uno de los servicios más usados en un entorno Azure, es la creación de máquinas virtuales, por su facilidad al momento de ser desplegadas. Existen muchas imágenes de SO que pueden ser utilizadas, y es muy sencillo escalar los recursos en caso de que se necesite una mayor capacidad.
Muchas veces, por facilidad de los administradores, se crean permisos de seguridad de red para que estas máquinas sean accedidas de manera remota, exponiendo algún puerto de administración conocido como RDP (3389) o SSH (22)
Una plataforma que nos permite buscar este servicio expuesto es Shodan:
Aunque es poco probable que encontremos alguna máquina virtual que permita el acceso de manera anónima o no autenticada, es importante considerar que estos recursos están expuestos por alguna mala configuración o sirven para un propósito especifico, como servir de punto de entrada a otros recursos.
En este punto es posible intentar autenticarnos con credenciales comunes, cuidando siempre de no causar algún bloqueo. Si se consiguiera acceso, pueden utilizarse las técnicas de explotación conocidas, por ejemplo, en caso de que sea una MV basada en Windows, podemos usar Mimikatz para extraer credenciales.
2) Cuentas de almacenamiento Azure
Otro de los servicios más utilizados en Azure es la cuenta de almacenamiento, la cual permite almacenar data en la nube. Azure tiene 4 sub-servicios:
- Blob Service: Almacenamiento general de archivos no estucturados, el cual es consumido a través de HTTP/HTTPs
- Files Service: Es similar a un sistema de archivos tradicional, el cual puede ser a unido a una máquina virtual. Se consume a través de SMB o NFS
- Table Service: Datasets de datos semiestructurados (NoSQL)
- Queue Service: Almacenamiento de colas de mensajes, el cual se accede a través de HTTP/HTTPs
Como mencionamos en el post anterior, existen sufijos DNS para los servicios de Microsoft, y para este caso son los siguientes:
- [Nombre].blob.core.windows.net
- [Nombre].file.core.windows.net
- [Nombre].table.core.windows.net
- [Nombre].queue.core.windows.net
Nuestro objetivo en este punto, es buscar repositorios que puedan contener información pública. Una herramienta que nos ayudará a conectarnos es Azure Storage Explorer, la cual puedes descargar desde acá: https://azure.microsoft.com/es-es/products/storage/storage-explorer
La aplicación es sencilla de utilizar, solo debes conectarte al repositorio y explorar (en caso de que haya archivos disponibles)
Al momento de conectarnos a un repositorio, existen 3 opciones:
- A través de un usuario creado en Azure AD: Esta opción la descartaremos por ahora, ya que veremos este tópico en el siguiente post
- Dirección URL de firma de acceso compartido (SAS): Esta forma de acceso depende de la creación de un token SAS, el cual es generado por el propietario del repositorio usualmente para brindar acceso temporal a un contenido. Es poco probable que pueda encontrarse públicamente, y difícil de predecir o suplantar, por lo que por ahora lo descartaremos
- De forma anónima: Esta es la opción que buscaremos por ahora. Un escenario común es que una aplicación, consuma sus recursos de un storage que está disponible públicamente. En un ambiente productivo, es probable que el contenido no sea interesante, por ejemplo, accediendo a imágenes o videos, sin embargo, un error que se suele cometer, es que en ambientes previos (desarrollo o certificación), la configuración también está disponible públicamente, pero se carga más información de la que se debería.
Es importante también mencionar que si queremos obtener información pública de la organización a la que estamos haciendo pentest, todas las técnicas de OSINT son válidas. La recolección de información es un paso clave en el proceso.
Y esto ha sido todo en este post. Por ahora dejaremos el tema aquí, y en la siguiente entrada veremos algunas técnicas para obtener credenciales de usuarios de Azure AD.