¿La fijación de DNS protege contra todos los ataques de reencuadernación de DNS?

6

Encontré un ejemplo de un escenario de ataque de reencuadernación de DNS en el documento "Ataques dinámicos de Pharming y Políticas del mismo origen bloqueadas para navegadores web ".

  

Figura 1 : un ejemplo de un ataque dinámico de pharming contra www.vanguard.com. (1) Inicialmente, el farmacéutico organiza las consultas de DNS de la víctima para que www.vanguard.com se resuelva a la dirección IP del farmacéutico, 6.6.6.6. (2) Luego, cuando la víctima visita www.vanguard.com, el farmacéutico devuelve un documento troyano que contiene Javascript malicioso y un iframe que hace referencia a la página de inicio de Vanguard. (3) El farmacéutico luego actualiza la entrada de DNS para www.vanguard.com a la dirección IP del servidor legítimo de Vanguard y niega las conexiones posteriores de la víctima. (4) Esto hace que el navegador de la víctima renueve su entrada de DNS para www.vanguard.com, y (5) cargue la página de inicio legítima de Vanguard en el iframe. (6) Una vez que el usuario se autentica, el Javascript malintencionado en el documento troyano secuestra su sesión con el servidor legítimo.

Ahora parece que los navegadores de hoy implementan una función llamada Fijación de DNS . De Wikipedia:

  

Los navegadores web pueden implementar la fijación de DNS: la dirección IP está bloqueada al valor recibido en la primera respuesta de DNS. Esta técnica puede bloquear algunos usos legítimos del DNS dinámico y puede no funcionar contra todos los ataques.

Mi pregunta es: ¿esta contramedida protege efectivamente contra el escenario de ataque descrito? Si es así, ¿cuáles son algunos ejemplos de escenarios de ataque que no están protegidos exitosamente (ver reclamo en la cita de Wikipedia)? Si no es así, ¿cuál es la razón por la que el ataque tiene éxito y cómo podría protegerse contra él con éxito?

    
pregunta Honoki 20.04.2012 - 15:47
fuente

3 respuestas

7

La fijación de DNS no protege contra los ataques sofisticados de reconexión de DNS .

Considere un escenario en el que un atacante configura un firewall frente a su servidor web. Solicita su sitio web, attacker.com, que da como resultado que una consulta de DNS devuelva su dirección IP. El resultado del DNS tiene un TTL (tiempo de vida) de 1 segundo. Normalmente, esto significa que el navegador debe realizar otra solicitud de DNS después de que haya transcurrido 1 segundo, sin embargo, la fijación de DNS le indica al navegador que ignore el TTL y le agregue alguna unidad de tiempo (por ejemplo, una hora). Así que ahora, su navegador no realizará otra consulta de DNS para ese nombre de host durante 1 hora, 1 segundo. Una vez que se completa la consulta de DNS, se envía su solicitud HTTP y el atacante le devuelve el sitio web que solicitó con el código javascript que iniciará el ataque.

Ahora, el Javascript del atacante ha configurado una solicitud AJAX que espera dos segundos antes de disparar. Luego, vuelve a solicitar automáticamente algún recurso en el sitio web del atacante. Sin embargo, la solicitud falla. Esto se debe a que el atacante ya ha configurado una regla de firewall que bloquea la solicitud de su navegador . Ahora estamos en el siguiente estado:

  1. El TTL ha caducado en su primera solicitud de DNS, pero la asignación de DNS todavía está vigente
  2. Hiciste una solicitud al sitio web del atacante a través de su llamada JS AJAX
  3. El firewall del atacante eliminó la solicitud

Estas tres cosas harán que su navegador web envíe otra consulta de DNS a pesar del hecho de que está usando la asignación de DNS. En efecto, el atacante ha derrotado fácilmente su estrategia de fijación de DNS mediante el uso de un firewall y Enviando una segunda solicitud fuera del TTL. La fijación de DNS no es una estrategia efectiva porque hay muchas razones legítimas por las que el servidor de alguien podría estar inactivo; su navegador se ve obligado a realizar una segunda consulta de DNS en caso de que haya otro registro de DNS que se resuelva en la máquina correcta (por ejemplo, en el caso de una migración de servidor, tiempo de inactividad, lo que sea). Básicamente, su navegador no tiene forma de saber si está siendo atacado aquí o no; por lo que sabe, el servidor está inactivo legítimamente y, por lo tanto, DEBE realizar otra solicitud de DNS.

Entonces ... ¿por qué importa que haya una segunda solicitud de DNS?

El atacante suele utilizar la segunda solicitud de DNS para devolver una dirección IP incorrecta para el registro de DNS. Los navegadores tienen lo que se denomina una política de "mismo origen" que evita que las páginas web realicen solicitudes de recursos que no son de su propiedad. Básicamente, la forma en que funciona el mismo origen es que dice que enlace solo puede solicitar enlace . Pero en realidad funciona usando la dirección IP para hostname.com, no el nombre de host legible por humanos. Entonces, en un ataque de reencuadernación de DNS, cuando su navegador realiza la segunda consulta de DNS que describí anteriormente, el atacante devolverá una dirección IP "falsa" en el resultado de la consulta de DNS. Entonces, su navegador pensará, por ejemplo, que la dirección IP 1.1.1.1 pertenece a attacker.com aunque en realidad pertenece a google.com. Esto permite al atacante explotar la misma política de origen del navegador; ahora el javascript del atacante puede solicitar cosas de google.com a través de AJAX. Además, pueden leer y configurar cookies y otras cosas maliciosas. Esto explota la misma política de origen engañando al navegador para que confíe en el segundo registro DNS que se devolvió. Ahora el navegador cree que hostname.com está asociado con la dirección IP 1.1.1.1, aunque en realidad no lo está. ¿Qué es un navegador para hacer? DNS no tiene ese tipo de autenticación incorporada. :(

Evitar el ataque de reencuadernación de DNS

Hay muchas maneras de prevenirlo, y estoy bastante seguro de que los navegadores modernos ya han implementado protección contra estos ataques. Una forma fácil de evitarlo (como propietario de un sitio web) es verificar el encabezado de host HTTP de una solicitud. Por ejemplo, si usted es google.com, entonces recibirá una solicitud pero el encabezado del host aún dirá attacker.com. Obviamente, eso no forma parte de su dominio, por lo que puede evitar el ataque simplemente eliminando la solicitud. ¿Por qué alguien querría hacer esto para empezar? Bueno, haga clic en el fraude en la publicidad. Raspando los motores de búsqueda de muchas máquinas a la vez. Robar datos valiosos de sitios web en la red interna de su empresa. Etc.

    
respondido por el KyleM 07.04.2013 - 20:58
fuente
5

Si desea tener en cuenta la totalidad del contenido que se puede ejecutar desde un navegador, entonces el navegador que realiza la fijación de DNS por sí solo no sería suficiente. Los complementos del navegador, como Flash y Java, pueden tener acceso a socket, lo que significa que podrían realizar consultas de DNS y, si no implementan una estrategia de fijación de DNS, el navegador seguirá siendo vulnerable por proxy. Consulte enlace o Google para "Proteger los navegadores de los ataques de recuperación de DNS" por Jackson et al. para mas detalles.

    
respondido por el Dave 10.11.2012 - 03:46
fuente
2

Intentaré responder mi propia pregunta con la ayuda de un ejemplo de ataque al que estuve vinculado. Los comentarios y observaciones son bienvenidos, porque no estoy seguro de la exactitud de esta respuesta.

Sí , la fijación de DNS evitaría el ataque descrito, aunque no es necesario que la situación sea completamente segura. Imagina esto:

  1. Inicialmente, el farmacéutico organiza las consultas de DNS de la víctima para que www.good.com las resuelva en la dirección IP del farmacéutico, 6.6.6.6.
  2. Luego, cuando la víctima visita www.good.com, el farmacéutico devuelve un documento troyano que contiene Javascript malicioso y un iframe que hace referencia a www.good.com/homepage. El farmacéutico también se asegura de que el encabezado Cache-Control especifique un valor de edad máxima muy alto.
  3. El farmacéutico luego actualiza la entrada de DNS de www.good.com a la dirección IP del servidor legítimo de Good y niega las conexiones posteriores de la víctima.
  4. Esto hace que el navegador de la víctima renueve su entrada de DNS para www.good.com, que el navegador no permitirá debido a la fijación de DNS.
  5. La asignación de DNS hará que el origen del iframe se obtenga de la dirección IP del farmacéutico (6.6.6.6/homepage).
  6. El servidor del farmacéutico rechaza la solicitud y el usuario puede ver un error.

Cuando la víctima vuelve a abrir su navegador algún tiempo después e intenta acceder a www.good.com

  1. La versión en caché de la página se carga en el navegador, independientemente de los registros DNS, incluido el JavaScript malicioso.
  2. El iframe se volverá a cargarse, porque el encabezado de Cache-Control no se aplica al contenido de los iframes (esta reclamación necesita una copia de seguridad).
  3. El contenido del iframe apuntará al servidor correcto, porque el registro de DNS está arreglado
  4. La página de inicio legítima de Good se carga en el iframe.

¿Cuáles son algunos ejemplos de escenarios de ataques que no se protegen con éxito?

Además del escenario descrito anteriormente, se proporciona un ejemplo de escenario de ataque de un tipo diferente en un comentario en el sitio Bugzilla de Mozilla , en relación con un problema con el almacenamiento en caché de DNS.

  

La información TTL del DNS no es algo que una sola aplicación debería decidir.   no quiere cumplir.

     

Se ha discutido que el comportamiento actual es un problema de "seguridad".    Negarse a cumplir con el parámetro TTL de una búsqueda de DNS es tan grande   De un agujero de seguridad, tal vez más grande. Uso de una búsqueda de DNS caducada y en caché (como   para aquellos usuarios que usan servicios DNS dinámicos,) terminarán enviando el error   información al servidor incorrecto, posiblemente un servidor e-vil.

     

Posible escenario:

     
  1. Mi servidor doméstico, mediante DHCP, recibe una dirección IP dinámica de 12.13.14.15
  2.   
  3. Registro el servicio dinámico myhome.dyndns.org para señalar a 12.13.14.15
  4.   
  5. La usuaria Alice visita mi sitio web, usa Mozilla y comienza una transacción.
  6.   
  7. Mi contrato DHCP expira y me dan una nueva dirección IP de 12.200.200.200
  8.   
  9. Mi servidor detecta el cambio y registra automáticamente myhome.dyndns.org   al 12.200.200.2002
  10.   
  11. Mi antigua dirección DHCP, 12.13.14.15 se le da a la computadora de Bob Evil.
  12.   
  13. Alice termina de completar un formulario web en Mozilla y lo envía. Mozilla   utiliza erróneamente la dirección IP en caché 12.13.14.15, y los datos son incorrectos   enviado a la computadora de Bob Evil.
  14.   

Esto realmente me ha pasado. Terminé golpeando el DSL de otras personas   enrutadores (si no tienen un sitio web configurado) en lugar de mi propio servidor con Mozilla,   aunque haya registrado una nueva dirección IP.

    
respondido por el Honoki 21.04.2012 - 16:48
fuente

Lea otras preguntas en las etiquetas