[LACNIC/Seguridad] DNS cache poisoning

[Jorge M. Niedbalski R.]

El día 13 de julio de 2008 19:59, Fernando Gont <fernando en gont.com.ar>
escribió:

>  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)
> -- 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
> 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), 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: 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: fernando en gont.com.ar || fgont en acm.org
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
> _______________________________________________
> Seguridad mailing list
> 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
>
>
>
>
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad
>
>

Estimado Fernando :

En definitiva 2^32 sigue siendo insuficiente , ¿Cual es tu propuesta al
respecto?


-- 
Jorge Niedbalski R.
-----------------------------------------
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20080714/706610f6/attachment.html>