Exfiltración de credenciales NTLM mediante un OVA malicioso
¡Hola a todos!
En el artículo de hoy os vamos a contar los pasos que seguimos para descubrir una vulnerabilidad 0-Day en VMware.
En uno de los test de intrusión que realizamos desde Entelgy Innotec Security para una gran compañía en la que los usuarios pueden enviar y ejecutar máquinas virtuales a diferentes servidores, se decidió buscar alguna vulnerabilidad en VMware, ya que era el sistema que estaba utilizando la compañía en ese momento. Para ello, investigamos el formato de los archivos OVA y OVF utilizados para describir máquinas virtuales.
OVF es un estándar (ISO-17203) abierto que se utiliza para definir máquinas virtuales. Los archivos OVF, están definidos en XML y constan de varias secciones, en las que se van definiendo las características de una máquina virtual. Entre las características se encuentra, por ejemplo, el número de procesadores, la cantidad de memoria RAM, los archivos de disco, etc.
En concreto, OVF contiene los siguientes apartados:
- References: En este apartado se encuentran las referencias que necesita el archivo OVF. Y es precisamente en este apartado donde se indican los archivos de disco que necesita la máquina virtual, justo donde radica la vulnerabilidad 0-Day.
- DiskSection: Definición de los discos que va a utilizar la máquina virtual.
- NetworkSection: Definición de las configuraciones de red.
- VirtualSystem: Aquí se especifican ciertas características como, por ejemplo, el número de núcleos del procesador, la cantidad de memoria RAM, etc.
El apartado “References” puede contener referencias a archivos que necesita la máquina virtual, por ejemplo, archivos de disco. Se indican con el tag “File”, de la siguiente forma:
En cada apartado de tipo “File”, se indica un parámetro ovf:href, que contiene una ruta al archivo en el sistema anfitrión. Las referencias pueden ser:
- Ruta local: C:\Users\file.vmdk, file.vmdk
- Ruta HTTP/S: http://contoso.com/disk.vmdk, https://contoso.com/disk.vmdk
- Ruta FTP: ftp://user:
Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.
Sin embargo, se observó que también es posible utilizar rutas UNC.
En este caso, VMware delega la obtención del archivo indicado al sistema operativo. Es en ese momento cuando Windows trata de obtener el archivo mediante una conexión SMB al servidor indicado. Al conectarse por samba al servidor, se envían también el hash NTLM del usuario en el que se ejecuta VMware.
Para capturar el hash por el atacante se puede utilizar un servidor Samba en el servidor al que apunta el OVF/OVA. Para ello, se puede utilizar el Impacket (https://github.com/SecureAuthCorp/impacket), o con Responder (https://github.com/SpiderLabs/Responder), por ejemplo. También se podría utilizar un servidor samba que contuviera los archivos, y, de esa forma, la máquina virtual se descargaría los discos y los montaría con total normalidad.
Se podría dar el escenario de un posible ataque si un atacante crea un OVF o una OVA en estas condiciones y una víctima abre ese archivo en VMware. Así, el atacante recibiría el hash NTLM en un servidor remoto, pasando inadvertido para el usuario. Tras obtener el hash NTLM de la víctima, el atacante puede ver cómo se llama al dominio en el que está el usuario y, además, puede intentar realizar un ataque mediante diccionario o fuerza bruta para obtener las credenciales de dominio del usuario para, posteriormente, suplantar su identidad en servicios como VPN, correo, etc.
Y aquí finaliza nuestro post para Security Garage. Esperamos que os haya resultado interesante, y que hayáis aprendido algo nuevo. ¡Hasta pronto!
Manuel Fernández-Aramburu
