El defecto en el corazón de Internet

Dan Kaminsky, inusualmente, no estaba buscando errores a principios de este año cuando se encontró con una falla en el núcleo de Internet. El investigador de seguridad estaba utilizando su conocimiento de la infraestructura de Internet para encontrar una mejor manera de transmitir videos a los usuarios. La experiencia de Kaminsky está en el sistema de nombres de dominio (DNS) de Internet, el protocolo responsable de hacer coincidir las URL de los sitios web con las direcciones numéricas de los servidores que los alojan. El mismo contenido se puede alojar en varios servidores con varias direcciones, y Kaminsky pensó que tenía un gran truco para dirigir a los usuarios a los servidores que mejor podían manejar sus solicitudes en un momento dado.

Ver problemas: El investigador de seguridad Dan Kaminsky descubrió por primera vez una vulnerabilidad básica en Internet el invierno pasado.

Normalmente, el DNS es confiable pero no ágil. Cuando una computadora, por ejemplo, un servidor que ayuda a dirigir el tráfico a través de la red de Comcast, solicita la dirección numérica asociada con una URL determinada, almacena la respuesta durante un período de tiempo conocido como tiempo de vida, que puede ser desde segundos hasta días. Esto ayuda a reducir la cantidad de solicitudes que realiza el servidor. La idea de Kaminsky era evitar el tiempo de vida, permitiendo que el servidor obtuviera una nueva respuesta cada vez que quisiera saber la dirección de un sitio. En consecuencia, el tráfico en la red de Comcast se enviaría a la dirección óptima en cada momento, en lugar de a cualquier dirección que ya se haya almacenado. Kaminsky estaba seguro de que la estrategia podría acelerar significativamente la distribución de contenido.

Fue solo más tarde, después de hablar casualmente sobre la idea con un amigo, que Kaminsky se dio cuenta de que su truco podía romper por completo la seguridad del sistema de nombres de dominio y, por lo tanto, de la propia Internet. Resulta que el tiempo de vida era el núcleo de la seguridad del DNS; ser capaz de eludirlo permitió una amplia variedad de ataques. Kaminsky escribió un pequeño código para asegurarse de que la situación fuera tan mala como pensaba. Una vez que lo vi funcionar, se me cayó el estómago, dice. Pensé: '¿Qué diablos voy a hacer con esto? Esto afecta a todo '.

La técnica de Kaminsky podría usarse para dirigir a los navegantes web a cualquier página web que elija un atacante. El uso más obvio es enviar personas a sitios de phishing (sitios web diseñados para engañar a las personas para que ingresen contraseñas bancarias y otra información personal, lo que permite que un atacante robe sus identidades) u otras versiones falsas de páginas web. Pero el peligro es aún peor: los protocolos como los que se utilizan para enviar correo electrónico o para comunicaciones seguras a través de Internet dependen en última instancia del DNS. Un atacante creativo podría utilizar la técnica de Kaminsky para interceptar el correo electrónico confidencial o para crear versiones falsificadas de los certificados que garanticen transacciones seguras entre los usuarios y los sitios web bancarios. Todos los días encuentro otro dominó, dice Kaminsky. Otra cosa se cae si el DNS es malo. ... Quiero decir, literalmente, miras a tu alrededor y ves cualquier cosa que esté usando una red, cualquier cosa que esté usando una red, y probablemente esté usando DNS.

Multimedia

• Vea un esquema de un ataque de envenenamiento de caché.

Kaminsky llamó a Paul Vixie, presidente del Consorcio de Sistemas de Internet, una corporación sin fines de lucro que apoya varios aspectos de la infraestructura de Internet, incluido el software más comúnmente utilizado en el sistema de nombres de dominio. Por lo general, si alguien quiere informar de un problema, espera que le lleve bastante tiempo explicarlo, tal vez una pizarra, tal vez un documento de Word o dos, dice Vixie. En este caso, tardó 20 segundos en explicar el problema y otros 20 segundos en responder a mis objeciones. Después de eso, le dije: 'Dan, estoy hablando contigo por un teléfono celular inseguro. Por favor, no vuelvas a decirle a nadie lo que me acabas de decir a través de un teléfono celular inseguro '.

Quizás lo más aterrador fue que debido a que la vulnerabilidad no estaba ubicada en ningún hardware o software en particular, sino en el diseño del protocolo DNS en sí, no estaba claro cómo solucionarlo. En secreto, Kaminsky y Vixie reunieron a algunos de los principales expertos en DNS del mundo: personas del gobierno de EE. UU. E ingenieros de alto nivel de los principales fabricantes de software y hardware de DNS, empresas que incluyen a Cisco y Microsoft. Organizaron una reunión en marzo en el campus de Microsoft en Redmond, WA. Los arreglos fueron tan reservados y apresurados, dice Kaminsky, que había personas en aviones de Microsoft que ni siquiera sabían cuál era el error.

Una vez en Redmond, el grupo trató de determinar el alcance de la falla y resolver una posible solución. Se decidieron por una medida provisional que solucionó la mayoría de los problemas, sería relativamente fácil de implementar y enmascararía la naturaleza exacta de la falla. Debido a que los atacantes comúnmente identifican los agujeros de seguridad mediante parches de ingeniería inversa destinados a solucionarlos, el grupo decidió que todos sus miembros tenían que lanzar el parche simultáneamente (la fecha de lanzamiento sería el 8 de julio). Kaminsky también pidió a los investigadores de seguridad que no especularan públicamente sobre los detalles de la falla durante 30 días después del lanzamiento del parche, en un intento de dar a las empresas el tiempo suficiente para proteger sus servidores.

El 6 de agosto, en la conferencia Black Hat, la reunión anual de expertos en seguridad de Internet del mundo, Kaminsky revelaría públicamente cuál era la falla y cómo podría explotarse.

Pidiendo problemas
Kaminsky no ha descubierto realmente un nuevo ataque. En cambio, ha encontrado una manera ingeniosa de darle vida a uno muy antiguo. De hecho, el defecto básico al que apunta su ataque es anterior a Internet.

La base del DNS fue establecida en 1983 por Paul Mockapetris, entonces en la Universidad del Sur de California, en los días de ARPAnet, el proyecto de investigación del Departamento de Defensa de EE. UU. Que vinculó computadoras en un pequeño número de universidades e instituciones de investigación y finalmente condujo a Internet. . El sistema está diseñado para funcionar como el servicio 411 de una compañía telefónica: dado un nombre, busca los números que llevarán al portador de ese nombre. El DNS se hizo necesario a medida que ARPAnet creció más allá de la capacidad de un individuo para realizar un seguimiento de las direcciones numéricas en la red. Mockapetris, quien ahora es presidente y científico en jefe de Nominum, un proveedor de software de infraestructura con sede en Redwood, CA, diseñó el DNS como una jerarquía. Cuando alguien escribe la URL de una página web en un navegador o hace clic en un hipervínculo, una solicitud se dirige a un servidor de nombres mantenido por el proveedor de servicios de Internet (ISP) del usuario. El servidor del ISP almacena las direcciones numéricas de las URL que maneja con frecuencia, al menos, hasta que expira su tiempo de vida. Pero si no puede encontrar una dirección, consulta uno de los 13 servidores raíz DNS, que dirige la solicitud a un servidor de nombres responsable de uno de los dominios de nivel superior, como .com o .edu. Ese servidor reenvía la solicitud a un servidor específico para un solo nombre de dominio, como google.com o mit.edu. El reenvío continúa a través de servidores con responsabilidades cada vez más específicas —mail.google.com o libraries.mit.edu — hasta que la solicitud llega a un servidor que puede proporcionar la dirección numérica solicitada o responder que no existe dicha dirección. A medida que Internet maduraba, quedó claro que el DNS no era lo suficientemente seguro. El proceso de pasar una solicitud de un servidor a otro brinda a los atacantes muchas oportunidades para intervenir con respuestas falsas, y el sistema no tenía garantías para garantizar que el servidor de nombres que respondía una solicitud fuera confiable. Ya en 1989, dice Mockapetris, hubo casos de envenenamiento de caché, en los que se engañó a un servidor de nombres para que almacenara información falsa sobre la dirección numérica asociada con un sitio web.
En la década de 1990, el trabajo del envenenador era relativamente fácil. Los servidores de nombres de nivel inferior generalmente son mantenidos por entidades privadas: Amazon, por ejemplo, controla las direcciones proporcionadas por el servidor de nombres amazon.com. Si un servidor de nombres de bajo nivel no puede encontrar una dirección solicitada, remitirá al solicitante a otro servidor de nombres o le dirá que la página no existe. Pero en los años 90, el servidor de bajo nivel también podía proporcionar al solicitante la dirección del servidor de nivel superior. Para envenenar un caché, un atacante simplemente tenía que falsificar esa información. Si un atacante engañaba, digamos, al servidor de nombres de un ISP para que almacenara la dirección incorrecta para el servidor .com, podría secuestrar la mayor parte del tráfico que viaja a través de la red del ISP. Mockapetris dice que posteriormente se agregaron varias funciones al DNS para proteger el sistema. Los servidores solicitantes dejaron de aceptar direcciones numéricas de nivel superior de servidores de nombres de nivel inferior. Pero los atacantes encontraron una forma de evitar esa restricción. Al igual que antes, remitirían a un solicitante a, por ejemplo, el servidor .com. Pero ahora el solicitante tenía que buscar la dirección del servidor .com por sí mismo. Solicitaría la dirección y el atacante se apresuraría a responder con una respuesta falsa antes de que llegara la respuesta real. También se agregaron medidas de seguridad ad hoc para proteger contra esta estrategia. Ahora, cada solicitud a un servidor DNS lleva un ID de transacción generado aleatoriamente, uno de los 65.000 números posibles, que también debe contener la respuesta. Un atacante que se apresure a ganar una respuesta legítima también tendría que adivinar el ID de transacción correcto. Desafortunadamente, una computadora puede generar tantas respuestas falsas con tanta rapidez que, si tiene suficientes oportunidades, seguramente encontrará la identificación correcta. Entonces, el tiempo de vida, originalmente destinado a evitar que los servidores de nombres se sobrecarguen con demasiadas solicitudes, se convirtió en otra característica de seguridad provisional. Debido a que el servidor solicitante almacenará una respuesta durante un período de tiempo, el atacante tiene solo unas pocas oportunidades de intentar una falsificación. La mayoría de las veces, cuando el servidor necesita una dirección .com, consulta su caché en lugar de verificar con el servidor .com. Kaminsky encontró una manera de eludir estas características de seguridad ad hoc, lo más importante, el tiempo de vida. Eso hizo que el sistema fuera tan vulnerable como cuando se descubrió por primera vez el envenenamiento de caché. Usando la técnica de Kaminsky, un atacante tiene un número casi infinito de oportunidades de proporcionar una falsificación. Digamos que un atacante quiere secuestrar todo el correo electrónico que un sitio de redes sociales como Facebook o MySpace envía a las cuentas de Gmail. Se registra para obtener una cuenta en la red social y, cuando se le solicita una dirección de correo electrónico, proporciona una que apunta a un dominio que controla. Comienza a iniciar sesión en la red social pero afirma haber olvidado su contraseña. Cuando el sistema intenta enviar una nueva contraseña, realiza una búsqueda de DNS que conduce al dominio del atacante. Pero el servidor del atacante afirma que la dirección solicitada no es válida. En este punto, el atacante podría remitir al solicitante a los servidores de nombres de google.com y competir para proporcionar una respuesta falsa. Pero entonces solo tendría una oportunidad de descifrar el ID de la transacción. Entonces, en cambio, remite al solicitante a los dominios inexistentes 1.google.com, luego 2.google.com, luego 3.google.com, y así sucesivamente, enviando una avalancha de respuestas falsas para cada uno. Cada vez, el servidor solicitante consultará los servidores de nombres de Google en lugar de su caché, ya que no tendrá direcciones almacenadas para ninguna de las URL falsas. El ataque sobrepasa por completo los límites establecidos por el tiempo de vida. Una de las falsificaciones del atacante está destinada a pasar. Entonces, es muy sencillo dirigir cualquier cosa que el servidor solicitante pretenda para Google a los propios servidores del atacante, ya que el atacante parece tener autoridad para las URL que terminan en google.com. Kaminsky dice que pudo realizar ataques de prueba en tan solo 10 segundos.

Un ataque de envenenamiento de caché
El envenenamiento de la caché hace que un servidor solicitante almacene información falsa sobre la dirección numérica asociada con un sitio web. A continuación se describe una versión básica del ataque, sin algunas de las técnicas más sofisticadas que emplea Kaminsky. 1. Para empezar, el atacante engaña al servidor de la víctima para que se comunique con un dominio que controla el atacante. El atacante podría, por ejemplo, afirmar haber olvidado una contraseña, lo que provocaría que la víctima respondiera por correo electrónico.
2. La víctima realiza una búsqueda de DNS para averiguar dónde enviar el correo electrónico. Pero el servidor de nombres del atacante remite a la víctima a otro servidor, como el de example.com. Dado que el atacante sabe que la víctima ahora iniciará una búsqueda de DNS para ese servidor, tiene la oportunidad de intentar envenenar su caché. 3. El atacante intenta proporcionar una respuesta falsa antes de que el servidor legítimo pueda proporcionar la verdadera. Si el atacante adivina el número de identificación correcto, la víctima acepta la respuesta de adivinación, que envenena el caché.
En la oscuridad
El 8 de julio, Kaminsky celebró la conferencia de prensa prometida, anunciando el lanzamiento del parche y pidiendo a otros investigadores que no especularan sobre la falla. Los proveedores de hardware y software se habían decidido por un parche que obliga al atacante a adivinar un ID de transacción más largo. Kaminsky dice que antes del parche, el atacante tuvo que hacer decenas de miles de intentos para envenenar con éxito un caché. Después del parche, tendría que ganar miles de millones. La noticia de la falla apareció en el New York Times, en el sitio web de la BBC y en casi todas las publicaciones técnicas. Los administradores de sistemas se apresuraron a hacer funcionar el parche en sus sistemas antes de que pudieran ser atacados. Pero debido a que Kaminsky no proporcionó detalles sobre la falla, algunos miembros de la comunidad de seguridad se mostraron escépticos. Thomas Ptacek, investigador de Matasano Security, publicó en Twitter: Primero lo digo aquí: dudando que realmente haya algo de carne en este anuncio de seguridad del DNS. Dino Dai Zovi, un investigador de seguridad mejor conocido por encontrar formas de enviar malware a una Macbook Pro completamente parcheada, dice: Definitivamente era escéptico sobre la naturaleza de la vulnerabilidad, especialmente debido a la cantidad de publicidad y atención frente a la poca cantidad de detalles. . Cada vez que veo algo así, instantáneamente me pongo mi sombrero de escéptico, porque se parece mucho a alguien con un interés creado en lugar de alguien que intenta arreglar algo. Dai Zovi y otros notaron que el momento era perfecto para promover la aparición de Black Hat de Kaminsky, y se enfurecieron ante la solicitud de abstenerse de especular. La falta de información fue particularmente controvertida porque los administradores del sistema a menudo son responsables de evaluar los parches y decidir si aplicarlos, sopesando el peligro de la falla de seguridad con la interrupción que causará el parche. Dado que el DNS es fundamental para el funcionamiento de cualquier organización que dependa de Internet, modificarlo no es algo que se haga a la ligera. Para empeorar las cosas, este parche no funcionó correctamente con ciertos tipos de firewalls corporativos. Muchos profesionales de TI expresaron su frustración por la falta de detalles y dijeron que no podían evaluar adecuadamente el parche cuando quedaba mucho oculto. Preocupado por el escepticismo sobre sus afirmaciones, Kaminsky celebró una conferencia telefónica con Ptacek y Dai Zovi, con la esperanza de hacerles ver lo peligroso que era el error. Ambos salieron de la convocatoria convertidos. Pero aunque Dai Zovi señala que mucho ha cambiado desde el momento en que los fabricantes de hardware y software se ocuparon de las fallas simplemente negando que los investigadores de seguridad hubieran identificado problemas reales, también dice: No sabemos qué hacer cuando las vulnerabilidades son realmente grandes. sistemas como DNS. Los investigadores se enfrentan a un dilema, dice: necesitan explicar las fallas para convencer a otros de su gravedad, pero una vulnerabilidad como la que encontró Kaminsky es tan grave que revelar sus detalles podría poner en peligro al público. Halvar Flake, un investigador de seguridad alemán, fue un observador que pensó que quedarse callado era la alternativa más dañina. La especulación pública es justo lo que se necesita, dice, para ayudar a la gente a comprender qué podría afectarlos. Flake leyó algunos materiales básicos, incluida la entrada de Wikipedia en alemán sobre DNS, y escribió una entrada de blog sobre lo que pensó que Kaminsky podría haber encontrado. Declarando que probablemente su conjetura estaba equivocada, invitó a otros investigadores a corregirlo. De alguna manera, en medio de la conmoción que su publicación causó en la comunidad de seguridad, apareció una explicación detallada de la falla en un sitio alojado por el empleador de Ptacek, Matasano Security. La explicación fue rápidamente eliminada, pero no antes de que proliferara en Internet. Se produjo el caos. Kaminsky publicó en Twitter, el error de DNS es público. Necesita parchear, o cambiar a OpenDNS [basado en Web], AHORA MISMO. En cuestión de días, Metasploit, un proyecto de seguridad informática que diseña ataques de muestra para ayudar en las pruebas, lanzó dos módulos que explotaban la falla de Kaminsky. Poco después, se vio en la naturaleza uno de los primeros ataques basados ​​en la falla de DNS. Se apoderó de algunos de los servidores de AT&T para presentar una página de inicio de Google falsa, cargada con los propios anuncios del atacante. Sin cookies
Treinta minutos antes de que Kaminsky subiera al escenario en Black Hat para revelar por fin los detalles de la falla, la gente comenzó a inundar el salón de baile del Caesar's Palace en Las Vegas. El orador que precedió a Kaminsky se apresuró a terminar. Se acabaron los asientos y la gente se sentó con las piernas cruzadas en cada centímetro cuadrado de alfombra. La abuela de Kaminsky, que estaba sentada en la primera fila, había horneado 250 galletas para el evento. No había ni mucho menos lo suficiente. Kaminsky subió al podio. Hay mucha gente ahí fuera, dijo. Santo cielo. Kaminsky es alto y sus gestos son un poco incómodos. A principios de agosto, dijo, se había protegido a más de 120 millones de clientes de banda ancha, ya que los proveedores de servicios de Internet aplicaron parches. El setenta por ciento de las empresas de Fortune 500 habían parcheado sus sistemas y un 15 por ciento adicional estaba trabajando en ello. Sin embargo, agregó, entre el 30 y el 40 por ciento de los servidores de nombres en Internet aún no estaban parcheados y eran vulnerables a su ataque de envenenamiento de caché de 10 segundos. En el escenario, cambió entre la alegre descripción de las oscuras posibilidades de su descubrimiento y los intentos de reunir la seriedad apropiada a su gravedad. Habló durante 75 minutos, volviéndose visiblemente más liviano a medida que se desahogaba de los secretos de siete meses. Cuando terminó su charla, la multitud se acercó a él, y reportero tras reportero se lo llevaron. Incluso los expertos en seguridad que estuvieron de acuerdo en que la vulnerabilidad era grave quedaron desconcertados por el entusiasmo de Kaminsky por la atención de los medios y su incansable esfuerzo por dar a conocer la falla. Más tarde ese día, Kaminsky recibió el premio Pwnie por el error más sobrevalorado de un grupo de investigadores de seguridad. (La palabra pwn, que rima con own, es jerga de Internet para dominar por completo. El premio de Kaminsky se subtitula The Pwnie por pwning a los medios de comunicación). Dai Zovi, al presentar el premio, trató de enumerar las publicaciones que habían llevado la historia de Kaminsky. Se rindió, diciendo: ¿Qué ¿No estabas en? ¡GQ! alguien gritó desde la audiencia. Kaminsky subió al escenario y escupió dos frases: Algunas personas encuentran errores; algunas personas solucionan errores. Estoy feliz de estar en la segunda categoría. Balanceando el premio, un pony de juguete dorado, por su cabello rosa brillante, caminó por el largo pasillo del salón de baile y salió por la puerta. ¿Quien esta a cargo?
Dependiendo de su perspectiva, la forma en que Kaminsky manejó la falla de DNS y su parche fue una grandilocuencia peligrosa que llamó innecesariamente la atención del público sobre la vulnerabilidad de Internet o, como Kaminsky lo ve, un truco de medios necesario para entrenar un foco de atención sobre los peligros del error. De cualquier manera, la historia apunta a la preocupante ausencia de cualquier proceso para identificar y corregir fallas críticas en Internet. Debido a que Internet está tan descentralizada, simplemente no hay una persona u organización específica a cargo de resolver sus problemas. Y aunque la falla de Kaminsky es especialmente grave, los expertos dicen que probablemente no sea la única en la infraestructura de Internet. Muchos protocolos de Internet no se diseñaron para los usos que se les dan actualmente; muchas de sus funciones de seguridad se agregaron y no abordan las vulnerabilidades subyacentes. A largo plazo, desde el punto de vista arquitectónico, tenemos que dejar de asumir que la red es tan amigable como es, dice Kaminsky. Simplemente somos adictos a mover información confidencial a través de Internet de forma insegura. Podemos hacerlo mejor. De hecho, en otra conferencia de seguridad pocos días después de la presentación de Kaminsky en Black Hat, un equipo de investigadores dio una charla que ilustraba fallas graves en el protocolo de enrutamiento de la puerta de enlace fronteriza de Internet. Al igual que Kaminsky, los investigadores habían encontrado problemas con el diseño fundamental de un protocolo de Internet. Al igual que la falla de DNS, el problema podría permitir que un atacante obtenga un amplio acceso al tráfico confidencial enviado a través de Internet.
Muchos expertos dicen que lo que sucedió con la falla de DNS representa el mejor de los casos. Mischel Kwon, directora de US-CERT, una división del Departamento de Seguridad Nacional que ayudó a correr la voz sobre el error de DNS, espera que la red de organizaciones que trabajaron juntas en este caso haga lo mismo si surgen otras fallas. Aunque no existe una jerarquía de autoridad en el sector privado, dice Kwon, existen fuertes conexiones entre empresas y organizaciones con el poder de implementar parches. Ella dice que confía en que, considerando el dinero y el esfuerzo que se invierte en mejorar la seguridad en Internet, los protocolos obsoletos se actualizarán. Pero esa confianza no se basa en una estrategia bien considerada. ¿Qué pasaría si Kaminsky no hubiera tenido conexiones extensas dentro de la comunidad de seguridad o, peor aún, no se hubiera comprometido a arreglar la falla en primer lugar? ¿Y si hubiera sido un verdadero sombrero negro empeñado en explotar la vulnerabilidad que había descubierto? ¿Y si su aparentemente hábil manipulación de los medios de comunicación hubiera fracasado y los detalles de la falla se hubieran conocido antes de que el parche estuviera en su lugar? Es más, incluso teniendo en cuenta las buenas intenciones de investigadores como Kaminsky, corregir fallas básicas en Internet no es fácil. Los expertos coinciden en que el problema del DNS no es una excepción. Varias propuestas están sobre la mesa para resolverlo por medios más confiables que un parche, principalmente reduciendo la confianza que un servidor solicitante otorga a un servidor de nombres. Las propuestas van desde arreglos relativamente simples, como incluir incluso más información aleatoria en las solicitudes realizadas a los servidores de nombres, hasta trasladar todo el sistema a un conjunto de protocolos que permitirían a los servidores de nombres firmar criptográficamente sus respuestas. Mientras tanto, tanto Kaminsky como Vixie dicen que los atacantes han comenzado a hacer uso de la falla de DNS y esperan que surjan más problemas. Kaminsky señala que la falla se vuelve particularmente peligrosa cuando se explota junto con otras vulnerabilidades. Una de esas combinaciones, dice, permitiría a un atacante hacerse cargo de las actualizaciones automáticas que un proveedor de software envía a sus clientes, reemplazándolas con malware. Kaminsky dice que ha pasado los últimos meses hablando por teléfono con empresas que serían objetivos atractivos para ese tipo de ataque, como autoridades de certificación, redes sociales y proveedores de servicios de Internet, tratando de convencerlos de que apliquen el parche lo antes posible. Lo que da miedo, dice Dai Zovi, es lo frágil que es [Internet]. … ¿Y qué vamos a hacer al respecto? Erica Naone es editora asistente en Revisión de tecnología.

esconder