GH Actions - Cache Poisoning
For further details check the original post https://scribesecurity.com/blog/github-cache-poisoning/
Cache Poisoning
La acción de Git action/cache introduce un mecanismo de caché en el proceso de Integración Continua (CI), abarcando dos etapas críticas:
Ejecutar Acción: Esta etapa implica buscar y recuperar datos en caché durante la ejecución de CI. La búsqueda utiliza una clave de caché única, dando lugar a dos resultados:
Cache-hit: Los datos solicitados se encuentran en la caché y se recuperan para su uso inmediato.
Cache-miss: No se encuentran datos coincidentes en la caché, lo que provoca una nueva descarga de los archivos y directorios requeridos, similar a una solicitud por primera vez.
Acción Post Workflow: Esta etapa se dedica a almacenar en caché los datos después del flujo de trabajo de CI. Específicamente, si ocurre un cache-miss durante la acción de ejecución, el estado actual de los directorios especificados se almacena en caché utilizando la clave proporcionada. Este proceso es automático y no requiere invocación explícita.
Medidas de Seguridad: Aislamiento de Caché y Restricciones de Acceso
Para mantener la seguridad y garantizar el aislamiento de la caché, se aplican restricciones de acceso, creando una separación lógica entre diferentes ramas. Por ejemplo, una caché creada para la rama Feature-A (con base en la rama principal) será inaccesible para una solicitud de extracción para la rama Feature-B (también basada en la rama principal).
La acción de caché sigue un orden de búsqueda específico:
Primero busca aciertos de caché dentro de la misma rama que la ejecución del flujo de trabajo.
Si no tiene éxito, extiende la búsqueda a la rama principal y otras ramas ascendentes.
Es importante destacar que el acceso a la caché está limitado a la rama, extendiéndose a través de todos los flujos de trabajo y ejecuciones de una rama específica. Además, GitHub aplica una política de solo lectura para las entradas de caché una vez que se crean, prohibiendo cualquier modificación.
Implicación en el Mundo Real: De un Ataque de Flujo de Trabajo de Baja a Alta Permiso
Un escenario ilustrativo de CI demuestra cómo un atacante podría aprovechar el envenenamiento de caché para escalar privilegios de un flujo de trabajo de bajo permiso a uno de alto permiso:
Se asume que el flujo de trabajo Unit-test, responsable de ejecutar pruebas unitarias y herramientas de cobertura de código, emplea una herramienta comprometida o vulnerable. Este flujo de trabajo utiliza la acción de Git action/cache, haciendo que la caché sea accesible para cualquier flujo de trabajo.
El flujo de trabajo Release, encargado de construir y liberar el artefacto de la aplicación, optimiza sus operaciones almacenando en caché las dependencias de Golang.
En este escenario, el flujo de trabajo de pruebas unitarias introduce una entrada de caché maliciosa al sustituir una biblioteca de registro de Golang legítima (`go
Last updated
