Domain IP Lookup

El mismo dominio, dos respuestas distintas

Primera solicitud

resuelve a una IP pública

Validación

se supera: parece segura

Vence el TTL

segundos después

Segunda solicitud

resuelve a 127.0.0.1

Seguridad

Qué es el DNS rebinding y por qué debería importarte

3 min de lectura

La mayoría de las comprobaciones de seguridad que involucran un dominio dan por hecho que su dirección IP es lo bastante estable como para validarla una vez y confiar en ella después. El DNS rebinding explota exactamente esa suposición. Un atacante controla el DNS de un dominio y lo configura para que, al principio, resuelva a una dirección IP pública normal, superando cualquier validación que realice el sistema objetivo, y después cambia la respuesta a una dirección interna (como 127.0.0.1 o un rango interno 10.x.x.x) para una solicitud posterior, cuando la comprobación ya se ha superado.

Por qué es más que un truco teórico

Un TTL muy corto hace que el ataque sea viable: el atacante configura el registro para que caduque en unos segundos, de modo que una comprobación de validación y la solicitud real que la sigue pueden ver dos respuestas distintas, con milisegundos de diferencia, sin que el sistema víctima se dé cuenta de que el terreno ha cambiado bajo sus pies. Cualquier sistema que resuelva un dominio una sola vez y reutilice esa IP en varias operaciones (o, peor aún, que lo resuelva una vez para validarlo y deje que otro componente lo resuelva de nuevo para la solicitud real) está potencialmente expuesto.

La única defensa fiable

Validar la cadena del nombre de host no basta, y validar una IP una sola vez tampoco. La única defensa sólida es comprobar la dirección realmente resuelta frente a una lista de bloqueo de rangos privados o internos en el punto en que se establece la conexión, cada vez y no solo en la validación inicial. Eso cierra el desfase temporal del que depende el rebinding, porque ya no hay ninguna ventana entre «comprobado» y «usado» para que la respuesta cambie.

  • Bloquea los rangos privados (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), el bucle local (127.0.0.0/8), el de enlace local (169.254.0.0/16) y los endpoints de metadatos de la nube, tanto para IPv4 como para IPv6.
  • Vuelve a comprobar en cada uso, no solo una vez al validar la entrada.
  • Trata una dirección IPv6 mapeada a IPv4 (como ::ffff:127.0.0.1) como equivalente a la dirección IPv4 que lleva incrustada: los intentos de rebinding a veces usan precisamente esta codificación para esquivar una comprobación ingenua pensada solo para IPv6.
Enfoque¿Cierra la brecha del rebinding?
Validar una sola vez la cadena del nombre de hostNo: no dice nada sobre a qué se resuelve
Resolver una vez y reutilizar la IP en solicitudes posterioresNo: el registro puede cambiar antes de la reutilización
Resolver y comprobar la lista de bloqueo en cada usoSí: no queda ninguna ventana para que cambie la respuesta

Dónde ha importado en la práctica

El DNS rebinding no es una preocupación académica marginal: se ha usado repetidamente contra routers domésticos, hubs de domótica y otros dispositivos que exponen una interfaz de administración local sin autenticación, bajo el supuesto de que solo el tráfico local de confianza podría llegar a ella. Una página web maliciosa, abierta en una pestaña normal del navegador dentro de la misma red, puede usar rebinding para que el propio navegador de la víctima (en el que el router ya confía simplemente por estar en la red local) envíe solicitudes directamente a esa interfaz de administración en nombre del atacante. El navegador cree todo el tiempo que sigue hablando con el dominio público original; lo único que cambió fue la respuesta DNS que hay por debajo.

Una variante más sutil: rebinding con varias respuestas

Una versión más sofisticada se salta por completo la espera a que caduque un TTL. Una sola respuesta DNS puede contener legítimamente más de un registro A, y algunos clientes simplemente los prueban en orden, o incluso rotan entre ellos en solicitudes distintas. Un atacante puede devolver una dirección pública legítima y una interna en la misma respuesta, confiando en que el cliente acabe probando la segunda entrada: sin esperas, sin ventana temporal, aprovechando solo que el DNS nunca se diseñó para garantizar que todas las direcciones de una respuesta con varias entradas sean igual de fiables. Es un buen recordatorio de que «comprobar la primera dirección devuelta» nunca es suficiente: cada dirección de una respuesta merece el mismo escrutinio.

¿Necesitas comprobar las direcciones DNS públicas de un dominio? Usa la herramienta Domain IP Lookup.

Lecturas relacionadas