Ripple20: Internet se ha roto otra vez

Sergio De Los Santos    22 junio, 2020
Ripple20: Internet se ha roto otra vez

En este caso, nos encontramos con que Ripple20 afecta a la implementación de la pila TCP de miles de millones de dispositivos IoT. Se habla de ataques 0-Day pero no lo son (no hay constancia de que hayan estado siendo aprovechadas por atacantes), y además una parte de ellas ya ha sido arreglada antes de ser anunciada. Pero no por ello estas vulnerabilidades son menos graves. Ante tal cantidad de dispositivos expuestos, ¿se ha vuelto a romper Internet?

Lo anunciaba el Department of Homeland Security y el CISA ICS-CERT. Se trata de 19 problemas de todo tipo en la implementación de la pila TCP/IP de la compañía Treck. Como esta implementación proporciona o licencia a infinidad de marcas (casi 80 identificadas) y dispositivos IoT, los afectados son, efectivamente, miles de millones. Y, por su propia naturaleza, muchos de ellos ni siquiera serán parcheados nunca.

¿Qué ha pasado?

La compañía JSOF ha hecho un minucioso análisis de la pila y ha encontrado problemas de todo tipo. Una escrupulosa auditoría que inevitablemente ha encontrado cuatro vulnerabilidades críticas, muchas graves y otras menores. Podrían permitir desde el control absoluto del dispositivo hasta el envenenamiento del tráfico, pasando por la denegación de servicio. Las razones para el optimismo es que han creado un logo y un nombre atractivo para los fallos y han reportado las vulnerabilidades de manera privada, por lo que muchas ya han sido solucionadas por Treck y otras empresas que usan su implementación. Las razones para el pesimismo son que otras no se han solucionado, y que es complicado rastrear las marcas y modelos afectados (66 marcas están pendientes de confirmar). En todo caso, otro dato importante a destacar es que estos dispositivos suelen encontrarse precisamente en plantas industriales, hospitales y otras infraestructuras críticas en los que una vulnerabilidad grave podría tener consecuencias horribles.

Así que sólo queda auditar, comprender y mitigar el problema caso a caso para saber si un sistema está realmente en peligro. Algo que ya debería hacerse bajo un plan de seguridad maduro (del que no deben estar exentos los entornos OT) pero que en todo caso podría servir de acicate para lograrlo. Porque son fallos graves, públicos y en las entrañas de dispositivos usados para operaciones críticas… Una verdadera espada de Damocles.

En todo caso, ya se conocen y por tanto, es posible protegerse o mitigar el problema, como ya ha ocurrido en el pasado ante otros graves problemas que han afectado a millones de dispositivos conectados. Con ellos parecía que Internet se iba a romper pero, a pesar de todo, seguimos adelante. Y no porque no hayan sido graves (o incluso, probablemente, aprovechados por terceros), sino porque se supo responder a ellos en tiempo y forma. No hay que restarles importancia, sino precisamente seguir otorgándosela para que no la pierdan, pero huyendo siempre de titulares catastrofistas. Repasemos algunos casos históricos.

Otros “apocalipsis” en ciberseguridad

Ya se han dado otros casos de catástrofes que afectarían a la red tal y como la conocemos y sobre los que se han escrito numerosos titulares pesimistas. Veamos algunos ejemplos:

  • 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). Eran otros tiempos y al final quedó en una especie de decepción apocalíptica que se sació con mucha literatura y algunos telefilmes.
  • 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: fue 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. Doce años después, incluso después de esa catástrofe, DNSSEC sigue siendo “una rareza”.
  • Espionaje a “gran escala” con BGP: en agosto 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 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: dio 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, etc. 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.
  • Spectre/Meltdown en 2017 (y desde entonces otros muchos fallos en los procesadores): este tipo de fallos contaba con algunos elementos muy interesantes como para suponer una importante innovación. Se trataba de fallos de diseño hardware, 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 para poder solucionar un fallo.

Sin embargo, si lo miramos con perspectiva, hasta el momento parece que nunca se ha utilizado ninguna de estas vulnerabilidades como método de ataque masivo que colapse Internet y “lo rompa”. Afortunadamente, la responsabilidad de todos los actores en la industria ha servido para que no nos situemos en los peores escenarios.

Desafortunadamente, sí que hemos sufrido graves problemas en la red, pero han sido provocados por otros fallos mucho menos espectaculares, basados en “gusanos tradicionales” como WannaCry. Lo que manifiesta quizás una interesante perspectiva sobre, por un lado, lo maduro de la industria y, por otro, el tremendo trabajo que es necesario culminar todavía en algunos aspectos incluso más simples.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *