Introducción
En las pruebas de penetración y el red teaming, a menudo se compromete un servidor expuesto al público y se descubre que tiene acceso a una red interna a la que no se puede llegar directamente desde la máquina de ataque. Para atacar estos sistemas internos, necesitas una forma de enrutar tu tráfico a través del servidor comprometido. Esta técnica se conoce como "pivoting" (pivoteo).
El pivoting consiste realmente en cambiar el punto de vista. Ya no estás realizando pruebas únicamente desde la posición de red de tu máquina original; estás utilizando un host comprometido como un nuevo punto de observación y acceso.
Una de las técnicas de pivoteo más potentes y comunes consiste en utilizar el reenvío dinámico de puertos SSH para crear un proxy SOCKS, combinado con una herramienta llamada proxychains. Esta combinación te permite enrutar casi cualquier herramienta de red externa (como Nmap, Nikto o Metasploit) de forma transparente a través del host comprometido.
En este laboratorio, simularemos un escenario en el que tienes acceso SSH a un host pivotante dedicado que se ejecuta en un contenedor Docker. Un segundo contenedor en la misma red privada de Docker aloja un servicio web interno oculto. El servicio no está expuesto directamente a la máquina virtual de LabEx, por lo que debes acceder a él a través del host pivotante SSH. Aprenderás a configurar un reenvío dinámico de puertos SSH, configurar proxychains y utilizarlo para acceder a ese servicio oculto a través del host pivotante.
Configurar el reenvío dinámico de puertos SSH (-D)
En este paso, establecerás una conexión SSH con el host pivotante en contenedor y crearás un proxy SOCKS local.
El reenvío dinámico de puertos te permite especificar un puerto local en tu máquina de ataque. El cliente SSH escuchará en este puerto y, cada vez que una aplicación se conecte a él, la conexión se reenviará a través del canal SSH seguro hacia el servidor SSH. El servidor SSH actúa entonces como un proxy, reenviando el tráfico a su destino final.
Esto es más flexible que el reenvío de un solo puerto, ya que el proxy SOCKS puede transportar muchas solicitudes de destino diferentes a través de un único túnel.
Para configurar esto, utilizamos la bandera -D en nuestro comando SSH. También utilizaremos algunas otras banderas para que la conexión se ejecute sin problemas en segundo plano.
La configuración creó una clave privada para ti en ~/project/pivot_key y expuso el servicio SSH del host pivotante en el puerto local 2222. Ejecuta el siguiente comando en tu terminal para crear un proxy SOCKS en el puerto local 9050:
ssh -f -D 9050 -q -C -N \
-o StrictHostKeyChecking=no \
-o UserKnownHostsFile=/dev/null \
-i ~/project/pivot_key -p 2222 pivot@127.0.0.1
Analicemos las banderas utilizadas en este comando. La bandera -D 9050 especifica el reenvío dinámico de puertos y establece el puerto de escucha local en 9050. La bandera -q activa el modo silencioso, que suprime los mensajes de advertencia y diagnóstico. La bandera -C solicita la compresión de todos los datos, lo que puede acelerar la conexión. La bandera -N indica a SSH que no ejecute un comando remoto, lo que resulta útil cuando solo estás reenviando puertos. La bandera -f envía el cliente SSH a segundo plano después de la autenticación, para que puedas seguir utilizando la misma sesión de terminal. Las opciones -o StrictHostKeyChecking=no y -o UserKnownHostsFile=/dev/null evitan que las solicitudes de clave de host de la primera conexión interrumpan el flujo de trabajo del laboratorio. La bandera -i le indica a SSH qué clave privada utilizar, y -p 2222 le indica que se conecte al contenedor del host pivotante en lugar del servicio SSH predeterminado de la máquina virtual de LabEx.
Después de ejecutar el comando, puedes verificar que el puerto esté abierto y escuchando utilizando el comando ss, que vuelca las estadísticas de los sockets.
ss -tuln | grep 9050
Deberías ver una salida similar a esta, que indica que tu máquina ahora está escuchando en el puerto 9050:
tcp LISTEN 0 128 127.0.0.1:9050 0.0.0.0:*
tcp LISTEN 0 128 [::1]:9050 [::]:*
Configurar Proxychains (/etc/proxychains.conf)
En este paso, inspeccionarás la configuración de proxychains.
Aunque ahora tienes un proxy SOCKS ejecutándose en el puerto 9050, la mayoría de las herramientas de línea de comandos (como Nmap) no saben de forma nativa cómo enrutar su tráfico a través de un proxy SOCKS. Aquí es donde entra en juego proxychains. Es una herramienta que obliga a cualquier conexión TCP realizada por una aplicación determinada a pasar a través de un proxy.
En la práctica, proxychains es lo que extiende el túnel desde una prueba manual hacia un flujo de trabajo operativo reutilizable a través de muchas herramientas.
El archivo de configuración de proxychains se encuentra en /etc/proxychains4.conf. Para este laboratorio, la entrada del proxy debe apuntar a un proxy SOCKS5 en 127.0.0.1 puerto 9050, lo cual coincide con el reenvío dinámico de puertos SSH que acabamos de crear.
Veamos la parte inferior del archivo de configuración para confirmar esta configuración. Utiliza el comando tail para imprimir las últimas 10 líneas del archivo:
tail -n 10 /etc/proxychains4.conf
Deberías ver una salida similar a la siguiente:
[ProxyList]
## add proxy here ...
## meanwile
## defaults set to "tor"
socks5 127.0.0.1 9050
La sección [ProxyList] es donde se definen los proxies. La línea socks5 127.0.0.1 9050 le indica a proxychains que enrute el tráfico a través del puerto local 9050. Dado que nuestro comando SSH -D creó un proxy exactamente en este puerto, no se necesita ninguna configuración adicional después de actualizar el tipo de protocolo.
Si alguna vez necesitas utilizar un puerto diferente o un tipo de proxy distinto, editarías este archivo utilizando un editor de texto como nano.
Probar el proxy SOCKS
En este paso, probarás si tu configuración de proxy funciona correctamente accediendo al servicio web interno oculto.
Recuerda que hay un servicio web ejecutándose en un contenedor interno oculto en 172.30.0.20:80. En un escenario del mundo real, esto representa un sitio de intranet interno al que no se puede acceder directamente desde Internet.
Para utilizar proxychains, simplemente antepones el comando proxychains4 a la herramienta que deseas ejecutar. Utilicemos curl para obtener la página web.
Ejecuta el siguiente comando:
proxychains4 curl http://172.30.0.20
Cuando ejecutas esto, proxychains intercepta la solicitud de red realizada por curl y la tuneliza a través del proxy SOCKS SSH en el puerto 9050. El host pivotante realiza entonces la solicitud a 172.30.0.20:80 en la red Docker interna y devuelve el resultado.
Deberías ver una salida similar a esta:
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.14
[proxychains] Strict chain ... 127.0.0.1:9050 ... 172.30.0.20:80 ... OK
Secret Internal Data: You have successfully pivoted
El mensaje OK indica que la conexión del proxy fue exitosa, y la última línea muestra los datos secretos del servidor web interno.
Ejecutar herramientas externas a través del pivote
En este paso final, utilizarás una herramienta externa más avanzada, Nmap, para escanear la red interna a través de tu pivote establecido.
Al utilizar proxychains con Nmap, existen limitaciones técnicas importantes que debes comprender. Los proxies SOCKS solo admiten conexiones TCP completas. No admiten ICMP (ping) ni escaneos SYN semiabiertos (que Nmap utiliza de forma predeterminada cuando se ejecuta con sudo).
Por lo tanto, al ejecutar Nmap a través de proxychains, debes obligarlo a utilizar un escaneo TCP Connect completo y deshabilitar el descubrimiento por ping.
Ejecuta el siguiente comando de Nmap para escanear el servicio web interno en el puerto 80:
proxychains4 nmap -sT -Pn -p 80 172.30.0.20
Analicemos las banderas de Nmap utilizadas aquí. La bandera -sT fuerza un escaneo TCP Connect, lo cual es obligatorio porque los proxies SOCKS no pueden manejar paquetes sin procesar o escaneos SYN. La bandera -Pn deshabilita el descubrimiento de hosts (ping); dado que los proxies SOCKS no pueden enrutar solicitudes de eco ICMP, Nmap asumiría incorrectamente que el host está inactivo si se omitiera esta bandera. Finalmente, la bandera -p 80 especifica el puerto exacto a escanear.
Verás que proxychains registra los intentos de conexión, seguidos de los resultados del escaneo de Nmap:
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.14
Starting Nmap 7.91 ( https://nmap.org ) at 2024-01-01 12:00 UTC
[proxychains] Strict chain ... 127.0.0.1:9050 ... 172.30.0.20:80 ... OK
Nmap scan report for 172.30.0.20
Host is up (0.0020s latency).
PORT STATE SERVICE
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds
Esto confirma que puedes enrutar con éxito herramientas de seguridad complejas a través de un host comprometido para interactuar con segmentos de red internos.
Resumen
¡Felicidades! Has completado con éxito el laboratorio de Reenvío dinámico de puertos con Proxychains.
En este laboratorio, aprendiste a crear un proxy SOCKS local utilizando el reenvío dinámico de puertos SSH (-D). También aprendiste a comprender e inspeccionar la configuración de proxychains. Además, enrutaste con éxito solicitudes HTTP básicas a través del proxy para acceder a servicios internos ocultos. Finalmente, adaptaste herramientas de escaneo avanzadas como Nmap para que funcionen a través de un proxy SOCKS utilizando escaneos TCP Connect (-sT) y deshabilitando el descubrimiento por ping (-Pn).
Estas técnicas de pivoteo son habilidades esenciales para navegar por entornos de red complejos durante pruebas de penetración y evaluaciones de seguridad.
