4.3.4.2. Ejemplos: payload shell bind en Internet
A continuación se va a mostrar un ejemplo de explotación con un payload para obtener una shell de tipo bind, tratando de mostrar los inconvenientes de este tipo de shells en un entorno de laboratorio en Internet. Para ello se ha usado dos redes de diferentes proveedores conectadas a través de Internet, teniendo en una de ellas el target y en el otro Kali Linux con Metasploit. Las IP públicas de las redes empleadas son las siguientes (se han enmascarado ligeramente por razones obvias), obtenidas a través del comando siguiente (tanto en CMD Windows como en consola de Linux):
nslookup myip.opendns.com resolver1.opendns.com
Con el fin de comprender los conceptos básicos de forma clara y agilizar la práctica, se ha empleado la versión Windows Server 2008 R2 de Metasploitable 3 para el target, siendo el objetivo el servicio SMB para esta versión de Windows en el puerto 445 que es vulnerable a EternalBlue. El puerto que se va a emplear para el parámetro RPORT es el que suele venir por defecto en Metasploit el 4444.
Por las características de la NAT y por el funcionamiento de las shell bind explicadas en el punto anterior (la conexión se establece en dirección de Metasploit al target), ha sido necesario habilitar portforwarding en ambos puertos en la red del target, cuya IP privada es 192.168.1.51. La red del target utiliza un router estándar y la forma de hacer esta técnica puede variar en función de la marca del router. Aquí ya aparece el primer inconveniente serio, pues si bien es lógico que un servicio público de un host esté expuesto, será muy poco probable que un administrador tenga habilitado un puerto sin uso que enlace con algún host. Sin duda, es un ejemplo forzado pero hay que examinar las realidades:
Ahora sí, ya desde Metasploit se puede proceder a efectuar la explotación del servicio SMB con EternalBlue. Aunque se ha efectuado de forma rápida, se ha empleado un payload de tipo stageless seteando el target adecuado (Windows Server 2008 R2). Como la práctica se está efectuando en Internet, para RHOSTS se va a indicar la IP pública de la red donde se aloja el servicio. En un principio, todo parece que va bien, pues el primer paso que hace EternalBlue es comprobar si el servicio es vulnerable:
msf > use exploit/windows/smb/ms17_010_eternalblue
msf > set payload payload/windows/x64/shell_bind_tcp
msf > set target 3
msf > set RHOSTS XXX.XXX.109.30
A partir de aquí pueden ocurrir diferentes cosas:
1. Blue Screen of Death:
- Indica un error fatal en el sistema. Durante los eventos del malware Wannacry que infectó una multitud de redes y hosts de todo el mundo usando precisamente EternalBlue como vector de ataque, en algunos host se producía esta incidencia que en parte también salvaba al sistema. Se ha resuelto añadiendo más CPU y RAM dedicada a la máquina virtual, sin ahondar en el motivo exacto.
2. Bloqueo de Firewall:
- Como ya se ha indicado en la introducción a los tipos de payload tipo shell (punto anterior), es habitual que sin los permisos adecuados un proceso del sistema sea capaz de abrir un puerto y permitir el tráfico de red (4444 para la shell). Además, el servicio podría estar restringido mediante un bloqueo de Firewall (esto también podría pasar para una shell reverse). En este caso, el sistema es incapaz de ejecutar la carga útil y aunque el proceso de explotación funciona, no se puede generar la shell.
- Para resolver esta situación se ha tenido que acceder al target de forma remota y habilitar una regla de Firewall para los puertos empleados en el proceso de explotación y obtención de la shell como se indica en pantalla:
Como en el portforwarding para el puerto 4444 en el target que se ha tenido que habilitar de forma expresa (ver arriba), en esta ocasión también se tiene que hacer un supuesto muy improbable que es que el sistema del target permita habilitar un puerto para obtener la shell. Es otro de los inconvenientes claros de las shell bind en Internet. En todo caso tras realizar los ajustes comentados, finalmente se obtiene la shell (la dirección 192.168.66.212 es la dirección privada de la red para el host de Kali Linux) empleando para ello el puerto 4444 en el target:
En conclusión, para un montante de ataque informático planteado de la forma clásica empleando Metasploit (escaneo de redes y servicios, hallar vulnerabilidades, lanzar el exploit…) los payloads de tipo shell bind resultan poco eficientes. No obstante, pueden resultar buenos en combinación con otras técnicas que tampoco se detallarán aquí por qué no es objetivo. Puede verse la conexión establecida desde el lado del target con la consola o Powershell, mostrándose la IP de la red de Kali:
netstat -a -p
A pesar de todo, sí es posible usar un payload shell bind en combinación con algún sistema que permita ocultar la IP empleada por Kali Linux, ya sea torificando la red, emplear un proxy, etc. En el bloque de ocultación se explicarán las diferentes opciones para el framework de Metasploit. En todo caso, para una demostración rápida, se ha empleado proxychains con Tor, de modo que las operaciones de red generadas por Metasploit queden torificadas. Se emplea proxychains con el inicio de msfconsole. Como se indica en pantalla, genera diferentes avisos:
proxychains msfconsole
El resultado es satisfactorio y se obtiene la shell, aunque como es de esperar el proceso será más lento. También como se indica en los resultados la conexión mostrada en Metasploit no se está efectuando directamente contra el target, sino con la medicación del protocolo SOCKS en el puerto 9050 de Kali Linux:
Ya finalmente para terminar esta muestra se vuelve a mostrar el resultado de netstat en el target. Como es de esperar, en la conexión establecida se muestra una IP pública que no se corresponde con la de la red empleada en Kali Linux, sino la obtenida a través de la red Tor.
