Un reciente ataque a la cadena de suministro ha dejado al descubierto las vulnerabilidades de un software de código abierto utilizado por más de 23.000 organizaciones, incluidas grandes empresas. La amenaza surgió cuando un atacante logró acceder de manera no autorizada a la cuenta de un mantenedor, inyectando código malicioso que roba credenciales.
El paquete afectado, tj-actions/changed-files, es parte de las GitHub Actions, herramientas fundamentales para la integración y entrega continua (CI/CD) en el desarrollo de software. Este ataque subraya la importancia de auditar el código y los paquetes de terceros, ya que la confianza ciega puede resultar en graves consecuencias.
Memoria del servidor comprometida a gran escala
Los desarrolladores se encontraron con que el código fuente de todas las versiones de tj-actions/changed-files había recibido actualizaciones no autorizadas. Estas modificaciones cambiaron las etiquetas que los desarrolladores utilizan para referirse a versiones específicas de código. Las nuevas etiquetas apuntaban a un archivo accesible públicamente, que copió la memoria interna de los servidores en ejecución, buscando credenciales y registrándolas en un archivo de log.
Como resultado, muchos repositorios públicos expusieron sus credenciales más sensibles, accesibles para cualquiera.
HD Moore, experto en seguridad de código abierto y CEO de runZero, destacó que uno de los aspectos más alarmantes de GitHub Actions es su capacidad para modificar el código fuente del repositorio que las utiliza, además de acceder a variables secretas asociadas a los flujos de trabajo. «La práctica más segura es auditar todo el código fuente y fijar un hash de confirmación específico en lugar de una etiqueta, aunque esto puede ser complicado«, comentó Moore.
El ataque revela que muchos usuarios de GitHub no seguían estas mejores prácticas. Aquellos que confiaron en etiquetas en lugar de en hashes de versiones verificadas se vieron afectados por el scraper de memoria. La amenaza es particularmente grave para los repositorios visibles públicamente, donde las credenciales pueden ser vistas por cualquier persona.
Un mantenedor de tj-actions informó que el atacante logró comprometer una credencial que el bot @tj-actions utiliza para acceder a repositorios con privilegios. Aunque la forma en que se comprometió la credencial sigue sin estar clara, el bot ya ha cambiado su contraseña y, para mayor seguridad, se ha implementado una clave de acceso, que requiere autenticación de dos factores por defecto, como estipula la FIDO Alliance.
Desde GitHub aseguraron que no hay evidencia de que la plataforma haya sido comprometida. Sin embargo, actuaron con cautela suspendiendo cuentas de usuario y eliminando contenido conforme a sus políticas de uso.
Posteriormente, restablecieron las cuentas y el contenido tras confirmar que todos los cambios maliciosos habían sido revertidos y la fuente de la vulnerabilidad asegurada. Recordaron a los usuarios la necesidad de revisar cuidadosamente cualquier GitHub Action o paquete en uso antes de actualizar a nuevas versiones.
La empresa de seguridad StepSecurity fue la primera en detectar este ataque, que fue identificado a través de anomalías en el tráfico de red. El incidente comenzó a notarse alrededor de las 9 a.m. del sábado, hora del Pacífico. Investigadores de Wiz también han confirmado que decenas de usuarios de tj-actions han sufrido daños reales debido a este ataque, observando el despliegue de scripts diseñados para robar secretos durante la ejecución de la carga maliciosa. Entre los secretos filtrados se incluyen claves de acceso a AWS, tokens de acceso personal de GitHub, tokens de npm y claves RSA privadas.
Este incidente es solamente el último ejemplo de un ataque a la cadena de suministro que afecta a un paquete de código abierto ampliamente utilizado. Casos anteriores incluyen la detección de un backdoor en xz Utils, un utility de compresión de datos utilizado por millones, y otros ataques recientes que han sido documentados en la comunidad de seguridad. Las empresas y administradores de sistemas que utilizan tj-actions deben inspeccionar cuidadosamente sus sistemas en busca de signos de compromiso y revisar todas las GitHub Actions para asegurarse de utilizar hashes criptográficos en lugar de etiquetas que apuntan a código no verificado.