La puerta trasera de XZ Utils en Linux pone de manifiesto un problema más amplio de seguridad en la cadena de suministro, y necesitamos algo más que espíritu comunitario para controlarlo.
El sector de la ciberseguridad se ha vuelto a poner en estado de alerta tras el descubrimiento de una insidiosa vulnerabilidad 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 ha registrado con el número CVE-2024-3094 y consiste en una puerta trasera insertada deliberadamente por un mantenedor voluntario del sistema que antes era fiable. Al permitir la ejecución remota de código (RCE) en algunos casos si se explota con éxito, representa un problema muy grave que puede causar graves daños en los procesos establecidos de creación de software.
Afortunadamente, otro responsable descubrió esta amenaza antes de que el código malicioso entrara en las versiones estables de Linux, pero sigue siendo un problema para aquellos que han comenzado a utilizar las versiones 5.6.0 y 5.6.1 de XZ Utils en el marco de Fedora Rawhide, y se ha pedido a las organizaciones que apliquen parches con carácter de urgencia. Si este descubrimiento no se hubiera hecho a tiempo, el perfil de riesgo lo convertiría en uno de los ataques más devastadores jamás registrados en la cadena de suministro, eclipsando quizás incluso a SolarWinds.
La dependencia de los voluntarios de la comunidad para el mantenimiento de sistemas críticos está ampliamente documentada, pero rara vez se aborda antes de que surjan problemas de gran impacto como este incidente. Aunque su incansable trabajo es esencial para el mantenimiento del software libre, esto pone de relieve la necesidad de hacer hincapié en las competencias en materia de seguridad y sensibilización a nivel de los desarrolladores, sin olvidar reforzar los controles de acceso a los repositorios de software.
¿Qué es la puerta trasera 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 4.0 y Fedora Rawhide de que las últimas versiones de las herramientas de compresión y las bibliotecas «XZ» contienen código malicioso que parece haber sido diseñado específicamente para facilitar el acceso no autorizado a terceros. La forma en que se inyectó este código malicioso probablemente será objeto de estudios en profundidad en el futuro, pero se trata de un ejercicio de ingeniería social sofisticado, paciente y prolongado por parte del autor de la amenaza, un atacante pseudónimo llamado Jia Tan. Esta persona dedicó innumerables horas a ganarse la confianza de otros responsables, a realizar contribuciones legítimas al proyecto y a la comunidad XZ Utils durante más de dos años, para finalmente obtener el estatus de «mantenedor de confianza» después de que varias cuentas falsas erosionaran la confianza en el propietario voluntario del proyecto, Lasse Collin:
Este escenario inusual es un excelente ejemplo de cómo una persona con un alto nivel técnico sigue siendo víctima de tácticas que suelen reservarse para personas menos informadas, lo que demuestra la necesidad de una formación de sensibilización sobre seguridad precisa y basada en las funciones. Solo gracias a la curiosidad y la rapidez mental del ingeniero de software de Microsoft y responsable de PostgreSQL, Andrés Freund, se descubrió la puerta trasera y se cancelaron las versiones, poniendo fin a lo que podría haber sido el ataque a la cadena de suministro más devastador de la historia reciente.
La puerta trasera en sí misma se considera oficialmente como una vulnerabilidad de la mayor gravedad posible en el Registro del NIST. Inicialmente considerada como una forma de eludir la autenticación SSH, una investigación más profunda reveló que permitía la ejecución remota de código no autenticado 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 un gran esfuerzo para ocultar el paquete malicioso que, cuando se activa para construirse durante el proceso de generación, obstaculiza la autenticación en SSHD a través de systemd. Como detalla Chapeau rouge, si se dan 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 autres, a des directives complètes publiées sur l'analyse des systèmes à la recherche d'instances de l'exploit et sur l'atténuation de ses effets, et sur les mesures immédiates recommandées par CISA est que les développeurs et utilisateurs concernés doivent rétrograder XZ Utils vers une version non compromise, comme XZ Utils 5.4.6 Stable.
Es extremadamente difícil prevenir este tipo de ataques, especialmente cuando se utilizan componentes de código abierto en el software, ya que la seguridad de la cadena de suministro es muy limitada y poco transparente. Ya hemos combatido fallos accidentales en la cadena de suministro de software, pero este riesgo ha aumentado y ahora incluye errores de seguridad implantados deliberadamente con el fin de comprometer la seguridad del software libre.
La mayoría de los desarrolladores no podrán detener un ataque de esta naturaleza si no tienen un agudo sentido de la seguridad, sólidos conocimientos en materia de seguridad y una pizca de paranoia. Se trata casi de exigir una mentalidad de actor de la amenaza. Sin embargo, una consideración principal debe centrarse siempre en los repositorios de código fuente que se controlan internamente (es decir, que no son de código abierto). Solo deberían ser accesibles para personas con competencias de seguridad pertinentes y verificadas. Los profesionales de AppSec pueden considerar una configuración como los controles de seguridad a nivel de rama, que solo permiten a los desarrolladores con experiencia en seguridad realizar cambios en la rama principal final.
Los mantenedores voluntarios son héroes, pero se necesita (o se debería necesitar) todo un pueblo para mantener un software seguro.
Para quienes no trabajan en el ámbito de la ingeniería de software, resulta difícil comprender que una comunidad dinámica de voluntarios mantenga minuciosamente sistemas críticos a su propio ritmo, pero esa es la naturaleza del desarrollo de código abierto, que sigue representando un riesgo crítico para los profesionales de la seguridad que protegen la cadena de suministro.
El software libre es un elemento esencial del ecosistema digital de prácticamente todas las empresas, y los responsables de confianza (la mayoría de los cuales actúan de buena fe) demuestran un verdadero heroísmo en su búsqueda desinteresada del progreso tecnológico y la integridad, pero es ridículo dejarlos actuar de forma aislada. En estos tiempos centrados en DevSecOps, la seguridad es una responsabilidad compartida, y cada desarrollador debe disponer de los conocimientos y las herramientas adecuadas para gestionar los problemas de seguridad con los que pueda encontrarse durante su jornada laboral. La sensibilización sobre la seguridad y las competencias prácticas no deberían ser negociables en el proceso de desarrollo de software, y corresponde a los responsables de la seguridad influir en el cambio a nivel empresarial.
Instaure hoy mismo una cultura de seguridad próspera en su organización gracias a Cursos de Secure Code Warrior.
Se ha descubierto una vulnerabilidad crítica, CVE-2024-3094, en la biblioteca de compresión de datos XZ Utils utilizada por las principales distribuciones de Linux, introducida por una puerta trasera por un actor malicioso. Este problema muy grave puede provocar la ejecución remota de código, lo que supone un riesgo importante para los procesos de creación de software. La vulnerabilidad afecta a las primeras versiones (5.6.0 y 5.6.1) de XZ Utils en Fedora Rawhide, por lo que se insta urgentemente a las organizaciones a que implementen parches. El incidente pone de relieve el papel esencial de los voluntarios de la comunidad en el mantenimiento del software de código abierto y subraya la necesidad de reforzar las prácticas de seguridad y el control de acceso a lo largo de todo el ciclo de desarrollo del software.
Director General, Presidente y Cofundador
Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.
Reserve una demostración
Director General, Presidente y Cofundador
Pieter Danhieux es un experto en seguridad mundialmente reconocido, con más de 12 años de experiencia como consultor de seguridad y 8 años como instructor principal de SANS enseñando técnicas ofensivas sobre cómo atacar y evaluar organizaciones, sistemas y personas en busca de debilidades de seguridad. En 2016, fue reconocido como una de las personas más cool de la tecnología en Australia (Business Insider), galardonado como Profesional de Seguridad Cibernética del Año (AISA - Asociación Australiana de Seguridad de la Información) y tiene certificaciones GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
El sector de la ciberseguridad se ha vuelto a poner en estado de alerta tras el descubrimiento de una insidiosa vulnerabilidad 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 ha registrado con el número CVE-2024-3094 y consiste en una puerta trasera insertada deliberadamente por un mantenedor voluntario del sistema que antes era fiable. Al permitir la ejecución remota de código (RCE) en algunos casos si se explota con éxito, representa un problema muy grave que puede causar graves daños en los procesos establecidos de creación de software.
Afortunadamente, otro responsable descubrió esta amenaza antes de que el código malicioso entrara en las versiones estables de Linux, pero sigue siendo un problema para aquellos que han comenzado a utilizar las versiones 5.6.0 y 5.6.1 de XZ Utils en el marco de Fedora Rawhide, y se ha pedido a las organizaciones que apliquen parches con carácter de urgencia. Si este descubrimiento no se hubiera hecho a tiempo, el perfil de riesgo lo convertiría en uno de los ataques más devastadores jamás registrados en la cadena de suministro, eclipsando quizás incluso a SolarWinds.
La dependencia de los voluntarios de la comunidad para el mantenimiento de sistemas críticos está ampliamente documentada, pero rara vez se aborda antes de que surjan problemas de gran impacto como este incidente. Aunque su incansable trabajo es esencial para el mantenimiento del software libre, esto pone de relieve la necesidad de hacer hincapié en las competencias en materia de seguridad y sensibilización a nivel de los desarrolladores, sin olvidar reforzar los controles de acceso a los repositorios de software.
¿Qué es la puerta trasera 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 4.0 y Fedora Rawhide de que las últimas versiones de las herramientas de compresión y las bibliotecas «XZ» contienen código malicioso que parece haber sido diseñado específicamente para facilitar el acceso no autorizado a terceros. La forma en que se inyectó este código malicioso probablemente será objeto de estudios en profundidad en el futuro, pero se trata de un ejercicio de ingeniería social sofisticado, paciente y prolongado por parte del autor de la amenaza, un atacante pseudónimo llamado Jia Tan. Esta persona dedicó innumerables horas a ganarse la confianza de otros responsables, a realizar contribuciones legítimas al proyecto y a la comunidad XZ Utils durante más de dos años, para finalmente obtener el estatus de «mantenedor de confianza» después de que varias cuentas falsas erosionaran la confianza en el propietario voluntario del proyecto, Lasse Collin:
Este escenario inusual es un excelente ejemplo de cómo una persona con un alto nivel técnico sigue siendo víctima de tácticas que suelen reservarse para personas menos informadas, lo que demuestra la necesidad de una formación de sensibilización sobre seguridad precisa y basada en las funciones. Solo gracias a la curiosidad y la rapidez mental del ingeniero de software de Microsoft y responsable de PostgreSQL, Andrés Freund, se descubrió la puerta trasera y se cancelaron las versiones, poniendo fin a lo que podría haber sido el ataque a la cadena de suministro más devastador de la historia reciente.
La puerta trasera en sí misma se considera oficialmente como una vulnerabilidad de la mayor gravedad posible en el Registro del NIST. Inicialmente considerada como una forma de eludir la autenticación SSH, una investigación más profunda reveló que permitía la ejecución remota de código no autenticado 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 un gran esfuerzo para ocultar el paquete malicioso que, cuando se activa para construirse durante el proceso de generación, obstaculiza la autenticación en SSHD a través de systemd. Como detalla Chapeau rouge, si se dan 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 autres, a des directives complètes publiées sur l'analyse des systèmes à la recherche d'instances de l'exploit et sur l'atténuation de ses effets, et sur les mesures immédiates recommandées par CISA est que les développeurs et utilisateurs concernés doivent rétrograder XZ Utils vers une version non compromise, comme XZ Utils 5.4.6 Stable.
Es extremadamente difícil prevenir este tipo de ataques, especialmente cuando se utilizan componentes de código abierto en el software, ya que la seguridad de la cadena de suministro es muy limitada y poco transparente. Ya hemos combatido fallos accidentales en la cadena de suministro de software, pero este riesgo ha aumentado y ahora incluye errores de seguridad implantados deliberadamente con el fin de comprometer la seguridad del software libre.
La mayoría de los desarrolladores no podrán detener un ataque de esta naturaleza si no tienen un agudo sentido de la seguridad, sólidos conocimientos en materia de seguridad y una pizca de paranoia. Se trata casi de exigir una mentalidad de actor de la amenaza. Sin embargo, una consideración principal debe centrarse siempre en los repositorios de código fuente que se controlan internamente (es decir, que no son de código abierto). Solo deberían ser accesibles para personas con competencias de seguridad pertinentes y verificadas. Los profesionales de AppSec pueden considerar una configuración como los controles de seguridad a nivel de rama, que solo permiten a los desarrolladores con experiencia en seguridad realizar cambios en la rama principal final.
Los mantenedores voluntarios son héroes, pero se necesita (o se debería necesitar) todo un pueblo para mantener un software seguro.
Para quienes no trabajan en el ámbito de la ingeniería de software, resulta difícil comprender que una comunidad dinámica de voluntarios mantenga minuciosamente sistemas críticos a su propio ritmo, pero esa es la naturaleza del desarrollo de código abierto, que sigue representando un riesgo crítico para los profesionales de la seguridad que protegen la cadena de suministro.
El software libre es un elemento esencial del ecosistema digital de prácticamente todas las empresas, y los responsables de confianza (la mayoría de los cuales actúan de buena fe) demuestran un verdadero heroísmo en su búsqueda desinteresada del progreso tecnológico y la integridad, pero es ridículo dejarlos actuar de forma aislada. En estos tiempos centrados en DevSecOps, la seguridad es una responsabilidad compartida, y cada desarrollador debe disponer de los conocimientos y las herramientas adecuadas para gestionar los problemas de seguridad con los que pueda encontrarse durante su jornada laboral. La sensibilización sobre la seguridad y las competencias prácticas no deberían ser negociables en el proceso de desarrollo de software, y corresponde a los responsables de la seguridad influir en el cambio a nivel empresarial.
Instaure hoy mismo una cultura de seguridad próspera en su organización gracias a Cursos de Secure Code Warrior.
El sector de la ciberseguridad se ha vuelto a poner en estado de alerta tras el descubrimiento de una insidiosa vulnerabilidad 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 ha registrado con el número CVE-2024-3094 y consiste en una puerta trasera insertada deliberadamente por un mantenedor voluntario del sistema que antes era fiable. Al permitir la ejecución remota de código (RCE) en algunos casos si se explota con éxito, representa un problema muy grave que puede causar graves daños en los procesos establecidos de creación de software.
Afortunadamente, otro responsable descubrió esta amenaza antes de que el código malicioso entrara en las versiones estables de Linux, pero sigue siendo un problema para aquellos que han comenzado a utilizar las versiones 5.6.0 y 5.6.1 de XZ Utils en el marco de Fedora Rawhide, y se ha pedido a las organizaciones que apliquen parches con carácter de urgencia. Si este descubrimiento no se hubiera hecho a tiempo, el perfil de riesgo lo convertiría en uno de los ataques más devastadores jamás registrados en la cadena de suministro, eclipsando quizás incluso a SolarWinds.
La dependencia de los voluntarios de la comunidad para el mantenimiento de sistemas críticos está ampliamente documentada, pero rara vez se aborda antes de que surjan problemas de gran impacto como este incidente. Aunque su incansable trabajo es esencial para el mantenimiento del software libre, esto pone de relieve la necesidad de hacer hincapié en las competencias en materia de seguridad y sensibilización a nivel de los desarrolladores, sin olvidar reforzar los controles de acceso a los repositorios de software.
¿Qué es la puerta trasera 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 4.0 y Fedora Rawhide de que las últimas versiones de las herramientas de compresión y las bibliotecas «XZ» contienen código malicioso que parece haber sido diseñado específicamente para facilitar el acceso no autorizado a terceros. La forma en que se inyectó este código malicioso probablemente será objeto de estudios en profundidad en el futuro, pero se trata de un ejercicio de ingeniería social sofisticado, paciente y prolongado por parte del autor de la amenaza, un atacante pseudónimo llamado Jia Tan. Esta persona dedicó innumerables horas a ganarse la confianza de otros responsables, a realizar contribuciones legítimas al proyecto y a la comunidad XZ Utils durante más de dos años, para finalmente obtener el estatus de «mantenedor de confianza» después de que varias cuentas falsas erosionaran la confianza en el propietario voluntario del proyecto, Lasse Collin:
Este escenario inusual es un excelente ejemplo de cómo una persona con un alto nivel técnico sigue siendo víctima de tácticas que suelen reservarse para personas menos informadas, lo que demuestra la necesidad de una formación de sensibilización sobre seguridad precisa y basada en las funciones. Solo gracias a la curiosidad y la rapidez mental del ingeniero de software de Microsoft y responsable de PostgreSQL, Andrés Freund, se descubrió la puerta trasera y se cancelaron las versiones, poniendo fin a lo que podría haber sido el ataque a la cadena de suministro más devastador de la historia reciente.
La puerta trasera en sí misma se considera oficialmente como una vulnerabilidad de la mayor gravedad posible en el Registro del NIST. Inicialmente considerada como una forma de eludir la autenticación SSH, una investigación más profunda reveló que permitía la ejecución remota de código no autenticado 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 un gran esfuerzo para ocultar el paquete malicioso que, cuando se activa para construirse durante el proceso de generación, obstaculiza la autenticación en SSHD a través de systemd. Como detalla Chapeau rouge, si se dan 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 autres, a des directives complètes publiées sur l'analyse des systèmes à la recherche d'instances de l'exploit et sur l'atténuation de ses effets, et sur les mesures immédiates recommandées par CISA est que les développeurs et utilisateurs concernés doivent rétrograder XZ Utils vers une version non compromise, comme XZ Utils 5.4.6 Stable.
Es extremadamente difícil prevenir este tipo de ataques, especialmente cuando se utilizan componentes de código abierto en el software, ya que la seguridad de la cadena de suministro es muy limitada y poco transparente. Ya hemos combatido fallos accidentales en la cadena de suministro de software, pero este riesgo ha aumentado y ahora incluye errores de seguridad implantados deliberadamente con el fin de comprometer la seguridad del software libre.
La mayoría de los desarrolladores no podrán detener un ataque de esta naturaleza si no tienen un agudo sentido de la seguridad, sólidos conocimientos en materia de seguridad y una pizca de paranoia. Se trata casi de exigir una mentalidad de actor de la amenaza. Sin embargo, una consideración principal debe centrarse siempre en los repositorios de código fuente que se controlan internamente (es decir, que no son de código abierto). Solo deberían ser accesibles para personas con competencias de seguridad pertinentes y verificadas. Los profesionales de AppSec pueden considerar una configuración como los controles de seguridad a nivel de rama, que solo permiten a los desarrolladores con experiencia en seguridad realizar cambios en la rama principal final.
Los mantenedores voluntarios son héroes, pero se necesita (o se debería necesitar) todo un pueblo para mantener un software seguro.
Para quienes no trabajan en el ámbito de la ingeniería de software, resulta difícil comprender que una comunidad dinámica de voluntarios mantenga minuciosamente sistemas críticos a su propio ritmo, pero esa es la naturaleza del desarrollo de código abierto, que sigue representando un riesgo crítico para los profesionales de la seguridad que protegen la cadena de suministro.
El software libre es un elemento esencial del ecosistema digital de prácticamente todas las empresas, y los responsables de confianza (la mayoría de los cuales actúan de buena fe) demuestran un verdadero heroísmo en su búsqueda desinteresada del progreso tecnológico y la integridad, pero es ridículo dejarlos actuar de forma aislada. En estos tiempos centrados en DevSecOps, la seguridad es una responsabilidad compartida, y cada desarrollador debe disponer de los conocimientos y las herramientas adecuadas para gestionar los problemas de seguridad con los que pueda encontrarse durante su jornada laboral. La sensibilización sobre la seguridad y las competencias prácticas no deberían ser negociables en el proceso de desarrollo de software, y corresponde a los responsables de la seguridad influir en el cambio a nivel empresarial.
Instaure hoy mismo una cultura de seguridad próspera en su organización gracias a Cursos de Secure Code Warrior.
Haga clic en el enlace siguiente y descargue el PDF de este recurso.
Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.
Mostrar el informeReserve una demostración
Director General, Presidente y Cofundador
Pieter Danhieux es un experto en seguridad mundialmente reconocido, con más de 12 años de experiencia como consultor de seguridad y 8 años como instructor principal de SANS enseñando técnicas ofensivas sobre cómo atacar y evaluar organizaciones, sistemas y personas en busca de debilidades de seguridad. En 2016, fue reconocido como una de las personas más cool de la tecnología en Australia (Business Insider), galardonado como Profesional de Seguridad Cibernética del Año (AISA - Asociación Australiana de Seguridad de la Información) y tiene certificaciones GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
El sector de la ciberseguridad se ha vuelto a poner en estado de alerta tras el descubrimiento de una insidiosa vulnerabilidad 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 ha registrado con el número CVE-2024-3094 y consiste en una puerta trasera insertada deliberadamente por un mantenedor voluntario del sistema que antes era fiable. Al permitir la ejecución remota de código (RCE) en algunos casos si se explota con éxito, representa un problema muy grave que puede causar graves daños en los procesos establecidos de creación de software.
Afortunadamente, otro responsable descubrió esta amenaza antes de que el código malicioso entrara en las versiones estables de Linux, pero sigue siendo un problema para aquellos que han comenzado a utilizar las versiones 5.6.0 y 5.6.1 de XZ Utils en el marco de Fedora Rawhide, y se ha pedido a las organizaciones que apliquen parches con carácter de urgencia. Si este descubrimiento no se hubiera hecho a tiempo, el perfil de riesgo lo convertiría en uno de los ataques más devastadores jamás registrados en la cadena de suministro, eclipsando quizás incluso a SolarWinds.
La dependencia de los voluntarios de la comunidad para el mantenimiento de sistemas críticos está ampliamente documentada, pero rara vez se aborda antes de que surjan problemas de gran impacto como este incidente. Aunque su incansable trabajo es esencial para el mantenimiento del software libre, esto pone de relieve la necesidad de hacer hincapié en las competencias en materia de seguridad y sensibilización a nivel de los desarrolladores, sin olvidar reforzar los controles de acceso a los repositorios de software.
¿Qué es la puerta trasera 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 4.0 y Fedora Rawhide de que las últimas versiones de las herramientas de compresión y las bibliotecas «XZ» contienen código malicioso que parece haber sido diseñado específicamente para facilitar el acceso no autorizado a terceros. La forma en que se inyectó este código malicioso probablemente será objeto de estudios en profundidad en el futuro, pero se trata de un ejercicio de ingeniería social sofisticado, paciente y prolongado por parte del autor de la amenaza, un atacante pseudónimo llamado Jia Tan. Esta persona dedicó innumerables horas a ganarse la confianza de otros responsables, a realizar contribuciones legítimas al proyecto y a la comunidad XZ Utils durante más de dos años, para finalmente obtener el estatus de «mantenedor de confianza» después de que varias cuentas falsas erosionaran la confianza en el propietario voluntario del proyecto, Lasse Collin:
Este escenario inusual es un excelente ejemplo de cómo una persona con un alto nivel técnico sigue siendo víctima de tácticas que suelen reservarse para personas menos informadas, lo que demuestra la necesidad de una formación de sensibilización sobre seguridad precisa y basada en las funciones. Solo gracias a la curiosidad y la rapidez mental del ingeniero de software de Microsoft y responsable de PostgreSQL, Andrés Freund, se descubrió la puerta trasera y se cancelaron las versiones, poniendo fin a lo que podría haber sido el ataque a la cadena de suministro más devastador de la historia reciente.
La puerta trasera en sí misma se considera oficialmente como una vulnerabilidad de la mayor gravedad posible en el Registro del NIST. Inicialmente considerada como una forma de eludir la autenticación SSH, una investigación más profunda reveló que permitía la ejecución remota de código no autenticado 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 un gran esfuerzo para ocultar el paquete malicioso que, cuando se activa para construirse durante el proceso de generación, obstaculiza la autenticación en SSHD a través de systemd. Como detalla Chapeau rouge, si se dan 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 autres, a des directives complètes publiées sur l'analyse des systèmes à la recherche d'instances de l'exploit et sur l'atténuation de ses effets, et sur les mesures immédiates recommandées par CISA est que les développeurs et utilisateurs concernés doivent rétrograder XZ Utils vers une version non compromise, comme XZ Utils 5.4.6 Stable.
Es extremadamente difícil prevenir este tipo de ataques, especialmente cuando se utilizan componentes de código abierto en el software, ya que la seguridad de la cadena de suministro es muy limitada y poco transparente. Ya hemos combatido fallos accidentales en la cadena de suministro de software, pero este riesgo ha aumentado y ahora incluye errores de seguridad implantados deliberadamente con el fin de comprometer la seguridad del software libre.
La mayoría de los desarrolladores no podrán detener un ataque de esta naturaleza si no tienen un agudo sentido de la seguridad, sólidos conocimientos en materia de seguridad y una pizca de paranoia. Se trata casi de exigir una mentalidad de actor de la amenaza. Sin embargo, una consideración principal debe centrarse siempre en los repositorios de código fuente que se controlan internamente (es decir, que no son de código abierto). Solo deberían ser accesibles para personas con competencias de seguridad pertinentes y verificadas. Los profesionales de AppSec pueden considerar una configuración como los controles de seguridad a nivel de rama, que solo permiten a los desarrolladores con experiencia en seguridad realizar cambios en la rama principal final.
Los mantenedores voluntarios son héroes, pero se necesita (o se debería necesitar) todo un pueblo para mantener un software seguro.
Para quienes no trabajan en el ámbito de la ingeniería de software, resulta difícil comprender que una comunidad dinámica de voluntarios mantenga minuciosamente sistemas críticos a su propio ritmo, pero esa es la naturaleza del desarrollo de código abierto, que sigue representando un riesgo crítico para los profesionales de la seguridad que protegen la cadena de suministro.
El software libre es un elemento esencial del ecosistema digital de prácticamente todas las empresas, y los responsables de confianza (la mayoría de los cuales actúan de buena fe) demuestran un verdadero heroísmo en su búsqueda desinteresada del progreso tecnológico y la integridad, pero es ridículo dejarlos actuar de forma aislada. En estos tiempos centrados en DevSecOps, la seguridad es una responsabilidad compartida, y cada desarrollador debe disponer de los conocimientos y las herramientas adecuadas para gestionar los problemas de seguridad con los que pueda encontrarse durante su jornada laboral. La sensibilización sobre la seguridad y las competencias prácticas no deberían ser negociables en el proceso de desarrollo de software, y corresponde a los responsables de la seguridad influir en el cambio a nivel empresarial.
Instaure hoy mismo una cultura de seguridad próspera en su organización gracias a Cursos de Secure Code Warrior.
Índice
Director General, Presidente y Cofundador
Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.
Reserve una demostraciónDescargarRecursos para ayudarle a empezar
Temas y contenidos de formación sobre el código seguro
Nuestro contenido de vanguardia evoluciona constantemente para adaptarse al panorama en constante cambio del desarrollo de software, teniendo en cuenta su función. Temas que abarcan desde la IA hasta la inyección de XQuery, ofrecidos para una variedad de puestos, desde arquitectos hasta ingenieros, pasando por jefes de producto y control de calidad. Descubra una visión general de lo que nuestro catálogo de contenidos tiene para ofrecer por tema y por función.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
%20(1).avif)
.avif)
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
Recursos para ayudarle a empezar
Cybermon está de vuelta: las missions Beat the Boss ya están disponibles bajo demanda.
Cybermon 2025 Beat the Boss ya está disponible todo el año en SCW. Implemente desafíos de seguridad avanzados relacionados con la IA y el LLM para reforzar el desarrollo seguro de la IA a gran escala.
Explicación de la ley sobre ciberresiliencia: lo que significa para el desarrollo de software seguro desde el diseño.
Descubra qué exige la ley europea sobre ciberresiliencia (CRA), a quién se aplica y cómo los equipos de ingenieros pueden prepararse mediante prácticas de seguridad desde el diseño, la prevención de vulnerabilidades y el refuerzo de las capacidades de los desarrolladores.
Facilitador 1: Criterios de éxito definidos y medibles
El facilitador 1 da inicio a nuestra serie de 10 partes titulada «Facilitadores del éxito», mostrando cómo combinar la codificación segura con resultados comerciales, como la reducción de riesgos y la rapidez, para garantizar la madurez a largo plazo de los programas.
