La puerta trasera de XZ Utils en Linux apunta a un problema más amplio de seguridad de la cadena de suministro, y necesitamos algo más que espíritu comunitario para mantenerla a raya.

El sector de la ciberseguridad ha vuelto a ponerse en alerta tras el descubrimiento de un insidioso fallo en la cadena de suministro de software. La vulnerabilidad, que afecta a la biblioteca de compresión de datos XZ Utils incluida en las principales distribuciones de Linux, se registra bajo el código CVE-2024-3094 y se reduce a una puerta trasera insertada deliberadamente por un mantenedor voluntario del sistema en el que se confiaba. Permitiendo la ejecución remota de código (RCE) en algunos casos si se explota con éxito, representa un problema de alta gravedad con la capacidad de causar graves daños en los procesos de construcción de software establecidos.

Afortunadamente, otro mantenedor descubrió esta amenaza antes de que el código malicioso entrara en las versiones estables de Linux, pero todavía plantea un problema para aquellos que han comenzado a ejecutar la versión 5.6.0. y 5.6.1. de XZ Utils como parte de Fedora Rawhide, y se insta a las organizaciones a parchearlo como una prioridad de nivel de emergencia. Si este descubrimiento no se hiciera a tiempo, el perfil de riesgo lo convertiría en uno de los ataques a la cadena de suministro más devastadores de los que se tiene constancia, quizá eclipsando incluso a SolarWinds.

La dependencia de los voluntarios de la comunidad para mantener los sistemas críticos está ampliamente documentada, pero rara vez se habla de ella hasta que salen a la superficie problemas de gran impacto como este incidente. Aunque su incansable labor es esencial para el mantenimiento del software de código abierto, este incidente pone de manifiesto la necesidad de hacer hincapié en la concienciación y las aptitudes de los desarrolladores en materia de seguridad, por no hablar de la necesidad de reforzar los controles de acceso a los repositorios de software.

¿Qué es el backdoor de XZ Utils y cómo se mitiga?

El 29 de marzo, Red Hat publicó una alerta de seguridad urgente para informar a los usuarios de Fedora Linux 40 y Fedora Rawhide de que las últimas versiones de las herramientas y librerías de compresión "XZ" contienen un código malicioso que parece haber sido creado a propósito para facilitar el acceso no autorizado de terceros.Cómo se inyectó este código malicioso será probablemente objeto de intenso estudio en el futuro, pero equivale a un sofisticado y paciente ejercicio de ingeniería social de años de duración por parte del actor de la amenaza, un atacante seudónimo llamado "Jia Tan". Este individuo dedicó incontables horas a ganarse la confianza de otros mantenedores, haciendo contribuciones legítimas al proyecto XZ Utils y a la comunidad durante más de dos años, hasta que finalmente se ganó el estatus de "mantenedor de confianza" después de que múltiples cuentas de títeres de la sombra erosionaran la confianza en el propietario voluntario del proyecto, Lasse Collin:

‍

‍

Este escenario inusual es un ejemplo perfecto de una persona altamente técnica que sigue siendo víctima de tácticas normalmente reservadas para su uso contra aquellos que son menos expertos, lo que demuestra la necesidad de una formación de concienciación de seguridad precisa y basada en roles. Sólo gracias a la curiosidad y rapidez mental de Andres Freund, ingeniero de software de Microsoft y mantenedor de PostgreSQL, se descubrió la puerta trasera y se revirtieron las versiones, deteniendo así lo que podría haber sido el ataque a la cadena de suministro más devastador de los últimos tiempos.

La puerta trasera en sí está siendo rastreada oficialmente como una vulnerabilidad de la mayor gravedad posible en el registro del NIST. Inicialmente se pensó que permitía eludir la autenticación SSH, pero investigaciones posteriores revelaron que permitía la ejecución remota de código sin autenticación en sistemas Linux vulnerables, incluyendo Fedora Rawhide, Fedora 41, Kali Linux, openSUSE MicroOS, openSUSE Tumbleweed y algunas versiones de Debian.

Jia Tan parece haber hecho todo lo posible para ofuscar el paquete malicioso, que, cuando se activa para construirse a sí mismo durante el proceso de construcción, dificulta la autenticación en SSHd a través de systemd.Como Red Hat detalló, en las circunstancias adecuadas, esta interferencia podría potencialmente permitir a un atacante romper la autenticación SSHd y obtener acceso remoto no autorizado a todo el sistema.

‍

Microsoft, entre otros, ha publicado una guía completa sobre el escaneo de sistemas en busca de instancias del exploit y la mitigación de su efecto, y la acción inmediata recomendada por CISA es que los desarrolladores y usuarios afectados deben actualizar XZ Utils a una versión no comprometida, como XZ Utils 5.4.6 Estable.

Prevenir este tipo de ataque es increíblemente difícil - especialmente cuando se utilizan componentes de código abierto en el software - ya que hay muy poca garantía y transparencia sobre la seguridad de la cadena de suministro. Ya hemos combatido los fallos accidentales en la cadena de suministro de software, pero este riesgo se ha elevado hasta incluir fallos de seguridad colocados deliberadamente con malicia para comprometer la seguridad del código abierto.

La mayoría de los desarrolladores no serán capaces de detener un ataque de esta naturaleza a menos que tengan un fuerte sentido de la conciencia de la seguridad, conocimientos sanos de seguridad y una pizca de paranoia. Es casi un caso de requerir una mentalidad de actor de amenazas. Sin embargo, una consideración principal debería centrarse siempre en los repositorios de código fuente controlados internamente (es decir, no de código abierto). Sólo deberían tener acceso a ellos las personas con conocimientos de seguridad pertinentes y verificados. Los profesionales de la seguridad de las aplicaciones podrían considerar una configuración como los controles de seguridad a nivel de rama, que sólo permiten a los desarrolladores con conocimientos de seguridad introducir cambios en la rama maestra final.

Los mantenedores voluntarios son héroes, pero hace falta (o debería hacer falta) un pueblo para mantener un software seguro.

Para quienes no pertenecen al ámbito de la ingeniería de software, la noción de que una animada comunidad de voluntarios mantiene concienzudamente sistemas críticos en su propio tiempo es un concepto difícil de entender, pero esta es la naturaleza del desarrollo de código abierto, y sigue siendo un área de riesgo crítico para los profesionales de la seguridad que protegen la cadena de suministro.

El software de código abierto es una parte vital del ecosistema digital de prácticamente todas las empresas, y los mantenedores de confianza (la mayoría de los cuales actúan de buena fe) son verdaderamente heroicos en su búsqueda desinteresada del progreso tecnológico y la integridad, pero es una farsa mantenerlos aislados. En estos tiempos centrados en DevSecOps, la seguridad es una responsabilidad compartida, y cada desarrollador debe estar armado con el conocimiento y las herramientas adecuadas para navegar por los problemas de seguridad que probablemente se encuentren en su día a día. La concienciación sobre la seguridad y las habilidades prácticas no deberían ser negociables en el proceso de desarrollo de software, y depende de los líderes de seguridad influir en el cambio a nivel empresarial.
‍

‍Construyahoy mismo una próspera cultura de la seguridad en su organización con un profundo Courses de Secure Code Warrior.