1 puntos por GN⁺ 2025-04-01 | 1 comentarios | Compartir por WhatsApp
  • Debido a una clave secreta (Secret) de GitHub expuesta, CodeQL, la herramienta de análisis estático de GitHub, quedó expuesta a un ataque a la cadena de suministro
  • La clave en cuestión fue válida durante 1.022 segundos, y dentro de ese lapso un atacante podía ejecutar código arbitrario en un workflow de GitHub Actions
  • Esta vulnerabilidad quedó registrada como un CVE público: CVE-2025-24362

Principales escenarios de impacto

A través de esta vulnerabilidad, un atacante podía ejecutar los siguientes ataques:

  • Filtración del código fuente de repositorios que usan CodeQL (afectación a la propiedad intelectual)
  • Robo de secretos de GitHub Actions y posibilidad de ataques posteriores
  • Ejecución de código en infraestructura interna a través de workflows de CodeQL
  • Posibilidad de robar incluso secretos de workflows que usan GitHub Actions Cache

Detección del ataque y proceso experimental

  • El equipo de investigación de Praetorian desarrolló una herramienta para escanear secretos incluidos en artifacts de workflows generados por GitHub Actions
  • En un repositorio relacionado con CodeQL se encontró un debug artifact que contenía un secreto
  • Se creó y ejecutó una herramienta PoC artifact_racer.py para demostrar que, mientras la clave fuera válida, un atacante podía crear branches/tags y hacer push de archivos

Resultados clave del experimento

  • Con ese token, un atacante podía:
    • crear una nueva branch
    • hacer push de archivos
    • agregar tags
  • CodeQL hace referencia por defecto al tag v3, y un atacante podía sobrescribir ese tag → era posible distribuir código malicioso a todos los usuarios de CodeQL

Potencial de propagación: ¿por qué es peligroso?

  • La mayoría de los usuarios no configuran CodeQL manualmente, sino que hacen clic en el botón "Enable CodeQL" en la configuración del repositorio de GitHub
  • El workflow configurado automáticamente en ese momento hace referencia al repositorio github/codeql-action y se basa en el tag v3
  • Si un atacante sobrescribe el tag v3 con un commit malicioso, se ejecutaría automáticamente código malicioso en una gran cantidad de proyectos

Posibilidad adicional de ataque: envenenamiento de caché (Cache Poisoning)

  • El workflow predeterminado de CodeQL usa GitHub Actions Cache
  • A través de esto, un atacante puede inyectar una caché maliciosa en el pipeline de build y luego robar secretos y obtener acceso interno en workflows posteriores
  • Objetivos representativos afectados:

Respuesta y parche de GitHub

  • Tras el reporte de la vulnerabilidad el 22 de enero de 2025, GitHub en menos de 3 horas:
    • detuvo el workflow vulnerable
    • registró un PR para evitar la carga de secretos
    • distribuyó la versión parcheada: CodeQL Action v3.28.3
  • Aviso oficial de seguridad: GHSA-vqf5-2xx6-9wfm

Medidas de respuesta

  • Al subir artifacts desde un workflow, limitar los archivos que se cargan
  • Tener cuidado de no incluir variables de entorno ni archivos dentro de .git/config o del directorio _temp/
  • Otorgar al GITHUB_TOKEN solo permisos de lectura
  • Se recomienda realizar un escaneo de secretos antes de subir artifacts (usando herramientas como Nosey Parker)

Conclusión

  • Incluso con la configuración predeterminada de CodeQL, una gran cantidad de proyectos puede quedar expuesta a ataques a la cadena de suministro
  • Las vulnerabilidades de seguridad en GitHub Actions siguen siendo una amenaza grave, y se requiere atención continua de la comunidad junto con estrategias de defensa

Información relacionada

1 comentarios

 
GN⁺ 2025-04-01
Opiniones de Hacker News
  • Hay quien opina que, cuando GitHub lance acciones inmutables, se podrá resolver más del 70% de los ataques
    • Cree que los problemas semanales de GitHub harán que eso se lance
  • No se menciona por qué el token temporal tenía permisos para crear un nuevo despliegue y generar una certificación de artefacto
    • Desactivaron los logs de depuración para resolver el problema, pero no hay respuesta sobre si cambiaron los permisos del token temporal para que se ajusten mejor al motor de análisis de código
  • Cada vez hay más convencimiento de que CI y CD deberían ser entornos completamente separados
    • Un compromiso en CI no debería provocar la filtración de tokens relacionados con CD
  • El tiempo de respuesta de GitHub es muy impresionante
  • Como alguien cuyo apellido es Prater, hay quien dice que le gustaría ser dueño de praetorian.com
  • Usar acciones públicas de GitHub puede causar problemas, y usarlas sin analizar el procedimiento del workflow es aún más riesgoso
    • En su lugar, recomienda usar woodpecker u otro buen constructor de CI (circle, travis, gitlab, etc.) y hacer self-hosting
  • Mencionan que usan CodeQL en el PR de OpenZFS y que OpenZFS no tiene problemas
    • El código de OpenZFS no es secreto
  • Hay quien se pregunta si el problema ya fue resuelto
  • Hay una queja de que el rendimiento del sitio es tan malo que casi no se puede hacer scroll