Al realizar un PenTest contra un sitio protegido por WAF, ¿qué debe saber un Pentester para mejorar la calidad de la prueba?

Su enfoque debe ser doble:

Técnico:
Compruebe si:

• Varias secuencias de escape (por ejemplo, \ x00,% s, \\, etc.)
• trucos de Unicode (por ejemplo, caracteres de varios bytes que terminan en 0x22 para producir un ")
• Métodos XSS alternativos (por ejemplo, <img src=0 onerror=alert(1) /> en lugar de <script>alert(1)</script> )
• Varios nasties (por ejemplo, XSS, inyección de SQL) dentro de las cookies y los encabezados HTTP - ¡a menudo los WAFs se los pierden!

Asesoramiento:
Asegúrese de que el cliente entienda que un WAF es solo un emplasto y no puede reparar una extremidad rota. Si la aplicación se rompe de forma explotable, un WAF puede evitar el ataque o mitigar parte del impacto, pero no hay forma de estar seguro de que será efectiva.

También es un arma de doble filo, ya que la gente a menudo asume que un error que un WAF hace que no se pueda explotar siempre será no explotable, y por lo tanto no necesita ser reparado (al menos con Cualquier prisa). Los navegadores y los lenguajes del lado del servidor HTML / CSS / JavaScript / SQL / XML, etc. evolucionan constantemente, por lo que pueden surgir nuevas técnicas de explotación que hacen que los errores antiguos sean explotables.

Me gustaría resaltar un punto adicional: si la prueba está dirigida a la aplicación web, y no está dirigida específicamente a la solución WAF que han implementado, entonces recomiendo encarecidamente preguntar a cliente para desactivar el WAF en su sitio de ensayo durante la prueba. Dejarlo activo hace que sea mucho más difícil para usted darles una estimación razonable de la postura de seguridad de la aplicación, y eso significa que obtienen menos valor de la prueba. Si están realmente interesados en probar el WAF, podrían hacer un día de prueba adicional luego que compare la capacidad de explotación de los problemas encontrados con y sin que el WAF esté habilitado.

Hay tres enfoques para atacar una aplicación web detrás de un Firewall de aplicación web (WAF). Si observa vulnerabilidades existentes de bypass de WAF puede ver que se dividen en dos categorías principales. Puede omitir un conjunto de reglas porque es demasiado restrictivo o no coincide con precisión con un ataque real, o puede atacar el preprocesador, lo que evitará todos los conjuntos de reglas. Hay una tercera categoría de bypass de WAF, que no requiere un exploit de bypass de WAF.

1. Los ataques del preprocesador WAF están dirigidos a intentar ocultar o eliminar una carga útil de ataque de una solicitud antes de ser procesada por un WAF conjuntos de reglas. Aquí hay dos exploits que son WAF preprocesador ataques:

   PHPIDS tenía un inseguro preprocesador "Eliminar duplicados" puede ser se utiliza para ocultar cualquier carga útil que se duplica 33 veces. (Descargo de responsabilidad: este es mi exploit)

   IBM WebSphere tenía un "pre-procesador de Eliminar comentarios" inseguro que se puede usar para ocultar cualquier carga útil.

2. Los ataques del conjunto de reglas WAF están explotando un conjunto de reglas débil que permite una atacante para enviar una cadena de ataque válida. En este caso las reglas. son demasiado simplistas un ataque puede ser modificado para evitar la detección. Hay dos direcciones para atacar una aplicación web detrás de una web Firewall de aplicaciones.

   Una dirección es intentar explotar una vulnerabilidad común, como como XSS o SQLi. Determine qué regla violó e intente y modifica tu carga útil de ataque para evitar esta regla. Las reglas pueden ser auditado usando un Regex Debugger , RegEx Buddy es mi favorito Herramienta para este proceso. Después de que puedas explotar SQLi, entonces Busca las vulnerabilidades de SQLi en la aplicación. Por ejemplo, si tuviera una cadena modificada que ejecutaría sleep(30) en una La base de datos MySQL sin ser detectada por el WAF, puede usar esta cadena a fuzz para SQLi ciego en la aplicación. Este es un ejemplo de una carga útil de Inyección SQL modificada para omitir mod_security . Este es un enfoque de caja negra en el que no tiene acceso a la aplicación web, pero el atacante siempre debe acceder al WAF.

   La otra dirección es la inversa, explota la aplicación web con una vulnerabilidad como SQLi sin el WAF, y luego intenta crear una cadena de ataque para explotar esta vulnerabilidad sin ser detectado por el WAF. Este es un enfoque de caja gris.

3. El tercer método para atacar una aplicación web detrás de un WAF es evitar el problema por completo. Es imposible que un WAF detecte todos los ataques . Existen vulnerabilidades comunes en la web. aplicaciones que WAFs no pueden evitar. CSRF, Asignación de masas , Insegura referencia directa de objetos, click-jacking, oráculos criptográficos, errores de lógica de autenticación / autorización ... use su imaginación .