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

El sector de la ciberseguridad volvió a ponerse en alerta máxima tras el descubrimiento de un insidioso compromiso en la cadena de suministro de software. La vulnerabilidad, que afecta a la biblioteca de compresión de datos XZ Utils que se incluye en las principales distribuciones de Linux, está registrada bajo el CVE-2024-3094 y se reduce a una puerta trasera insertada deliberadamente por un mantenedor voluntario que antes era de confianza. Al permitir la ejecución remota de código (RCE) en algunos casos si se explota con éxito, representa un problema de alta gravedad con capacidad para causar daños graves en los procesos de compilació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 sigue siendo un problema para quienes han empezado a ejecutar las versiones 5.6.0 y 5.6.1 de XZ Utils como parte de Fedora Rawhide, y se insta a las organizaciones a aplicar parches como prioridad de emergencia. Si este descubrimiento no se hubiera hecho a tiempo, el perfil de riesgo lo convertiría en uno de los ataques a la cadena de suministro más devastadores registrados, quizás incluso eclipsando a SolarWinds.

La dependencia de voluntarios de la comunidad para mantener sistemas críticos está ampliamente documentada, pero rara vez se discute hasta que problemas de gran impacto como este incidente salen a la superficie. Aunque su incansable trabajo es esencial para el mantenimiento del software de código abierto, esto pone de relieve la necesidad de hacer hincapié en las habilidades de seguridad y la concienciación a nivel de desarrollador, por no hablar de mayores controles de acceso en torno a los repositorios de software.

¿Qué es la puerta trasera 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 bibliotecas de compresión "XZ" contienen código malicioso que parece haber sido creado específicamente para facilitar el acceso no autorizado de terceros. La forma en que se inyectó este código malicioso será probablemente objeto de un intenso estudio en el futuro, pero equivale a un ejercicio de ingeniería social sofisticado, paciente y de años de duración por parte del actor de la amenaza, un atacante seudónimo llamado "Jia Tan". Esta persona pasó incontables horas ganándose la confianza de otros mantenedores, realizando contribuciones legítimas al proyecto y a la comunidad de XZ Utils durante más de dos años, hasta que finalmente obtuvo el estatus de "mantenedor de confianza" después de que varias cuentas falsas erosionaran la confianza en el propietario del proyecto voluntario, Lasse Collin:

‍

‍

Este escenario inusual es un ejemplo perfecto de cómo una persona altamente técnica puede seguir siendo víctima de tácticas reservadas normalmente para quienes tienen menos conocimientos, lo que demuestra la necesidad de una formación en concienciación sobre seguridad basada en roles y precisión. Solo gracias a la curiosidad y rapidez mental del ingeniero de software de Microsoft y mantenedor de PostgreSQL, Andres Freund, 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. Aunque inicialmente se pensó que permitía eludir la autenticación SSH, una investigación posterior reveló que permitía la ejecución remota de código sin autenticación en sistemas Linux vulnerables, incluidos Fedora Rawhide, Fedora 41, Kali Linux, openSUSE MicroOS, openSUSE Tumbleweed y algunas versiones de Debian.

Jia Tan parece haber hecho grandes esfuerzos para ofuscar el paquete malicioso, el cual, cuando se activa para construirse durante el proceso de compilación, obstaculiza la autenticación en SSHd a través de systemd. Como Red Hat detalló, en las circunstancias adecuadas, esta interferencia podría permitir potencialmente 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 cómo escanear sistemas en busca de instancias del exploit y mitigar su efecto, y la acción inmediata recomendada por CISA es que los desarrolladores y usuarios afectados degraden XZ Utils a una versión no comprometida, como XZ Utils 5.4.6 Stable.

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 fallos accidentales en la cadena de suministro de software, pero este riesgo ha aumentado hasta incluir errores de seguridad plantados deliberadamente con malicia para comprometer la seguridad del código abierto.

La mayoría de los desarrolladores no podrán detener un ataque de esta naturaleza a menos que tengan un fuerte sentido de la concienciación sobre la seguridad, conocimientos sólidos 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 siempre debe centrarse en los repositorios de código fuente que están controlados internamente (es decir, que no son de código abierto). Estos solo deben ser accesibles para personas que tengan habilidades de seguridad verificadas y relevantes. Los profesionales de AppSec podrían considerar una configuración como controles de seguridad a nivel de rama, permitiendo solo a los desarrolladores con habilidades de seguridad confirmar cambios en la rama maestra final.

Los mantenedores voluntarios son héroes, pero se necesita (o debería necesitarse) a toda una comunidad para mantener un software seguro

Para quienes están fuera del ámbito de la ingeniería de software, la idea de que una comunidad entusiasta de voluntarios mantenga minuciosamente sistemas críticos en su propio tiempo es un concepto difícil de comprender, 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 absurdo que sigan trabajando de forma aislada. 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 encontrará en su jornada laboral. La concienciación sobre la seguridad y las habilidades prácticas deben ser innegociables en el proceso de desarrollo de software, y depende de los líderes de seguridad influir en el cambio a nivel empresarial.
‍

‍Construya hoy mismo una cultura de seguridad próspera en su organización con los cursos detallados de Secure Code Warrior.