ARTICULOS LavulnerabilidadKaminskyde PDF

http://gabriel.verdejo.alvarez.googlepages.
com La vulnerabilidad Kaminsky del sistema DNS

Pgina 1 de 27
La vulnerabilidad del sistema de nombres
(DNS) de Dan Kaminsky

Por [email protected] - Noviembre 2008

Este documento est orientado a la divulgacin pblica de conocimiento por lo que los
aspectos tcnicos, si bien deberan ser rigurosos, son tratados de forma accesible para
cualquier persona con un mnimo de inters.

En este escrito se explica la vulnerabilidad del sistema de nombres (DNS) que Dan Kaminsky
[www1] dio a conocer durante el verano de 2008 y se realiza un breve anlisis de su impacto
en Internet.

La estructura de este documento se divide en dos apartados claramente diferenciados, que
todo y estar relacionados entre s, permiten al lector ir directamente a la parte que ms se
ajuste a su nivel o inters en el tema.

Anlisis tcnico: En este apartado se realizar una explicacin amena del protocolo
de resolucin de nombres orientado a la famosa vulnerabilidad. Se comentarn los
aspectos tcnicos ms relevantes y se complementar con un ejemplo prctico.

Impacto social: En la segunda parte de este documento se describir la cronologa
seguida por Dan Kaminsky en la gestin de esta vulnerabilidad y se reflexionar
brevemente sobre el impacto terico y real as como la gestin (modlica?) realizada
por parte de la comunidad.

To learn, read. To know, write. To master, teach" Yogi tea bag

1. Anlisis tcnico de la vulnerabilidad de Kaminsky

1.1 Convenciones y definiciones

Siempre que se realiza un documento en un idioma distinto a los que originalmente incluyen
la informacin, se produce una prdida por el cambio de contexto. Tambin hay que notar
que muchas veces las traducciones de una misma expresin varan en funcin del traductor.

De esta forma y para mantener el espritu riguroso de este manuscrito referenciaremos los
vocablos y expresiones anglfonas sin traducirlos. Dejamos como trabajo para el lector la
eleccin de la traduccin que considere ms adecuada.

Por cuestiones de eficiencia Internet se organiza jerrquicamente mediante direcciones IP,
estas direcciones pueden ser vistas como los nmeros de telfono dnde el prefijo, por
ejemplo, nos suele indicar a qu provincia estamos llamando.

http://gabriel.verdejo.alvarez.googlepages.com La vulnerabilidad Kaminsky del sistema DNS

Pgina 2 de 27

Para facilitar el uso de Internet a las personas, generalmente es ms fcil recordar un nombre
que una ristra de nmeros, se facilit un servicio que permitiera el uso indistinto de las
direcciones IP o sus nombres asociados. Al igual que pasa con el listn telefnico nicamente
necesitamos recordar el nombre de la persona para poder obtener su nmero de telfono.

El sistema de DNS (Domain Name System) [Stevens94][AL01][Liu02][www2][www3] es el
encargado, entre otras funciones importantes, de establecer las correspondencias entre los
nombres y las direcciones IP utilizadas en Internet.

A continuacin enumeraremos una serie de conceptos vitales para entender cmo funciona
este sistema de traduccin de nombres a direcciones:

Resolver Es la parte cliente del servicio DNS. Su funcin es la de realizar las
peticiones solicitando la direccin IP de un nombre.

Nameserver Es la parte servidora del DNS. Su funcin es la de contestar a las
peticiones de nombres recibidas.

Zone Es una lista que contiene las parejas <nombre> / <direccin IP>.
En realidad una zona puede contener ms informacin, pero para
nuestra explicacin esta simplificacin es suficientemente buena.

Delegation Cuando un nameserver no conoce el contenido de una zone pero sabe
a quien preguntar, utiliza un mecanismo de delegacin que consiste en
contestar a la peticin recibida indicando dnde se ha de buscar.

GTLD El Global Top Level Domain es el servidor que contiene toda la
informacin referente a un dominio de ltimo nivel.

En el caso del nombre www.google.com el GTLD correspondiente
sera el de .com, en el caso de www.rediris.es sera el .es y as
sucesivamente.

Authoritative nameserver Para cada una de las zone que puedan existir debe
haber un servidor que se encargue de esta traduccin.

Recursive nameserver Si un nameserver recibe una peticin de resolucin y no
conoce la respuesta, realiza a su vez las peticiones que
sean necesarias para acceder a la zone correspondiente
que contenga la respuesta.

Esta capacidad recursiva es configurable, de forma que
no siempre todos los servidores responden a todas las
consultas. Por ejemplo un proveedor de Internet (ISP)
que nicamente contesta peticiones de sus clientes.


Pgina 3 de 27
Resource record Adems de la traduccin <nombre> / <direccin IP>
que ya hemos comentado, los nameservers tambin
pueden proporcionar otros tipos de informacin til al
sistema [www60].

Ejemplos de este aspecto puede ser la obtencin de los
servidores de correo de un dominio (registros MX).

Root server El sistema de DNS proporciona un conjunto bsico de
servidores de forma que a partir de ellos se pueda
resolver cualquier peticin. Esta lista de servidores
bsicos es fija
1
y est permanentemente almacenada
en todos los Recursive nameservers.

Para investigar ms y ver el formato y funcin que
tienen estos servidores se puede consultar la bibliografa
adjunta [www4][www5].

1.2 Seguimiento de una peticin de resolucin de nombre para www.rediris.es

Para ejemplificar el funcionamiento del DNS realizaremos una peticin de ping a RedIris
[www29]. Este comando se suele utilizar para la comprobacin de la conectividad entre dos
ordenadores.

Este ejemplo es del todo inofensivo y consiste simplemente en enviar una peticin a
www.rediris.es para que nos la retorne. En el caso de utilizar Windows debemos abrir una
ventana de MS-DOS (figura 1) y para sistemas *Unix simplemente tener acceso a un shell o
x-terminal (figura 2).

Fig. - 1: Sesin MS-DOS en Windows.

1
Todo y que no es estrictamente cierto ya que algn Root server podra alguna vez cambiar su direccin IP, podemos asumir
perfectamente para nuestros propsitos que estos son siempre los mismos con las mismas direcciones.

Pgina 4 de 27

Fig. - 2: Xterminal en *Unix.

Lo primero que realizar nuestro ordenador es enviar una peticin a nuestro servidor de
nombres solicitndole la direccin IP de www.rediris.es (figura 3).

Obviamente para nuestro ejemplo debemos asumir que ninguna peticin se encuentra en la
memoria cach (lugar dnde se guardan las peticiones ya realizadas) de los servidores. Esto
nos permitir analizar en detalle todo el proceso.

Fig. - 3: Peticin del cliente al servidor DNS.

Una vez solicitada la peticin a nuestro servidor de nombres, este comprueba que no conoce
la respuesta (figura 4) y consulta entonces su base de datos interna de Root servers para elegir
uno al azar. Este mecanismo de seleccin aleatorio tiene como objetivo evitar el colapso de
un nico servidor balanceando las peticiones entre los distintos elementos del conjunto.

Una vez seleccionado uno de los servidores genera una peticin para reenviar la consulta
sobre el nombre de www.rediris.es. El Root server que recibe la peticin comprueba que no
conoce la respuesta y entonces responde proporcionando el GTLD que gestiona el dominio
solicitado (.es en nuestro caso).

NOTA: Efectivamente un ataque exitoso a todos los Root servers pondra en serios aprietos a
Internet. No profundizaremos ms en este tema por desviarnos de nuestro objetivo
inicial, pero s incluimos en la bibliografa los detalles de varios intentos de ataques
al servicio de DNS [www12][www13].


Pgina 5 de 27

Fig. - 4: Peticin del Recursive nameserser (ISP) al Root server.

Una vez recibido el GTLD del dominio .es nuestro Recursive nameserver le enva una
nueva peticin de solicitud (figura 5) de resolucin de nombre para www.rediris.es. El
servidor GTLD comprueba que no dispone de la respuesta y entonces busca en su base de
datos qu servidores se encargan del dominio de segundo nivel de la peticin (rediris.es en
nuestro caso).

Fig. - 5: Peticin del Recursive nameserser (ISP) al GTLD.

Una vez ms nuestro Recursive nameserver recibe una contestacin negativa a su pregunta
junto con un nuevo servidor al que debe preguntar. De esta forma vuelve a realizar la peticin
de resolucin de nombre (figura 6) para www.rediris.es y la enva al servidor encargado de
gestionar el dominio rediris.es.

Finalmente recibe una contestacin afirmativa dnde se explicita la direccin IP asociada al
nombre www.rediris.es (130.206.1.22).

Fig. - 6: Peticin del Recursive nameserser (ISP) al servidor del dominio rediris.es.

Una vez resuelta la peticin original por el Recursive nameserver este enva la respuesta
(www.rediris.es = 130.206.1.22) al usuario inicial, que realizar a su vez una conexin a la
direccin IP proporcionada (figura 7).

Cabe destacar que el sistema de cach de DNS se encarga de almacenar las ltimas peticiones
que se realizan por los usuarios de forma que no sea necesario realizar este proceso
incontables veces cada segundo para cada usuario.

Por otro lado, el sistema de DNS permite marcar cada una de estas respuestas con un perodo
de validez de forma que los nuevos cambios que se realicen sean visibles en un perodo de
tiempo finito. El TTL (Time To Live) [www6][www7] es el mecanismo que gestiona la
validez de los registros del sistema de DNS.


Pgina 6 de 27

Fig. - 7: Respuesta del Servidor DNS del ISP a nuestra peticin de www.rediris.es

1.3 Anlisis de las respuestas generadas en la resolucin de nombre de www.rediris.es

Una vez realizada la explicacin simplificada del proceso de resolucin de nombres, debemos
profundizar un poco ms para entender cmo funciona esta vulnerabilidad y cmo afecta al
servicio de DNS. Para seguir nuestro anlisis deberemos asumir que el lector est
mnimamente familiarizado con el protocolo TCP/IP [Stevens94][www14][www15].

Para los ejemplos que utilizaremos necesitaremos la herramienta DIG (Domain Information
Groper) [www8][www9] que nos permitir simular el comportamiento de un Resolver. En
caso de que no se tenga acceso a este programa se pueden utilizar versiones on-line como
[www10] o [www11].

Fig. - 8: Prototipo de paquete IP que utiliza el protocolo DNS.

Todas las peticiones de resolucin de nombres que se realizan a los diferentes servidores de
nombres circulan por Internet encapsuladas en datagramas IP (figura 8 [www6]).


Pgina 7 de 27
De todos los campos que contiene el datagrama IP, para nuestro estudio, la parte ms
relevante de estas peticiones hace referencia al Query ID que es el identificador de peticin
que crea el cliente cada vez que desea realizar una resolucin de nombres. De esta forma el
cliente puede solicitar simultneamente varias peticiones para nombres distintos (cada una
con un Query ID diferente) y no confundir las respuestas.

Este identificador es muy importante ya que no slo nos permite disfrutar de un mecanismo
que permite solicitar varias peticiones de resolucin de nombres concurrentes (por ejemplo
abrir un navegador con dos pestaas o tabs distintas, una a www.google.es y otra a
www.rediris.es) si no que tambin nos protege de respuestas no solicitadas.

Al recibir una respuesta DNS lo primero que se realiza es una comprobacin de los Query ID
pendientes. Si existe una peticin pendiente de resolverse con ese identificador, se acepta la
respuesta. Si no existe ninguna peticin pendiente o la peticin no coincide exactamente con
la que formul el cliente, el paquete recibido es descartado inmediatamente.

A continuacin analizaremos los mensajes que se van intercambiando en este proceso de
resolucin de nombres ya que es aqu dnde reside la clave del ataque Kaminsky. Podemos
observar un ejemplo de respuesta a la peticin de resolucin del nombre www.rediris.es en la
figura 9.

gaby@servidor:~$ dig www.rediris.es

; <<>> DiG 9.3.4-P1.1 <<>> www.rediris.es
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21940
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 7

;; QUESTION SECTION:
;www.rediris.es. IN A

;; ANSWER SECTION:
www.rediris.es. 2785 IN CNAME babia.rediris.es.
babia.rediris.es. 2785 IN A 130.206.1.22

;; AUTHORITY SECTION:
rediris.es. 814 IN NS sun.rediris.es.
rediris.es. 814 IN NS scsnms.switch.ch.
rediris.es. 814 IN NS ns02.fccn.pt.
rediris.es. 814 IN NS chico.rediris.es.

;; ADDITIONAL SECTION:
sun.rediris.es. 3321 IN A 130.206.1.2
ns02.fccn.pt. 2677 IN A 193.136.2.228
ns02.fccn.pt. 2408 IN AAAA 2001:690:a80:4001::200
chico.rediris.es. 3320 IN A 130.206.1.3
scsnms.switch.ch. 110003 IN A 130.59.1.30
scsnms.switch.ch. 110003 IN A 130.59.10.30
scsnms.switch.ch. 110003 IN AAAA 2001:620::1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Oct 10 23:16:04 2008
;; MSG SIZE rcvd: 298

Fig. - 9: Peticin del cliente al servidor DNS usando DIG.

Si analizamos el mensaje de la figura 9 podemos observar claramente una serie de apartados
que nos aportan diferente informacin relevante [AL01]:


Pgina 8 de 27
Question Section: Contiene la peticin original que se ha realizado. La especificacin
actual impide que exista ms de una peticin en este campo.

Answer Section: En este apartado se incluyen los Resource records. Este apartado s
puede contener varios registros correspondientes a la consulta, por ejemplo en casos
de multihoming
2
.

Authority Section: Explicita los registros de los servidores de nombre (NS records)
referentes a la peticin solicitada.

Additional Section: Contiene la informacin que permite completar el resto de
secciones. Por ejemplo en el caso de existir varios servidores de nombres se explicitan
sus direcciones IP para que puedan ser contactados.

1.4 DNS poisoning

El envenenamiento de la cach DNS (DNS poisoning) es un mecanismo que busca falsear las
correspondencias <nombre> / <direccin IP> que almacenan los Nameserver. Este tipo de
ataques busca redireccionar todo el trfico de los clientes hacia los servidores que controla el
atacante.

Es importante diferenciar este tipo de ataques del Phishing [www17][www18] dnde se
intenta engaar al incauto enmascarando la realidad tras unos engaos ms o menos
sofisticados de forma que este pique el anzuelo.

Un ejemplo tpico de Phising podra ser pedir dinero para una ONG por alguna catstrofe
natural adjuntando un enlace a http://www.cruzroja.es que en realidad apunta a una copia
fraudulenta del tipo http://www.cUrzroja.es que el atacante controla.

En el caso del DNS poisoning el usuario a todos los efectos se est conectando a
http://www.cruzroja.es ya que su DNS ha resuelto la peticin correctamente! Como
podemos observar este tipo de ataques son potencialmente mucho ms peligrosos ya que
afectan a todos los usuarios que utilicen el servidor de nombres infectado (imaginemos el
caso de un DNS de un gran ISP).

Afortunadamente no es tan sencillo engaar al sistema de DNS ya que para que una
peticin pueda ser falseada debe cumplir con estos cuatro requisitos:

1. El Query ID recibido en la respuesta ha de corresponderse con un identificador de
consulta pendiente en el cliente. En la prctica esto significa que el atacante debe
adivinar este identificador, de ah la importancia que sea escogido de forma aleatoria.

2. El apartado Question section ha de corresponderse exactamente con la pregunta
original formulada por el cliente. Si hemos preguntado por www.rediris.es no
aceptaremos respuestas a www.google.es.

2
Casos en los que varios nombres estn asociados a una misma direccin IP.

Pgina 9 de 27

3. Los apartados Authority section y Additional section de la respuesta han de pertenecer
al mismo dominio que la peticin original. Esta restriccin exige que si estamos
preguntando por www.rediris.es en la respuesta no se aada una refeerncia para otro
dominio (por ejemplo www.google.es) que no sea el solicitado expresamente.

4. La respuesta, ver formato de la cabecera UDP de la figura 8, ha de llegar por el
mismo puerto que fue solicitada. Al igual que ocurre con el Query ID que nos permite
simultanear varias peticiones, el protocolo UDP tambin nos permite varias
conexiones discriminando por el valor del puerto UDP de origen (source port).

Una respuesta a una peticin de resolucin de nombres que cumpla las restricciones
anteriores es considerada vlida y por tanto se utilizar en la resolucin de nombres
correspondientes a ese dominio y en la cach del servidor (al menos por el perodo
establecido por el TTL).

Para adivinar el Query ID podemos utilizar varias tcnicas dependiendo de la versin y del
servidor de nombres. Actualmente existen decenas de programas que realizan las funciones
de servidores de DNS [www19][www20] y cada una de ellas tiene incontables versiones. De
esta forma como siempre sucede en estos casos, el sistema de prueba y paciencia es el que
mejor funciona.

Por otro lado cabe recordar que como ya se ha indicado anteriormente las respuestas que no
son correctas simplemente se ignoran, permitiendo al atacante usar la fuerza bruta para
generar cientos o miles de peticiones con el objetivo de mejorar la probabilidad de acierto.

En el caso de versiones antiguas de servidores DNS, el Query ID se generaba simplemente
incrementando en uno el nmero anterior. Este sistema poco sofisticado permite que la
probabilidad de adivinar el identificador sea muy alta ya que simplemente debemos espiar
la red o provocar que nos realice una peticin de resolucin de nombres para adivinar el
nmero a partir del cual debemos probar.

La clave consiste en obligar al cliente a realizar una peticin a un Nameserver que
controlemos. Existen muchas maneras creativas de realizarlo, por ejemplo podemos enviar un
email o crear una pgina web con una referencia a nuestro dominio de forma que casi de
forma automtica y sin que el cliente se de cuenta nos enve la informacin que necesitamos.

Para nuestro ejemplo podemos suponer que tenemos el control del dominio ficticio de
Internet dominiomalo.com. Nuestro objetivo es que los distintos clientes se conecten para
resolver la direccin IP asociada al nombre malisimo.dominiomalo.com.

NOTA: Obviamente todo este sistema queda enormemente simplificado si tenemos acceso a
espiar la red por la que circulan las peticiones del cliente.

Una vez que el cliente realiza la peticin a un servidor que ya controlamos, podemos obtener
el Query ID y el puerto UDP utilizados. Adems en este momento tenemos una peticin
legtima de un cliente a un dominio que controlamos y que es Authoritative para
dominiomalo.com

Para iniciar nuestro ataque realizamos una peticin de resolucin al Nameserver que utiliza

Pgina 10 de 27
nuestra vctima con el nombre que deseamos suplantar (www.rediris.es en nuestro ejemplo).

Fig. - 10: Solicitud de resolucin de nombre por parte de un cliente fraudulento.

El atacante, una vez que ha elegido el nombre a suplantar, sabe que en un breve perodo de
tiempo (ver procedimiento explicado en el punto 1.2 de este documento) el Recursive
nameserver solicitar el nombre del servidor GTLD para obtener el servidor del dominio
rediris.es (ver figura 10) que en nuestro caso es sun.rediris.es.

NOTA: Obviamente debemos asumir que la respuesta a nuestra peticin fraudulenta no se
encuentra en la cach del servidor, ya que entonces todo el proceso de resolucin de
nombre no se realiza y nuestro ataque deja de ser efectivo.

Es en este mismo momento dnde el atacante empieza a bombardear al Recursive nameserver
con miles de respuestas falsas creadas usando sucesivos Query ID
3
y completndolas con los
datos del puerto UDP y las secciones que ya conoce (ver figura 11).

El objetivo del atacante es doble:

Acertar el Query ID con alguna de las peticiones fraudulentas.

Que la respuesta fraudulenta llegue antes que la autntica ya que una vez contestada
el Query ID deja de estar pendiente y por tanto se descartan segundas respuestas.

Cabe destacar que debido a que el atacante necesita asegurarse que sus respuestas
fraudulentas lleguen antes que las legtimas y que cuantas ms genere ms posibilidades de
xito tendr, el consumo de ancho de banda para este ataque puede ser grande. Existen
diferentes argucias que se pueden emplear como ir atacando servidores prximos
geogrficamente (por ejemplo consiguiendo acceso a una o varias mquinas de la red del ISP
y utilizarlas como lanzaderas) o realizar respuestas fraudulentas coordinadas desde ms de
una fuente.

Otra posibilidad es la de silenciar al servidor que enve la respuesta legtima generando un
ataque de denegacin de servicio Distribuido (DDOS) [www22][www23][www24] de forma
que el atacante pueda probar tranquilamente todas las combinaciones y casi asegurarse al
100% el xito del ataque.

3
No necesariamente consecutivos ya que el atacante podra ser capaz de predecir la secuencia aleatoria.

Pgina 11 de 27

Fig. - 11: Bombardeo de respuestas fraudulentas para suplantar la identidad.

Una vez conseguido su objetivo la respuesta fraudulenta se almacena en la cach del servidor
y es utilizada para todos los clientes que la soliciten. Es ms, como la peticin aceptada es la
nuestra podemos indicar en la respuesta cual es el Authoritative nameserver para todo el
dominio
4
! (ver figura 12).

Pese a que muchos servidores eligen los campos de UDP port y Query ID de forma aleatoria,
la realidad suele ser que las secuencias son predecibles y por tanto reproducibles. Esto es lo
que hace tan importante la paciencia del atacante y el trabajo previo de investigacin que
permita averiguar que secuencia utiliza nuestra vctima.

La implementacin de funciones realmente aleatorias es un problema clsico en informtica
que ya ha dado varias vulnerabilidades gloriosas. Podemos destacar una reciente en la
distribucin de Linux Debian [www21].

Fig. - 12: Suplantacin de www.rediris.es para todos los usuarios del ISP.

4
Este aspecto es importante y lo retomaremos en el ataque Kaminsky [www16].

Pgina 12 de 27

1.5 La vulnerabilidad de Kaminsky

Como hemos analizado en el apartado anterior gran parte de la problemtica se solventa con
el uso de funciones realmente aleatorias. Sin embargo cabe destacar (ver figura 8) que el
campo del Query ID es de 16 bits con lo que el espacio de posibles combinaciones es de
65535 posibilidades.

Si bien es un nmero razonable de posibilidades actualmente (el potencial atacante debera
generar decenas de miles de respuestas antes de que llegara la respuesta legtima) la
posibilidad de que las funciones no sean tan aleatorias como se pretende o el incremento
constante del ancho de banda disponible hacen que no debamos perder de vista este aspecto.
Por otro lado la longitud de este campo no puede ser variada, es un estndar que usa toda
Internet!, sin modificar todos los servidores DNS.

Hasta ahora hemos visto que secuestrar un nombre concreto en el sistema de DNS requiere
un cierto volumen de trabajo. Si nuestros objetivos son ms ambiciosos (redireccionar el
correo, todos los servidores web del dominio...) podemos observar cmo la cantidad de
trabajo a realizar lo hace prcticamente inviable.

La vulnerabilidad descubierta por Dan Kaminsky [www16][www25][www26][www27] da
una vuelta de tuerca ms al procedimiento anterior creando una respuesta fraudulenta que nos
permitir secuestrar el Authoritative nameserver y por tanto todo el dominio!.

El primer paso consiste en configurar un servidor de DNS de realice las funciones de
Authoritative nameserver del dominio a secuestrar (rediris.es en nuestro caso). Obviamente
en este DNS fraudulento tendremos configurados todos los registros (Resource records
[Liu02]) de forma que se resuelvan a nuestras direcciones IP que contendrn las copias de las
webs y servicios a secuestrar.

Dependiendo de la sofisticacin que deseemos alcanzar, nicamente necesitamos modificar
las respuestas a un nombre concreto (por ejemplo www.rediris.es) y resolver el resto con las
direcciones IP legtimas o replicar toda la estructura del dominio lo que nos permitira entre
otras cosas acceso a todo su correo.

NOTA: No hay ningn problema en que cualquier persona se configure su propio servicio de
DNS que resuelva cualquier dominio de Internet. Sin embargo no es muy til ya que
nadie (excepto nosotros mismos) lo utilizar. Con Kaminsky esto cambia.

A continuacin (figura 13) debemos forzar la resolucin de un nombre perteneciente al
dominio a secuestrar que no se encuentre en la cach del DNS atacado. Una manera de
asegurarnos este punto puede ser creando nombres aleatorios que pertenezcan al dominio por
ejemplo x12123424.rediris.es o x32321.rediris.es.

Una vez generadas las peticiones de resolucin de nombres maliciosas, al igual que en el
DNS poisoning, el atacante bombardea al DNS con una serie de respuestas fraudulentas con
el objetivo de adivinar el Query ID. Sin embargo estas respuestas no contienen como antes la
direccin IP del nombre solicitado, si no que indican que no se conoce la direccin IP y que
ha de preguntar al Nameserver que controlamos (ver figura 14) para obtener la respuesta final
(la explicacin del proceso de resolucin se encuentra en el punto 1.2 de este documento).

Pgina 13 de 27
Fig. - 13: Forzando la resolucin de nombres aleatorios del dominio rediris.es

Adems como parte de esta respuesta fraudulenta se adjunta en el campo Additional section
la direccin IP del servidor ilegtimo de DNS que controlamos (ver figuras 9 y 14). De esta
forma podemos incluso dar el nombre real del servidor del dominio atacado ya que falseamos
su direccin IP.

A partir de ese momento, ya que queda almacenada en la cach del servidor DNS del ISP,
todas las peticiones de resolucin de nombres asociadas al dominio rediris.es pasaran a
resolverse por el servidor DNS del atacante. Razonablemente todas las respuestas que genere
el servidor fraudulento de DNS proporcionaran un valor TTL lo ms alto posible.

Fig. - 14: Bombardeo de respuestas maliciosas a las peticiones fraudulentas realizadas.

Este ataque puede optimizarse generando varias peticiones de resolucin de nombres
aleatorios que no existan en la cach. De esta forma si por ejemplo el atacante puede generar
50 respuestas fraudulentas antes de que el DNS legtimo responda, puede ir probando
continuamente con nombres distintos hasta que finalmente su peticin sea aceptada.


Pgina 14 de 27
Un posible ataque DDOS [www23][www24] al servidor o servidores DNS que generan la
respuesta legtima con el objetivo de consumir su ancho de banda o incluso colapsarlos
podra incrementar el nmero de respuestas fraudulentas que el atacante podra realizar.

Cabe destacar que este ataque conceptualmente tambin podra generalizarse perfectamente
para secuestrar todo un GTLD (Global Top Level Domain) con lo que por ejemplo todos los
subdominios de .es o de .com estaran comprometidos, lo que equivale en la prctica a
dominar Internet.

1.6 Cmo mitigar la vulnerabilidad de Kaminsky?

Como ya hemos visto anteriormente, la atenuacin del impacto que produce este ataque pasa
por el uso de funciones realmente aleatorias de forma que se dificulte al mximo la
posibilidad de acertar los campos claves (ver figura 8):

Query ID: El identificador de la peticin de resolucin de nombres es un campo de 16 bits
que nos deja un espacio de 65536 posibilidades.

Source port (UDP): El puerto de origen de la comunicacin UDP es tambin un nmero de
16 bits que nos deja un espacio de 65536 posibilidades.

Si utilizamos ambos campos para extender el espacio de claves tenemos 32 bits lo que nos da
un total de 4.294.967.296 alternativas.

Desgraciadamente es complicado reservar todo el espacio de puertos UDP de un sistema ya
que muchos otros protocolos y programas lo utilizan como sistema de comunicacin (NFS,
Skype, Windows...). De esta forma nuestro espacio real de posibilidades queda reducido
considerablemente, aunque en la actualidad es considerado seguro.

En el caso de Microsoft [www28] para sus sistemas Windows ha optado por reservar un
mximo de 2500 puertos UDP aleatorios lo que nos deja un espacio de algo ms de 160
millones de posibilidades.

2500 (UDP) * 65536 (Query ID) = 163.840.000

Otra posibilidad bastante ingeniosa que se ha planteado, y adems es compatible con la
anterior, es la de utilizar el bit 0x20 [www49][www108][www109][www110]. En las letras
del abecedario (a-z, A-Z), su representacin ASCII permite jugar con el uso de este bit para
crear combinaciones de maysculas y minsculas.

www.rediris.es = WwW.rEdIrIs.Es = wWw.ReDiRiS.eS

De esta forma, como la peticin de nombres es insensible a maysculas o minsculas y como
la respuesta debe incluir la peticin original realizada, el posible atacante no slo debe
adivinar el QueryID y el Puerto UDP, si no que debe adivinar tambin la combinacin
ganadora de maysculas y minsculas.


Pgina 15 de 27
2. Impacto social

2.1 Cronologa oficial

A continuacin realizaremos una reconstruccin tan pormenorizada como sea posible del
proceso que se ha seguido en la gestin de esta vulnerabilidad. Este seguimiento se inicia
antes de empezar el ao 2008 y abarca hasta finales de Agosto de ese mismo ao. La
seleccin de este perodo de tiempo nos permitir conocer cmo y quien descubri esta
vulnerabilidad, que proceso de gestin se realiz hasta su anuncio pblico el mes de Julio y
finalmente la evolucin y respuesta de la comunidad.

La informacin utilizada en este apartado se ha obtenido principalmente de los propios
comentarios de Dan Kaminsky accesibles desde su Blog personal [www16] as como de
varias entrevistas aparecidas en distintos medios de comunicacin [www50][www54]
[www55][www56].

A finales del ao 2007 Dan se encontraba trabajando en un proyecto que implicaba la
eleccin de la ruta ms rpida para servir datos desde distintos servidores web en el contexto
de triangular routing [SJ08][www59].

Como parte de estas pruebas empez a explorar distintas posibilidades relacionadas con el
servicio de DNS y los Resource records [www60]. Dentro de los experimentos que realiz
empez a comprobar la posibilidad de actualizar los registros de dominio del DNS mediante
el uso de nombres aleatorios para acelerar el proceso del intercambio de datos.

A inicios del 2008 [www38] y como fruto de estas pruebas descubre que es posible modificar
la cach de los servidores DNS para inyectar nueva informacin mediante respuestas creadas
especficamente saltndose el procedimiento ordinario de resolucin de nombres. Una vez
verificado el procedimiento y tras comprobar que con una implementacin de su programa
realizada en lenguaje C puede conseguirse en menos de 10 segundos, toma conciencia del
problema de seguridad que implica esta vulnerabilidad.

El 20 de Febrero, una vez verificado el impacto potencial y tras comentarlo con gente de
confianza perteneciente a su entorno ms cercano, Dan contacta con Paul Vixie [www61]
[www62] del Internet Systems Consortium, ISC [www63]. Es a partir de este punto dnde
empieza el intercambio de emails entre las distintas personalidades del sistema de DNS y las
empresas ms importantes del sector (CISCO, Microsoft, Yahoo...).

El da 31 de Marzo un equipo de emergencia cuidadosamente seleccionado y formado por 16
personas de todos los rincones del mundo se rene en los cuarteles generales de Microsoft. La
empresa de Bill Gates generosamente accede a proporcionar toda la infraestructura necesaria
para que este grupo pueda evaluar el impacto real de esta vulnerabilidad y realice el trabajo
necesario para solventarlo.

Finalmente el martes 8 de Julio de 2008, que pasar a la historia de Internet como la primera
gran accin coordinada por motivos de seguridad en la red, en una conferencia de prensa
multitudinaria se presentan simultneamente las actualizaciones para todos los servicios de
DNS relevantes en Internet [www64][www65].


Pgina 16 de 27
El da 9 de Julio Dan Kaminsky publica en su blog personal [www30] una entrada con el
ttulo An astonishing collaboration en la que seala la existencia de una terrible
vulnerabilidad en el servicio de nombres (DNS). En su escrito detalla de forma general cuatro
puntos principales que hacen referencia a esta vulnerabilidad as como al proceso que se ha
seguido para minimizar su impacto en Internet.

1. Es una vulnerabilidad multi-plataforma, es decir, es independiente del hardware en el
que funcione.

2. Es un fallo de diseo del protocolo DNS y por tanto es el mismo para casi todas las
implementaciones de este servicio, independientemente del sistema operativo.

3. Se ha conseguido que, para la mayora de los sistemas existentes, se publiquen las
versiones corregidas del software simultneamente.

4. Por primera vez en la historia de Internet se ha conseguido una accin coordinada ante
una vulnerabilidad tan importante.

Tambin agradece la colaboracin de grandes empresas como Microsoft, CISCO o Yahoo en
la gestin de esta vulnerabilidad. Detalla incluso el caso de Yahoo que se ha visto obligado a
abandonar la versin 8 del programa BIND [www31] para utilizar la ltima actualizacin de
la versin 9 que corrige este problema
5
.

Adems solicita a la comunidad de Internet una moratoria de 30 das para evitar las
especulaciones pblicas y dar tiempo para que los correspondientes administradores de
sistemas puedan actualizar sus servidores DNS.

Finalmente emplaza a toda la comunidad a la conferencia que realizar en Las Vegas dentro
del Defcon [www33][www34] el da 6 de Agosto de 2008 dnde desvelar los detalles de
esta vulnerabilidad.

El lunes 21 de Julio Thomas Dullien, conocido por su alias Halvar Flake, publica una entrada
en su blog [www53] en la que cuestiona la utilidad de esta moratoria de especulaciones
pblicas con el argumento de que hackers profesionales s van a especular y ganar 30 das de
calma puede crear una sensacin de falsa seguridad.

De esta forma Dullien apunta la posibilidad de que este fallo est relacionado directamente
con la generacin de respuestas espurias por parte de un atacante. Dada una consulta de un
servidor DNS el atacante le enviar respuestas fraudulentas con el objetivo de suplantar al
servidor de nombres legtimo que resuelva el dominio. A partir de este instante decenas de
blogs de seguridad se hacen eco de esta posibilidad y empiezan a desarrollar esta teora.

Este mismo da, cabe destacar que estamos hablando de diferentes zonas horarias, en el blog
de Thomas Ptacek [www52] empleado de la empresa de seguridad Matasano [www68] (que
ya estaba al corriente de la vulnerabilidad Kaminsky) aparece una entrada que describe con
precisin el ataque. Si bien a las pocas horas se retira el comentario y se solicita pblicamente
disculpas, ya es tarde, miles de sitios en Internet se han hecho eco de este post.

5
Cabe destacar que el software de DNS de Dan J. Bernstein [www32] no se ve afectado por esta vulnerabilidad, demostrando que un
buen trabajo de ingeniera del software es posible en informtica.

Pgina 17 de 27
El da 22 de Julio y tras desvelarse la vulnerabilidad Kaminsky la prctica totalidad de
revistas, boletines y blogs de seguridad de Internet reproducen los acontecimientos del da
anterior en una vorgine de informacin, comentarios y opiniones [www51][www54]
[www55][www56][www69][www70]. Incluso el mismo Dan Kaminsky intenta aclarar la
situacin concediendo una entrevista a la conocida revista Wired [www37][www38] pero ya
es demasiado tarde, la gestin controlada de la vulnerabilidad ha fracasado.

El da 23 contina la resaca de comentarios y especulaciones sobre el impacto real de la
vulnerabilidad y los posibles exploits
6
existentes. Especialistas en seguridad como Bruce
Schneier publican sus puntos de vista para evitar que se mate al mensajero [www71].

El 24 de Julio Dan publica un post en su blog [www41] con el ttulo de Details dnde
realiza una explicacin detallada de su vulnerabilidad y proporciona algunos datos con el
objetivo de contrarrestar las acusaciones de afn de protagonismo y alarmista. Entre los datos
que proporciona se encuentra el de estimaciones personales sobre servidores vulnerables al
ataque (85% el 9 de Julio, 50% el da 24) que confirman la necesidad de aplicar los parches y
la importancia de disponer de una ventana de tiempo para que los administradores puedan
actualizar sus sistemas (si bien en realidad han sido 13 das en vez de los 30 que solicitaba).

El da 26 de Julio Kaminsky vuelve a realizar una entrada en su blog dnde comenta muy
escuetamente la situacin antes de la publicacin de su vulnerabilidad, el peligro una vez
divulgada y la situacin final una vez actualizado el servicio de DNS con los parches.

Los das siguientes siguen marcados por los comentarios y exposiciones que expertos en
seguridad, supuestos en muchos casos, realizan en los medios de comunicacin justificando o
atacando a Dan. Podemos destacar a nivel de resumen esta reflexin de Schneier [www72].

El 6 de Agosto de 2008 sobre las 11.15 horas, Dan Kaminsky presenta en la conferencia
Black Hat de Las Vegas [www75] su trabajo sobre la vulnerabilidad del sistema de nombres
(DNS) [www74][www76].

El viernes 8 de Agosto Dan publica en su blog un post [www45] a modo de resumen que
recoge los aspectos ms importante sobre la charla realizada en la conferencia de Las Vegas y
destaca lo insegura que es Internet en general ya que no existe un nico punto crtico de fallo,
sino que muchos aspectos son potenciales talones de Aquiles y por tanto la gestin de la
seguridad ha ser tratado como algo global y no nicamente como un problema aislado de un
protocolo.

El da 9 de Agosto Dan publica en su blog una interesante entrada de ttulo On the flip side
[www46] donde justifica la eleccin realizada para solventar esta vulnerabilidad ante las
crticas recibidas por parte de la comunidad de especialistas en seguridad.

En realidad, como nunca se ocult, la actualizacin proporcionada no elimina la posibilidad
de este ataque si no que la minimiza incrementando el espacio de posibilidades de 65356 a
varios cientos de millones.

6
Programa o conjunto de tcnicas que permite explotar una vulnerabilidad dada en un sistema o servicio para obtener un beneficio
ilcito.

Pgina 18 de 27
En muchas de estas discusiones se plantean otras alternativas a la escogida, como por
ejemplo DNSSEC [www78][www79]. Incluso se discuten nuevos modelos de gestin de
seguridad en el desarrollo de aplicaciones y los paralelismos de gestin existentes frente a
una red hostil y una red segura. Daniel J. Bernstein [www77] es un ejemplo a seguir en este
aspecto ya que ha demostrado con sus programas que si nos tomamos en serio la seguridad y
forma parte bsica del diseo en las aplicaciones y protocolos, estos tipos de ataques
oportunistas quedan enormemente mitigados (aunque no eliminados).

El 27 de Agosto Kaminsky reflexiona en su blog sobre la seguridad en Internet en una resea
titulada The emergence of a theme [www47] dnde seala como toda la red es vulnerable y
no nicamente por el protocolo DNS. Protocolos clave como BGP [www80], SNMPv3
[www81] o SSL [www82] entre otros, que tambin han sido objeto en los ltimos meses de
grandes vulnerabilidades cuyo impacto es equiparable a la del servidor de nombres. El
problema cada vez pasa a ser menos tcnico y ms poltico, quien le pone el cascabel al gato
en Internet?

Este mismo da Gabriel Somlo [www83] enva un correo electrnico a la lista de usuarios del
programa BIND proponiendo una solucin para este problema nicamente cambiando un
carcter
7
(One-character patch) [www57]. La propuesta que realiza Somlo consiste,
aproximadamente, en mantener las respuestas en la cach del servidor hasta que caduquen, es
decir, que se cumpla en su totalidad su plazo de validez o TTL. El cruce de correos sobre esta
nueva propuesta se sucede internamente en la lista durante un par de das.

Finalmente el 29 de Agosto una de las webs de noticias ms consultadas en Internet,
Slashdot, publica esta nueva aportacin de Somlo [www84]. A partir de este momento y
como suele pasar con este asunto, cientos de servicios de noticias de todo el mundo se hacen
eco de esta posibilidad extendiendo el rumor por Internet [www85].

Este mismo da y obligado una vez ms por las circunstancias, Dan Kaminsky que considera
muy peligrosa esta propuesta, publica en su blog un anlisis detallado de esta y otras
aportaciones en dos artculos titulados Please do not destroy DNS in order to save it
[www48] y Towards the next DNS fix [www49].

El argumento que esgrime Kaminsky contra esta posible solucin es que puede pervertir una
de las caractersticas importantes del DNS, su flexibilidad. Si realizamos un cambio de
direccin IP en un nombre ya resuelto, por ejemplo porque se ha estropeado el servidor web,
este cambio no ser visible para los servidores que implementen esta funcionalidad
mientras el anterior siga siendo vlido (no se haya cumplido su TTL).

Los meses de Septiembre y Octubre de 2008 no aportan mucha ms informacin sobre este
tema por lo que no han sido detallados. En caso de que el lector desee una perspectiva ms
amplia puede consultar la bibliografa adjunta.

2.2 Controlar lo incontrolable

A primera vista podemos observar un ejemplo modlico de coordinacin en la gestin de
vulnerabilidades por parte de los especialistas de seguridad que la descubren, las empresas y

7
Concretamente su propuesta es la de cambiar una comparacin estricta del tipo A < B por una ms laxa del tipo A <= B.

Pgina 19 de 27
los desarrolladores. Se plantea incluso la posibilidad de establecer este mecanismo como
modelo de comunicacin de vulnerabilidades por parte de los CERT [www35][www36]. Sin
embargo al realizar una exploracin minuciosa podemos observar que tal vez no sea todo tan
idlico como aparenta.

Para simplificar el anlisis que realizaremos en este apartado, dividiremos en tres partes la
gestin detallada en el punto anterior:

1. Descubrimiento del problema y desarrollo de la solucin: Este apartado abarca
desde finales de 2007, cuando Kaminsky es consciente de la gravedad de la
vulnerabilidad, hasta el 7 de Julio de 2008.

2. Anuncio pblico: En esta parte incluiremos las 48 horas posteriores al anuncio
mundial de la vulnerabilidad realizado el 8 de Julio.

3. Libre albedro: Perodo de tiempo que va desde el anuncio pblico hasta la fecha de
este escrito (Noviembre de 2008).

2.2.1 Descubrimiento del problema y desarrollo de la solucin

Cuando Dan es consciente del problema y decide cual es su siguiente paso, fija para siempre
el rumbo de los dos primeros apartados. En vez de publicar un exploit en cualquiera de los
miles de webs de seguridad o en su mismo blog, intentar vender o aprovecharse de su
conocimiento, decide buscar un peso pesado de la comunidad como Paul Vixie.

Esta decisin que es la correcta, al menos moralmente, no deja de ser un salto al vaco ya que
debido al calado del problema haba muchas posibilidades de que una vez reportado, quedase
apartado del proceso por las diferentes empresas y organismos que tomasen el control.

Afortunadamente, segn mi opinin no nicamente para Dan si no para toda Internet,
Kaminsky pas a ser colaborador de pleno derecho organizando las diferentes sesiones de
trabajo y contribuyendo en la evaluacin e implementacin de las soluciones.

La importancia de que Kaminsky no quedara relegado del proceso es clave, ya que su
conocimiento no slo de la vulnerabilidad en s si no de cmo lleg a descubrirla es bsica
para proporcionar una solucin razonable. A fin de cuentas hay que ser muy ingenuo para no
pensar que antes o despus podra aparecer otro Dan Kaminsky.

Contar con su visin permite de primera mano evaluar las soluciones desde el punto de vista
adecuado, la del usuario real y experimentado, evitando la tentacin de una nica visin
acadmica o terica. No hay que olvidar que mayoritariamente los hackers viven de estas
visiones nicas.

Una vez seleccionado discretamente un grupo de trabajo (no he conseguido detalles sobre el
criterio seguido) que generosamente acoge Microsoft, se establece un plan que consiste en
buscar una solucin, comunicarla a los distintos fabricantes para que la implementen de
forma discreta con el objetivo de proporcionar simultneamente las actualizaciones a toda la
comunidad de Internet, y hacer un aviso pblico conjunto de esta vulnerabilidad sin incluir
detalles.

Pgina 20 de 27
La discrecin con la que se ha llevado esta parte vuelve a ser acertada. No ha existido ni un
solo indicio de filtracin del proceso realizado en estas fechas. Es ms, cuando se encuentran
con empresas como Yahoo que utilizan la versin 8 del programa BIND este grupo tiene el
suficiente peso como para hacerles cambiar todos sus sistemas a la versin 9.

Cabe destacar cmo una y otra vez Kaminsky destaca muy favorablemente el apoyo y soporte
incondicional de grandes empresas y multinacionales en la gestin de esta crisis. Algo que a
priori (cada empresa tiende a cuidar lo suyo, por eso son empresas y no ONGs) podra haber
resultado muy difcil de coordinar.

Finalmente, nada es gratis, Microsoft impone que el da de la semana en que se publicaran las
versiones corregidas de los programas, un martes (curiosamente el mismo da en el que esta
compaa publica sus actualizaciones).

2.2.2 Anuncio pblico

De forma coordinada y tras tener accesibles las actualizaciones de los distintos programas, el
martes 8 de Julio se produce el anuncio oficial de la existencia de una vulnerabilidad crtica
en el sistema de DNS. Se envan las notas a todos los sistemas de alerta (CERT) de Internet y
todos los boletines y webs de seguridad hacen referencia a este tema indicando la necesidad
de actualizar los sistemas inmediatamente [www100][www101].

Dan Kaminsky publica en su blog el da 9 de Julio una entrada en la que describe cmo los
distintos organismos y empresas de Internet han colaborado estrechamente ante este riesgo y
remarca la importancia de actualizar los sistemas. Seala que no va a proporcionar detalles
concretos de la vulnerabilidad debido a su gravedad y solicita a la comunidad de expertos que
durante 30 das se abstengan de especular al respecto con el objetivo de dar tiempo a todos
los administradores para actualizar sus sistemas
8
.

Adems emplaza a todos lo interesados en la vulnerabilidad a la conferencia que realizar el
6 de Agosto dentro del Black Hat en Las Vegas.

Si bien el modelo escogido en este caso es el adecuado al centralizar toda la gestin y emitir
un nico aviso en vez de cientos de avisos por parte de cada fabricante, no deja de ser muy
ingenuo realizar una peticin a toda Internet. Como en cualquier grupo numeroso, no
olvidemos que Internet tiene cientos de millones de usuarios, siempre tendremos gente
dispuesta a sacar ventaja a cualquier precio. Como se suele decir popularmente el mal nunca
descansa.

Otra cuestin a tener en cuenta es el tema de la divulgacin (disclosure) de vulnerabilidades
en sistemas o servicios [www86][www87]. Pese a que nosotros como usuarios percibamos
Internet como un todo no hay que perder de vista que en ltima instancia cada servidor, y
por tanto cada servicio, reside fsicamente en un pas u otro y como tal est obligado por su
legislacin vigente.

8
No hay que olvidar que existen decenas de millones de servidores de nombres en Internet.

Pgina 21 de 27

De forma muy resumida podemos clasificar en dos grupos las distintas posiciones existentes.
Divulgacin total (full disclosure), dnde estas vulnerabilidades son publicadas
9
en su
totalidad incluyendo los detalles tcnicos para favorecer el conocimiento y el desarrollo de
programas seguros, y contra la divulgacin total (non full disclosure), dnde se prohbe la
difusin pblica de detalles en favor del orden y control del riesgo asociado
10
.

En una serie de artculos aparecidos este ao en SecurityFocus [www58][www88] se repasa
la legislacin actual en doce pases europeos, Espaa no aparece, formulando a un abogado
de cada uno de estos pases la misma pregunta sobre la legislacin vigente referente a la
divulgacin de vulnerabilidades (What does the current law of your country say about
disclosure of security vulnerabilities in software?).

De las respuestas recibidas se puede deducir asombrosamente que prcticamente no hay
legislacin especfica sobre el tema, derivando la cuestin a leyes sobre intrusin en sistemas
o posesin de herramientas o informacin que permite realizar un acto ilegal.

En el caso de Europa existe como normativa de referencia el Council of Europe Convention
on Cybercrime [www93][www94][www95] que intenta regular la persecucin de los actos
ilegales en Internet dotando de un marco comn a los distintos pases. Desgraciadamente todo
y recoger aspectos como el fraude, acceso no autorizado a datos y ordenadores o los actos
que infrinjan el Copyright, no dejan de ser una serie de normas o recomendaciones con poca
cobertura real que nicamente suelen utilizarse en casos concretos que afectan a varios
pases. Esta normativa tambin ha sido ratificada entre otros muchos pases por Estados
Unidos.

Mayoritariamente la ley no sanciona la publicacin de vulnerabilidades en sistemas o
servicios siempre y cuando el descubridor no obtenga beneficio de ello. Es indicativo un caso
en Dinamarca dnde un adolescente public la direccin de una pgina web que dejaba sin
servicio a un sistema de pago por Internet denominado Valus [www89][www90]. Si bien este
joven fue absuelto, puesto que no se demostr intencin de daar o causar perjuicio directo al
sistema, la gente que la utiliz s fue condenada con una multa.

Tambin quedan recogidas ms o menos universalmente en las distintas legislaciones el
concepto de perjuicio ocasionado, no el posible si no el real, por la divulgacin de una
vulnerabilidad. Cabe destacar como posible ejemplo los casos de divulgaciones de problemas
de seguridad falsos o exagerados (bulos) con el objetivo de perjudicar a la competencia. En
este caso es necesario denuncia expresa del perjudicado.

Finalmente desde el punto de vista legal mayoritario, el tema es peliagudo y debe ser tratado
con cautela ya que como no hay normas claras/jurisprudencia cada tribunal tiende a aplicar su
criterio, tambin sera factible perseguir la divulgacin de vulnerabilidades por la va de
posesin de informacin privilegiada o el uso de herramientas de hacking/ingeniera inversa.

En muchos pases la posesin de herramientas que permitan cometer un delito (por ejemplo
una lanza trmica [www91][www92]) si se demuestra intencionalidad es punible.

9
Es importante destacar que esto no significa publicitar irresponsablemente o sin control. Existen organismos como los CERT
encargados de recoger esta informacin y divulgarla adecuadamente.

10
Las empresas y organismos afectados controlan en este caso el flujo de informacin. Si bien puede parecer que este modelo evitara
potenciales problemas del sistema anterior, cabe el peligro de la ocultacin o perversin en la gestin de la informacin.

Pgina 22 de 27

Como ejemplo meditico de esta parte queremos destacar el caso de Guillaume T. [www93]
un joven investigador francs que public en su blog varias vulnerabilidades [www96] de un
sistema antivirus denominado Viguard perteneciente a la compaa Tegam Internacional que
en 2004 estaba realizando en Francia una campaa publicitaria muy agresiva asegurando que
su producto era 100% seguro contra todo tipo de virus conocidos y desconocidos.

Guillaume (conocido popularmente como Guillermito) fue denunciado por esta compaa
solicitando 900.000 Euros en compensacin por los cargos de falsedad, divulgacin de
informacin maliciosa y uso de herramientas/procedimientos ilegales (denominacin del uso
de tcnicas de ingeniera inversa). Tras varios meses de juicio Guillermito fue condenado y
su posterior apelacin desestimada (puede consultarse la cronologa y la sentencia original en
[www97]).

Al margen del gran circo meditico que en su momento cre este juicio y su sentencia, la
parte a destacar y que generalmente se omite por ambas partes es la que motiv realmente la
condena: El uso de una copia del antivirus para la que Guillaume no tena licencia!
[www98].

De esta forma lo que en realidad empez a ser un juicio por la libertad de expresin y
difusin del conocimiento, acab convertido en un simple uso ilegtimo de un programa para
el cual no haba pagado la licencia.

2.2.3 Libre albedro

Una vez realizado el anuncio pblico de la vulnerabilidad del sistema de DNS y tras 13 das
de comentarios y especulaciones discretas, Thomas Dullien (Halvar Flake) el 21 de Julio abre
la caja de Pandora apuntando ms o menos acertadamente en qu consiste la vulnerabilidad
que Kaminsky intenta esconder hasta su conferencia en Las Vegas.

Es a partir de este momento dnde los comentarios empiezan a subir de tono cuestionando el
impacto real de este problema, el tipo de gestin que se ha aplicado y el papel protagonista de
Dan Kaminsky.

Mucha gente desea llevarse la gloria del descubrimiento y ser el primero en publicar un
documento o exploit en Internet, a fin de cuentas como dijo Senna el segundo es el primero
de los perdedores. Tampoco hay que obviar el negocio que supondra vender esta
informacin a grupos de extorsionadores y piratas informticos.

Ese mismo da (por afn de protagonismo?) un empleado de la empresa Matasano que
estaba informado de la vulnerabilidad, publica los detalles concretos del ataque. En pocas
horas se borra esta informacin del blog, pero ya es tarde, cientos y en pocas horas miles de
sitios web se han hecho eco de esta explicacin.

Justo a partir de este momento todo el trabajo cuidadosamente planificado y desarrollado
durante seis meses cae como un castillo de naipes. Empieza una frentica competicin de
artculos y comentarios de expertos en seguridad destinados a cuestionar la importancia de
esta vulnerabilidad e incluso la necesidad de actualizar los servidores de DNS [www54]
[www55][www56][www99].

Pgina 23 de 27
El mismo da 23 aparecen los primeros exploits en Internet para que cualquiera pueda
utilizarlos a su conveniencia [www66][www67]. Abrumado por los acontecimientos
Kaminsky intenta reconducir la situacin publicando diferentes artculos en su blog
insistiendo en la importancia de que se actualicen los sistemas y concediendo mltiples
entrevistas.

Sin embargo y pese a los esfuerzos desplegados tanto por Dan como por el resto de
instituciones y empresas que participaron en la gestin de esta vulnerabilidad, cada vez ms
voces discrepantes se alzan en Internet cuestionando la importancia que se le ha dado e
incluso acusndoles de exagerar una vulnerabilidad conocida desde hace aos [www73].

En muchos foros y webs de noticias de seguridad aparecen opiniones contradictorias que
incluso recomiendan no actualizar los sistemas hasta no conocer todos los detalles. Desde el
punto de vista de costes econmicos actualizar todos los DNS (imaginemos una gran empresa
o un ISP) son nicamente muchas horas extras en el mejor de los casos. Como ejemplo de
esta situacin catica podemos sealar que a finales de Julio Apple an no haba distribuido
la versin corregida de su servidor DNS! [www103].

Durante el mes de Agosto empiezan a aparecer varias acusaciones de censura y exceso de
control [www104][www105][www106] hacia las personas externas a los grupos de trabajo.
Diferentes propuestas como la de utilizar conexiones TCP en vez de UDP [www107] o la de
no actualizar los registros previamente resueltos mientras sean vlidos (ver apartados 1 y 2 de
este documento referentes a tiempo de vida o TTL) aaden ms fuego al debate oficial al ser
rechazadas tajantemente.

2.3 Conclusiones

Como hemos podido observar analizando el proceso tan en detalle como ha sido posible, la
gestin discreta en la primera fase es clave para poder conseguir unos buenos resultados. La
eleccin crtica se produce siempre en el primer paso ya que cuando se filtra un rumor y se
pierde el control de una situacin, es imposible reconducirla.

Por este motivo es muy importante potenciar la existencia de organismos como los CERT que
permitan iniciar una gestin adecuada de las situaciones de riesgo y poner al cargo de estos
centros verdaderos profesionales de la seguridad informtica capaces de iniciar y coordinar
las acciones necesarias en casos de peligro. Tambin se ha de formar y concienciar a todo el
sector de las tecnologas de la informacin (TI) sobre la importancia real de la seguridad. En
un mundo (Internet) sin fronteras ni distancias, lo que afecta a mi vecino me acabar
afectando a m.

Los profesionales de las TI deben saber dnde han de acudir en busca de informacin o
asesoramiento en las situaciones de riesgo. Han de tener las nociones de que protocolos de
actuacin se han de seguir y sobre todo que no se ha de hacer.

La sociedad tambin debe ser sensibilizada sobre el tema de la seguridad de forma que exija
profesiones capaces de dar respuesta a estas necesidades y confe en las gestiones realizadas.

Finalmente la auditoria pblica de la gestin realizada por estos centros cuando el riesgo haya
disminuido es clave para conseguir no slo una red segura, si no una red en la que confiemos.

Pgina 24 de 27
3. Agradecimientos

Para ser honestos debo reconocer que este documento es bastante ms largo de lo que en un
principio planifiqu. Tambin reconozco que he tenido que dedicar bastante ms tiempo del
que dispona inicialmente a documentarme, leer y sobre todo entender las infinitas referencias
del tema.

De esta forma, si usted ha soportado las veintitrs pginas anteriores y ha llegado hasta este
punto, mi agradecimiento sincero es para usted. Tambin debo agradecer a Arnau, David y
Rubn/outime sus acertados comentarios.

4. Copyright

Este documento se distribuye bajo la licencia Creative Commons 2.5 que permite la difusin
libre de este documento debiendo siempre respetar y citar en los crditos a su autor y
prohibiendo el uso comercial sin expresa autorizacin del autor.

http://creativecommons.org/licenses/by-nc/2.5/es/


Pgina 25 de 27
Bibliografa

[Stevens94] TCP/IP Illustrated, Volume I, W. Richard Steven. Addison-Wesley 994.
[AL01] DNS and Bind, Paul Albitz, Cricket Liu. Oreilly 2001.
[Liu02] DNS & Bind Cookbook, Cricket Liu. Oreilly 2002.
[SJ08] Effect of triangular routing in mixed Ipv4/IPv6 Networks, Teerapat
Sanguankotchakorn, Preeda Jaiton, IEEE 2008.
(http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04498189)

[www1] http://www.kb.cert.org/vuls/id/800113
[www2] http://tools.ietf.org/html/rfc920
[www4] http://www.unix.com.ua/orelly/networking_2ndEd/dns/ch12_09.htm
[www5] http://www.dnsdoctor.org/Tests_description#Root_servers
[www6] http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
[www8] http://en.wikipedia.org/wiki/Domain_Information_Groper
[www9] http://www.madboa.com/geek/dig/
[www10] http://www.kloth.net/services/dig.php
[www11] http://www.geektools.com/digtool.php
[www12] http://en.wikipedia.org/wiki/DNS_Backbone_DDoS_Attacks
[www13] http://www.cs.cornell.edu/People/egs/beehive/rootattack.html
[www15] http://gabriel.verdejo.alvarez.googlepages.com/
[www16] http://www.doxpara.com/
[www17] http://www.onguardonline.gov/topics/phishing.aspx
[www18] http://es.wikipedia.org/wiki/Phishing
[www19] http://mydns.bboy.net/survey/
[www20] http://cr.yp.to/surveys/dns1.html
[www21] http://www.debian.org/security/2008/dsa-1571
[www22] http://www.rediris.es/rediris/boletin/57/enfoque2.html
[www23] http://gabriel.verdejo.alvarez.googlepages.com/DEA-es-2DOS-DDOS.pdf
[www24] http://www.cert.org/homeusers/ddos.html
[www25] http://www.securityfocus.com/columnists/477
[www26] http://www.securityfocus.com/news/11526
[www27] http://www.securityfocus.com/news/11529
[www28] http://www.microsoft.com
[www29] http://www.rediris.es/rediris/
[www30] http://www.doxpara.com/?p=1162
[www31] http://www.isc.org/products/BIND/
[www32] http://cr.yp.to/djbdns/install.html
[www33] http://defcon.org/html/defcon-16/dc-16-schedule.html
[www34] http://media.defcon.org/dc-16/video/dc16_kaminsky/dc16_kaminsky_cache_full.mov
[www35] http://www.cert.org/
[www36] http://www.rediris.es/cert/
[www37] http://blog.wired.com/27bstroke6/2008/07/details-of-dns.html
[www38] http://blog.wired.com/27bstroke6/2008/07/kaminsky-on-how.html
[www39] http://isc.sans.org/diary.html?storyid=4687

Pgina 26 de 27
[www51] http://www.securityfocus.com/brief/779
[www52] http://amd.co.at/dns.htm
[www53] http://addxorrol.blogspot.com/2008/07/on-dans-request-for-no-speculation.html
[www54] http://beezari.livejournal.com/141796.html
[www55] http://www.linuxjournal.com/content/understanding-kaminskys-dns-bug
[www56] http://www.linuxjournal.com/content/dns-bug-why-you-should-care
[www57] http://marc.info/?t=121981071400003
[www58] http://www.securityfocus.com/print/columnists/466
[www59] http://www.eecs.wsu.edu/~smedidi/Mipv6.ppt
[www60] http://www.dns.net/dnsrd/rr.html
[www61] http://www.isc.org/index.pl?/about/mgmt/vixie.php
[www62] http://en.wikipedia.org/wiki/Paul_Vixie
[www63] http://www.isc.org/index.pl
[www64] http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1320461,00.html
[www65] http://news.cnet.com/8301-10789_3-9985618-57.html
[www66] http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
[www67] http://www.caughq.org/exploits/CAU-EX-2008-0003.txt
[www68] http://www.matasano.com/
[www69] http://www.hispasec.com/unaaldia/3546
[www71] http://www.schneier.com/essay-230.html
[www72] http://www.schneier.com/blog/archives/2008/07/the_dns_vulnera.html
[www73] http://isc.sans.org/diary.html?storyid=4693
[www74] http://www.doxpara.com/DMK_BO2K8.ppt
[www75] http://www.blackhat.com/html/bh-usa-08/bh-usa-08-schedule.html
[www76] http://venturebeat.com/2008/08/06/black-hat-dan-kaminsky-explains-the-bug-that-threatened-the-internet/
[www77] http://cr.yp.to/djb.html
[www78] http://www.dnssec.net/
[www79] http://www.dnssec-deployment.org/
[www80] http://www.bgp4.as/
[www83] http://www.cs.colostate.edu/~somlo/
[www84] http://www.securityfocus.com/brief/808
[www85] http://it.slashdot.org/article.pl?sid=08/08/29/127210
[www86] http://www.csoonline.com/article/440110/The_Vulnerability_Disclosure_Game_Are_We_More_Secure_?CID=28072
[www87] http://www.schneier.com/blog/archives/2007/01/debating_full_d.html
[www88] http://www.securityfocus.com/columnists/448/
[www89] http://www.valus.dk
[www90] http://www.fauxhemian.dk/archives/000189.html

Pgina 27 de 27
[www91] http://www.multipick-service.cc/htdocs/es/werkzeug/thermolanzen/
[www92] http://camarasacorazadas.blogspot.com/
[www93] http://www.usdoj.gov/criminal/cybercrime/COEFAQs.htm
[www94] http://www.coe.int/t/DG1/LEGALCOOPERATION/ECONOMICCRIME/cybercrime/default_en.asp
[www95] http://conventions.coe.int/Treaty/Commun/QueVoulezVous.asp?NT=185&CL=ENG
[www97] http://www.guillermito2.net/archives/2004_12_28.html
[www98] http://www.schneier.com/blog/archives/2005/03/france_makes_fi.html
[www99] http://blog.invisibledenizen.org/2008/07/kaminskys-dns-issue-accidentally-leaked.html
[www100] http://news.bbc.co.uk/2/hi/technology/7496735.stm
[www101] http://www.kriptopolis.org/fallo-critico-dns-obliga-parchear-internet
[www102] http://www.wired.com/politics/security/commentary/securitymatters/2008/07/securitymatters_0723
[www103] http://db.tidbits.com/article/9706
[www104] http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01433.html
[www105] http://www.av8.net/IETF-watch/DNSEXT/Management.html
[www106] http://cr.yp.to/djbdns/namedroppers.html
[www107] http://readlist.com/lists/isc.org/bind-users/2/10854.html
[www108] http://www.ietf.org/proceedings/08jul/slides/dnsext-2.pdf
[www109] http://www.caida.org/workshops/wide/0808/slides/source_port_randomness.pdf
[www110] http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

ARTICULOS LavulnerabilidadKaminskyde PDF

Cargado por

Copyright:

Formatos disponibles

ARTICULOS LavulnerabilidadKaminskyde PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ARTICULOS LavulnerabilidadKaminskyde PDF

Cargado por

Copyright:

Formatos disponibles

http://gabriel.verdejo.alvarez.googlepages.

com La vulnerabilidad Kaminsky del sistema DNS

También podría gustarte