[LACNIC/Seguridad] DNS cache poisoning

[Fernando Gont]

Hola Roque,

Si, sorry. Me referia a UDP.

Obviamente, el comentario de Vixie es acertado.

Pero esta clarisimo que, si uno considera que 16 
bits del query ID + 16 bits del source port 
permiten de manera bastante simple los ataques de 
fuerza bruta, dejar fijo el source port es un 
tanto... ridiculo, por asi decirlo.

Si el source port es aleatorio, entonces la 
cantidad de paquetes requerida para un ataque de 
fuerza bruta pasa de 2^16 a 2^32. No es el cielo, 
pero... al menos no es tan trivial como 2^16 paquetes.

Saludos,
Fernando




>fernando,
>Me imagino que te referis a UDP....
>
>Aca te mando una referencia que salió en NANOG 
>sobre avisos de la vulnerabilidad en el 95...
>
>Paul
>Vixie described it in 1995 at the Usenix Security Conference
>(<http://www.usenix.org/publications/library/proceedings/security95/vixie.html>http://www.usenix.org/publications/library/proceedings/security95/vixie.html)
>-- in a section titled "What We Cannot Fix", he wrote:
>
>With only 16 bits worth of query ID and 16 bits worth of UDP
>port number, it's hard not to be predictable.  A determined
>attacker can try all the numbers in a very short time and can
>use patterns derived from examination of the freely available
>BIND code. Even if we had a white noise generator to help
>randomize our numbers, it's just too easy to try them all.
>
>The ISC web page on the attack notes "DNSSEC is the only definitive
>solution for this issue. Understanding that immediate DNSSEC deployment
>is not a realistic expectation..."
>
>
>
>slds
>r.
>
>On Jul 11, 2008, at 1:21 AM, Fernando Gont wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA256
>>
>>Estimados,
>>
>>Algunos comentarios sobre los alertas recientes sobre la vulnerabilidad de
>>"cache poisoning". Es interesante destacar que la vulnerabilidad reportada
>>no es propia del protocolo DNS, sino que, si bien es sufrieda por una
>>variedad de implementaciones, dicha vulnerabilidad reside en un error de
>>*implementación*, y no de protocolo.
>>
>>Básicamente, el problema en cuestión es que las implementaciones
>>efectadas envían sucesivas peticiones DNS utilizando un mismo TCP source
>>port, por lo cual se facilita notablemente la realización del llamado "DNS
>>cache poisoning". Ninguna de las especificaciones de DNS requieren esto.
>>
>>De hecho, la implementación de DNS djbdns no es vulnerable a este ataque.
>>
>>Pese a la publicidad que ha recibido esta vulnerabilidad en los últimos
>>días, esta vulnerabilidad ya había sido discutida publicamente en detalle
>>por D. J. Berstein al menos en el año 2001
>>(<http://groups.google.com/group/mailing.unix.bind-users/msg/92f94d2f940cdfa>http://groups.google.com/group/mailing.unix.bind-users/msg/92f94d2f940cdfa
>>b).
>>
>>(At the risk of sounding our own horn ;-) ), la vulnerabilidad en cuestión
>>podría haber sido prevenida implementando aleatorización de puertos
>>("port randomization") de acuerdo a alguna de las técnicas descriptas en
>>nuestro Internet-Draft de la IETF
>>(<http://www.gont.com.ar/drafts/port-randomization/index.html>http://www.gont.com.ar/drafts/port-randomization/index.html), 
>>publicado
>>hace cuatro años atrás. Dicho draft es el resultado de discusiones con
>>una
>>variedad de implementadores, incluyendo algunos de FreeBSD.
>>
>>Dicho eso, está claro que es recomendable que aquellos que se encuentren
>>utilizando alguna de las implementaciones vulnerables actualicen las mismas
>>de forma urgente. Y también me interesa aclarar que lo anterior no le
>>quita crédito a Kaminsky. Está claro que su trabajo a llevado a que se
>>parcheen numerosas implementaciones, lo cual es mas que interesante y
>>rescatable.
>>
>>Fernando Gont
>>
>>
>>
>>
>>
>>
>>-----BEGIN PGP SIGNATURE-----
>>Version: PGP Desktop 9.5.3 (Build 5003) - not
>>licensed for commercial use: <http://www.pgp.com>www.pgp.com
>>
>>wsBVAwUBSHbfI2l+Jnd3SMmAAQiHEwf/QNgkjiIYmyfvYFipVp13ovVKSJeNHEhn
>>Y2B05AToqzD7lJM725O1MW7Z+0KVDU1iwLtspDpLjz60nzyiK8b8R+484tE0TAXl
>>VkTfhbXgOUKuzprUM8Wtx0uV2hfaR7r4ftfC6aXMz8wMU22A/GeY1jsdCyM9y+gf
>>ofdIqzyA6tZhExIUxbQDutpdDqAROClM7AXTVkMgWoZ0XO5/oCBnGRMBv+txvRn3
>>zb/DnviA/k/Rg8v0x1Ny3RloyYWebjaCDKgfAymBsYksbUDICRka2jGo9B7vHV1i
>>ySHQg8NvXAt1Yv70rokUDuHUSF9ROboFaHaH1KFN5lnXIb39Uq+FvA==
>>=71Vf
>>-----END PGP SIGNATURE-----
>>
>>
>>--
>>Fernando Gont
>>e-mail: 
>><mailto:fernando en gont.com.ar>fernando en gont.com.a 
>>r || <mailto:fgont en acm.org>fgont en acm.org
>>PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>
>>
>>
>>
>>_______________________________________________
>>Seguridad mailing list
>><mailto:Seguridad en lacnic.net>Seguridad en lacnic.net
>>https://mail.lacnic.net/mailman/listinfo/seguridad
>
>
>_______________________________________________
>Seguridad mailing list
>Seguridad en lacnic.net
>https://mail.lacnic.net/mailman/listinfo/seguridad

--
Fernando Gont
e-mail: fernando en gont.com.ar || fgont en acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20080713/9d0f11b2/attachment.html>