Wafw00f identificar y detectar Firewall de Aplicaciones Web
Wafw00f identificar y detectar Firewall de Aplicaciones Web
Wafw00f es una herramienta de reconocimiento escrita en Python que viene preinstalada en Kali Linux. Su objetivo principal es identificar y detectar Firewall de Aplicaciones Web (WAF) en un sitio web objetivo.
¿Cómo funciona?
Envia peticiones HTTP normales y analiza las respuestas (encabezados, cookies, código de estado).
Si no detecta nada a simple vista, envía peticiones con vectores de ataque simulados (como pequeñas inyecciones XSS o SQLi) para provocar que el WAF reaccione y revele su firma.
Compara las respuestas con su base de datos de firmas (detecta más de 100 WAFs populares como Cloudflare, Akamai, AWS WAF, Imperva, ModSecurity, etc.).
Comandos básicos y uso
1. Instalación o actualización
En Kali Linux ya viene instalada por defecto, pero si necesitas actualizarla o instalarla manualmente:
sudo apt update && sudo apt install wafw00f
2. Escaneo básico
Para analizar un sitio web específico:
wafw00f https://ejemplo.com
3. Ver todos los WAFs soportados
Si quieres consultar qué cortafuegos es capaz de detectar la herramienta:
wafw00f -l
4. Probar todos los métodos de detección (-a)
Por defecto, wafw00f se detiene en cuanto encuentra el primer WAF. Con la bandera -a analiza de forma exhaustiva para encontrar todas las firmas posibles:
wafw00f -a https://ejemplo.com
5. Escaneo a través de un proxy (-p)
Útil si necesitas canalizar el tráfico a través de Burp Suite o TOR:
wafw00f https://ejemplo.com -p http://127.0.0.1:8080
Opciones y parámetros útiles
| Parámetro | Descripción |
-v, -vv | Activa el modo detallado (verbose) para ver qué peticiones se están enviando. |
-i <archivo> | Lee una lista de objetivos desde un archivo de texto. |
-o <archivo> | Guarda los resultados en un archivo (soporta formatos TXT, JSON, CSV). |
-H <header> | Añade encabezados HTTP personalizados (ej. Cookies de sesión o User-Agent). |
La evasión de un WAF (Web Application Firewall) se basa en explotar las diferencias entre cómo interpreta la petición el WAF y cómo la interpreta el servidor de aplicaciones final (backend). Si logras estructurar un payload para que el WAF lo considere inofensivo pero el backend lo ejecute, habrás conseguido sobrepasarlo.
1. Descubrimiento de la IP de Origen (Origin IP Bypass)
Es la técnica más directa y efectiva cuando el WAF actúa como un Reverse Proxy (como Cloudflare, Imperva o Akamai).
Si logras identificar la dirección IP real del servidor, puedes enviar las peticiones directamente a ella, dejando al WAF fuera de la ecuación.
Métodos para encontrar la IP de origen:
Registros Históricos de DNS: Consultar servicios como SecurityTrails o Censys para ver la IP del dominio antes de activar el WAF.
Archivos SSL/TLS: Buscar el certificado TLS del dominio en repositorios como Crt.sh o mediante escaneos globales (Shodan).
Tráfico Saliente (Out-of-Band): Forzar al servidor backend a realizar una petición externa (vía SSRF, envio de correos desde la web, avatares por URL) y registrar la IP desde la que responde.
2. Ofuscación y Codificación de Payloads (Encoding & Obfuscation)
Los WAFs basan gran parte de su detección en coincidencia de patrones (expresiones regulares). Alterar la sintaxis del payload sin romper la ejecución en la base de datos o intérprete permite esquivar las reglas.
En Inyecciones SQL (SQLi):
Comentarios intercalados: Utilizar comentarios para romper palabras clave retenidas por el WAF.
SQLUNI/**/ON SE/**/LECT username, password FR/**/OM usersUso de espacios alternativos: Sustituir espacios por caracteres de control o saltos de línea (
%0A,%0D,%09,+).Sustitución de funciones/operadores: Usar alternativas que realizan la misma función lógica.
En lugar de
AND 1=1$\rightarrow$AND 2>1o&& 1En lugar de
HEX()$\rightarrow$BIN_TO_UUID()o codificaciones en hexadecimal (0x...).
En Cross-Site Scripting (XSS):
Variaciones de mayúsculas/minúsculas y etiquetas raras:
HTML<sCrIpt>alert(1)</sCrIpt> <svg/onload=alert(1)> <body/onload=alert(1)>Codificación HTML / Unicode / Hexadecimal:
HTML<a href="javascript:alert(1)">Click</a>
3. Contaminación de Parámetros HTTP (HTTP Parameter Pollution - HPP)
Esta técnica explota cómo los diferentes entornos web manejan la presencia de múltiples parámetros con el mismo nombre en una sola petición (GET /index.php?id=1&id=2).
| Tecnología Backend | Resultado interpretado para id en ?id=1&id=2 |
| PHP / Apache | Toma el último valor (2). |
| ASP.NET / IIS | Concatena los valores con coma (1,2). |
| Node.js (Express) | Crea un array con los valores (['1', '2']). |
Ejemplo de evasión:
Si envías
?id=SELECT&id=1,2,3 FROM users, un WAF basado en PHP solo analizaría la segunda parte (1,2,3 FROM users) considerándolo seguro, mientras que un entorno ASP.NET recibiríaSELECT,1,2,3 FROM users, ejecutando la consulta.
4. Manipulación del Protocolo y Encabezados HTTP
Consiste en alterar la estructura de la petición HTTP para confundir a los analizadores sintácticos del WAF.
Caso de Encabezados (Header Oversize): Enviar encabezados HTTP extremadamente largos o un número masivo de ellos para superar el límite de búfer de inspección del WAF.
Content-Type inusuales: En peticiones
POST, cambiar la codificación del cuerpo:De
application/x-www-form-urlencodedamultipart/form-dataoapplication/json.
Uso de comodines en comandos (RCE): Si logras ejecución remota de comandos, puedes evadir filtros de palabras clave usando comodines (
*,?) en Linux:Bash/bin/cat /etc/passwd # Bloqueado por WAF /b?n/c?t /et?/pass* # Evade la regla
5. Abuso de Desincronización HTTP (HTTP Request Smuggling)
Se produce en arquitecturas donde hay un servidor frontal (WAF / Reverse Proxy) y un servidor backend comunicándose mediante peticiones HTTP/1.1 encadenadas.
Si ambos servidores discrepan en cómo determinar el final de una petición HTTP usando los encabezados Content-Length y Transfer-Encoding: chunked, el atacante puede "contrabandear" una segunda petición oculta dentro del cuerpo de la primera. El WAF solo analiza la petición externa visible, dejando pasar el payload malicioso interno hacia el backend.
Resumen de Buenas Prácticas para Pentesting
⚠️ Nota metodológica: Al realizar pruebas de evasión de WAF, es indispensable contar con autorización explícita en el alcance (Scope). Iniciar con un enfoque de caja blanca o con acceso a la IP interna agiliza las pruebas de vulnerabilidades en la aplicación antes de evaluar la efectividad de las reglas del WAF.
La Contaminación de Parámetros HTTP (HTTP Parameter Pollution o HPP) es una técnica de evasión que explota una discrepancia fundamental: no existe un estándar RFC único que defina cómo debe comportarse un servidor web cuando recibe varios parámetros con el mismo nombre en una sola petición.
Cuando un WAF y un servidor backend procesan parámetros duplicados de forma diferente, un atacante puede "repartir" o estructurar un payload malicioso para que el WAF no detecte nada sospechoso, pero el backend termine ejecutándolo.
El Comportamiento Heterogéneo de las Tecnologías
Para entender cómo se logra la evasión, primero hay que ver cómo reaccionan las distintas tecnologías al recibir una petición como:
| Tecnología / Servidor Web | Comportamiento con Parámetros Duplicados | Valor final interpretado por la aplicación |
| ASP.NET / IIS | Concatena los valores usando una coma | val1,val2 |
| PHP / Apache | Toma únicamente el último valor | val2 |
| JSP / Tomcat | Toma únicamente el primer valor | val1 |
| Node.js (Express) | Crea un arreglo de cadenas (Array) | ['val1', 'val2'] |
| Python (Django / Flask) | Toma únicamente el último valor | val2 |
Escenario Práctico: Evasión de Inyección SQL en ASP.NET
Imagina una aplicación desarrollada en ASP.NET conectada a una base de datos SQL Server, protegida por un WAF que analiza el tráfico antes de que llegue al servidor.
1. El Objetivo y la Consulta Vulnerable
El servidor backend ejecuta la siguiente consulta en la base de datos reemplazando el valor recibido en el parámetro id:
SELECT * FROM productos WHERE id_categoria = [VALOR_RECIBIDO]
Un payload típico de SQL Injection como 1 UNION SELECT username, password FROM users sería bloqueado de inmediato por las reglas de firmas del WAF al detectar la combinación de palabras clave UNION SELECT.
2. La Petición Maliciosa usando HPP
El atacante divide el payload en dos parámetros id idénticos dentro de la misma URL:
GET /producto.aspx?id=1/*&id=*/UNION/*&id=*/SELECT/*&id=*/username,password/*&id=*/FROM/*&id=*/users WHERE 1=1
3. ¿Cómo procesa esto el WAF?
El WAF recibe la petición e inspecciona los parámetros id por separado o toma únicamente el primer/último valor según su lógica interna:
Ve
id=1/*$\rightarrow$ Seguro (solo es un número y un inicio de comentario).Ve
id=*/UNION/*$\rightarrow$ Seguro (palabra aislada).Ve
id=*/SELECT/*$\rightarrow$ Seguro.
Como no observa el patrón completo UNION SELECT dentro de un único parámetro evaluado, el WAF permite el paso de la petición.
4. ¿Cómo lo procesa el Backend (ASP.NET)?
Cuando la petición supera el WAF y llega a la aplicación ASP.NET, la tecnología concatena automáticamente todos los parámetros id usando comas:
Al intercalar comentarios en SQL (/* ... */), la coma introducida por ASP.NET queda dentro de un comentario y es ignorada por el motor de la base de datos:
-- La consulta armada en la base de datos resulta en:
SELECT * FROM productos WHERE id_categoria = 1/*,*/UNION/*,*/SELECT/*,*/username,password/*,*/FROM/*,*/users
La sintaxis resultante equivale a:
SELECT * FROM productos WHERE id_categoria = 1 UNION SELECT username,password FROM users
Resultado: La inyección SQL se ejecuta con éxito en la base de datos extrayendo las credenciales.
HPP Servidor vs. HPP Cliente
Aunque el ejemplo anterior se enfoca en el lado del servidor (evasión de WAF), existe otro tipo de HPP:
HPP Server-Side: Afecta a la lógica interna y componentes de seguridad (WAF, proxies) concatenando o sustituyendo variables en peticiones de backend.
HPP Client-Side: Ocurre cuando el servidor genera enlaces HTML reutilizando parámetros duplicados de la URL sin sanitizar, lo que puede derivar en vulnerabilidades como Cross-Site Scripting (XSS) o Redirecciones Maliciosas.
¿Cómo prevenir la contaminación de parámetros?
Normalización en el WAF/Proxy: Configurar el WAF para que consolide y analice las peticiones exactamente de la misma manera en que lo hace el servidor backend que tiene detrás.
Rechazo estricto: Configurar el servidor web o el marco de desarrollo para rechazar o devolver un código
400 Bad Requestsi se detectan parámetros duplicados en la misma petición.Uso de Consultas Preparadas (Parameterized Queries): Aunque la HPP logre evadir el WAF, las consultas preparadas en el código fuente impiden que la inyección SQL llegue a ejecutarse.
