¿Qué son los ataques de encabezado Host HTTP?
Los ataques de encabezado de Host HTTP se han convertido en una técnica común entre los atacantes y tienen varias variantes. Antes de profundizar en los ataques y en lo que permiten, empezaremos por explicar qué es un encabezado de Host HTTP.
¿Qué es el encabezado Host de HTTP?
El encabezado de Host HTTP proporciona información sobre el host y el puerto, y está pensada para ayudar a los servidores de origen a determinar qué recursos utilizar cuando atienden peticiones de varios dominios.
Otros encabezados de Host
A veces, las aplicaciones complementan al encabezado de Host con otras similares, como «X-Forwarded-Host», «X-Host» y otras variaciones. Las utilizaremos en algunas de las descripciones de los ataques que aparecen a continuación, ya que son vulnerables de la misma manera que el encabezado de Host si se utilizan incorrectamente.
Los tipos de ataques de encabezado Host HTTP
El encabezado de Host es una parte crítica de la utilización de Internet, pero las aplicaciones se vuelven vulnerables cuando se confía implícitamente en él, se utiliza para funcionalidades adicionales o se configura incorrectamente. Los atacantes pueden aprovechar este comportamiento a través de la inyección diferentes tipos de contenido en el encabezado de Host, lo que puede dar lugar a vulnerabilidades más graves, como por ejemplo:
Envenenamiento del encabezado Host
Envenenamiento de la caché web
Envenenamiento por restablecimiento de contraseña
Falsificación de peticiones del lado del servidor
Según cómo se utilicen los valores proporcionados por el encabezado de Host en una aplicación, también podrían permitirse otros ataques, como el Cross-Site Scripting o la inyección SQL, al igual que cualquier otra entrada proporcionada por el usuario cuando no se procesa de forma segura. Por ahora, vamos a suponer que no se utiliza el encabezado de Host en consultas SQL sin procesar y nos centraremos en los ataques más directos.
1. Envenenamiento del encabezado Host
En el caso más sencillo, una aplicación puede utilizar el valor del encabezado de Host para redirigir el tráfico a la página de inicio de sesión, por ejemplo. Si la aplicación utiliza el encabezado de Host para crear el enlace de redirección, un atacante puede enviar la siguiente petición HTTP:
GET / HTTP/1.1
Host: www.attackers-domain.example.com
Y generar una respuesta de redireccionamiento a tu dominio controlado:
HTTP/1.1 302 Found
...
Ubicación: http://www.attackers-domain.example.com/login.php
Por sí solo, este ataque no es muy útil, ya que es difícil conseguir que un usuario objetivo realice esta petición. Sin embargo, el envenenamiento del encabezado de Host puede combinarse con otros ataques para aumentar su eficacia.
2. Envenenamiento de la caché web
El envenenamiento de la caché web no es una vulnerabilidad del encabezaso de Host per se, sino un mecanismo de entrega que hace explotable el mencionado envenenamiento del encabezado de Host. Digamos que una aplicación no utiliza el encabezado de Host para construir sus enlaces de redirección (lo cual es correcto) y que, en cambio, utiliza un encabezado alternativo, como X-Host, para hacerlo (lo cual no es correcto). En este escenario, un atacante puede inyectar su dominio en el encabezado X-Host para envenenar la redirección. No obstante, todavía necesita una forma de entregar esa redirección a los usuarios.
Aquí es donde entra en juego el envenenamiento de la caché web. Las cachés web suelen utilizar partes de una petición HTTP como «claves» para saber cuándo deben utilizar el contenido almacenado en caché en lugar de enviar la petición al origen. Esta clave suele incluir el encabezado de Host y puede incluir otros encabezados. En nuestro ejemplo, el encabezado X-Host no forma parte de la clave de caché, pero se utiliza de forma insegura en la respuesta (como en nuestro ejemplo de redirección), los atacantes pueden utilizar la caché para redirigir de forma maliciosa a otros usuarios. Entonces, el atacante encuentra una forma de conseguir que su petición se almacene en caché para servirla a otros usuarios.
Echemos un vistazo a un ejemplo de envenenamiento de caché web. Primero, el atacante obtiene la siguiente petición almacenada en caché que incluye tu dominio malicioso en el encabezado de X-Host, que se utilizará en un redireccionamiento:
GET / HTTP/1.1
Host: www.super-cool-fun-domain.example.com
X-Host: www.attackers-domain.example.com
Entonces, un usuario sin malas intenciones decide visitar la aplicación y envía una petición normal.
GET / HTTP/1.1
Host: www.super-cool-fun-domain.example.com
X-Host: www.super-cool-fun-domain.example.com
Si la solicitud del atacante se almacenara en caché basándose en la ruta y el encabezado de Host, dicho usuario recibiría ahora la respuesta envenenada almacenada en caché, que le redirigiría a la página del atacante.
HTTP/1.1 302 Found
...
Ubicación: http://www.attackers-domain.example.com/login.php
Los ataques de envenenamiento de caché web se basan en la diferencia entre los encabezados que se utilizan como clave de caché y las que utiliza la aplicación para formular las respuestas. En el ejemplo anterior, el encabezado X-Host permitía envenenar las respuestas en caché y redirigir a los usuarios a un sitio malicioso en lugar de a la aplicación real.
3. Envenenamiento por restablecimiento de contraseña
El envenenamiento por restablecimiento de la contraseña es muy similar al envenenamiento del encabezado de Host anterior, ya que la aplicación vulnerable utiliza el encabezado de Host para crear el enlace de restablecimiento de la contraseña que envía al usuario solicitado durante el proceso de restablecimiento. Por ejemplo, supongamos que un atacante envía la siguiente petición POST para solicitar un restablecimiento de contraseña para el usuario «Alice»:
POST /password-reset HTTP/1.1
Host: www.attackers-domain.example.com
...
user=alice
La aplicación utiliza el valor del encabezado de Host para crear el enlace de reinicio y envía un correo electrónico al usuario Alice con dicho enlace.
www.attackers-domain.example.com?reset_token=super-random-reset-token-value-12345
Si el usuario hace clic en el enlace, el atacante captura el token de restablecimiento y puede cambiar la contraseña del usuario por la suya.
4. Falsificación de peticiones en el lado del servidor
La falsificación de peticiones del lado del servidor (SSRF) es una vulnerabilidad que permite a un atacante hacer que la aplicación del lado del servidor realice peticiones a una ubicación arbitraria. En una SSRF de encabezado de Host, el atacante explota el enrutamiento utilizado por los sistemas situados entre el usuario y la aplicación del lado del servidor. Si este middleware (por ejemplo, un equilibrador de carga) es vulnerable a la SSRF del encabezado de Host, el atacante puede utilizarlo para interactuar con sistemas internos a los que de otro modo no tendría acceso. Una forma común de probarlo es poner un dominio único y controlado (por ejemplo, Burp Collaborator de Portswigger o interactsh de Project Discovery) en el valor del encabezado de Host. Si ese dominio único recibe una consulta DNS u otra petición de un sistema en la ruta de red de las aplicaciones objetivo (por ejemplo, el equilibrador de carga) durante un ataque de encabezado de Host, puede ser vulnerable a la inyección de solicitudes al servidor proxy (SSRF). Estos ataques tienden a ser complejos, pero también devastadores, como se detalla en la investigación de James Kettle.
Ejemplos reales de ataques de encabezado de Host HTTP
Ahora que ya conoces los tipos de ataques a encabezados de Host, veamos algunos ejemplos reales.
CVE-2022-29933: envenenamiento por restablecimiento de contraseña en Craft CMS
SEC Consult descubrió que la instalación predeterminada de Craft CMS genera correos electrónicos de restablecimiento de contraseña utilizando el valor del encabezado de HTTP «X-Forwarded-Host». En este ejemplo, un atacante inyecta su dominio controlado en el X-Forwarded-Host para envenenar el enlace de restablecimiento de contraseña del usuario Alice de la siguiente manera:
POST /index.php?p=admin/actions/users/send-password-reset-email HTTP/1.1
Host: <installation-domain>
X-Forwarded-Host: www.attackers-domain.example.com
...
Cookie: CRAFT_CSRF_TOKEN=[...]
loginName=alice@example.com
Cuando el usuario alice@example.com recibe el correo electrónico de restablecimiento de contraseña, este contiene un enlace al dominio controlado por el atacante.
http://www.attackers-domain.example.com/index.php?p=admin/set-password&code=<reset-code>&id=<uuid>
Si el usuario accede al enlace, el atacante capturará su código de restablecimiento y podrá restablecer su contraseña para hacerse con el control de la cuenta.
SSRF ciega en Slack a través de la inyección de X-Forwarded-Host
Este ataque elude la validación débil de X-Forwarded-Host para lograr una SSRF ciega en files.slack.com. En primer lugar, files.slack.com intenta validar los encabezados de Host y X-Forwarded-Host durante el procesamiento y devuelve un código de respuesta HTTP 500 si no son de files.slack.com. Sin embargo, es posible saltarse la validación X-Forwarded-Host añadiendo un carácter @ al final del dominio. Así, el atacante configura un dominio de callback para capturar peticiones (por ejemplo, con Burp Collaborator o el interactor de Project Discovery) y envía la siguiente petición a slack.files.com:
GET /<URI> HTTP/1.1
Host: files.slack.com
...
X-Forwarded-Host: files.slack.com@www.unique-attackers-domain.example.com
El dominio files.slack.com de la URL construida a partir del encabezado de X-Forwarded-Host se trata como usuario HTTP (HTTP Basic Auth), y el www.unique-attackers-domain.example.com se trata como nombre de host. El atacante recibe una petición de un sistema de backend, lo que confirma el éxito de la SSRF. Desde aquí, se pueden usar varias técnicas ciegas de SSRF diferentes para intentar filtrar información, interactuar con los sistemas de backend y más.
Cómo prevenir ataques de encabezado HTTP Host
Hay varias formas de prevenir los ataques al encabezado de Host de HTTP, que varían en su eficacia y desventajas. A continuación encontrarás soluciones prácticas para prevenir este tipo de ataque.
Evita usar el valor del encabezado de Host y sus variantes en el código de la aplicación
La forma más fácil de prevenir ataques de encabezado de Host es evitar el uso del valor del encabezado de Host en tu código de aplicación. Además, usar configuraciones del lado del servidor o URL relativas frustrará por completo los ataques de encabezado de Host.
Realiza una validación estricta de los valores del encabezado de Host
Si tienes que usar el valor del encabezado Host, deberías emplear las siguientes técnicas para prevenir ataques al encabezado Host:
Comprueba que el encabezado de Host esté en una lista de valores permitidos. Por ejemplo, si tu aplicación solo utiliza tres dominios, asegúrate de que el encabezado de Host sea únicamente uno de esos tres valores.
Comprueba que haya solo un encabezado de Host. Los encabezados de Host duplicados pueden utilizarse a veces para eludir la validación, siempre y cuando la validación y el uso del encabezado extraigan valores diferentes de la petición.
Evita utilizar alternativas y anulaciones del encabezado de Host, como X-Host o X-Forwarded-Host, y, si no tienes más remedio, sigue las mismas recomendaciones proporcionadas para el encabezado de Host.
Cómo Fastly ayuda a prevenir los ataques de encabezado Host HTTP
Sigue la guía de Fastly sobre la prevención del envenenamiento de la caché para asegurarte de que se implementen protecciones adicionales.
Si estás usando el cortafuegos de aplicaciones web de última generación de Fastly, puedes añadir protecciones adicionales para defenderte contra los ataques de encabezados de Host HTTP y bloquear todas las peticiones con encabezados de host no válidos (p. ej., aquellos que no están en tu lista de dominios permitidos).
Resumen
El encabezado de Host es una parte vital de Internet (y de Fastly), pero cuando se confía implícitamente en él, se usa para funcionalidades adicionales o está mal configurado, los atacantes pueden aprovechar este comportamiento mediante la inyección de diferentes tipos de contenido malicioso en él. Esto puede permitir varios tipos de ataques, incluidos el envenenamiento de encabezados de Host, el envenenamiento de caché web, el envenenamiento por restablecimiento de contraseñas y la falsificación de peticiones del lado del servidor (SSRF). Al utilizar las soluciones que hemos descrito, junto con la orientación de Fastly para prevenir el envenenamiento de caché, las aplicaciones pueden evitar las variantes de ataque al encabezado de Host.
Descubre más sobre las capacidades de seguridad de Fastly
