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.
