martes, mayo 28, 2019

Un módulo para detectar el peligroso bug CVE-2019-0708 con Metasploit {No uses exploits públicos. Troll mode ON}

Cada cierto tiempo en el mundo de la seguridad se van viendo vulnerabilidades mediáticas que prometen ser unas de las vulnerabilidades del año por el impacto que tienen o que pueden tener entre la sociedad y las empresas. Podemos recordar ciertas vulnerabilidades como Heartbleed, una vulnerabilidad en el que algunos medios de comunicación tildaron del fin de Internet, ShellShock, una que tuvo un impacto real sobre Internet y que afecto a diferentes servicios y organizaciones o EternalBlue, una de las ‘wormables’ o ‘gusanables’ más temidas de los últimos años.

Figura 1: Un módulo para detectar el peligroso bug CVE-2019-0708 con Metasploit
{No uses exploits públicos. Troll mode ON}

Estas vulnerabilidades tan populares suelen ser una avalancha en las tecnologías afectadas, y nosotros tratamos algunas de ellas en detalle en nuestro libro de Hacking con Tecnologías Web donde se explica cómo localizarlas en servidores en empresas dentro de un proyecto de Ethical Hacking, y, en el caso de ShellSock y de EternalBlue preparamos un módulo para Metasploit.

Figura 2: Libro de Hacking de Tecnologías Web de 0xWord
donde se explica en detalle Heartbleed o Shellshock

En este año tenemos ya una candidata. El CVE-2019-0708 es una vulnerabilidad de las que llaman mediática, a pesar de no tener un nombre fuerte como las anteriores, por al sistema operativo y servicio que afecta. Según su expediente RDS, Remote Desktop Services, tiene una vulnerabilidad que permite la ejecución de código remoto. Esto puede suceder cuando un atacante no autenticado conecta con el servicio y envía una serie de peticiones que provocan la ejecución de código.

El base score del CVSS es 9.8 en su versión 3.0 y de 10 en la versión 2.0 del CVSS, lo que apunta ael nivel de  criticidad de la vulnerabilidad. Y como esto es lo que se puede leer en el expediente se han disparado todas las alarmas, cómo es lógico.

Las configuraciones o sistemas afectados o que se conocen que están afectados son Microsoft Windows 2008/R2 y Microsoft Windows 7, aunque no se descarta que haya algo más. Algo parecido en su día con Eternalblue. Me quedo con un tuit de mi compañero Sergio de los Santos en el que dice que no hay exploit público, a día de la fecha del propio tuit, pero que Github se estaba llenando de supuestos exploits que eran puro ‘troleo’ o quizá algo peor.

Quise echar un ojo a lo que Sergio de los Santos indicaba, ya que me pareció ver algo por Exploit-db, aparte de los repositorios de Github. Cuando visité Exploit-db no había rastro del CVE-2019-0708. ¿Qué había pasado? Era extraño, pues juraría que había estado publicado un exploit allí.

Al buscar por Google encontré el enlace a Exploit-db que apuntaba al CVE-2019-0708. Al acceder al recurso me encontré el 404 de Exploit-db. Vale, parece que algo había y no está.

Figura 4: Recurso "not found" en Exploit-db

Tirando de la caché de Google pude ver que realmente había algo y que hubo algo. Utilizando la opción “En caché” puedes consultar lo que había entonces y era hora de verlo.

Figura 5: Web de Exploit-DB en Caché de Google

He de decir que al ver el exploit escrito en Python pensé puede que haya algo ya y hayan decidido por precaución hasta que los sistemas se actualicen. Pero fue algo que duró en mi cabeza poco. Recordando el mensaje de Sergio de los Santos pensé puede que hayan subido un exploit que realmente era un "fake".

Figura 6: Inicio del supuesto exploit de CVE-2019-0708

Sea como sea, el inicio del código del exploit es el que se puede ver en la imagen. El comienzo típico de este tipo de códigos. Lo dicho, sea como sea, el exploit público no está, aunque seguramente es cuestión de tiempo que pueda aparecer algo que no sea fake.

Figura 7: Hacking con Metasploit. Advanced Pentesting.

Lo que sí ha aparecido y la gente de Metasploit ha integrado ya en el framework es un módulo para detectar máquinas en una red que son vulnerables a esta vulnerabilidad. El módulo de Metasploit llamado BlueKeep Microsoft Remote Desktop RCE Check ha sido implementado por zerosum0x0 y JaGoTu. El módulo puede encontrarse, primero, en el repositorio de zerosum0x0 y, además, en el repositorio oficial de Metasploit. El módulo está clasificado como auxliary, dentro del apartado de los scanner. La ruta es auxliary/scanner/rdp.

Figura 8: Módulo para Metasploit de descubrimiento de CVE-2019-0708

Utilizando el comando use podemos acceder al módulo comentado anteriormente dentro de una versión de Metasploit actualizada. Mostrando las opciones del módulo se pueden ver los atributos a configurar que, en este caso y como suele ocurrir en el caso de los módulos auxiliary de tipo scanner, son pocos.

Figura 9: Opciones del módulo de descubrimiento

Tras configurar el atributo RHOSTS, el cual puede ser configurado con un rango de direcciones o una red se puede proceder a ejecutar el módulo. Si decidimos utilizar RHOSTS para escanear una red de equipos podríamos poner algo como set RHOSTS 10.0.0.0/24. Si, por el contrario, queremos configurar RHOSTS para solo una máquina debemos ejecutar set RHOSTS [Dirección IP]. Una vez todo está preparado ejecutamos el módulo con el comando run o exploit, es indiferente, ya que uno es el alias del otro.

Figura 10: Ejecución del módulo de descubrimiento

La salida del módulo nos dirá si la máquina o máquinas escaneadas son vulnerables. Como se ve en la imagen anterior, la máquina es vulnerable y debería ser actualizada lo antes posible.

Figura 11: Descubrimiento de máquinas vulnerables al CVE-2019-0708

Para ejemplificar el sencillo proceso de configuración para evaluar la existencia de la vulnerabilidad en una red, os dejamos un video corto explicativo. Si no has actualizado tu sistema Windows es hora de hacerlo y con carácter de urgencia.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.

2 comentarios:

Unknown dijo...


Chema ya lleva algún la vulnerabilidad dando vueltas y aún no han sacado ningún script que explote esa vulnerabilidad, esta raro para eternalblue salió bastante rápido??

Unknown dijo...

Hay varios PoC funcionales que provocan BSOD. Lo que aun no existe es ninguno público que permita ya un RCE. Seguro que alguien ya lo tiene implementado pero no lo ha desvelado para poderlo aprovechar únicamente él. En realidad, el paso que falta a partir del PoC del BSOD es conseguir el tamaño de la egg adecuada para aprovechar el buffer overflow y poder escribir en la posición exacta del stack la primera instrucción de la shellcode.

Entrada destacada

Tu Latch "Hack Your Innovation Contest": Haz un PoC & Hack por 1.000 €

El pasado Telefónica Innovation Day 2024 lanzamos oficialmente el " Tu Latch Hack Your Innovation Contest " en el que repartimos ...

Entradas populares