Una vuelta de tuerca

En un lugar de España de cuyo nombre no quiero acordarme, se encontraron hace tiempo varias de máquinas con sistema operativo Windows XP que no tenían ningún puerto abierto, salvo el puerto 445/TCP (protocolo SMB), y que era vulnerables a MS17-010 (EternalBlue/DoblePulsar).

De estas máquinas se quisieron obtener los hashes de los usuarios dados de alta ... pero como es obvio, las imágenes no se corresponde con el entorno donde realmente se llevó a cabo las acciones, sino del entorno de pruebas donde se gestaron las pruebas antes del asalto final.

ENTORNO DE PRUEBAS

Las pruebas se llevaron a cabo entre dos máquinas virtuales:

1.- Máquina Kali Linux, con direccionamiento IP: 172.21.5.246. 

                Máquina que lanzaría el exploit.

2.- Máquina Windows XP de 32 bits, con direccionamiento IP: 172.21.5.230

                Máquina virtual que simula una de las máquinas encontradas en la red de no sé sabe                                      dónde.

DESCUBRIMIENTO DE LA VULNERABILIDAD

Se confirmo mediante dos maneras:

1.- Mediante el archivo .nse:  smb-vuln-ms17-010.nse, utilizado por la herramienta: Nmap.

Confirmación de la presencia de la vulnerabilidad MS17-010 mediante la herramienta: Nmap

  

2.- Mediante el módulo de escaneo de la vulnerabilidad residente en la herramienta: metasploit.

Confirmación de la presencia de la vulnerabilidad MS17-010 mediante la herramienta: metasploit

EXPLOTACIÓN DE LA VULNERABILIDAD

Para la explotación, no se utilizo el módulo de metasploit ya que sólo está probado en sistemas Windows 7 y Windows Server 2008 R2.

Información sobre el módulo de metasploit que permite aprovecharnos del MS17-010

Se utilizo uno de los desarrollos en python ubicado en Github, que ha sido testeado en múltiples entornos, entre ellos, el Windows XP.

Sistemas en lo que el script en python, descargado de Github,  ha sido testeado

Si nos fijamos en el código del script: zzz_exploit.py, veremos que dicho exploit deja en la unidad C$ un archivo de 0 bytes, llamado: pwned.txt, como muestra de que la explotación ha sido realizada.

Función que crea remotamente el archivo: pwned.txt en la unidad C$

Pero qué ocurriría si se modifica el código para subir un archivo que NO fuera una shell reversa (no se quiere hacer mucho ruido en el sistema objetivo, ni tener que lidiar contra un AV), si no, un archivo con extensión: scf, conveniente modificado para que nos envíe los hashes de los usuarios del sistema.

Función modificada que sube el archivo: PoC.scf, a la unidad C$

Archivo con extensión: .scf. En dicho archivo se indica que vaya a buscar el icono del fichero a la ubicación dada y que coincide con la máquina que controlamos.

Tras la ejecución de dicho archivo: scf, que se realizará de manera transparente para el usuario de la máquina objetivo, además de que su ejecución se llevará a cabo de manera automática

-según sea grabado en el disco duro, el sistema operativo ejecutará el contenido del archivo-, provocará el envío de los hashes de los usuarios dados de alta en el sistema, tal y como ya se había comentado en la siguiente entrada de este blog.

Ejecución del exploit

Archivo obtenido en la máquina objetivo en la raíz de la unidad C

Hashes que se envían a la máquina que controlamos.

¿A partir de aquí? ... Imaginación.

CONTRAMEDIDAS

Obviamente, y como ya  dijeron multitud de personas, dejar de utilizar el protocolo SMB v1 y pasarse a SMB v2, en cualquiera de los sistemas que se utilicen. Y si el sistema no tiene una actualización para ello, cambia el sistema operativo o no trabajes con el protocolo SMB.

Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia.