Linux.
Cuando el pivote es un sistema de este tipo, existen un buen conjunto de herramientas y utilidades
que cumplen con el propósito de ejecutar movimientos laterales. Por ejemplo, sería posible utilizar
herramientas que probablemente ya se encuentran instaladas en el sistema como es el caso de Socat,
el cliente de OpenSSH o incluso Nmap. También es bastante común encontrar entornos de
desarrollo o interpretes de lenguajes como PHP, Python o Ruby, algo que también puede ser útil a la
hora de desplegar scripts que permitan automatizar labores de descubrimiento y ataque. A
continuación se enseñan algunas alternativas que pueden ser validas para el descubrimiento y
explotación de otros sistemas en el entorno de red.
Pivoting con OpenSSH y ProxyChains.
Es posible que en el objetivo se encuentre activo un servicio OpenSSH, algo que puede ser muy útil
para pivotar a otros sistemas accesibles. Con OpenSSH es posible crear túneles locales, remotos o
dinámicos y solamente es necesario contar con una cuenta valida o clave pública en el sistema
comprometido. La creación de túneles trae varios beneficios, el primero de ellos es que enruta de
forma automática el tráfico sin necesidad de establecer modificar la configuración de rutas en el
sistema. Por otro lado, el tráfico se encuentra encapsulado en la conexión SSH, por lo tanto no será
posible analizar dicho tráfico por parte de un IDS u otras soluciones de seguridad perimetral. Los
túneles locales y remotos tienen un funcionamiento similar en el sentido de que permiten abrir un
puerto en el cliente (túnel local) o en el servidor (túnel remoto) cuyas conexiones entrantes serán
enrutadas a una dirección IP/dominio y puerto que se especifique. La declaración de un túnel SSH
tiene la siguiente sintaxis:
Túnel local:
ssh -L
<CLIENT_INTERFACE>:<LOCAL_PORT>:<DESTINATION_INTERFACE>:<DESTINA
TION_PORT> user@victim
Túnel Remoto:
ssh -R
<CLIENT_INTERFACE>:<LOCAL_PORT>:<DESTINATION_INTERFACE>:<DESTINA
TION_PORT> user@victim
El funcionamiento de ambos mecanismos es equivalente, pero tal como se ha mencionado antes la
diferencia está en que en un túnel local el puerto encargado de enrutar las peticiones a un destino
concreto se abre en el cliente, es decir, en la máquina del atacante y en un túnel remoto el puerto se
abre en el servidor, es decir, en la máquina de la víctima. De esta manera, aunque el atacante no
tenga acceso a una IP que se encuentra en un segmento de red local de la víctima, si el sistema
comprometido tiene una interfaz de red que permite el acceso a dicho segmento el atacante lo
utilizará como un pivote para realizar conexiones “puerto a puerto”. Se trata de un mecanismo
sencillo, directo, limpio y que simplifica enormemente los movimientos laterales y posterior ataque
de sistemas conectados a una red en el interior del objetivo. No obstante, antes de poder crear un
túnel local o remoto correctamente, es necesario conocer el entorno de la víctima, es decir, realizar
el proceso de reconocimiento y descubrir las máquinas que se encuentran activas y sus
correspondientes puertos abiertos. Dado que los túneles con SSH permiten establecer conexiones
“puerto a puerto”, es necesario tener ésta información previamente, descubrir la dirección IP de un
sistema en el segmento de red de área local de la víctima, escanear sus puertos abiertos y
seleccionar uno de ellos para crear el túnel. La siguiente imagen enseña la diferencia entre ambos
puertos con algunas direcciones IP que permitirán ilustrar los conceptos explicados anteriormente.
En la imagen anterior la víctima tiene dos interfaces red con una IP asignada. La IP a la que tiene
acceso el atacante es la “88.123.44.67”. En este ejemplo si se establece un túnel local se abrirá en la
máquina del atacante el puerto 8080 y todas las peticiones entrantes en dicha máquina y puerto,
serán automáticamente enrutadas por OpenSSH a la IP “10.10.1.101” en el puerto “80” gracias a la
conexión que se ha establecido con el servidor y que evidentemente, el pivote puede conectarse a
dicha IP sin ningún problema ya que cuenta con otra interfaz de red que está conectada al segmento
de red “10.10.1.0/24”. Este mismo mecanismo aplica al túnel remoto, pero en ésta ocasión el puerto
que se abre es el “6789” en la máquina comprometida y todas las peticiones entrantes por dicho
puerto serán enrutadas a la IP “10.10.1.110” en el puerto “445”. Como se puede apreciar no ha sido
necesario manipular rutas o ningún tipo de configuración de red en la víctima, la implementación de
OpenSSH se encarga de realizar estas operaciones de forma transparente.
Aunque es un buen mecanismo para pivotar, si se desea atacar a múltiples puertos de una máquina
en el objetivo será necesario crear un túnel por puerto, lo que no es práctico. Por ese motivo
también es posible crear túneles dinámicos. Un túnel dinámico hace que el pivote funcione como un
proxy, es decir, que permite enrutar todas las peticiones entrantes por un puerto concreto a cualquier
<IP>:<PUERTO> siempre y cuando sea accesible desde el servidor SSH (es decir, el pivote). La
sintaxis para abrir un túnel dinámico es más simple y se indica con la opción “-D”
Túnel SSH dinámico.
ssh -D <CLIENT_INTERFACE>:<LOCAL_PORT>user@victim
El puerto especificado se abrirá en el cliente, es decir, en la máquina del atacante y se puede utilizar
para acceder a cualquiera de las rutas que se encuentren mapeadas en la víctima, por ejemplo, para
conectar con cualquiera de los sistemas que se encuentran en redes locales que son inaccesibles para
el atacante de forma directa.
En la imagen anterior la víctima comprometida tiene la IP “192.168.1.94” la cual es accesible por
parte del atacante, sin embargo como se puede ver al listar las interfaces de red, existe otra IP en esa
máquina que apunta a un segmento de red interno la cual es la “10.10.1.101” y que no es accesible
por parte del atacante. Dicho lo anterior, la siguiente imagen refleja cómo se puede crear un túnel
dinámico en donde se abre el puerto “8001” en la máquina del atacante y el cual podrá ser utilizado
como proxy para acceder a cualquiera de las rutas disponibles en el servidor, incluyendo aquellas
que apunten al segmento “10.10.1.0/24”.
Con ésto ya es suficiente para comenzar a realizar movimientos laterales contra la red interna del
objetivo, llevando a cabo el proceso de descubrimiento de otros sistemas disponibles en la red con
herramientas como Nmap. Sin embargo, para utilizar este túnel de una forma más simple se puede
especificar en el fichero de configuración principal de ProxyChains.
Se trata de una herramienta en la que todos los comandos ejecutados que requieran una conexión a
un sistema externo, deben pasar primero por uno o varios servidores proxy que se encuentran
definidos en el fichero de configuración maestro, el cual por defecto se encuentra ubicado en
“/etc/proxychains.conf”. Para instalar esta herramienta, basta simplemente con ejecutar el comando
“apt install proxychains” en sistemas basados en Debian o “yum install proxychains” en los
basados en Red Hat. En el fichero de configuración solamente sería necesario incluir el siguiente
contenido.
[ProxyList]
socks5 127.0.0.1 8001
En cada línea que se encuentra en la sección [ProxyList] se puede declarar un proxy, el cual será
utilizado por utilizado por proxychains para enrutar la petición. Por defecto, el orden de los
servidores proxy que se indique en dicho listado es importante, ya que se seguirá de forma estricta.
Esto es conveniente recordarlo aunque en este ejemplo el listado solamente tendrá un servidor
proxy que es el que apunta al túnel dinámico creado anteriormente en el puerto “8001”.
Ahora, sería posible utilizar ProxyChains, el túnel dinámico con SSH y Nmap para realizar el
descubrimiento de sistemas activos en el segmento de red local en el que se encuentra el sistema
comprometido.
La imagen anterior demuestra que funciona correctamente, sin embargo la salida producida por
nmap puede producir confusión. En primer lugar, si se observa atentamente, solamente las
máquinas en el “10.10.1.101” y “10.10.1.102” han contestado correctamente al sondeo con Nmap,
en las trazas se puede ver claramente que no hay conectividad con las otras IP del rango indicado en
puerto 80 y luego, en los resultados aparece que todas las IPs en el rango introducido se encuentran
activas, lo cual es claramente un error. Ahora bien, probablemente el lector se preguntará ¿por qué
no se ha realizado un Ping Scan si es lo que se ha indicado con la opción “-sP”?. Se debe al
funcionamiento de Nmap. Cuando se utiliza un proxy, nmap tiene algunas restricciones y solamente
puede utilizar la primitiva “CONNECT”, la cual solamente se puede utilizar en conexiones TCP y
un “ping” utiliza protocolo ICMP. Por esta razón el comportamiento de nmap con un servidor proxy
socks puede ser confuso o incluso hacer pensar que hay algo que se ha configurado
incorrectamente, pero en realidad este es el motivo. Al margen de esto, se puede realizar un escaneo
TCP contra cualquiera de los objetivos descubiertos en el segmento de red local de la máquina
comprometida o incluso realizar ataques contra dichos sistemas.
La configuración indicada hasta ahora de ProxyChains y un túnel SSH dinámico es aplicable a
cualquier otra herramienta de hacking, solamente es necesario ejecutarla con el comando
“proxychains” tal como se ha visto con Nmap.
Pivoting partiendo de una sesión en Metasploit Framework.
Metasploit Framework también cuenta con un módulo para el establecimiento de un proxy socks
que permitirá que una sesión concreta se puedan utilizar como pivote por parte de otras
herramientas en el entorno del atacante, algo muy similar a lo que se ha explicado previamente con
ProxyChains y un túnel SSH. En primer lugar es necesario tener una sesión en la máquina que
actuará como pivote. Si dicha sesión es del tipo “shell” se puede intentar actualizar a una versión
meterpreter con el comando “sessions -u <session_id>”. La sesión se utilizará para crear una nueva
ruta en entorno de msfconsole gracias al comando “route” el cual permite gestionar las rutas de red
que se encontrarán habilitadas en el framework. Una vez creada dicha ruta será posible utilizar un
módulo apropiado, como por ejemplo “auxiliary/server/socks5” y a continuación utilizarlo por
medio de ProxyChains o cualquier otra herramienta.
En la imagen anterior se puede ver la configuración que se tendría que aplicar. Hay que tener en
cuenta que el comando “route” es el que realmente permite que el servidor proxy socks pueda
funcionar correctamente. Dicho comando se encarga de indicar al entorno de msfconsole que las
peticiones cuyo destino sea cualquier IP del rango “10.10.1.0/24” serán gestionadas por la sesión
especificada. A continuación, se puede trabajar desde otra terminal y editar nuevamente el fichero
de configuración de ProxyChains, sin embargo en esta ocasión se ha iniciado un servidor proxy
socks5 en el puerto “9090”, estos detalles se deben indicar en la sección [ProxyList] cuyo contenido
ahora tendrá lo siguiente:
[ProxyList]
socks5 127.0.0.1 9090
Ahora se puede utilizar proxychains tal como se ha visto anteriormente.
Se puede ver claramente en la cadena de peticiones se está utilizando servidor proxy que se ha
iniciado con Metasploit Framework en el puerto “9090”. Partiendo de la ruta definida en el entorno
de msfconsole se pueden establecer conexiones a una máquina que se encuentra disponible en el
segmento de red local del pivote, inaccesible de forma directa para el atacante.
Pivoting utilizando socat.
Socat es una herramienta muy versatil que cuenta con multitud de opciones para establecer
conexiones. Con el objetivo de aplicar técnicas de pivoting, se podría instalar socat en el sistema
comprometido si no se encuentra instalado y posteriormente, crear un “forwarder” que podrá
enrutar el tráfico a otro punto en la red del pivote. Esto es similar a lo que se ha visto previamente
con el comando “route” en msfconsole o los túneles SSH, sin embargo no siempre es posible
utilizar SSH o tener una sesión de Metasploit Framework en el objetivo y resulta conveniente
conocer y aplicar otros mecanismos que permitan obtener los mismos resultados.
Socat cuenta con las opciones “TCP4-LISTEN” y “TCP4” para abrir un puerto en el sistema y
conectarse a un socket concreto respectivamente. Se trata de opciones que al combinarlas dan como
resultado un mecanismo simple y estable para redireccionar todas las peticiones entrantes por un
puerto determinado a otro punto en la red. Por ejemplo:
socat TCP4-LISTEN:8080,fork,reuseaddr TCP4:10.10.1.102:80
Si éste comando se ejecuta en el sistema comprometido, se abrirá el puerto 8080 en dicho sistema y
todas las conexiones entrantes serán automáticamente redireccionadas a la IP y puerto
“10.10.1.102:80”. Asumiendo que el atacante no puede conectarse de forma directa a la IP
“10.10.1.102” este sencillo comando permitirá utilizar el pivote para establecer conexiones directas
a una red local ubicada en el objetivo.
Como se puede apreciar en la imagen, en el sistema que actúa como pivote se abre el puerto 1337 y
cualquier petición entrante en dicho puerto, se redirecciona a “10.10.1.102:80” de tal manera que
desde el sistema del atacante, solamente hace falta realizar las peticiones contra el puerto 1337 en la
máquina comprometida (pivote) y realizar el proceso completo de recolección de información,
explotación y post-explotación.
Pivoting utilizando ncat.
Ncat es una herramienta basada en Netcat que ha sido desarrollada para el proyecto de Nmap, pero
con mejoras sustanciales con respecto al Netcat tradicional. Es capaz de utilizar tanto TCP como
UDP para la transmisión de información y permite el establecimiento de servidores proxy HTTP.
Dadas sus características se convierte en una alternativa perfectamente valida a la hora de pivotar al
interior de una red interna. El siguiente comando permitirá levantar un proxy HTTP utilizando Ncat.
Si se ejecuta en el pivote, permitirá enrutar de forma transparente las peticiones hacia un destino
arbitrario al interior de la red del pivote. Nuevamente, se puede utilizar proxychains para indicar la
ubicación concreta en la que se encuentra en ejecución dicho servidor proxy.
En la imagen se puede observar cómo se realizan las peticiones por medio del proxy HTTP de
forma transparente, no hace falta establecer ningún tipo de regla de enrutamiento o configuración
especial, el proxy levantado con ncat se encarga de realizar todo el trabajo.
Otras soluciones.
Existen otras alternativas para el establecimiento de servidores proxy o herramientas de
enrutamiento transparente (forwarders) sin embargo en muy raras ocasiones se encontrarán
instaladas en el sistema objetivo. A continuación se listan algunas de estas herramientas para que
sirvan como referencia en el caso de que se quiera probarlas.
3proxy: https://github.com/z3APA3A/3proxy
tinyproxy: https://github.com/tinyproxy/tinyproxy
ssf: https://github.com/securesocketfunneling/ssf
regeorg: https://github.com/sensepost/reGeorg
rinetd http://www.rinetd.com/
