De hackers y código abierto: la desconocida historia del ciberataque que pudo destruir Internet

Hace unos meses presenciamos uno de los ataques más audaces y potencialmente dañinos en la historia de Internet, un hackeo que podría haber devastado la red. Durante una revisión rutinaria de un programa de compresión de datos, un ingeniero de Microsoft descubrió accidentalmente un sabotaje, evitando así un desastre sin precedentes. Este ataque ha encendido todas las alarmas dentro de la comunidad open source, dejando una pregunta en el aire: ¿hasta qué punto puede manipularse o corromperse un programa antes de que alguien se dé cuenta?

El software se come el mundo, y open source se come al software. Incluso proveedores como Microsoft, que durante años fueron reacios a adoptarlo, ahora contienen una proporción cada vez mayor de código que cualquiera puede leer, modificar o utilizar libremente.

No es una exageración decir que los cimientos de la economía digital están hechos a base de código abierto. Basta con observar el uso generalizado del kernel de Linux. Su presencia es ubicua, funcionando como el “intermediario” entre el hardware de las máquinas y las aplicaciones que se ejecutan sobre ellas. Es uno de los primeros programas que se cargan cuando encendemos un ordenador, un servidor o una supercomputadora. Es fácil deducir que todos los sectores, incluido el de infraestructuras críticas, lo utilizan.

Sin embargo, a pesar de que la economía digital está construida sobre open source, todavía no se comprenden bien los riesgos que entraña depender de una comunidad que opera de forma anónima y descentralizada, y donde la colaboración se basa en la confianza implícita que da la reputación. En realidad, no sabemos mucho sobre las debilidades y posibles puntos ciegos de esta forma de cooperación. Solo ahora empezamos a ser conscientes de su existencia.

La transparencia radical de open source lo convierte en el software más seguro

Todo software es susceptible de contener errores en su código. Cualquier fabricante puede producirlos en su desarrollo. Estos fallos se conocen como vulnerabilidades de día cero: defectos de fábrica que pasan inadvertidos y permanecen ocultos hasta que alguien los encuentra y los explota. Estas «puertas traseras» dan acceso a los sistemas sin ser detectados. Al fin y al cabo, se utiliza una puerta que nadie más conoce. Los gobiernos y las agencias de espionaje de todo el mundo, entre otros, están dispuestos a pagar grandes sumas de dinero por conocerlas.

La compraventa de vulnerabilidades de día cero es uno de los mercados más opacos del mundo. Poco se sabe sobre sus compradores y vendedores, ya que ninguno se anuncia. Actúan a escondidas. Esto es algo que no puede suceder con el software open source. Aquí todo está a la vista y puede auditarse. La transparencia es radical. Cualquiera puede ver, evaluar o corregir el código. No hay lugar donde esconderse. ¿Qué podría permanecer oculto a los ojos de una comunidad que el año pasado superó los 100 millones de miembros?

En realidad, no todos los ojos miran en todas las direcciones. La mayoría se fija en el brillo de lo nuevo. Precisamente, lo que atrae talento a esta comunidad es la posibilidad de que cualquiera pueda innovar. No hace falta ser una gran multinacional. Algunas contribuciones importantes son realizadas por equipos pequeños, incluso por un único desarrollador. Y esto que lo hace tan atractivo, al mismo tiempo, es su mayor debilidad. En primer lugar, porque, alejados de la innovación, programas ya consagrados a un mantenimiento continuo no generan interés y sus creadores entran, frecuentemente en solitario, en la rutinaria tarea de actualizarlos. En segundo lugar, porque estos programas son la base sobre la que se construyen nuevos desarrollos, y si fallan, arrastran todo lo que se haya creado encima de ellos. De hecho, para medir el riesgo de un proyecto de open source se utiliza el «factor autobús». Se trata de identificar si algún componente del desarrollo depende de un solo individuo, porque si este fuera atropellado por un autobús, el proyecto entero se vería impactado.

Anatomía de un ataque que pudo devastar Internet

El programa ZX Util es uno de esos ejemplos en los que un desarrollador hace una contribución individual disruptiva. De la noche a la mañana, crea un programa capaz de comprimir datos de forma mucho más rápida y efectiva que los existentes. Su uso se populariza y comienza a extenderse, y nuevos desarrollos se construyen sobre él. Transcurrido un tiempo, su creador sigue encargado de su mantenimiento, actualizándolo para adaptarlo a nuevos sistemas operativos, procesadores o dispositivos.

Un día, un colaborador anónimo comienza a proponer algunas mejoras en el programa. Es un desconocido, tan solo han intercambiado algunos correos. Poco a poco va ganándose su confianza sugiriendo pequeños cambios aquí y allá. Sin embargo, no son suficientes. En paralelo, grupos de usuarios del programa comienzan a pedir actualizaciones y lamentan que el programa se esté quedando obsoleto, que esté siendo desatendido. Su creador, después de años de abnegada dedicación, termina cediendo a la presión. No puede dedicarle el tiempo necesario y delega el mantenimiento en ese colaborador que ha estado ayudándole durante los últimos dos años.

El supuesto colaborador es en realidad un grupo de hackers que, después de un sofisticado ataque de ingeniería social (también están detrás de las presiones los usuarios insatisfechos), se ha hecho con el control de ZX Util. A partir de este momento, comienzan a realizar pequeñas modificaciones en el programa con la intención de crear un troyano que sirva como “puerta trasera” para otro software que utiliza este compresor de datos. Quieren sabotear un programa (OpenSSH) que literalmente es la llave maestra que da acceso a todos los servidores de Internet.

El último paso para alcanzar su objetivo es conseguir que los principales sistemas operativos de la comunidad open source acepten la nueva actualización propuesta por los hackers y comiencen a distribuirla de forma masiva. Es entonces cuando llega a las manos de un ingeniero de Microsoft que, en una prueba rutinaria, percibe que el programa tarda medio segundo más de lo que debería. Empieza a investigar y para su sorpresa descubre toda la trama.

Mirando al futuro: ¿es posible evitar que está situación se repita?

El ataque a ZX pone de manifiesto la fragilidad de la economía digital. Pero ¿qué se puede hacer para proteger un ecosistema de desarrolladores tan dinámico que opera a escala global? Conscientes de la envergadura de este reto, DARPA, una agencia del Departamento de Defensa estadounidense, lanzó el verano pasado un programa para conocer mejor los riesgos del ecosistema open source. Algunos ejemplos de iniciativas que están en marcha son crear un mapa de dependencias en la cadena de suministro del software, realizar un análisis de sentimiento de los distintos grupos de desarrolladores, o identificar vulnerabilidades en el desarrollo, mantenimiento y distribución del software.

El volumen de proyectos y contribuciones que se realizan anualmente dentro de la comunidad para crear y mejorar el software se mide en miles de millones, según datos del último estudio Octoverse realizado por GitHub. Esto da una idea de la complejidad tanto tecnológica como social de este análisis. Aquí entra en juego la inteligencia artificial, que se ha convertido en una herramienta indispensable para comprender los riesgos y proteger la integridad del software.

El éxito de open source es indiscutible. Ha hecho posible que millones de personas colaboren a una escala sin precedentes en la historia de la humanidad. Hoy en día, no se puede entender la innovación digital sin esta comunidad de desarrolladores. Sin embargo, el precio que hay que pagar por su éxito es tener que exponerse a riesgos desconocidos. Esta vez, los atacantes han estado a medio segundo de desencadenar una catástrofe, probablemente lo más cerca que hemos estado nunca de romper Internet.

Más Información