El envenenamiento por artefactos en acciones de GitHub importa malware a través de canalizaciones de software package


Un atacante que envíe cambios a un repositorio de código abierto en GitHub podría hacer que los proyectos de computer software posteriores que incluyen la última versión de un componente compilen actualizaciones con código malicioso.

Eso es según la firma de seguridad de la cadena de suministro de software program Legit Security, que dijo en un aviso publicado el 1 de diciembre que esta debilidad de «envenenamiento de artefactos» podría afectar los proyectos de software package que usan GitHub Steps, un servicio para automatizar las canalizaciones de desarrollo, al activar el proceso de compilación cuando se detecta un cambio en una dependencia de software.

La vulnerabilidad no es teórica: Legit Protection simuló un ataque al proyecto que administra Rust, lo que provocó que el proyecto se recompilara utilizando una versión personalizada y maliciosa de la popular biblioteca de computer software GCC, afirmó la compañía en el aviso.

Es possible que el problema afecte a una gran cantidad de proyectos de código abierto porque los mantenedores generalmente ejecutan pruebas en el código aportado antes de analizar el código ellos mismos, dice Liav Caspi, director de tecnología de Legit Security.

«Es un patrón común hoy en día», dice. «Muchos proyectos de código abierto hoy en día, ante una solicitud de cambio, ejecutan un montón de pruebas para validar la solicitud porque el mantenedor no quiere tener que revisar el código primero. En su lugar, ejecuta pruebas automáticamente».

El ataque aprovecha el proceso de compilación automatizado a través de GitHub Steps. En el caso del lenguaje de programación Rust, el patrón susceptible podría haber permitido que un atacante ejecutara código de manera privilegiada como parte de la tubería de desarrollo, robando secretos del repositorio y potencialmente manipulando el código, dijo Legit Security.

«En pocas palabras: en un flujo de trabajo vulnerable, cualquier usuario de GitHub puede crear una bifurcación que construya un artefacto», dijo la empresa. indicó en su aviso. «Luego, inyecte este artefacto en el proceso de creación del repositorio first y modifique su salida. Esta es otra forma de ataque de la cadena de suministro de software program, donde un atacante modifica la salida de la construcción».

La vulnerabilidad permite un ataque similar al ataque de inserción de malware que se dirigió a CodeCov y, a través del computer software de esa empresa, a sus clientes intermedios.

«[T]La falta de una implementación nativa de GitHub para la comunicación de artefactos entre flujos de trabajo llevó a muchos proyectos y a la comunidad de GitHub Steps a desarrollar soluciones inseguras para la comunicación entre flujos de trabajo e hizo que esta amenaza fuera muy frecuente», afirmó Legit Security en el aviso.

GitHub confirmó el problema y pagó una recompensa por la información, mientras que Rust arregló su tubería vulnerable, declaró Legit Safety.

Envenenamiento de artefactos de GitHub
Fuente: Seguridad legítima

La cadena de suministro de program necesita seguridad

La vulnerabilidad es el último problema de seguridad que afecta las cadenas de suministro de software program. Las agencias gubernamentales y de la industria han buscado cada vez más reforzar la seguridad del application de código abierto y el application proporcionado como servicio.

En mayo de 2021, por ejemplo, la administración de Biden emitió su orden ejecutiva sobre la mejora de la seguridad cibernética de la nación, una regla federal que, entre otros requisitos, exige que el gobierno exija estándares de seguridad básicos para cualquier software package que compre. Por el lado de la industria privada, Google y Microsoft han prometido miles de millones de dólares para reforzar la seguridad en el ecosistema de código abierto, que proporciona el código que comprende más de las tres cuartas partes del código foundation de la aplicación promedio.

Lógico, pero vulnerable

El problema de seguridad pertenece a una clase de problemas difíciles de encontrar conocidos como problemas lógicos, que incluyen problemas con permisos, la posibilidad de que los repositorios bifurcados se inserten en una canalización y la falta de diferenciación entre repositorios bifurcados y base.

Debido a que los proyectos de software a menudo usan scripts automatizados para verificar los envíos de código antes de reenviarlos a los mantenedores, las solicitudes de extracción se ejecutarán a través de la automatización antes de que cualquier persona las verifique en busca de código malicioso. Si bien la automatización ahorra tiempo, también debe considerarse una forma de que los atacantes inserten código malicioso en la canalización.

“Cuando estás haciendo desarrollo de código abierto, el problema es mayor, porque estás aceptando contribuciones de cualquier persona en el mundo”, dice Caspi. «Estás ejecutando cosas en las que no puedes confiar».

GitHub reconoció el problema y amplió las formas de excluir los envíos de colaboradores externos para que no se inserten automáticamente en la canalización de Acciones. La empresa actualizó sus API GetArtifact y ListArtifacts con el objetivo de proporcionar más información para ayudar a determinar si se puede confiar en un artefacto.

«Cualquiera que haga algo como lo hizo el proyecto Rust, confiando en la información de un tercero, sigue siendo vulnerable», dice Caspi. «Es un problema de lógica. GitHub acaba de facilitar la escritura de un script más seguro».



Enlace a la noticia unique