🔁Port Forwarding dinámico
Port Forwarding dinámico con SSH y SOCKS Tunelling
Port Forwarding en contexto
Port Forwarding es una técnica que nos permite redirigir una solicitud de comunicación de un puerto a otro. El reenvío de puertos utiliza TCP como capa de comunicación principal para proporcionar comunicación interactiva para el puerto reenviado. Sin embargo, se pueden utilizar diferentes protocolos de capa de aplicación, como SSH o incluso SOCKS (capa que no es de aplicación), para encapsular el tráfico reenviado. Esto puede resultar eficaz para eludir los firewalls y utilizar los servicios existentes en su host comprometido para pasar a otras redes.
SSH Local Port Forwarding
Tomemos como ejemplo la imagen de abajo:
Tenemos nuestro host de ataque (10.10.15.5) y un servidor Ubuntu de destino (10.129.15.50), que hemos comprometido. Escanearemos el servidor Ubuntu de destino usando Nmap para buscar puertos abiertos.
Escaneando el objetivo de pivoting
La salida de Nmap muestra que el puerto SSH está abierto. Para acceder al servicio MySQL, podemos ingresar mediante SSH al servidor y acceder a MySQL desde el interior del servidor Ubuntu, o podemos reenviarlo a nuestro puerto localhost 1234 y acceder a él localmente. Una ventaja de acceder a él localmente es que si queremos ejecutar un exploit remoto en el servicio MySQL, no podremos hacerlo sin el reenvío de puertos. Esto se debe a que MySQL está alojado localmente en el servidor Ubuntu en el puerto 3306. Entonces, usaremos el siguiente comando para reenviar nuestro puerto local (1234) a través de SSH al servidor Ubuntu.
Ejecución de Port Forwarding Local
El comando -L le dice al cliente SSH que solicite al servidor SSH que reenvíe todos los datos que enviamos a través del puerto 1234 al servidor Ubuntu localhost:3306. Al hacer esto, deberíamos poder acceder al servicio MySQL localmente en el puerto 1234. Podemos usar Netstat o Nmap para consultar nuestro host local en el puerto 1234 para verificar si el servicio MySQL fue reenviado.
Confirmación de Port Forwarding con Netstat
Confirmación de Port Forwarding con Nmap
De manera similar, si queremos reenviar múltiples puertos desde el servidor Ubuntu a su host local, puede hacerlo incluyendo el local port:server:portargumento en su comando ssh. Por ejemplo, el siguiente comando reenvía el puerto 80 del servidor web Apache al puerto local de su host de ataque en 8080.
Forwarding de múltiples puertos
Configuración para pivotar
Ahora, si escribe ifconfig en el host de Ubuntu, encontrará que este servidor tiene varias NIC:
Uno conectado a nuestro host de ataque (
ens192)Uno comunicándose con otros hosts dentro de una red diferente (
ens224)La interfaz de loopback (
lo).
Buscando oportunidades para pivotar usando ifconfig
A diferencia del escenario anterior donde sabíamos a qué puerto acceder, en nuestro escenario actual no sabemos qué servicios se encuentran al otro lado de la red. Por lo tanto, podemos escanear rangos más pequeños de IP en la red ( 172.16.5.1-200) o en toda la subred ( 172.16.5.0/23). No podemos realizar este análisis directamente desde nuestro host de ataque porque no tiene rutas a la red 172.16.5.0/23. Para hacer esto, tendremos que realizar un Port Forwarding dinámico y pivotar nuestros paquetes de red a través del servidor Ubuntu. Podemos hacer esto iniciando un SOCKS listener en nuestro localhost(host de atacante) y luego configurar SSH para reenviar ese tráfico a través de SSH a la red (172.16.5.0/23) después de conectarnos al host de destino.
Esto se llama SSH tunneling sobre SOCKS proxy. SOCKS significa Socket Secure, un protocolo que ayuda a comunicarse con servidores donde existen restricciones de firewall. A diferencia de la mayoría de los casos en los que iniciaría una conexión para conectarse a un servicio, en el caso de SOCKS, el tráfico inicial lo genera un cliente SOCKS, que se conecta al servidor SOCKS controlado por el usuario que desea acceder a un servicio en el cliente. -lado. Una vez establecida la conexión, el tráfico de la red se puede enrutar a través del servidor SOCKS en nombre del cliente conectado.
Esta técnica se utiliza a menudo para eludir las restricciones impuestas por los cortafuegos y permitir que una entidad externa eluda el cortafuegos y acceda a un servicio dentro del entorno del cortafuegos. Un beneficio más de utilizar el proxy SOCKS para pivotar y reenviar datos es que los proxies SOCKS pueden pivotar mediante la creación de una ruta a un servidor externo desde NAT networks. Los proxies SOCKS son actualmente de dos tipos: SOCKS4y SOCKS5. SOCKS4 no proporciona autenticación ni soporte UDP, mientras que SOCKS5 sí lo proporciona. Tomemos un ejemplo de la imagen a continuación donde tenemos una red NAT de 172.16.5.0/23, a la que no podemos acceder directamente.
En la imagen de arriba, el host del ataque inicia el cliente SSH y solicita al servidor SSH que le permita enviar algunos datos TCP a través del socket ssh. El servidor SSH responde con un reconocimiento y el cliente SSH comienza a escuchar localhost:9050. Cualquier información que envíe aquí se transmitirá a toda la red (172.16.5.0/23) a través de SSH. Podemos usar el siguiente comando para realizar este reenvío de puerto dinámico.
Habilitación de Port Forwarding dinámico con SSH
El argumento -D solicita al servidor SSH que habilite el reenvío de puertos dinámico. Una vez que tengamos esto habilitado, necesitaremos una herramienta que pueda enrutar los paquetes de cualquier herramienta a través del puerto 9050. Esto lo podemos hacer usando la herramienta proxychains, que es capaz de redirigir conexiones TCP a través de servidores proxy TOR, SOCKS y HTTP/HTTPS y también nos permite encadenar múltiples servidores proxy. Al utilizar cadenas de proxy, también podemos ocultar la dirección IP del host solicitante, ya que el host receptor solo verá la IP del host dinámico. Proxychains se utiliza a menudo para obligar a una aplicación a pasar tráfico TCP por servidores proxy alojados como SOCKS4/ SOCKS5, TOR o proxies HTTP/ HTTPS.
Para informar a proxychains que debemos usar el puerto 9050, debemos modificar el archivo de configuración de proxychains ubicado en /etc/proxychains4.conf. Podemos agregar socks4 127.0.0.1 9050a la última línea si aún no está allí.
Comprobando /etc/proxychains4.conf
Ahora, cuando inicie Nmap con proxychains usando el siguiente comando, enrutará todos los paquetes de Nmap al puerto local 9050, donde nuestro cliente SSH está escuchando, lo que reenviará todos los paquetes a través de SSH a la red 172.16.5.0/23.
Usando Nmap con Proxychains
Esta parte de empaquetar todos los datos de Nmap usando proxychains y reenviarlos a un servidor remoto se llama SOCKS tunneling. Una nota más importante para recordar aquí es que solo podemos realizar escaneos completos de conexión TCP sobre proxychains . La razón de esto es que proxychains no puede comprender paquetes parciales. Si envía paquetes parciales, como escaneos de media conexión, arrojará resultados incorrectos. También debemos asegurarnos de que somos conscientes del hecho de que es posible que las comprobaciones host-alive no funcionen en objetivos Windows porque el firewall de Windows Defender bloquea las solicitudes ICMP (pings tradicionales) de forma predeterminada.
Un escaneo de conexión TCP completo sin ping en todo un rango de red llevará mucho tiempo. Entonces, para este módulo, nos centraremos principalmente en escanear hosts individuales o rangos más pequeños de hosts que sabemos que están activos, que en este caso será un host de Windows en 172.16.5.19.
Realizaremos un escaneo remoto del sistema usando el siguiente comando.
Enumeración de host Windows a través de Proxychains
El escaneo de Nmap muestra varios puertos abiertos, uno de los cuales es el puertoRDP(3389). De manera similar al escaneo de Nmap, también podemos pivotar con msfconsole a través de proxychains para realizar escaneos RDP vulnerables usando módulos auxiliares de Metasploit.
Usando Metasploit con Proxychains
También podemos abrir Metasploit usando proxychains y enviar todo el tráfico asociado a través del proxy que hayamos establecido.
Usemos el módulo rdp_scanner auxiliar para verificar si el host en la red interna está escuchando en 3389.
Usando el módulo rdp_scanner
En la parte inferior del resultado anterior, podemos ver el puerto RDP abierto con la versión del sistema operativo Windows.
Dependiendo del nivel de acceso que tengamos a este host durante una evaluación, podemos intentar ejecutar un exploit o iniciar sesión con las credenciales recopiladas. Para este módulo, iniciaremos sesión en el host remoto de Windows a través del túnel SOCKS. Esto se puede hacer usando xfreerdp. El usuario en nuestro caso es victor,y la contraseña espass@123
Usando xfreerdp con Proxychains
El comando xfreerdp requerirá que se acepte un certificado RDP antes de establecer exitosamente la sesión. Tras aceptarlo, deberíamos tener una sesión RDP, pivotando a través del servidor Ubuntu.
Pivoting de RDP exitoso
Caso práctico
Pregunta 1
Ha capturado correctamente las credenciales en un servidor web externo. Conéctese al objetivo y enumere las interfaces de red. ¿Cuántas interfaces de red tiene el servidor web de destino? (Incluida la interfaz loopback)
Vemos que el host tiene 3 interfaces de red: ens192, ens224 y lo
Pregunta 2
Aplica los conceptos que se enseñan en esta sección para pasar a la red interna y usar RDP (credenciales: victor:pass@123) para tomar el control del host Windows en 172.16.5.19. Envía el contenido de Flag.txt ubicado en el escritorio.
Confirmación de port forwarding
Vemos que el port forwarding se ha realizado correctamente, por lo que vamos a conectarnos a RDP con proxychains:
El pivoting es un éxito y conseguimos acceder a la flag mediante RDP!
Última actualización