Kaminsky, Kaminsky, Kaminsky …

Buenas,

No sabría por dónde empezar. El culebrón del verano tiene demasiados episodios, y pese a que he intentado mantenerme al margen (la inundación de información en los medios es letal, abrumadora y en algunos casos, hasta aburrida), al final he decidido hacer un pequeño resumen del tema candente del momento: el grave problema detectado por el investigador Dan Kaninsky en el protocolo DNS.

El origen del mal

http://www.kriptopolis.org/fallo-critico-dns-obliga-parchear-internet

Here Comes The Cavalry

Tal y como se puede leer en la explicación de DShield, la cual utilizaré por su concisión y facilidad de comprensión, el protocolo DNS usa UDP. Un servidor DNS funciona enviando peticiones en paquetes individuales UPD, y una vez que recibe una respuesta, hace unas verificaciones elementales. Cada respuesta usa una única random query ID, es decir, un identificador aleatorio único, y se tienen que cumplir dos reglas básicas: que todas las respuestas y peticiones emparejadas compartan ese ID, y que las respuestas se emitan desde el mismo puerto empleado en la petición. Si se cumplen las condiciones, la primera respuesta válida es la que prevalece.

Si un atacante tuviera la capacidad de conocer el puerto empleado en la petición y el valor de esa query ID, podría fabricar respuestas falsas que serían aceptadas, ya que cumplen con las condiciones. El query ID tiene 16 bits de longitud, lo que permite obtener 2^16 = 65.536 combinaciones posibles, y respecto a puertos, hay que moverse entre, más o menos, números no reservados (superiores a 1024) y que no excedan del valor límite, 65535, lo que deja, mal contadas, 64.000 combinaciones.

Sería fácil pensar que falsificar una respuesta es complicado, probabilísticamente hablando: hay que acertar entre 60 y pico mil opciones para puerto y query ID. Sobre el terreno, es fácil concluir en que no todos los rangos de puertos están disponibles, y que de facto, casi todos los DNS operan con los mismos puertos, lo que reduce drásticamente la combinatoria.

Sobre el query ID, la cosa no está igualmente muy boyante. Probabilísticamente, en un espacio de 65.536 combinatorias, uno de cada 65.536/2 = 32.768 intentos concluiría en éxito. Sin embargo, la aleatoriedad de los DNS está directamente ligada a la longitud en bits del query ID, que como máximo es 16, pero que en implementaciones defectuosas, puede ser menor, reduciendo el espacio considerablemente. Otras veces, la implementación defectuosa simplemente generará IDs predecibles:

* VU#484649 – Microsoft Windows DNS Server vulnerable to cache poisoning
* VU#252735 – ISC BIND generates cryptographically weak DNS query IDs
* VU#927905 – BIND version 8 generates cryptographically weak DNS query identifiers

Entender lo que ha pasado

“The-Cat-is-Out-of-The-Bag” DNS Bug

Multiple DNS implementations vulnerable to cache poisoning

Multiple Vendors DNS Spoofing Vulnerability

Kaminsky’s DNS Attack Disclosed, Then Pulled

Attack Code Published For DNS Vulnerability

Attack code published for DNS flaw

|)ruid and HD Moore release part 2 of DNS exploit

Los DNS de los mayores proveedores de Internet del mundo también siguen siendo vulnerables

Script Kiddies al ataque: Metasploit

http://www.caughq.org/exploits/CAU-EX-2008-0002.txt

http://www.caughq.org/exploits/CAU-EX-2008-0003.txt

Maneras de verificar nuestros DNS

http://entropy.dns-oarc.net/test/

http://www.doxpara.com/

Firmas Snort

#by many very smart people
# This may be a high load sig. Take time and seriously consider
# that your dns_servers var is set as narrowly as possible
alert udp any 53 -> $DNS_SERVERS any (msg:»ET CURRENT_EVENTS Excessive DNS Responses with 1 or more RR’s (100+ in 10 seconds) – possible Cache Poisoning Attempt»; byte_test:2,>,0,6; byte_test:2,>,0,10; threshold: type both, track by_src, count 100, seconds 10; classtype:bad-unknown; sid:2008446; rev:8;)

#this will catch large numbers of nxdomain replies, a sign that someone may be trying to poison you
alert udp any 53 -> $HOME_NET any (msg:»ET CURRENT_EVENTS Excessive NXDOMAIN responses – Possible DNS Poisoning Attempt Backscatter»; byte_test:1,&,128,2; byte_test:1,&,3,1,relative; threshold: type both, track by_src, count 100, seconds 10; classtype:bad-unknown; sid:2008470; rev:1;)

En resumen: un problema serio, y que requiere actuaciones rápidas y serias. Estaremos al tanto de la evolución del incidente :)

Saludos,

9 comentarios sobre “Kaminsky, Kaminsky, Kaminsky …

  1. Gracias por el enlace http://entropy.dns-oarc.net/test/ , más claro que el original indicado por Kaminsky (doxpara).

    Me sorprende ‘positivamente’ que a día de hoy las cadenas de resolución de nombrado / servicio DNS de algunos ISP’s empiezan a estar ‘parcheadas’. Esto se puede visualizar, por ejemplo, en el sitio web de bandaancha:

    http://bandaancha.eu/analizador-dns

    En la 3a columna del listado de DNS’s se puede apreciar si es vulnerable o no. Más o menos 1 de cada 5 está marcado como NO vulnerable (jeje, yo esperaba que fuera peor ;-) ).

    En cualquier caso, espero que los delincuentes no hagan su AGOSTO y nos pillen en bañador (qué casualidad), sabiendo que ya empiezan a salir propuestas de exploits y Mr Kaminsky, si no recuerdo mal, hará una demostración de su descubrimiento a principios del mes veraniego.

    DNS’s rápidos / no vulnerables que he testeado hoy exitosamente:

    208.67.222.222, 208.67.220.220 (OpenDNS)
    217.116.0.176, 217.116.0.177 (ns1, ns2.acens.net)
    62.37.237.140 (orange)

    Hoy, otros DNS como ya.com (62.151.20.6) y Telefonica (ej: 80.58.0.97 y 80.58.32.97) resultan inconsistentes en el test de entropía.

    No está de más poner DNS’s de confianza tanto en vuestros portátiles (sí, ese que te lleva a la playa) como en vuestros routers ADSL… ;-)

    Un abrazo a todos :-)

  2. Interesantes las descripciones http://amd.co.at/dns.htm (*) y las refs como CAU-EX-2008-0002, para imaginar ataques y el por qué de la importancia de «randomizar» source port y transaction ID.

    (*) Caché de blogspot Matasano (?)

    Mis conocimientos de DNS son muy básicos, pero la reciente lectura de arriba (*) hace que me pregunte OTRA vez el significado de las siguientes entradas en log de cortafuegos personal Comodo que vengo observando desde hace tiempo (había leído que eran «normales», provenientes de los DNS; pero ahora no estoy tan seguro):

    Entrada típica Log:
    Date/Time :2008-07-29 00:56:02
    Severity :High
    Reporter :Network Monitor
    Description: UDP Port Scan
    Attacker: 62.37.237.140
    Ports: 5356, 38343, 11972, 64253, 33260, 17151, 20975, 2038, 995, 6613, 24774, 48086, 63440, 47054, 18892, 63444, 10234, 34754, 3541, 3833, 10432, 58336, 21989, 43503, 14321, 10787, 47675, 10938, 44194, 53555, 32093, 16721, 22293, 54033, 23345, 30039, 22493, 11963, 29626, 10938, 10930, 8762, 43691, 10922, 15017, 53525, 7511, 21809, 29055, 65365
    The attacker has been temporarily blocked

    62.37.237.140 es el DNS que tengas configurado. Hasta ahora pensaba que realmente no hay ataque (y probablemente no lo es), pero me llama la atención, por ejemplo hoy, que estas entradas se repiten más o menos cada 45 minutos (sin haber pinchado nuevos links).

    PREGUNTA: ¿Qué significan…? Por si alguien me puede orientar. Ejemplo:

    Hipotesis1: son ráfagas de respuestas DNS genuinas que el FW rechaza por su ritmo. O actualizaciones que, realmente no competen a un PC con Windows, por no ser realmente un auto-servidor DNS (?). Not clear

    Hipotesis2 (teoría de la conspiración :-) ): son ráfagas de respuestas DNS falsas (spoofing malware) intentando envenenar por azar.

    Hipotesis3: la que sugiráis vosotros.

    Seguramente lo más sencillo e inofensivo será lo más probable.

    GRACIAS por cualquier orientación (ej: dónde informarme).

  3. Hipotesis3 (thinking as a phisher): Ahora no son malignas pero si lo *serán* (a partir de agosto)… ráfagas de respuestas DNS falsas (spoofing malware) intentando envenenar por azar (o algoritmos más eficientes). Tendrán más éxito en los sistemas no parcheados o sin cortafuegos buenos.

    Ej: en máquinas windows no parcheadas, el rango de puertos podría limitarse a 1030 – 5000

    A ver qué compañía reporta el primer troyano con estas características y cuándo. Yo calculo para la 2a. semana de agosto…. :-)

  4. jcbarreto,

    Los tiempos de reacción de los ISPs y carriers es bastante decepcionante, la verdad. Un vistazo al analizador de DNS que citas basta para comprobarlo.

    La solución óptima pasa por usar, hasta que el tema esté aclarado, OpenDNS.

    En el log que muestras, veo la pauta típica y tópica de un escaneo de puertos automatizado. Teniendo en cuenta que 62.37.237.140 es el DNS de Orange, yo no me preocuparía ;)

  5. Gracias Sergio por la respuesta. Decirte que estoy ‘enganchado’ al tema ;-) leyendo mucho. Ej…

    (a) «Dicen» algunos que el parcheo es sólo problema de lado servidor DNS. Es mentira. ej: Windows tiene un cliente DNS resolver y hace caché…

    Casualmente lo tengo desactivado hace tiempo por recomendación de Spybot S&D v1.5.2, entre otros (hmmm…)

    Sobre esta caché DNS de Windows, me llama profundamente la atención un parámetro de registro «QueryIpMatching» que por default (incl. S.O. parcheados hasta julio 2008) permiten que Windows admita datos DNS de direcciones IP aunque no haya solicitado nada !! (puff)

    Mis dedos no pueden responder a todo lo que pasa por mi mente con este dato; continúo leyendo al respecto. Sólo se me ocurre que en 2008, ese parámetro realmente ya es obsoleto (no me cuadra contra source port y transaction ID, aunque sea en máquinas Windows).

    (b) Ok, volviendo al punto del UDP Port Scan supuesto del DNS de Orange (62.37.237.140) y tu respuesta, hoy estoy tranquilo; pero para el futuro… no. Pienso en IP spoofing de malware corriendo en 127.0.0.1… Entonces es un fake-ORANGE en local o remoto!

    Ej:

    malware1-bot.exe en PC’s haciendo muuuúltiples peticiones a servidores DNS reales de dominios aleatorios inexistentes. Menuda cadena de peticiones se genera ¿no? DNS1 -> DNS2 -> … ROOT y respuestas de retorno. Pensando en esto, se entiende que MS no recomiende deshabilitar cache-DNS. Si no, Internet se nos cae.

    malware2-local-poisoner.exe el que genera respuestas falsas para pillar por estadística puerto/transaction ID, para infectar 1 de cada 10.000 peticiones DNS, por poner algún número.

    Acaso hay maneras más fáciles de hacer pharming, simplemente envenenando directamente la caché-DNS de Windows. Pero una combinación de lo anterior puede inspirar a gente; si no la ha inspirado ya y hace tiempo (ej: ROCK PHISH group)

    En fin, está entretenido.

Comentarios cerrados.