La historia que te voy a contar en este programa del podcast enCLAVE DIGITAL, bien merece una película hollywoodiense.

¿Y si te dijera que, gracias a la cabezonería de un ingeniero de Microsoft, hace tan solo unas pocas semanas se destapó la que ya es considerada una de las campañas de espionaje mundial más sofisticadas de las últimas décadas?

Una capaz de poner en jaque la práctica totalidad de servicios informáticos del mundo.

Tal cual y como lo oyes.

Vamos a hablar de cómo, durante dos años, estos cibercriminales perpetraron la estrategia definitiva para llegar a comprometer cualquier servidor Linux. Y cómo el trabajo de un simple voluntario acabó evitando lo que podría haber sido un auténtico holocausto informático.

¡Empecemos!

xz utils

El héroe de esta historia de hackers

No me queda otra que empezar hablando de Andres Freund (EN), un desarrollador alemán de 38 años que trabaja para Microsoft.

Y no sé lo que tú harás en tus ratos libres…

En mi caso, por ejemplo, me gusta salir a pasear por el campo, entrenar o jugar a videojuegos.

Sin embargo, lo de Andres va a otro nivel.

¿Quieres saber por qué?

El bueno de Andres dedica parte de sus ratos libres a testear librerías de Linux.

Sí, hay gente para todo :D.

Y le entiendo, ojo, que yo también tuve mi época de trastear con el sistema operativo open source por antonomasia.

Pero a diferencia de en mi caso, Andres ha hecho de su hobby lo que podríamos considerar un trabajo a media jornada no remunerado, habida cuenta de que este ingeniero es uno de los principales contribuidores de la base de datos Postgres, una de las principales bases de datos de open source.

Pues bien.

Hace unas semanas, como te comentaba, el bueno de Andres había terminado su jornada de trabajo en Microsoft, y como cada tarde, decidió que era un buen día para probar algunas de las nuevas versiones de librerías que había en el repositorio de su distribución de Linux preferida.

Descargó los archivos y se puso a pasarles una serie de controles rutinarios.

Sin embargo, y para su sorpresa, descubrió que uno de los procesos SSH tardaba un poco más en ejecutarse de lo normal.

Que ojo, no estamos hablando de nada del otro mundo.

Era simplemente una demora de medio segundo.

Repito: Medio maldito segundo.

Esto, ya no solo para mi, sino para cualquier desarrollador de la Comunidad, puede pasar totalmente desapercibido.

A fin de cuentas, ¿a quién le importa actualmente la optimización de recursos, con conexiones cada vez más rápidas y ordenadores cada vez más potentes?

Medio segundo en una prueba unitaria puede pasar desapercibido para cualquiera.

Y, sin embargo, a Andres se le encendió la bombilla, recordando que hacía unos días, el vuelo de vuelta a casa después de visitar a la familia por Navidad, se había encontrado unos cuantos errores de SSH en otra prueba automática realizada.

Algo que, de nuevo, no tiene por qué ser grave.

De hecho, mi propia página (cualquier software colgado a la red que dependa de múltiples recursos, para ser más estrictos) suele dar algunos warnings y errores habitualmente. Y, pese a ello, lo más normal es que todo funcione perfectamente.

Pero recordemos que no estamos ante un técnico sin más. Andrés es uno de esos «de la vieja guardia», así que, motivado por la búsqueda de una razón lógica para ambos eventos, se puso manos a la obra a analizar qué demonios estaba haciendo que el SSH diera algunos fallos hace unos días, y ahora tardara un poco más en cargar de la cuenta.

Un par de horas más tarde, y tras revisar por tercera vez que no se estaba equivocando, luchando porque su corazón no le saliera por la boca, bebió de una sentada todo el vaso que tenía delante suyo para recuperar la humedad de una boca totalmente seca por el nerviosismo, y se llevó las manos a la cabeza: Había descubierto lo que en el argot técnico se llama un 0 day.

Una vulnerabilidad que alguien había metido en esa librería en particular, y que permitía al atacante ejecutar cualquier petición a la máquina infectada con permisos de administrador.

Escucha:

Se encuentra una puerta trasera en una utilidad de Linux ampliamente utilizada que apunta a conexiones SSH cifradas.

El código malicioso colocado en xz Utils ha estado circulando durante más de un mes.

Reportaje en ArsTechnica (EN)

¿Qué es XZ Utils?

Para explicarlo en cristiano, intentando usar los menos tecnicismos posibles, quédate con la idea de que XZ Utils es una herramienta que permite comprimir archivos (entre otras cosas, no me vengáis ahora los técnicos a corregirme…) muy eficiente.

Es, para que nos entendamos, como los formatos .zip o .rar que seguramente alguna vez en tu día a día has descargado, y que incluía dentro varios archivos más pesados que su contenedor original.

Pues el .xz es lo mismo, pero empleando un algoritmo (el LZMA) que consigue reducir hasta un 70% el peso que tienen los tradicionales gzip, muy usados en el mundo del desarrollo.

Y aquí entra en escena otro protagonista.

Este formato de fichero, por seguir con la trama, fue creado en 2005 por Lasse Collins, otro de esos desarrolladores que, en sus ratos libres, y sin recibir remuneración de ningún tipo, decidió publicar en abierto su proyecto.

Tres años más tarde, los ficheros .xz se empiezan a popularizar, hasta el punto de que varias distribuciones de Linux (es decir, varios sistemas operativos basados en este SO gratuito) lo adoptan como el sistema de ficheros por defecto.

Todo esto mientras, recuerdo, el proyecto sigue siendo gestionado por una única persona: Collins.

Sin embargo, en 2021 ocurre algo que cambiará, para siempre, el futuro de esta historia.

Pero antes de meterme en este jaleo, quiero que tengas en cuenta que en nuestros días XZ Utils está presente en la práctica totalidad de sistemas Linux que hay en el mundo.

Tal es su impacto, que se calcula que del millón de servidores web con más tráfico en Internet, el 96,3% utilizan XZ Utils.

Y, por tanto, ese 93% largo serían vulnerables a este ciberataque (EN).

Uno que permitiría, como te comentaba anteriormente, que estos cibercriminales hubieran tenido acceso a cualquier servidor web del mundo con permisos de administrador, pudiendo tumbarlo, o mejor aún, robar datos, redirigir tráfico, estafar a los usuarios…

Todo que se te ocurra, vaya.

Ha habido, que sepamos, muy pero que muy contadas ocasiones en toda la historia de la informática en que hemos estado tan sumamente cerca de que alguien con intereses maliciosos fuera capaz de poner en jaque el conjunto de toda la sociedad informática.

Y esta, ha sido una de ellas.

Sin el descubrimiento de Andres, preocupado por ese mísero medio segundo de latencia en un proceso random, muy probablemente esta nueva versión de XZ Utils hubiera acabado en producción (es decir, disponible en la casi totalidad de servidores web mundiales), dando a sus cibercriminales la capacidad de hacer lo que quisieran con el futuro del mundo.

Y no estoy exagerando.

De ahí que te dijera al principio del podcast que en unos años bien podríamos tener una película de toda esta historia.

Porque, ahora viene lo bueno.

¿Sabes a qué me refiero?

Escucha.

¿Quién está detrás del mayor hackeo a Linux de las últimas décadas?

Esta es la pregunta del millón.

Y, para responderla, vamos a repasar lo que ocurrió desde esos últimos meses de 2021 hasta la actualidad.

Ahí es cuando entra en escena un tal Jin Tan, un desarrollador que empieza a enviar parches y propuestas a la lista de distribución de XZ.

Collins, que recordemos que, hasta el momento, era el único gestor del proyecto (y su creador), no era la primera vez que recibía ayuda de otros desarrolladores, y por eso, en febrero de 2022 es cuando tenemos constancia de que la primera pieza de código enviada por Jin Tan es incluida en XZ.

Pocos meses después, y tras numerosos cruces de emails entre los miembros de la Comunidad, Jin Tan envía otro parche, que es rápidamente secundado por otros dos supuestos desarrolladores: Jigar Kumar y Dennis Ens.

En esas conversaciones, estos desarrolladores echan en cara a Lasse de que el proyecto evolucione tan lentamente cuando ya hay un grupo de entusiastas, como Jin Tan, interesados en aportar código.

Collins se disculpa, recordando que todo esto SIGUE HACIÉNDOLO sin percibir ni un mísero dólar, y que está revisando en sus ratos libres todas las propuestas que le llegan, aunque reconoce que un poco de ayuda no le vendría nada mal, y agradece a Jin Tan que se haya molestado en mejorar el código e incluir nuevas funcionalidades.

Este tipo de presiones continuarán durante los meses siguientes, llegando a amenazar al bueno de Lasse con crear un fork de su proyecto (es decir, coger lo que él había creado, cambiarle de nombre, y ofrecerlo a la comunidad como si fuera otro desarrollo):

«El progreso no se producirá hasta que haya un nuevo mantenedor […] es mejor que esperes hasta que aparezca un nuevo mantenedor o te bifurques. Enviar parches aquí no tiene ningún propósito en estos días. El mantenedor actual perdió interés o ya no le interesa mantener más. Es triste ver un repositorio como este».

Comentario de uno de los supuestos desarrolladores en la lista de correo

Lasse sigue defendiéndose con que no da a basto. Que no vive de esto, que está experimentando «problemas mentales personales», y que intentará aumentar la dedicación al proyecto.

De hecho, cada vez más parches de Tan llegan a la versión final de la librería, y este desarrollador, tras las múltiples presiones, acabará por ser nombrado gestor del proyecto, y obteniendo, por tanto, los permisos de mantenimiento, a finales de 2022.

Así, en marzo de 2023 Jin Tan publicará, ya con permisos de gestión de la librería (y, por tanto, sin necesitar la aprobación de su creador), la primera versión (la 5.4.2) bajo su entero control.

Y en junio de ese mismo año, otro desarrollador que se hace llamar Hans Jansen envía un par de parches que son rápidamente aceptamos por Tan, y que abrirían la caja de Pandora, al ser los primeros que incluyen ya una serie de funcionalidades necesarias para que el 0 day, es decir, la puerta trasera instalada por Tan en una actualización (la versión 5.6.0 de la librería) en febrero de 2024, funcione.

A partir de ese momento, y en los próximos días hasta que nuestro héroe, el alemán Andres, diera a conocer el hackeo, el futuro de la seguridad de prácticamente todo sistema informático colgado de la red ha pendido de un hilo.

Lo que podemos aprender de este ciberataque

Desde entonces he ido leyendo varios análisis que han estado publicando en prácticamente todos los grandes medios sectoriales.

Y, como era de esperar, todavía quedan unas cuantas cuestiones a considerar.

Para empezar, no tenemos constancia de que tanto Jansen (el supuesto desarrollador cuyo código abrió la puerta al ciberataque), como Kumar o Ens (los dos supuestos desarrolladores que hostigaron al creador de la liberaría a que buscase a un nuevo gestor), como, por supuesto, Jin Tan (el que subió el parche que incluía el malware) sean personas reales.

No hay registros de ellos por Internet más allá de las conversaciones realizadas en esta lista de correo, lo que apunta a que probablemente estemos ante la misma persona, o ante un grupo de personas organizadas bajo la misma célula de ciberespionaje.

Por otro lado, me parece CRÍTICO hacer hincapié en lo que supone que en la actualidad, buena parte de las tripas que dan forma a los servicios que todos utilizamos en nuestro día a día, estén siendo gestionados por personas que, recalco, NI TAN SIQUIERA VIVEN DE ELLO, y que por tanto, dedican sus ratos libres de forma totalmente desinteresada por el bien de la sociedad.

En enero de hace un par de años tuvimos un caso semejante con la vulnerabilidad Log4j, un componente básico para plataformas como iCloud, Twitter y compañía.

Y ya entonces decía lo siguiente:

Su creador, Volkan Yazici, harto tras años de estar subiendo parches a su herramienta y haber facturado en todo este tiempo la friolera de 36,9€ euros (no millones de euros, euros), decidió abandonar el proyecto a su suerte, y sería recuperado por un grupo de cibercriminales, vinculados al parecer con el gobierno chino y de Irán, que acabarían por insertar una vulnerabilidad que puso en jaque los cimientos de Internet.

Historia completa contada en el blog de PabloYglesias

En aquel entonces ya muchos estuvimos debatiendo sobre las opciones que teníamos.

Porque, por un lado, no tiene absolutamente nada de sentido que haya grandes corporaciones como Google, Amazon, Facebook y Microsoft que ganan miles de millones de dólares construyendo tecnología por encima de estos componentes, y que por debajo, haya desarrolladores trabajando hasta 22 horas al día sin cobrar un mísero dólar por todo su trabajo.

La historia del sotware libre tiene grandes beneficiados, pero esa misma historia olvida a todos los que están haciendo posible esta sociedad digital, amparándose en lo típico de «es que lo hacen desinteresadamente».

El futuro de muchas de estas librerías acaba siendo como lo que ocurrió con Log4j. Quien está detrás acaba abandonándolo por falta de tiempo, por acabar quemado, porque forma una familia y tiene mejores cosas que hacer, o, simplemente, porque acaba teniendo un trabajo que es lo que le da de comer.

Y, por el camino, nos encontramos, de pronto, con problemas muy serios de seguridad que afectan a nivel mundial:

¿Se debería por ley considerar el software libre una amenaza para la seguridad nacional, y por tanto prohibir su uso, por ejemplo, en infraestructuras críticas?

¿Se debería entonces forzar a que las grandes compañías que hacen uso del software libre estén obligadas a financiarlo?

Estas eran dos de las preguntas que lanzaba en su momento, y que siguen tan vigentes hoy en día como lo estaban en 2022.

La respuesta, no obstante, no es tan fácil de dar.

Y, por último, no puedo terminar este podcast sin dedicarle unas palabras al nivel de sofisticación de este ciberataque.

Recordemos que estamos hablando de una campaña que empezó a gestarse nada menos que hace tres años.

Tres años en el que el, o los cibercriminales, han tenido, no solo la paciencia, sino también la capacidad técnica, para hacerse pasar por varios perfiles de supuestos desarrolladores e ir, poco a poco ganándose la confianza del gestor de una librería que muchos, antes de este suceso, ni tan siquiera sabíamos que existía.

Todo con un roadmap lo suficientemente elaborado y pautado, que les permitiera, tres años después, acabar comprometiendo la seguridad de toda la infraestructura web mundial.

Llegar a este punto, hace que la mayoría apuntemos a que estamos, nuevamente, ante agentes que, como mínimo, están financiados por gobiernos como China, Rusia, o la propia Estados Unidos.

Una campaña de espionaje que solo Dios sabría dónde habría acabado, y algo contra lo que combatir va a ser prácticamente imposible.

Porque este es el corolario con el que tengo que acabar, pese a que me gustaría que fuera diferente.

El software libre no es el problema, sino justo lo contrario.

Aunque ahora muchos medios señalen las debilidades del software libre (que, por supuesto, las tiene), deberíamos quedarnos con la idea de que ha sido gracias a que XZ está distribuido de forma abierta, que nos hemos enterado de que algo así estaba a punto de suceder.

Esto mismo. Justo esto mismo, podría estar ocurriendo a día de hoy en cualquier otro software de Google, de Microsoft, de Amazon, de Meta… de cualquier gran compañía. Pero claro, como solo los ingenieros de la compañía pueden auditarlo, probablemente nunca nos enteraremos…

y dicho todo esto, ahora turno para ti:

  • ¿Qué medidas crees que deberíamos tomar para minimizar el riesgo real de abandono de proyectos open source críticos para la sociedad de la información por parte de desarrolladores no remunerados?
  • ¿Quién crees que puede estar detrás de este ciberespionaje a gran escala?
  • Y, por último, ¿crees que es el software propietario un parche a esta problemática del software libre?

Te leo en comentarios, y abramos debate.

Sobre el videopodcast enCLAVE DIGITAL

enCLAVE DIGITAL es el videopodcast de Pablo F. Iglesias, consultor de presencia digital y reputación online.

Si este contenido te sirve para estar bien informado sobre la actualidad en materia de negocios digitales, reputación y tecnología, te agradecería que le dieras a suscribirte en mi canal de Youtube o en la plataforma de podcasting desde donde me escuchas, le des a Me Gusta, me dejes un comentario o reseña y lo compartas con aquellos a los que les pueda interesar.

¡Seguimos!

Si utilizas otra plataforma de podcasting, busca «enCLAVE DIGITAL« en la app para localizarlo, o visita la página del videopodcast, donde ofrezco enlaces directos a las principales plataformas actuales: