Del plato a la boca, se cae la sopa: El caso DNS-Kaminsky-Dullien

No hace mucho les platicaba acerca del caso Kaminsky y cómo mantuvo en secreto (aunque, eso sí, divulgando a los cuatro vientos que tenía un secreto) una vulnerabilidad encontrada en el protocolo DNS, y comentaba yo acerca de la importancia de no revelar algo que pudiera caer en manos enemigas y ser explotado. En esto estábamos, cuando me entero este fin de semana que alguien se le adelantó a Kaminsky (que ya se veía con los reflectores encima): Thomas Dullien (aka Flake) publicó en su blog lo que él pensaba (por cierto, acertadamente) que podía ser el problema del DNS. Esto no sería relevante si no fuera porque alguien que participó en el proyecto de Kaminsky lo confirmó, con lujo de detalles. Aunque esta información estuvo publicada en Internet poco tiempo (fue quitada después de una disculpa), fue suficiente para que ahora medio mundo conozca los detalles y seguramente ya se están preparando los exploits correspondientes.

Bueno, esto iba a ocurrir de cualquier manera en agosto, cuando Kaminsky lo dijera en el BlackHat, así que los que hicieron la tarea y actualizaron (o parcharon) sus sistemas podrán dormir tranquilos. (?)

Esto deja varias lecciones: Primero, que cualquier persona con el tiempo, conocimiento y motivación suficientes, pudo haber descubierto la falla. Segundo, que no podemos confiar en la Seguridad por Oscuridad, es decir, que el simple hecho de ocultar algo no lo hace seguro. Y tercero, que a veces no conviene esperar tanto a los reflectores, especialmente cuando hay tanta expectativa: bien dicen que del plato a la boca, se cae la sopa.

Hasta luego.

:wq!

Error forense en Numb3rs

¿Y la cadena de custodia, 'apá?

Anoche ví el episodio Sacrifice de la primera temporada de Numb3rs, la serie de televisión donde Charlie Eppes, un chavo matemático, ayuda a su hermano Don, agente del FBI, a resolver casos usando ¿qué creen? sí, matemáticas. He visto algunos episodios de la primera temporada y, aunque el concepto es interesante, algunas cosas son realmente difíciles de creer (de acuerdo, es entretenimiento). Cuando llego a ver televisión (algo muy remoto), lo hago para divertirme, no para estudiar matemáticas (esas las estudio a otra hora), y Numb3rs había sido prometedor, pero el episodio que vi anoche casi me causa una conmoción cerebral, por el impacto recibido al ver cómo los principios de investigación forense (al menos en el ámbito de la informática) eran echados a la basura. Les platico, aunque les advierto que revelaré parte de la trama. Bueno, están advertidos.

Como algunos de ustedes saben, me apasiona el tema de la seguridad de información, la criptografía y las investigaciones forenses en crímenes informáticos. Así que, cuando comienza el episodio y me doy cuenta de que la computadora de la víctima formará parte de la investigación, digo: "esto se va a poner interesante", pero, ¡oh, desilusión!, nunca se involucró a un forense de computadoras que conociera el procedimiento, obviamente no se inició la cadena de custodia, y peor aún, se transgredieron varios principios fundamentales del análisis forense que habrían ocasionado que, en caso de que tuvieran que ir a un juicio, la evidencia hubiera resultado inútil.

El episodio trata de la investigación del homicidio de un investigador que trabaja en un proyecto clasificado (confidencial) del gobierno; los archivos de su computadora personal (donde presumiblemente estaba toda su investigación) habían sido borrados. Primero: ¿qué hacía este investigador con información confidencial en su computadora casera? Por lo visto nadie le explicó al investigador el modelo de confidencialidad Bell-LaPadula, lo mismo que aquél militar que fue cesado porque su hija divulgó información clasificada del ejército, misma que encontró en una memoria flash (USB) donde su papá (el ex-militar) había copiado dichos archivos confidenciales... aunque esa es otra historia.

Pero, como dijera Jack El Destripador (Jack The Ripper): "vamos por partes" :-D. Por ejemplo: cuando llegan los supuestos forenses, comienzan a revisar la computadora directamente en la escena del crimen. Un buen forense no hubiera hecho eso; debieron haber comenzado la cadena de custodia del equipo, llevado al laboratorio forense, extraído el disco duro, obtenido una imagen bit a bit, montado la copia en modo read-only en un sistema operativo para analizar (de preferencia el de Linus, no el de Bill :-)) y, ahora sí, comenzar a investigar. Al no haber hecho esto, nuestros amigos investigadores expertos del FBI incurrieron en un error forense, al manipular directamente la computadora involucrada. Otra falla fue el hecho de que Charlie trató de revisar la PC del investigador, ahora occiso, también directamente, sin trabajar sobre una copia. Puras fallas.

Por otra parte, la explicación que Charlie le da a su hermano respecto a la sobreescritura de datos es algo ilustrativa, y cumple con el propósito de poner en contexto a la audiencia. Lo que él explica es un concepto que en seguridad conocemos como zeroization, que consiste en sobreescribir los datos con algún patrón de bits, de modo que se dificulte la recuperación de los datos originales. El asesino sabía que borrar los archivos no era suficiente, pues generalmente son recuperables, pero con zeroization sería mucho más difícil (pero no para nuestro héroe matemático). A lo mejor si se hubiera robado la computadora, el móvil hubiera parecido distinto y la investigación no hubiera requerido a los forenses de cómputo. Caso cerrado. :-D

Ya sé que todo esto al final es ficción y que en la vida real no se hubieran cometido tantos errores en materia forense. Además, pienso que para muchos es mucho más entretenido ver a estos personajes en la investigación que al forense y su laboratorio. Al final, como siempre, encontraron al culpable y todos vivieron felices, listos para el siguiente episodio... excepto Charlie, que se quedó pensando si lo que hacía era bueno o malo, si ayudaba a salvar vidas o las quitaba. Un dilema muy grande para una mente tan brillante. ;-)

:wq!

// Para los que no entendieron el subtítulo, está inspirado en la frase célebre del comercial de un chavito que está platicando con su papá, y le pregunta cuándo va a hereder la camioneta.

La importancia de no 'soltar la sopa': El caso DNS-Kaminsky

Hasta este día no había escrito ningún comentario referente a vulnerabilidades o riesgos de seguridad, aún cuando siempre procuro estar pendiente de las actualizaciones y avisos relevantes diariamente. Sin embargo, mientras leía y profundizaba en los detalles de una de las actualizaciones relevantes de Microsoft de esta semana, me llamó enormemente la atención el caso de Dan Kaminsky, un profesional en seguridad informática que descubrió hace pocos meses (y por accidente, dice él) una vulnerabilidad en la implementación del protocolo DNS, que afecta tanto a servidores DNS como a clientes DNS.

Sólo para estar en el mismo contexto y para que nadie se sienta excluído: DNS (Domain Name System) es el servicio que se usa en Internet para evitar tener que memorizar (nosotros los humanos) direcciones IP (como 209.85.173.104) y en lugar de eso, recordar más fácilmente nombres de dominio tales como www.google.com. Sin DNS, Internet no sería lo que es ahora (no sería atractivo para muchísima gente).

Regresando al tema, lo que me llamó la atención de esto fue la forma de proceder de Dan Kaminsky al darse cuenta del problema. El hacker típico sin ética (black hat) habría explotado la vulnerabilidad en algún servidor expuesto (que, tratándose del servicio de DNS, no hubiera representado ninguna dificultad) y casi inmediatamente lo habría difundido en algún foro de hacking (en esos ámbitos, el dudoso prestigio de ser el primero en consumar un ataque es muy bien visto, aunque no sea éticamente correcto o legal). El problema aquí es que, por tratarse de un problema masivo, es decir, que afecta a todos los sistemas DNS, independientemente del fabricante, el atacante podría tener virtualmente control absoluto de prácticamente cualquier sistema de resolución de nombres de dominio (DNS) y direccionar a sitios falsos para robar información o cometer actos fraudulentos. Un gran riesgo.

Pero Kaminsky no lo hizo público. En lugar de anunciar públicamente (y quizá irresponsablemente) la falla, buscó a los principales proveedores involucrados en el desarrollo de servicios DNS (Sun Microsystems, Cisco, Microsoft) y al CERT (Computer Emergency Response Team) de Estados Unidos, y en conjunto comenzaron a trabajar secretamente en la solución, con el propósito de liberar la solución a nivel mundial al mismo tiempo. Esto ocurrió ayer, el día en que los principales proveedores de la industria liberaron simultáneamente los patches para sus respectivos productos. Las palabras clave en esto son "secretamente" y "en conjunto". Si no se hubiera hecho así, a estas alturas tendríamos un caos por todos los que habrían explotado ya la vulnerabilidad sin existir una solución de fondo en todos los sistemas. El mismo Kaminsky invita a seguir investigando el DNS, y a no hacer públicos los hallazgos en los foros o canales de IRC, y yo estoy completamente de acuerdo con él.

Los ataques a los sistemas DNS no son nuevos. Desde hace tiempo han existido los ataques de buffer overflow, DNS cache poisoning, spoofing, entre otros, pero no se había presentado un caso que involucrara de forma masiva a los sistemas en todo el mundo, y que se manejara de forma tan profesional y organizada como se hizo en esta ocasión. Así es como lo veo.

¿Qué tiene que ver esto con un usuario de servicios a través de Internet? Absolutamente todo. DNS interviene en prácticamente cualquier interacción en Internet... imagínense tener que visitar sitios Web usando la dirección IP, como http://209.85.173.104 por ejemplo. ¡Qué complicado! (las campañas de mercadotecnia se verían en apuros). Así que DNS nos ayuda a que escribamos http://www.google.com en el navegador, en lugar de la dirección IP, pues DNS hace la traducción del nombre de dominio en la dirección IP correspondiente. Si este problema se explotara, podríamos ser redirigidos sin darnos cuenta a servidores falsos y ser víctimas de pharming; o los correos electrónicos que enviáramos serían dirigidos a servidores extraños y ser interceptados por alguien más. Si DNS falla, Internet falla. El impacto sería enorme, pero aquí es donde la estrategia de manejarlo en forma coordinada tiene un gran valor.

Aún no hay información detallada acerca de esto, y la implementación presumiblemente se ha hecho pensando en que sea muy difícil la ingeniería inversa de los parches que están siendo liberados, precisamente para dar tiempo de instalar los parches en todos los sistemas que usan DNS, o de mover de BIND8 (que ya está muerto, excepto en Yahoo!) a BIND9. De hecho en este preciso momento ya hay varios tratando de identificar (usando ingeniería inversa) exactamente qué es lo que los parches corrigen, para tratar de explotarlo; esto es algo que no se puede evitar, y es la razón por la que es importante que todos los que tienen servicios que usan DNS instalen los parches cuanto antes. Kaminsky va a dar su versión en la próxima conferencia de Black Hat en Las Vegas, pero los detalles seguirán en secreto, al menos por un buen rato.

La seguridad es asunto de todos, y la seguridad en Internet no es la excepción. Al menos yo quiero que cuando mi familia se conecte a Internet para leer las noticias, comprar un libro, jugar en línea, usar el correo electrónico, hacer un pago bancario o simplemente leer un blog, lo haga con seguridad. ¿Quién no? Qué bueno que Dan Kaminsky no soltó la sopa. ;-)

:wq!