dns-rebinding-attacks

Acerca de dns-rebinding-attacks

Una guía de ataques de reasignación de DNS centrada en la técnica del lado del cliente para eludir la política de mismo origen del navegador cambiando la dirección IP asociada a un nombre de host que la víctima ya ha cargado. La idea central es que la política de mismo origen comprueba la cadena del nombre de host, no la dirección IP resuelta: un atacante que controle el DNS autoritativo de su dominio puede servir código JavaScript malicioso en la primera resolución (la IP del atacante) y, a continuación, volver a resolver el mismo nombre de host a una IP interna, de modo que el navegador trate las solicitudes al servicio interno como de mismo origen y el script pueda leer las respuestas.

Esto aclara la distinción con respecto al SSRF, ya que el «DNS rebinding» es su equivalente del lado del cliente, y detalla los obstáculos prácticos y las soluciones alternativas. Dado que los navegadores mantienen su propia caché DNS que ignora los TTL bajos (aproximadamente 60 segundos en Chrome, Edge y Firefox), se documentan estrategias de elusión que incluyen esperar a que se vacíe la caché, respuestas con múltiples registros «A» que bloqueen la IP del atacante para forzar el recurso alternativo, inundación de subdominios para obtener nuevas resoluciones y retrasos en los service workers. Las variantes de ataque incluyen el reenlace HTTP clásico, el reenlace WebSocket, un híbrido TOCTOU del lado del servidor y el método rápido de registros A múltiples.

Úsalo al probar aplicaciones que confían en el DNS para las comprobaciones de origen o que realizan operaciones fetch/XHR del lado del cliente a dominios controlados por el atacante, especialmente cuando no es posible el SSRF del lado del servidor. Una tabla de objetivos de alto valor enumera los metadatos en la nube (169.254.169.254), las API de Docker y Kubernetes, paneles de administración internos, Elasticsearch, Redis y Consul/etcd, con una nota que indica que el requisito de token de IMDSv2 se resiste a la reasignación porque no es fácil configurar encabezados personalizados en modo «no-cors». Las herramientas cubiertas incluyen Singularity, el servicio rbndr.us sin configuración previa (con un formato de subdominio de IP hexadecimal), whonow y servidores DNS mínimos en Python, y establece referencias cruzadas con las técnicas de SSRF y de configuración errónea de CORS.

Preguntas frecuentes

¿En qué se diferencia el reenlace de DNS del SSRF?

El SSRF se produce en el lado del servidor, mientras que el reenlace de DNS es su equivalente en el lado del cliente, que se ejecuta en el navegador de la víctima. Aprovecha que la política de mismo origen comprueba la cadena del nombre de host, no la IP resuelta.

¿Por qué un TTL de 0 no funciona de inmediato?

Los navegadores mantienen su propia caché DNS que ignora los TTL bajos (alrededor de 60 segundos en Chrome, Edge y Firefox), por lo que la habilidad abarca técnicas de elusión como la espera, los registros A múltiples con alternativa de respaldo, la inundación de subdominios y los retrasos de los service workers.

¿Cuáles son los objetivos internos de mayor valor?

Los metadatos en la nube en 169.254.169.254, la API de Docker, la API de Kubernetes, los paneles de administración internos, Elasticsearch en el puerto 9200, Redis en el puerto 6379 y Consul/etcd.

¿Se pueden robar credenciales de AWS de IMDSv2 mediante el reenlace?

No es fácil. IMDSv2 requiere un encabezado «X-aws-ec2-metadata-token» en una solicitud PUT, y el rebinding no puede establecer fácilmente encabezados personalizados en la solicitud inicial del token en modo «no-cors». IMDSv1 está más expuesto.

¿Qué herramientas recomienda?

Singularity (un marco completo), rbndr.us (sin configuración, que utiliza subdominios con pares de IP hexadecimales), whonow (un servidor de rebinding dinámico) y servidores DNS mínimos personalizados en Python.