El problema del DNS (Parte 2)

(Por El Microsaurio) No, no nos quedaremos sin la Web mañana por la tarde. Pero en parte se debe a la discreción de un tipo que encontró el problema, lo analizó, se comunicó con otro que conocía a todos “los grandes”, convocó a una reunión, y no dio a publicidad el problema hasta que se prepararon los parches.
Después de una sentada de los grandes (Siemens Alemania, Fujitsu Supercomputers de Japón, IBM, Cisco, HP, Novell/Suse, Red Hat) en un campus de Microsoft, durante la cual se discutió acerca de un error de diseño de BIND (tal como te lo contamos ayer), se pusieron manos a la obra.
Los desarrollos (y los parches) fueron puestos a punto, probados y preparados para entregar a los encargados de los servidores DNS públicos, corporativos y de los ISP de todo el mundo. Finalmente decidieron que el día en que se publicara el parche DNS para sistemas de Microsoft, el primer martes de julio, se “blanquearía” el problema. Y que hasta ese momento se mantendría el secreto. ¿Por qué? Elemental, Watson. El precio era mucho más caro: múltiples estafas al sistema bancario, o cortes intencionales de conectividad por empresa o región, para mencionar algunos de los daños posibles.
Culebrón informático
El mundillo de los expertos en informática está dividido (desde hace años) entre los partidarios de Full Disclosure y los que prefieren la Responsible Disclosure. Lo primero es “descubrí una falla de seguridad, la publico inmediatamente, así obligo a Las Grandes Empresas a que produzcan un parche ya mismo”. Lo segundo es lo que piden Las Grandes Empresas: “avisame en secreto, dame tiempo para preparar el parche, cuando solucione el problema lo podés publicar y llevarte la gloria”.
Como de costumbre, hay miles de dólares detrás de esto. En una conducta que algunas veces es casi extorsiva, hay hackers/expertos que aprietan a Las Grandes Empresas con emailes del tipo “yo publico esto el viernes, si ustedes pueden emparchar, mejor”. Y otros que venden sus hallazgos a servicios como Tipping Point, que “guardan” la falla, le meten un respetable puñado de dólares en la boca al hacker y le sacan bastante más a Las Grandes Empresas por administrar los tiempos de la publicación.
El riesgo cuando se publica una falla sin que se conozca el parche lo corren los usuarios comunes, claro. Las Grandes Empresas tienen eficientes administradores de sistemas que en el noventa por ciento de los casos les sacan las papas del fuego. El usuario común, simplemente se queda sin las papas.
No en vano en el blog de Matasano Security un especialista (y dueño de esa empresa) publicó “caramba, Dan Kaminski podría haber hecho centenares de miles de dólares con esta falla DNS” como podrán leer aquí y justamente este especialista, Tom Ptacek, insistió tanto en conocer la falla que el miércoles pasado Richard Mogull, investigador de seguridad para Gartner USA (un tipo que también conoce “a todo el mundo”) hizo que el descubridor de la falla, Kaminsky, llamara por teléfono a Ptacek para explicarle esa vulnerabilidad y porqué había que mantener silencio.
Resultado: este posteo en el blog de Matasano que no tiene desperdició por lo conciso: “Emparchen su servidor ya. Dan tenía razón. Yo estaba equivocado” Con una observación lateral interesante: “…emparchen, mientras no estén usando un servidor DJBDNS como el que yo uso en mis productos de seguridad…”
Exactamente. Adivinaste. Sí hay un programa servidor DNS que esta vez <no> necesita parche, porque no tiene la falla descubierta por Kaminsky. Es un producto conocido por los linuxeros, cuya descripción podrás encontrar aquí en la Wikipedia, que arranca con “…es una implementación de DNS creada por Daniel J. Bernstein debido a sus frustraciones con los repetidos agujeros de seguridad de BIND; hay una recompensa de 500 dólares para la primera persona que encuentre un agujero de seguridad (…) en djbdns, y el premio no ha sido ganado aún por nadie…”
Comentarios laterales
Después de que estas discusiones tomaran estado público, alguien señaló que hace tres años una persona que preparaba un examen para certificación de seguridad había publicado un “paper” que describía esta misma falla; al día siguiente, un periodista de Australia informó sobre un material que describía la falla diez años atrás. Uf, la Internet ya es vieja, y el tema es conocido. Uno de los que avisó que podría atacarse de esta manera a programas como BIND fue… Daniel J. Bernstein.
Ah, mucha gente se preguntó por qué se demoró tanto el tema del anuncio público. Las malas lenguas relacionaron inmediatamente esta demora (de marzo a julio) con el afiebrado trabajo de un grupo de desarrolladores de una Enorrrrme Empresa de Software, que no llegaban a tiempo con el parche.
Aunque no debe tener relación, el anuncio se hizo el martes en que se publicó el parche/actualización de Microsoft para “su” sistema DNS de Windows Server.
Por ahora, colorín colorado.
El señor Kaminsky, en el blog que te mencioné arriba, publicó un “probador de vulnerabilidad”, a la derecha del texto principal. Es el recuadro que se llama “DNS CHECKER”. No tengo la menor intención de señalarlo como una prueba infalible, pero, por desgracia, en la noche del jueves me indicaba que el servidor utilizado en mi conexión no estaba emparchado. El lunes la mediodía (4 días después del anuncio público) seguía igual. Paciencia. Que tengan una semana interesante. Y a los colegas admin, que les sea leve y no les envenenen la caché.