Lo que sabemos sobre la puerta trasera en xz Utils que casi infectó al mundo entero

Incidente de la puerta trasera en xz Utils: lo que sabemos sobre el caso que casi infectó al mundo entero

• xz Utils es una utilidad de compresión de datos instalada en Linux y en casi todos los sistemas operativos de la familia Unix.
• Ocurrió un incidente en el que una actualización maliciosa de este software estuvo a punto de insertar una puerta trasera.
• Un desarrollador de Microsoft descubrió y dio a conocer esta puerta trasera, evitando una crisis justo antes de que se integrara en distribuciones importantes de Linux como Debian y Red Hat.

¿Cómo funciona la puerta trasera?

• El código malicioso añadido en las versiones 5.6.0 y 5.6.1 manipula sshd, es decir, el ejecutable para conexiones SSH.
• Una persona con una clave criptográfica específica puede ocultar código dentro de un certificado de autenticación de inicio de sesión SSH, subirlo y ejecutarlo en un dispositivo con la puerta trasera instalada.
• No se sabe qué código se llegó a subir realmente, pero en teoría sería posible realizar diversas acciones, como robar claves criptográficas o instalar malware.

Cómo se introdujo la puerta trasera

• La puerta trasera parece haber sido preparada a lo largo de varios años.
• En 2021, un usuario llamado JiaT75 contribuyó por primera vez al proyecto de código abierto.
• En enero de 2023, JiaT75 hizo su primera contribución a xz Utils y luego, bajo el nombre Jia Tan, fue asumiendo cada vez más responsabilidades.
• Tan reemplazó en el proyecto oss-fuzz la información de contacto de Collins por la suya y pidió desactivar la función ifunc durante las pruebas.
• Estos cambios dificultaron detectar modificaciones maliciosas cuando Tan las introdujo en xz Utils.

Distribuciones afectadas

• Fedora Rawhide, Fedora 41, Debian testing/unstable/experimental, openSUSE Tumbleweed y MicroOS, y Kali Linux, entre otras, incluían versiones de xz con la puerta trasera.

Opinión de GN⁺

• Este incidente deja en evidencia vulnerabilidades de seguridad en el ecosistema de código abierto y sirve como llamado de atención para la comunidad de desarrolladores.
• Dado el uso tan extendido del software afectado, esta situación recuerda a usuarios y administradores de Linux la importancia de aplicar actualizaciones rápidas y realizar revisiones de seguridad.
• Un caso similar fue el hackeo de SolarWinds, que también mostró los riesgos de los ataques a la cadena de suministro.
• Es necesario verificar la identidad de quienes contribuyen a proyectos de código abierto y reforzar los procesos de revisión de código.
• A raíz de este incidente, se espera que cobre aún más importancia la auditoría de seguridad y las herramientas de detección de vulnerabilidades.

[GN⁺]

Opinión de Hacker News

• OpenSSH es la implementación de sshd más popular y no se enlaza con la biblioteca liblzma, pero Debian y muchas otras distribuciones de Linux agregan parches para conectar sshd con systemd. systemd sí se enlaza con liblzma, por lo que xz Utils podría afectar a sshd.

• Xz es un programa y una biblioteca de compresión de código abierto que ayuda a escribir tus propios programas para manejar datos comprimidos. Se usa en muchos otros programas, incluido OpenSSH.

• binutils de GNU también se enlaza con liblzma y se usa todavía más ampliamente que OpenSSH. En la mayoría de los casos, binutils se usa para compilar OpenSSH, el sistema operativo donde corre sshd y más. Esto sugiere que los actores maliciosos eligieron un buen proyecto para infiltrarse profundamente en el software de código abierto.

• El objetivo es usar un framework de pruebas estandarizado que ayude a escribir más tests para apoyar la estabilidad del proyecto XZ a largo plazo. Como muchas funciones todavía no están probadas, estos tests serían útiles.

• No hubo mucha discusión sobre el mecanismo de enlazado que puede conectarse a la función RSA_public_decrypt. Hubo bastante discusión sobre lo que puede lograrse mediante separación de procesos y similares, pero poco sobre esa redirección de llamadas de función. Se plantea la duda de si se puede establecer una forma de enlazar componentes importantes mediante una jerarquía de confianza.

• Se dice que "casi" infectó al mundo, pero en realidad distribuciones populares de Linux como Arch, Gentoo y openSUSE Tumbleweed se distribuyeron durante varias semanas con el backdoor incluido, y en Tumbleweed definitivamente funcionó. La expresión "casi" no es apropiada.

• Predicción de que se descubrirá un caso similar dentro de los próximos 12 meses. Empezará con mantenedores sospechando de commits pasados de otros.

• Lecciones personales obtenidas de este incidente:

  • Los tarballs de distribución del código fuente que incluyen código distinto al del repositorio fuente son malos. Hay que alejarse de esa práctica.
  • Los artefactos autogenerados siempre deberían hacerse commit.
  • Los artefactos autogenerados que todo el mundo se salta durante el code review pueden ser un problema. Si este tipo de archivos está en el repositorio, debería haber tests automáticos para verificar que nadie los manipuló.
  • autotools y la cultura de autotools son malas.
  • libsystemd causa problemas en el ecosistema. A menudo se ignora a quienes critican systemd, pero systemd es grande, complejo, tiene muchas dependencias y la mayoría de los programas solo usan una parte de él.
  • La cultura de que reutilizar código siempre es bueno y de que está bien depender de bibliotecas grandes para funciones pequeñas es errónea. Las dependencias traen carga de mantenimiento y riesgos de seguridad, así que hay que equilibrarlas con la funcionalidad.
  • Puede ser problemático que los mantenedores de distribuciones apliquen parches considerables a los paquetes. En la práctica, eso crea forks de facto muy usados que nadie realmente mantiene.
  • Hay que hacer posible que los desarrolladores puedan trabajar en OSS de forma sostenible económicamente. liblzma y xz-utils tienen decenas de millones de instalaciones, pero había un solo mantenedor con problemas de salud mental.
  • El code review y el reemplazo de mantenedores ahora deben considerar factores geopolíticos.

• Expresión de agradecimiento porque quien descubrió el problema fue un ingeniero de Microsoft que trabajaba en Azure Postgres. Ahora les gusta Azure.

• El mantenedor original de xz pudo haber entregado la responsabilidad a Jia Tan sin haberlo conocido en persona ni haber hablado por teléfono con él. Se cuestiona si es normal comunicarse solo por email/GitHub. Se espera que, después de esta historia, los mantenedores de proyectos open source sean más cuidadosos.

• Aunque se piense que este backdoor fue descubierto temprano, puede que ya haya cumplido su objetivo. Especialmente si los objetivos eran desarrolladores que usan distribuciones rolling release como Kali y Debian.

• Se sugiere que fue un error afirmar que Lasse Collin, mantenedor de larga data de xz Utils, no actualizaba el software con suficiente frecuencia o rapidez.