El documento introduce DNSSEC y explica cómo autentica las respuestas DNS para prevenir ataques como el envenenamiento de caché. DNSSEC logra esto firmando digitalmente cada zona con una clave privada y exponiendo la clave pública correspondiente, permitiendo a los clientes verificar la integridad y autenticidad de las respuestas. Además, cada dominio delegante mantiene un token criptográfico de la zona firmada para indicar que está firmada y verificar su clave pública.

1. DNSSEC. Introducción
TALLER DE CONFIGURACION DE DNSSEC

2. Domain Name System
u Nace en 1983 en sustitución del modelo host existente
u Sirve como traductor (guía de teléfonos) de nombres fácilmente
recordables a direcciones IP… y viceversa
u Es una base de datos, consistente, jerárquica, distribuida y delegada
u Las zonas de autoridad evitan la duplicación de registros
u Se parte de un nodo central que va delegando en zonas de autoridad los
subdominios creados, topología tipo árbol
u Cada zona de autoridad es responsable de sus recursos
u A su vez puede crear subdominios propios o delegarlos en nuevas zonas
u Su diseño lo hace extremadamente escalable y disponible… e inseguro
2

3. Escalable y disponible
u Utiliza mayoritariamente UDP. Recordemos qué es stateless y qué
significa
u Las respuestas se cachean para acelerar la disponibilidad de la
resolución
u No ofrece método de autentificación
u ergo…….
¡¡¡FACILMENTE SUPLANTAR LAS RESPUESTAS!!!
3

4. Estructura de una petición
4
DNS
k.root-servers.net
g.nic.es
Dns2.meh.es
ns1.dgcatastro.net
www.catastro.meh.es.
1
2
3
4
5
6
7
89
1
3
5
7
9

5. Amenazas a una petición
5
DNS
k.root-servers.net
g.nic.es
Dns2.meh.es
ns1.dgcatastro.net
www.catastro.meh.es.
Hacker inside

6. Envenenamiento de caché
6
u Ataque basado en lo previsible
u Si realizo una petición para un
determinado registro con una
determinada ID aceptaré el paquete si
me responde a ese registro con esa ID
u ID = 2 bytes
u Tengo una posibilidad entre 65536 para
acertar

7. Aleatoriedad (Ramdonnes)
u Aleatoriedad no tan aleatoria
u Teóricamente 2 bytes de posibilidades
u Aunque el generador de aleatoriedad de Bind 9.4.1 siempre generaba el
siguiente ID en un rango de más/menos 10 del anterior con lo que sólo
hacían falta 15 consultas para predecir el siguiente ID con fiabilidad
u Pero el malo aun necesita enviarme un buen número de paquetes
para conseguir que almacene en caché su respuesta… ¿o no?
u Si al ID le sumo los puertos posibles incremento 2 bytes más de
aleatoriedad
u Aunque no es posible la utilización de todas las interfaces
u No sólo resulta complicado en un ordenador aun cuando sólo lo dediquemos a
DNS, el paso por la electrónica de red modifica la cabecera de los puertos en
ocasiones (NAT)
7

8. Y llegó Dan Kaminsky…
u Todos felices hasta 2007
u Sabíamos de la posibilidad del envenenamiento de caché
u Aunque tenían que inundarnos a paquetes para conseguir introducirlo
en nuestra caché
u Mitigación mediante aumento en los TTLs
u Kaminsky y su bug
u Demostró que los elementos de mitigación no eran válidos:
u TTL no es un elemento de seguridad
u 65536 posibles respuestas son insuficientes para no ser engañado
8

9. Kaminsky’s bug para suplantar
www.example.com
u En la carrera por la respuesta el malo no se anda de brazos
cruzados, puede mandar miles de respuestas con diferentes IDs
suplantando www.example.com esperando que alguno acierte y
llegue antes que la respuesta correcta. Si manda 100 ya no es
1oportunidad entre 65536 sino 1 entre 655
u Si no acierto tendrá que esperar a que el registro se extinga por TTL
lo que puede suponer semanas para volver a intentarlo … ¿o no?
u Hagamos que el servidor busque un subdominio no existente y
respondámosle hasta introducir el registro en su caché:
1.example.com…. N.example.com
u En algún momento lograremos suplantar por ejemplo
666.example.com porque aquí no hay carreras. La TTL sólo funciona
para un único registro
9

10. ¡Hemos suplantado
666.example.com!!!
u ¿Pero no queríamos suplantar www.example.com? ¿Por qué querría
suplantar un dominio no existente? ¿Puedo terminar suplantando
www.example.com si he logrado suplantar 666.example.com?
u Tres posibles respuestas válidas del DNS ante una consulta sobre
666.example.com para lograr la suplantación:
1. 666.example.com es 6.6.6.6
2. No sé quién es 666.example.com
3. No sé quién es pero www.example.com en 6.6.6.6 lo sabe
1. Delegación pura y dura. Los raíces responderán vete a COM a preguntar
2. COM responderá vete a EXAMPLE.COM a preguntar
3. EXAMPLE.COM tendría que responder vete a www.example.com a preguntar
pero www.example.com no es un servidor de nombres y su dirección 1.2.3.4 si es
conocida
10

11. Suplantando www.example.com
en tres pasos
1. Envio una consulta a la víctima para un recurso no existente de
example.com, por ejemplo 123.example.com
2. Envío 200 respuestas a la misma victima con distintos IDs
redireccionando al servidor www.example.com y aquí está el
truco ya que respondemos:
a. 123.example.com IN NS www.example.com
b. www.example.com IN A 6.6.6.6
3. Si alguna de las respuestas llega ha funcionado, caché
envenenada. Si ninguna llega vuelvo al primer paso hasta
conseguirlo.
11

12. ¿Pero realmente esto vale para
algo al malo?
u Sin duda. Puede hacer que cualquier recurso parezca que viene de la
fuente original
u Recibir o enviar los correos de una organización
u Controlar los mecanismos SPAM
u Recibir llamadas SIP u otros servicios asociados a SRV del suplantado
u Redireccionar no sólo páginas web sino lo que es peor, código embebido
en ellas ¿Suplantamos Google analitycs?
u ¿Y un certificado emitido por una CA no me protege? ¿Cómo verifica la CA
que eres tu?
u Verifican tu dominio con WHOIS (Utiliza DNS lookup)
u Envian un correo al dominio a validar (Registro MX en DNS)
u Comprueban la web a firmar (Registro A en DNS)
u ¿Una buena pelicula de miedo? Mira la presentación de Kaminsky en
2008: http://www.slideshare.net/dakami/dmk-bo2-k8
12

13. Es una amenaza real
u Múltiples exploits
disponibles
13

14. Es una amenaza real
u Múltiples exploits
disponibles
14

15. Es una amenaza real
u Múltiples exploits
disponibles
u Bastantes ya lo han
conseguido
15

16. Es una amenaza real
u Múltiples exploits
disponibles
u Bastantes ya lo han
conseguido
u Amenaza real
16

17. De Bug a Flaw
u Demasiado grave para no tenerlo en cuenta así que puedo
mitigarlo o corregirlo
u Mitigarlo:
u Aleatoriedad del puerto. Paso de 1 oportunidad entre 65536 a 1 entre
163.840.000 a 2.147.483.648
u Demasiado tráfico para pasar desapercibido… aunque no el suficiente
u Nos basta haber actualizado nuestros DNS desde 2009… aunque todavía
encontramos DNS con BIND 9.2.x (2007)
u Corregirlo:
u Autentificando la respuesta con DNSSEC
u Requiere esfuerzo… no mucho
17

18. Por si fuera poco el tema de la
caché
u Problemas de MitM entre Registradores-Maestros y Maestros-
Esclavos
u Problemas de vulnerabilidades de servidor en Maestros y Esclavos
u Problemas de MitM entre Forwarders y Esclavos
u Problemas de MitM entre clientes y Forwarders
u Problemas de suplantación entre Forwarders y Esclavos
u Problemas de suplantación entre clientes y Forwarders
¡¡¡Todos los problemas de resolución quedan corregidos con DNSSEC!!!
18

19. DNSSEC
u ¿Qué nos ofrece DNSSEC?
u Autentificación del mensaje de respuesta del servidor DNS maestro y
verificación de su integridad
u Sin perder ninguna de las características de DNS
u Consistente, distribuido, jerárquico, escalable y disponible
u Compatible con DNS
u Pero no ofrece:
u Autorización, confidencialidad o protección contra la denegación de
servicio
u Lo consigue aplicando algoritmos de firma de clave criptográfica
pública a la información de resolución de nombres
19

20. DNSSEC aplicado
u El SOA firma cada uno de
los conjuntos de recursos de
su zona (El átomo del DNS)
20

21. DNSSEC aplicado
u El SOA firma cada uno de
los conjuntos de recursos de
su zona (El átomo del DNS)
u El SOA expone la clave
pública de firma de su zona
para que cualquiera pueda
verificar la firma
21

22. DNSSEC aplicado
u El SOA firma cada uno de los
conjuntos de recursos de su
zona (El átomo del DNS)
u El SOA expone la clave
pública de firma de su zona
para que cualquiera pueda
verificar la firma
u El dominio delegante
mantiene un token
criptográfico de la zona
firmada que:
u Indica que la zona está
firmada
u Verifica la clave pública de
la zona
22

23. Topología DNSSEC
23

24. 24
© 2015, Fernando Parrondo para 36bootis.com
Esta obra está sujeta a la licencia
Reconocimiento-NoComercial-CompartirIgual 4.0
Internacional de Creative Commons. Para ver una
copia de esta licencia, visite
http://creativecommons.org/licenses/by-nc-
sa/4.0/