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

La industria 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 viene incluida en las principales distribuciones de Linux, se registra con el código CVE-2024-3094 y se reduce a una puerta trasera insertada deliberadamente por un mantenedor del sistema voluntario que alguna vez confiaba en él. Permitir la ejecución remota de código (RCE) en algunos casos si se aprovecha correctamente, representa un problema muy grave, ya que puede causar graves daños en los procesos de creació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 las organizaciones instado a parchear es 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 la historia, quizás incluso eclipsando a SolarWinds.

La dependencia de los voluntarios de la comunidad para mantener los sistemas críticos está ampliamente documentada, pero rara vez se discute hasta que salen a la luz temas de gran impacto, como este incidente. Si bien su incansable labor es esencial para el mantenimiento del software de código abierto, esto pone de manifiesto la necesidad de que los desarrolladores presten especial atención a las habilidades y la concienciación en materia de seguridad, por no hablar de reforzar los controles de acceso 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 informar a los usuarios de Fedora Linux 40 y Fedora Rawhide de que las últimas versiones de las bibliotecas y herramientas de compresión «XZ» contienen código malicioso que parece estar diseñado específicamente para facilitar el acceso no autorizado de terceros. Es probable que la forma en que se inyectó este código malicioso sea objeto de un intenso estudio en el futuro, pero se trata de un ejercicio de ingeniería social sofisticado, paciente y de varios años por parte del actor de amenazas, un atacante seudónimo llamado «Jia Tan». Esta persona pasó incontables horas ganándose la confianza de otros mantenedores, haciendo contribuciones legítimas al proyecto y a la comunidad de XZ Utils durante más de dos años y, finalmente, obtuvo el estatus de «mantenedor de confianza» después de que varias cuentas de sockpuppet erosionaran la confianza en el propietario voluntario del proyecto, Lasse Collin:

‍

‍

Este escenario inusual es un excelente ejemplo de cómo una persona altamente técnica sigue siendo víctima de tácticas que normalmente se reservan para quienes tienen menos conocimientos, lo que demuestra la necesidad de una formación precisa y basada en funciones para concienciar sobre la seguridad. Fue solo por la curiosidad y rapidez de pensamiento del ingeniero de software de Microsoft y responsable del mantenimiento de PostgreSQL, Andrés Freund, que se descubrió la puerta trasera y se anularon 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í misma está siendo rastreada oficialmente como una vulnerabilidad de la mayor gravedad posible en Registro del NIST. Inicialmente se pensó que permitía eludir la autenticación mediante SSH, pero una investigación posterior reveló que permitía la ejecución remota de código sin autenticar 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 todo lo posible para ocultar el paquete malicioso, que, cuando se activa para que se construya solo durante el proceso de creación, dificulta la autenticación en SSHd a través de systemd. Como Red Hat En detalle, en las circunstancias adecuadas, esta interferencia podría permitir a un atacante romper la autenticación SSHd y obtener acceso remoto no autorizado a todo el sistema.

‍

Microsoft, entre otros, ha guía completa publicada sobre el análisis de los sistemas en busca de casos de explotación y la mitigación de su efecto, y la acción inmediata recomendada por CISA es que los desarrolladores y usuarios afectados deberían cambiar XZ Utils a una versión sin compromisos, 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 pocas garantías y transparencia en lo que respecta a la seguridad de la cadena de suministro. Ya hemos combatido las fallas accidentales en la cadena de suministro de software, pero este riesgo se ha incrementado e incluye errores de seguridad creados deliberadamente con fines malintencionados 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 una fuerte conciencia de seguridad, conocimientos de seguridad sólidos y una pizca de paranoia. Es casi un caso en el que se requiere una mentalidad de actor de amenazas. Sin embargo, una consideración principal siempre debe centrarse en los repositorios de código fuente que somos controlado internamente (es decir, no de código abierto). Solo deberían ser accesibles para personas que tengan habilidades de seguridad relevantes y verificadas. Los profesionales de AppSec podrían plantearse una configuración similar a la de los controles de seguridad a nivel de sucursal, que solo permita a los desarrolladores expertos en seguridad introducir cambios en la última rama maestra.

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

Para quienes están fuera del ámbito de la ingeniería de software, la idea de que una comunidad animada de voluntarios mantenga minuciosamente los sistemas críticos en su tiempo libre 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 responsables de su mantenimiento (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 mantenerlos funcionando de forma aislada. En estos tiempos centrados en DevSecops, la seguridad es una responsabilidad compartida, y todos los desarrolladores deben contar con los conocimientos y las herramientas adecuadas para resolver los problemas de seguridad con los que es probable que se enfrenten en su jornada laboral. El conocimiento de la seguridad y las habilidades prácticas no deberían ser negociables en el proceso de desarrollo de software, y corresponde a los líderes de seguridad influir en el cambio a nivel empresarial.
‍

‍Cree hoy mismo una cultura de seguridad próspera en su organización con información exhaustiva Cursos de Secure Code Warrior.