Pregunta bug kaminsky - bailiwicks


He estado leyendo sobre el error de DNS kaminsky, tratando de entender mejor cómo funciona. Creo que tengo la esencia de eso, pero Dan menciona bailiwicks, que están siendo utilizados para apuntar a servidores DNS detrás de firewalls.

¿Alguien puede explicar qué es una bailía y dar un ejemplo de cómo se usa para apuntar a los servidores que están detrás de los firewalls para explotar el error kaminsky?


5
2017-07-14 23:40


origen


Este artículo de Linux Journal tiene una buena explicación del error, con énfasis en qué parte juegan Bailiwicks: linuxjournal.com/content/understanding-kaminskys-dns-bug - Ehtyar
Punto 4 de cs.berkeley.edu/~daw/teaching/cs261-f09/reading/… - Pacerier


Respuestas:


Bailía

El diario de Linux artículo ese Ehtyar publicado tiene una buena explicación de qué es una bailía y cómo se relaciona con el DNS. Básicamente, los registros adicionales se agregan a una respuesta DNS para ayudar a encontrar servidores DNS delegados. Para citar el ejemplo del artículo:

$ dig @ns1.example.com www.example.com
;; ANSWER SECTION:
www.example.com.    120      IN    A    192.168.1.10

;; AUTHORITY SECTION:
example.com.        86400    IN    NS   ns1.example.com.
example.com.        86400    IN    NS   ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.    604800   IN    A    192.168.2.20
ns2.example.com.    604800   IN    A    192.168.3.30


Ataque

Los detalles sobre el ataque están en Dan's. diapositivas (ver diapositivas 24/25). Para atacar a un servidor detrás de un firewall:

  • Una búsqueda de un subdominio de un dominio que controla el atacante (por ejemplo, '1.badguy.com') se activa.
  • El servidor atacante responde con un registro CNAME para el dominio que está intentando envenenar (por ejemplo, 'debian.org'). Esto provoca una consulta de DNS desde el destino a 'debian.org'.
  • Tan pronto como el servidor atacante envía la referencia de CNAME, comienza a transmitir las respuestas de DNS falsificadas que incluyen una respuesta adicional (por ejemplo, ''security.debian.org'apuntando a la dirección IP de'badguy.com').
  • Si el Id. De transacción en la respuesta se adivina correctamente, el servidor detrás del firewall ahora piensa "security.debian.org'se resuelve a la dirección del chico malo.

Hay muchas formas de hacer que el servidor detrás del firewall busque una dirección IP, solicitudes internas de clientes, resolución de direcciones IP en los registros del servidor, etc. Bortzmeyer Menciona que el firewall es en gran medida irrelevante en este ataque.


3
2017-07-15 06:45



El hecho de que el servidor DNS esté detrás de un firewall o no es irrelevante aquí: el ataque funciona de todos modos. Y su explicación es incorrecta ya que, precisamente, security.debian.org NO está en la bailía de badguy.com. El artículo de Linux Journal que mencionas lo explica correctamente. - bortzmeyer
@bortzmeyer tienes razón, me he perdido un paso en el ataque. Creo que es correcto ahora. - Luke Quinane


Como lo mencionó Mark Johnson, el conjunto de servidores DNS es el conjunto De los dominios es autoritario para. A la vez, los servidores de nombres recursivos. se aceptan datos fuera de servicio de los servidores de nombres autorizados. Asi que, el servidor de nombres autorizado para foo.example podría agregar adicionales datos en su respuesta indicando la dirección IP de www.bar.example y él fue creido. Esta fue la base de la Ataque de Kashpureff. Para Por mucho tiempo, los servidores de nombres ya no creen en los datos fuera de bailía, como Instruido por RFC 2181, sección 5.4.1.

El ataque de Kaminsky hace no utilizar datos fuera de bailía y por lo tanto, trabajó con servidores de nombres recientes también. los Linux Journal El artículo mencionado por Luke Quinane lo explica muy bien (pero el resto del post de Luke Quinane, especialmente sobre cortafuegos es cuestionable)

Con respecto a los firewalls, esto es principalmente un problema no relacionado. Si un servidor de nombres quiere recibir respuestas a sus consultas, debe ser accesible para que, Ya sea que tenga un firewall o no enfrente de él, no importa: el El ataque de Kaminsky solo necesita un canal, el DNS.

Dado que el ataque Kaminsky está en el servidor de nombres que las máquinas cliente utilizará, ya sea que estas máquinas estén protegidas o no por el firewall no importa. (Un buen ejemplo de por qué un firewall no es una magia Dispositivo y no protege todo.)


6
2017-07-20 10:36