Sobre la nueva vulnerabilidad de DNS
Estaba viendo Slashdot y leí sobre este posteo de Paul Vixie (un viejo conocido de los unix-fan), hablando sobre la recepción bastante negativa que ha tenido la exposición parcial de la nueva vulnerabilidad, que se espera sea explicada totalmente en la Black Hat Conference el 7 de agosto.
Dejo una traducción libre del post de Paul:
"El miércoles 8 de julio CERT/CC publicó el aviso #800113 referido a una vulnerabilidad de envenenamiento de caché DNS descubierta por Dan Kaminsky que será completamente expuesta el 7 de agosto en la conferencia Black Hat. Aunque el arreglo a largo plazo para este tipo
de ataque y similares es Secure DNS, sabemos que no podemos tener hoy ni lo suficientemente pronto firmadas la root zone, ni la .COM o que sistema de registro (registrar) se encargue de zone keys. Así que como solución temporal, los afectados están recomendando que sea implementada universalmente la técnica de puertos UDP aleatorios (o "randomización" de puertos UDP), de Dan Bernstein.
Las reacciones fueron mixtas, pero sobre todo negativas. Como coordinador de la respuesta combinada de los vendors he escuchado multitud de quejas, y he visto como Dan Kaminsky ha sido llamado idiota por como manejó la exposición de la vulnerabilidad. Dejénme responder un poco a ello aquí, sin llegar a que lo tomen como algo personal:
P: "¿Es este el mismo ataque que X describió tiempo atrás en Y?"
R: No, no lo es.
P: "Estás siendo exagerado, ya sabíamos que DNS era terriblemente inseguro"
R: Todo lo que pensamos que sabíamos era incorrecto.
P: "Creo que el nuevo ataque de Dan es Z"
R: Si tu suposición es correcta, entonces puedes controlar la agenda, ¿quieres hacerlo?
P: "¿Por qué no se me mantuvo al tanto de esto?"
R: El manejo de comunicaciones seguras es difícil. No hubo intención de ofender a nadie.
Ahora, para el boletín de noticias: Tom Cross de ISS-XForce a señalado correctamente que si tu nameserver recursivo está detrás de varias formas de dispositivos NAT/PAT, el parche no te hará ningun bien ya que tus números de puerto serán reescritos cuando vayan hacia afuera, a menudo usando algun lindo algoritmo no aleatorio que busque números de puerto sustitutos. Dan y yo estamos trabajando con CERT/CC en un un anuncio sobre una vulnerabilidad derivada ya que al parecer la mayoría de los NAT/PAT de la industria tienen de hecho este problema. La obvia solución temporal es que muevas tus DNS recursivos para que estén fuera del perímetro NAT/PAT o habilita a tu dispositivo NAT/PAT para que sea un ALG, o usa un forwarding TSIG seguro cuando pase a través de tu perímetro.
Por favor haz lo siguiente, Primero, toma el aviso en serio, no somos un montón de novatos alarmistas, si te decimos que "la casa de tu DNS se está incendiando" y te damos un matafuegos, tómalo. Segundo, toma a Secure DNS en serio, incluso aunque hay problemas intratables en su
modelo de administración, implementalo localmente y presiona a tus vendors para que te den las herramientas que necesitas. Tercero, deja de quejarte, tenemos mucho trabajo que hacer hasta el 7 de agosto y es un poco tonto gastar tiempo discutiendo cuando necesitamos estar parcheando (cosas)."
Lo traduje todo en una sentada rápida, aclaraciones y correcciones son bienvenidas y deseadas.
El aviso de la vulnerabilidad:
http://www.kb.cert.org/vuls/id/800113
Fuente:
http://tech.slashdot.org/tech/08/07/15/0032227.shtml
El post original de Vixie:
http://www.circleid.com/posts/87143_dns_not_a_guessing_game/
Dardo Valdez (yaco)
Administrador de Sistemas
IM: [email protected]
blog: http://sysnotas.blogspot.com
Dejo una traducción libre del post de Paul:
"El miércoles 8 de julio CERT/CC publicó el aviso #800113 referido a una vulnerabilidad de envenenamiento de caché DNS descubierta por Dan Kaminsky que será completamente expuesta el 7 de agosto en la conferencia Black Hat. Aunque el arreglo a largo plazo para este tipo
de ataque y similares es Secure DNS, sabemos que no podemos tener hoy ni lo suficientemente pronto firmadas la root zone, ni la .COM o que sistema de registro (registrar) se encargue de zone keys. Así que como solución temporal, los afectados están recomendando que sea implementada universalmente la técnica de puertos UDP aleatorios (o "randomización" de puertos UDP), de Dan Bernstein.
Las reacciones fueron mixtas, pero sobre todo negativas. Como coordinador de la respuesta combinada de los vendors he escuchado multitud de quejas, y he visto como Dan Kaminsky ha sido llamado idiota por como manejó la exposición de la vulnerabilidad. Dejénme responder un poco a ello aquí, sin llegar a que lo tomen como algo personal:
P: "¿Es este el mismo ataque que X describió tiempo atrás en Y?"
R: No, no lo es.
P: "Estás siendo exagerado, ya sabíamos que DNS era terriblemente inseguro"
R: Todo lo que pensamos que sabíamos era incorrecto.
P: "Creo que el nuevo ataque de Dan es Z"
R: Si tu suposición es correcta, entonces puedes controlar la agenda, ¿quieres hacerlo?
P: "¿Por qué no se me mantuvo al tanto de esto?"
R: El manejo de comunicaciones seguras es difícil. No hubo intención de ofender a nadie.
Ahora, para el boletín de noticias: Tom Cross de ISS-XForce a señalado correctamente que si tu nameserver recursivo está detrás de varias formas de dispositivos NAT/PAT, el parche no te hará ningun bien ya que tus números de puerto serán reescritos cuando vayan hacia afuera, a menudo usando algun lindo algoritmo no aleatorio que busque números de puerto sustitutos. Dan y yo estamos trabajando con CERT/CC en un un anuncio sobre una vulnerabilidad derivada ya que al parecer la mayoría de los NAT/PAT de la industria tienen de hecho este problema. La obvia solución temporal es que muevas tus DNS recursivos para que estén fuera del perímetro NAT/PAT o habilita a tu dispositivo NAT/PAT para que sea un ALG, o usa un forwarding TSIG seguro cuando pase a través de tu perímetro.
Por favor haz lo siguiente, Primero, toma el aviso en serio, no somos un montón de novatos alarmistas, si te decimos que "la casa de tu DNS se está incendiando" y te damos un matafuegos, tómalo. Segundo, toma a Secure DNS en serio, incluso aunque hay problemas intratables en su
modelo de administración, implementalo localmente y presiona a tus vendors para que te den las herramientas que necesitas. Tercero, deja de quejarte, tenemos mucho trabajo que hacer hasta el 7 de agosto y es un poco tonto gastar tiempo discutiendo cuando necesitamos estar parcheando (cosas)."
Lo traduje todo en una sentada rápida, aclaraciones y correcciones son bienvenidas y deseadas.
El aviso de la vulnerabilidad:
http://www.kb.cert.org/vuls/id/800113
Fuente:
http://tech.slashdot.org/tech/08/07/15/0032227.shtml
El post original de Vixie:
http://www.circleid.com/posts/87143_dns_not_a_guessing_game/
Dardo Valdez (yaco)
Administrador de Sistemas
IM: [email protected]
blog: http://sysnotas.blogspot.com
0 Comments:
Publicar un comentario
Gracias por dejar un comentario en Segu-Info.
Gracias por comentar!