El pasado 14 de marzo StepSecurity detectó un error de seguridad crítico que provenía de la GitHub Action tj-actions/changed-files, que permitía obtener los secretos de los pipelines y agentes de CI que se ejecutaban en GitHub.

En primer lugar, comenzamos explicando qué es tj-actions/changed-files y por qué ha sido un ataque tan crítico.

tj-actions/changed-files es una GitHub Action (es decir, una tarea para pipelines instaurada dentro del Marketplace de GitHub) creada para obtener todos los ficheros modificados entre dos SHAs de dos commits en un código trackeado a través de Git.

El uso de “actions” en GitHub es muy popular, ya que permiten simplificar ciertos pasos del pipeline usando un componente de terceros, de tal forma que no es necesario que el desarrollador que implemente el pipeline tenga que desarrollar todo el proceso, únicamente se sirve de una acción creada por la comunidad.

Esta GitHub Action es ampliamente usada ya que actualmente se estima que el día 14 de marzo, momento en el que se descubrió el ataque, estaba presente en más de 23.000 repositorios públicos de GitHub.

¿Qué ocurrió realmente?

El día 14 de marzo a las 4 de la tarde, el equipo de monitorización de la compañía de ciberseguridad StepSecurity detectó una alerta acerca de una anomalía en el tráfico de red al monitorizar un agente en GitHub.

Tras una investigación en el agente y en el pipeline que provocaba este tráfico, se observó que la tarea de tj-actions/changed-files estaba realizando comportamientos inesperados. Tras una evaluación del repositorio de código de la “action” se detectó el ataque.

Un ciberdelincuente había podido comprometer la cuenta de un bot que tenía permisos de lectura y escritura en el código del repositorio tj-actions/changed-files, generando así un Personal Access Token (PAT) que le permitiría realizar un cambio en el desarrollo.

A través de ese token, el atacante modificó el código inyectando un payload que se ejecutaría cada vez que se lanzase la acción dentro de un agente Linux.

Ese commit, creado en una rama auxiliar y cuyo identificador era 0e58ed8671d6b60d0890c21b07f8835ace038e67, contenía el payload codificado en Base 64 con el fin de ocultarse, tal y como podemos ver en la imagen anterior, y posteriormente se decodificaba en el propio agente para ser ejecutado.

Si decodificamos el exploit encontramos, simplificadamente, un comando que se descargaba y ejecutaba un script Python que permitía hacer un “dump” de la memoria del agente y que, posteriormente, se procesaba con “grep” con el fin de mostrar las credenciales en los logs de los pipelines de GitHub.

¿Cómo un commit en una rama auxiliar puede afectar a todos los pipelines?

Esta es la clave del ataque, ya que el PAT con los permisos del bot permitían crear y reescribir tags.

El atacante fue capaz de reescribir la mayoría de los tags presentes en el repositorio para que apuntasen al commit malicioso, de tal forma que se usara la versión que se usara, todos los repositorios ejecutarían el mismo código, aquel implementado en el famoso commit 0e58ed8671d6b60d0890c21b07f8835ace038e67.

¿Qué implicaciones ha tenido este ataque?

Las implicaciones del ataque son realmente críticas. Cualquier pipeline que contase con esa GitHub Action entre los días 14 y 15 de marzo ha expuesto las credenciales de los agentes en los logs de GitHub.

La rápida respuesta de GitHub, que eliminó temporalmente el repositorio y la “action” del Marketplace hasta tener un fix viable, ha conseguido que el ataque no haya sido más grave.

Este problema se agudiza para todos aquellos proyectos open-source, donde estos logs son de acceso y dominio público. Además, al poder reescribir los tags, la vulnerabilidad ha afectado a cualquier versión de la “action”.

Es una vulnerabilidad muy importante, ya que la exposición pública de los secretos, añadido a la explotabilidad directa y la extensión de la vulnerabilidad en un alto conjunto de versiones, hace que sea uno de los casos de ataques contra la cadena de suministro del software más relevante de los últimos meses.

¿Cómo sé si estoy afectado y como puedo mitigarlo?

Esta vulnerabilidad afecta a todos aquellos desarrollos que usan repositorios en GitHub y hayan lanzado un pipeline con la GitHub Action tj-actions/changed-files durante el 14 y 15 de marzo.

De haberse producido, es muy probable que hayas sido afectado y que los secretos alojados en el agente hayan sido expuestos.

Para mitigar el fallo de seguridad, es necesario:

• Asegurarse de que la GitHub Action tj-actions/changed-files esté establecida a la última versión, actualmente v46.0.1.
• Rotar todos los secretos comprometidos entre el 14 y 15 de marzo, y revisar las exposiciones de información en los logs (eliminando las ejecuciones en la medida de lo posible).
• Limitar el uso de GitHub Actions a aquellas que sean imprescindibles, mantenidas, seguras y verificadas.

Además, por parte del equipo técnico que mantiene la “action”, ya se han tomado medidas adicionales para reducir el riesgo de la vulnerabilidad:

• GitHub a revocado automáticamente el PAT del bot usado para cometer el ataque.
• Las credenciales de acceso para el bot se han modificado y endurecido.
• La autenticación del bot se ha pasado a tipo “passkey” (más robusto que PATs o autenticación basada en usuario/contraseña).
• Se ha aplicado el principio de mínimo privilegio a los permisos del bot, reduciendo su impacto en caso de un nuevo ataque.

Desde Ciberso proporcionamos soluciones DevSecOps con experiencia en defendernos contra ataques a la cadena de suministro del software y auditorías a la postura de seguridad en entornos Git (como seguridad de pipelines, en repositorios o en entornos cloud).

Nuestra solución HESTIA, en su versión Pro, realiza análisis contra el cumplimiento de los repositorios y seguridad de pipelines y agentes de CI/CD, protegiéndote de ataques contra la cadena de suministro software.