Vulnerabilidad Dan Kaminsky (I)

Como es de suponer muchos de vosotros habréis leído por infinidad de sitios sobre la vulnerabilidad de DNS que ha provocado un revuelo considerable.

En esta entrada voy a "intentar" explicarla con un poco detalle para quien tenga curiosidad de cómo se producido y por qué.
Los requisitos para no perderse demasiado es saber cual es básicamente el funcionamiento del protocolo DNS. Para esto aconsejo los siguientes enlaces que lo explican y dan una visión general:

Wikipedia
Video tutorial

Una vez ya tenemos claro el mecanismo del protocolo DNS de manera genera y para que sirve, empezaremos en esta primera entrada explicando aquellas partes del protocolo implicadas en la vulnerabilidad para que después sea más fácil comprenderla:

Descripción del protocolo DNS

Lo primero que debemos saber y refrescar es cual es la estructura de un mensaje del protocolo rfc1035: Lo primero de todo es saber que un mensaje DNS se estructura 5 secciones:

1. Header
2. Question
3. Answer
   
4. Authority
5. Additional
   

A continuación se explicarán brevemente las secciones relevantes para entender la vulnerabilidad, no siendo el objetivo de esta entrada explicar todo acerca del protocolo, pero sí lo suficiente. Por lo que se explicarán Header, question y Additional Records.

1. Header

ID: Identificador de 16 bits que genera el que realiza la petición, este identificador se copia en la respuesta y puede ser utilizado por el que realiza la query para como que es la respuesta a su petición; pudiendo descartar respuestas de un tercero.

QR: Especifica si es una pregunta ó una respuesta.

Opcode: Indica el tipo de query.

AA: Si este bit está activo indica que el servidor de nombres que contesta es una autoridad del nombre de dominio.

TC: Mensaje truncado en la transmisión. RD: Si está activo le indicamos al servidor que continue la pregunta recursivamente. RA: En un respuesta nos indica si está activo si el servidor permite recursión. Z: no se usa. RCODE: Indica el tipo de respuesta. QDCOUNT: número de entradas en la sección de la pregunta. ANCOUNT: número de entradas en la sección dedicada a la respuesta. NSCOUNT: número de entradas en la sección dedicada a la AA. ARCOUNT: número de registros en la sección adicional.

2. Question

QNAME: nombre de dominio

QTYPE: tipo de query.

QCLASS: clase query.

3. Additional Records (Resource Record)

NAME: Nombre de dominio al cual este RR pertenece.

TYPE: contiene el tipo de RR. Especifica el significado de los datos de RDATA.

CLASS: especifica la clase de datos del campo RDATA.

TTL: Tiempo en segundos que el RR puede ser cacheado/almacenado, después debería ser eliminado. El valor de cero indica que no almacenes.

RDLENGTH: tamaño del campo RDATA.

RDATA: Variable que describe el recurso.

Ejemplo de una petición DNS

Esto sería el contenido de una query preguntando por www.google.es:

Ilustración 1: Query DNS

Observamos como tiene el bit Recursion Desired a 1 y el campo Questions a 1.

Lo siguiente sería la contestación del servidor DNS:

Ilustración 2: Response

Lo primero que se observa es como el ID es el mismo tanto en la pregunta como en la respuesta. Vemos como la respuesta incluye 5 recursos derivados de su pregunta, 2 alias y 3 registros de tipo host (A) que indican la dirección de red. Además vemos 7 Authority nameservers y 7 RR’s adicionales.

Con esto hemos visto cuales son los registros del DNS que después nos ayudarán a entender un poco mejor el ataque de Dan Kaminsky y cómo se realiza una petición sensilla a un servidor DNS. En una entra posterior veremos ataques existentes y el nuevo descubierto por Dan Kaminsky.