Internet se ha roto, otra vez (y III)

lunes, 8 de enero de 2018

Tranquilos, hablamos de Metldown y Spectre pero desde otro punto de vista. Pensábamos que no sería necesario retomar esta serie, pero aquí está de nuevo. Ahondaremos en aspectos menos explorados sobre estos fallos que sacuden de nuevo los cimientos de la seguridad. Vamos a intentar aportar algo nuevo. No es la primera catástrofe en la red. ¿Las ha habido peores? ¿Es realmente una catástrofe, o lo serán sus "daños colaterales"?

Otros apocalipsis
En general, ya se han dado casos muy similares de catástrofes que afectarían a la red tal y como la conocemos, y de la que se han desprendido titulares dantescos. El primero en llegar a las masas fue el "efecto 2000", que aunque no contó con logotipo oficial desde el principio, sí que disfrutó de una marca propia (Y2K)... pero eran otros tiempos y quedó en una especie de decepción apocalíptica que se sació con mucha literatura y algunos telefilms. Recientemente ya hemos sufrido varias veces fallos muy graves que ponían en jaque la seguridad en la red. Resumimos algunos:


  • El apocalipsis criptográfico de Debian en 2008. Se eliminó en 2006 una línea de código en el paquete OpenSSL que ayudaba a generar la entropía al calcular el par de claves pública y privada. Las claves generadas con él ya no eran realmente fiables o verdaderamente seguras. 
  • Kaminsky y los DNS en 2008. Un fallo inherente al protocolo, no un problema de implementación. Dan Kaminsky lo descubrió sin ofrecer detalles. Thomas Dullien se aventuró semanas después a publicar en su blog su particular visión de lo que podía ser el problema y acertó: era posible falsificar (a través del envío continuo de cierto tráfico) las respuestas de los servidores autorizados de un dominio. Diez años después, incluso después de esa catástrofe, DNSSEC sigue siendo "una rareza".
  • Espionaje a "gran escala" con BGP. En agosto también de 2008, se hablaba de nuevo de la mayor vulnerabilidad conocida en Internet. Tony Kapela y Alex Pilosov demostraron una nueva técnica (que se creía teórica) que permitía interceptar el tráfico de Internet a una escala global. Se trataba de un fallo de diseño en el protocolo BGP (Border Gateway Protocol) que permitiría interceptar e incluso modificar todo el tráfico de Internet no cifrado.
  • Heartbleed en 2014. Pues eso. De nuevo, la posibilidad de conocer las claves privadas en servidores expuestos. Además inauguró las vulnerabilidades "de marca" porque el apocalipsis también hay que saber venderlo: se diseñó un logo y una página exclusiva con plantilla que se convertiría en estándar de facto, se reservó un dominio, se orquestó una especie de campaña de comunicación, se colaron exageraciones para dar empaque, se cuidó el "timing"... Abrió el camino a una nueva forma de notificar, comunicar y difundir fallos de seguridad. Aunque curiosamente el efecto técnico a corto fue otro: se puso a prueba el sistema de revocación de certificados y efectivamente, no estuvo a la altura.

Pero con perspectiva, hasta el momento parece que nunca se han utilizado ninguna de estas vulnerabilidades como métodos de ataque masivo que colapsen Internet y "la rompan". ¿Han servido estas grandes catástrofes para poner contra las cuerdas a la Red? Tampoco. ¿Alguien se ha beneficiado de ellas? Seguro. Para poner de rodillas a la red, en realidad, se usan otras armas: malware común y sencillo, realizado por atacantes menos sofisticados, como Blaster, Sasser, CodeRed o Slammer que sí que consiguieron un impacto masivo en la Red. Y obviamente, EternalBlue/Wannacry: ¿Qué decir sobre esto? Tuvo que venir un gusano tradicional a "romper" o al menos poner patas arriba internet. Pero para conseguirlo no fue necesario recurrir a un fallo catastrófico ni catastrofista… sino que incluso resultaba extremadamente similar a la famosa vulnerabilidad en SMB que ya aprovechaba Conficker diez años antes.

Entonces... ¿es más o menos grave Meltdown/Spectre que todo esto?
Primera versión de la alerta en CERT.org en la que se aconsejaba cambiar el procesador


Cuenta con algunos elementos muy interesantes como para suponer una importante innovación. Se trata de un fallo de diseño hardware, y nada menos que en el procesador. Pocas veces habíamos sido testigos de una nota en el CERT.org donde se propusiera tan abiertamente cambiar el hardware. Podíamos mitigar el software, dejar de usarlo, deshabilitar funcionalidad, filtrar el uso… ¿pero proponer la renuncia a al mismísimo corazón de un sistema? Esto se sitúa más allá de lo que habíamos visto en seguridad hasta ahora. Un precedente cercano (salvando todas las distancias) puede ser lo que ocurrió en 1999 también con Intel. La PIC (Electronic Privacy Information Center) comunicó a finales de 1999 a la FTC (Federal Trade Comission) que investigase a Intel por entender que los por entonces nuevos Pentium III atentaban contra la privacidad del usuario. Se supone que debía mejorar la generación de números aleatorios y "fomentar el comercio en internet" pero resultó que PIII lo que generaba era una especie de "super-cookie" que identificaría al usuario (se le llamó PSN, Processor Serial Number) y que podía ser accedido por el navegador. Impensable hoy por hoy, pero planteado abiertamente por Intel en 1999. Aun así, tras la campaña "bigbrotherinside.com", la compañía tuvo que publicar un parche para deshabilitarlo, que resultó a su vez un fiasco y finalmente renunciar a la tecnología. Pero eran otros tiempos.

Mozilla dando a entender que el fallo es aprovechable a través de JavaScript

Hoy Meltdown/Sprectre supone un fallo complejo del que quizás no haya que temer tanto las consecuencias directas como los fallos colaterales.

Parches que existían antes del problema y efectos colaterales
Es poco probable que Meltdown se utilice de forma masiva, al menos para conocer o acceder a información "secreta". Quizás, podemos aventurarnos a que los efectos colaterales serán el mayor problema de esta vulnerabilidad. Algunos que se nos ocurren:
  • El primer efecto colateral ha sido tener que deshabilitar por completo una tecnología para "mitigar el fallo". La raíz básica del problema es que permite a un proceso normal ver memoria de kernel a causa del "ansia" del procesador por tomar caminos inexplorados en las ramas de decisión, y poder adelantarse y ver incluso más allá de donde le corresponde. Y esto en cierta manera ya se tenía previsto. Primero por el proyecto KASLR de 2014 que intentaba que se mitigara la posibilidad de filtrar información sobre las direcciones de memoria. Pero tenía sus propios fallos, lo que llevó a desarrollar KAISER y ahora KPTI… curiosamente, estos solucionaban Metldown, aunque todavía no existiera como tal. De hecho, Metldown es una especie de PoC de algo que se conocía de antemano, no solo por los autores de KPTI sino por la propia Joanna Rutkowska. El problema de esta tecnología de mitigación es que tienen un impacto importante en el rendimiento, puesto que se tiene que mapear y desmapear el kernel en userspace al ejecutar cada proceso, lo que en la práctica significa adiós al prefetch. Esto es letal para el rendimiento. La buena noticia es que afecta "solo" a programas que realicen muchas llamadas al kernel (syscalls) y "cuánto" lo hacen, depende también bastante de la propia naturaleza del programa. ¿Los más afectados? Virtualizadores, dockers… y la nube. Amazon y Azure parcheando sistemas como locos durante estos días. Google incluso desarrollando su propia solución para que el impacto en el rendimiento sea cero.
  • Un segundo efecto colateral llegará si se confirma que se puede aprovechar de alguna manera por JavaScript o a través del navegador. Esto permitiría no tanto aprovechar el fallo en sí, sino una fórmula de eludir ASLR, y poder así aprovechar más y mejor las vulnerabilidades de ejecución de código que ya existen y existirán. Aun así, puede ser complicado que los atacantes puedan realizar esto porque por ejemplo Mozilla ya ha publicado que reducirá la precisión de sus sistemas para que no pueda ser aprovechado por JavaScript y poco a poco se encargará de solucionarlo del todo. Chrome ya, en cierta forma, lo tenía previsto a través de su "site isolation" (siempre a la vanguardia en cuanto a sandboxing se refiere) y estaba a punto de ponerlo "en producción". Sobre el resto de navegadores, también pondrán sus propias medidas.
  • Todavía no están claras las consecuencias de Spectre por sí mismo (que afecta no solo a Intel sino a todos los procesadores), y si se avanzará en la forma en la que puede ser aprovechado. Y es que estos fallos en esencia, acentúan el eterno problema de sacrificar rendimiento sin importar la seguridad… Una técnica usada durante 20 años (ejecución especulativa) que resulta que tiene consecuencias en seguridad que pocos habían sido capaces de materializar.
  • Un último efecto colateral pasará por utilizar Meltdown como reclamo, pero no técnicamente sino como "marca" o excusa, dada su gran popularidad incluso entre los no técnicos. Malware que se hará pasar por sistemas de mejora de rendimiento, medidores de impacto de Meltdown, parches infectados, noticias falsas, clickbaits… incluso en Github ya se hacen "bromas" sobre el asunto.

Broma (Rickrolling) inocua en Github, pero que podría tener consecuencias funestas

Conclusiones
Una vulnerabilidad con características únicas, al tratarse de un hardware esencial, difícil de reemplazar, con pocas alternativas, cuya mitigación no es sencilla y con una solución que depende solo del fabricante y pasa por un rediseño hardware que no veremos en breve. Un fallo que se mantendrá a nivel hardware por mucho tiempo con nosotros y otro tanto a nivel software, con lo que no lo veremos "solucionado" por completo hasta dentro de muchos años. Un aspecto positivo es que asistiremos a toda una industria del hardware rediseñando sistemas que deberán incluir la seguridad (la capacidad de aislar incluso más las instrucciones) como prioridad ante el rendimiento, incluso. Un caso de lo más interesante en muchos aspectos por lo que ha supuesto y lo que supondrá.

Pero en definitiva, para el usuario final, hoy por hoy y tras tanto revuelo, en el día a día es más práctico que siga preocupándose  por el ransomware y los criptominers que por un posible ataque Metldown/Spectre propiamente o por sufrir las consecuencias de una hipotética bajada del rendimiento.

Sergio de los Santos
Innovación y laboratorio

No hay comentarios:

Publicar un comentario