Inyección de Scripts en GitHub Actions: La Puerta Trasera en CI/CD

Cómo los atacantes explotaron GitHub Actions para comprometer Ultralytics YOLO y lanzar backdoors en PyPI

En diciembre de 2024, la comunidad de código abierto presenció uno de los ataques a la cadena de suministro más sofisticados de la historia reciente. La biblioteca Ultralytics YOLO, un pilar en inteligencia artificial para visión por computadora y detección de objetos, fue víctima de un ataque meticulosamente orquestado que explotó vulnerabilidades en los flujos de trabajo de GitHub Actions. Este incidente nos recuerda que las cadenas de suministro de software modernas solo son tan seguras como su eslabón más débil, y cada vez más, ese eslabón es la pipeline automatizada de CI/CD.

Entendiendo el ecosistema de Ultralytics

Ultralytics YOLO cuenta con más de 30,000 estrellas y más de 6,000 forks en GitHub, con su paquete en PyPI acumulando casi 60 millones de descargas a lo largo de su existencia. La biblioteca impulsa aplicaciones críticas de aprendizaje automático en diversas industrias, desde vehículos autónomos hasta sistemas de imagen médica. Su adopción masiva la convirtió en un objetivo atractivo para actores maliciosos que buscan impacto máximo con una sola vulneración.

La biblioteca funciona como dependencia para numerosos paquetes populares, incluyendo la extensión ComfyUI Impact Pack, creando un efecto cascada donde comprometer Ultralytics podría afectar a miles de aplicaciones downstream. La naturaleza interconectada de las dependencias modernas transforma una sola vulnerabilidad en una crisis de seguridad a nivel de ecosistema.

La línea de tiempo del ataque: un asalto en múltiples fases

Primera fase: compromiso inicial (4-5 de diciembre de 2024)

El ataque comenzó cuando versiones maliciosas 8.3.41 y 8.3.42 fueron publicadas en PyPI los días 4 y 5 de diciembre. La sofisticación de este primer asalto se hizo evidente cuando los desarrolladores descubrieron que el código malicioso solo existía en los paquetes de PyPI, no en el código fuente del repositorio en GitHub. Esta discrepancia apuntaba a una vulneración ocurrida durante el proceso automatizado de construcción y despliegue, en lugar de una inyección tradicional en el código del repositorio.

Al notar comportamientos anómalos, los desarrolladores lanzaron la versión 8.3.42 como remediación. Sin embargo, al no identificar aún el vector de ataque real, esta “solución” contenía la misma carga maliciosa, ampliando la ventana de vulnerabilidad y exponiendo a más usuarios que actualizaron rápidamente.

Segunda fase: robo de credenciales y persistencia (7 de diciembre de 2024)

Tras publicar versiones limpias 8.3.43 y 8.3.44, la carga maliciosa reapareció en versiones 8.3.45 y 8.3.46 el 7 de diciembre. En esta ocasión, el código malicioso solo estaba en los paquetes de PyPI, no en GitHub. El análisis comunitario sugirió que los atacantes habían exfiltrado con éxito tokens API de PyPI durante la primera vulneración, permitiéndoles subir paquetes contaminados sin tocar la infraestructura de GitHub.

La segunda fase mostró un nivel preocupante de persistencia y adaptabilidad. Los atacantes no solo comprometieron la pipeline inicial, sino que también aseguraron credenciales de acceso a largo plazo, permitiéndoles continuar su campaña incluso después de solucionar la vulnerabilidad original.

La vulnerabilidad técnica: inyección de scripts en GitHub Actions

Entendiendo la vulnerabilidad

La intrusión en el entorno de construcción se logró mediante un vector sofisticado: explotando una vulnerabilidad conocida de inyección de scripts en GitHub Actions reportada previamente por el investigador de seguridad Adnan Khan. Esta clase de vulnerabilidad ocurre cuando los flujos de trabajo de GitHub Actions incorporan entradas controladas por el usuario, como nombres de ramas o títulos de pull requests, sin una sanitización adecuada.

La vulnerabilidad permitía a los atacantes inyectar código arbitrario creando nombres de ramas con cargas maliciosas incrustadas. Cuando los flujos de trabajo que usaban la acción vulnerable se ejecutaban en el disparador pull_request_target, estos nombres de ramas especiales se ejecutaban como código en el entorno de construcción, permitiendo robar secretos y modificar artefactos.

El mecanismo del ataque

El 4 de diciembre de 2024, un usuario de GitHub llamado openimbot abrió dos pull requests en borrador sospechosos en el repositorio de acciones de Ultralytics. Estas solicitudes parecían inofensivas a simple vista, pero sus nombres de rama contenían cargas de inyección cuidadosamente diseñadas para descargar y ejecutar un script remoto.

La clave de este ataque fue su explotación del disparador pull_request_target. A diferencia del disparador estándar pull_request, pull_request_target ejecuta el código del flujo de trabajo desde la rama base en lugar del fork, y lo que es más importante, otorga acceso a secretos del repositorio. Este diseño, pensado para facilitar automatizaciones seguras en contribuciones externas, se convirtió en el mecanismo que permitió el ataque.

Adnan Khan reportó esta vulnerabilidad de inyección de scripts en agosto de 2024, y posteriormente fue parcheada. Sin embargo, se introdujo una regresión en el código, y el código vulnerable reapareció apenas diez días después de que Ultralytics publicara su aviso de seguridad, creando una ventana de oportunidad que los atacantes explotaron con eficiencia devastadora.

Tácticas de envenenamiento de caché

Los atacantes emplearon técnicas de envenenamiento de caché para mantener sus modificaciones mediante GitHub Actions, un método documentado por Khan en su investigación de seguridad. Al envenenar la caché de la acción, lograron que sus modificaciones maliciosas persistieran en múltiples ejecuciones del flujo de trabajo, dificultando su detección y remediación.

La carga maliciosa: más allá de la minería de criptomonedas

Objetivo principal: minería de criptomonedas

El atacante modificó dos archivos críticos: downloads.py y model.py. El código inyectado en model.py realizaba detección sofisticada del entorno, verificando la arquitectura del sistema y el sistema operativo para descargar cargas específicas de la plataforma. El archivo downloads.py contenía el código del descargador que recuperaba y ejecutaba los binarios maliciosos.

La carga maliciosa desplegada era un minero de criptomonedas XMRig dirigido a Monero, una criptomoneda centrada en la privacidad que ofrece funciones de anonimato, dificultando rastrear las transacciones. El minero consumía recursos del sistema, aumentando costos de electricidad y degradando el rendimiento.

La amenaza mayor

Aunque la minería de criptomonedas fue la carga desplegada, los investigadores de seguridad señalaron que las implicaciones potenciales eran mucho más siniestras. El vector de ataque permitía a los actores maliciosos tener control total sobre el entorno de construcción, pudiendo inyectar cualquier código arbitrario en paquetes descargados por decenas de miles de usuarios.

Imagina las implicaciones: un atacante con ese nivel de acceso podría desplegar ransomware en entornos empresariales, robar claves API y credenciales de sistemas CI/CD, establecer backdoors persistentes en sistemas de producción, o incluso envenenar modelos de aprendizaje automático con modificaciones adversariales.

Implicaciones más amplias para la seguridad en CI/CD

PyPI vs. GitHub: entendiendo la superficie de ataque

Al principio, muchos asumieron que PyPI era el punto de fallo, ya que el software manipulado se descubrió allí primero. Esta atribución errónea reveló una brecha crítica en cómo los desarrolladores y equipos de seguridad conceptualizan la seguridad en la cadena de suministro. PyPI no fue comprometido; más bien, los paquetes que alojaba fueron envenenados en la upstream durante el proceso automatizado de construcción.

Según el blog oficial de PyPI, no se utilizó ninguna vulnerabilidad en PyPI para ejecutar este ataque. Esta distinción es crucial para entender dónde deben implementarse los controles de seguridad y cómo investigar los ataques en la cadena de suministro.

La paradoja de la publicación confiable

Irónicamente, Ultralytics usaba Trusted Publishing, una función de seguridad diseñada para mejorar la seguridad en la cadena de suministro eliminando tokens API de larga duración en favor de credenciales de corta duración generadas mediante OpenID Connect. Trusted Publishing significa que las credenciales son temporales y no necesitan rotación en caso de compromiso, teniendo un valor limitado en el tiempo si son exfiltradas.

Sin embargo, el ataque demostró que incluso medidas avanzadas como Trusted Publishing pueden ser eludidas si el entorno de construcción está comprometido. Los atacantes no necesitaron robar tokens de larga duración, ya que podían ejecutar código en el entorno de construcción confiable durante la ventana de tiempo en que las credenciales temporales estaban activas.

Riesgo en el ecosistema de GitHub Actions

Este no fue el primer caso en que GitHub Actions sirvió como punto de fallo para un proyecto en Python. En enero de 2024, investigadores demostraron cómo secuestrar flujos de trabajo de GitHub Actions para comprometer la infraestructura de desarrollo del proyecto PyTorch, revelando que miles de proyectos usando GitHub Actions eran vulnerables.

El problema va más allá de configuraciones incorrectas. La escala de vulnerabilidad sugiere que los valores predeterminados inseguros en GitHub Actions son comunes, en lugar de que los desarrolladores descuiden la seguridad. Cuando la seguridad requiere una implementación perfecta en miles de proyectos, el resultado inevitable es vulnerabilidad generalizada.

Lecciones del investigador de seguridad Adnan Khan

Un historial de descubrimientos

El investigador Adnan Khan tiene un historial de investigar y detectar problemas de seguridad relacionados con GitHub Actions. Su trabajo ha sido clave para identificar vulnerabilidades sistemáticas en pipelines de CI/CD, desde fallos de inyección de scripts hasta configuraciones incorrectas en runners autohospedados.

Su metodología de investigación ofrece valiosas perspectivas sobre cómo piensan los atacantes. Analizando sistemáticamente los flujos de trabajo en repositorios populares, identificó patrones de prácticas inseguras explotables a escala. Sus hallazgos demostraron que estos no son incidentes aislados, sino síntomas de desafíos arquitectónicos fundamentales para hacer los sistemas CI/CD tanto flexibles como seguros.

El patrón de ataque “Pwn Request”

La investigación de Khan estableció lo que la comunidad de seguridad llama ahora ataques “Pwn Request”, una clase de vulnerabilidad donde los flujos de trabajo activados por solicitudes externas se ejecutan con permisos elevados, incorporando entradas no confiables. El nombre combina “pwn” (jerga de hackers para compromiso) con “pull request”, resaltando cómo un mecanismo legítimo de colaboración se convierte en vector de ataque.

El problema central radica en flujos de trabajo que usan disparadores como pull_request_target o workflow_run junto con interpolación insegura de valores controlados por el atacante. Cuando nombres de ramas, títulos de PR o comentarios se incrustan directamente en comandos shell o scripts sin la debida cita, los atacantes pueden escapar del contexto literal y ejecutar comandos arbitrarios.

Detección y respuesta: cómo la comunidad contraatacó

Descubrimiento inicial y atribución

Un desarrollador llamado “metrizable” descubrió inicialmente el código comprometido al comparar el paquete de Ultralytics en PyPI con el repositorio en GitHub. Este análisis de discrepancias, comparando código fuente con artefactos distribuidos, fue crucial para identificar que la vulneración ocurrió durante el proceso de construcción, no en el repositorio fuente.

La rápida respuesta comunitaria mostró el valor del desarrollo abierto y transparente. En pocas horas del primer reporte, múltiples investigadores de seguridad, desarrolladores y organizaciones estaban analizando el ataque, compartiendo hallazgos y coordinando respuestas en issues de GitHub, foros de seguridad y redes sociales.

Respuesta organizacional

Google Colab bloqueó el acceso a sistemas con versiones comprometidas de YOLO, mientras que desarrolladores afiliados a Ultralytics instaron a los usuarios a desinstalar la versión 8.3.41. Estas medidas inmediatas ayudaron a contener la propagación del malware, aunque la demora en reconocer la vulnerabilidad de la versión 8.3.42 complicó los esfuerzos de remediación.

ComfyUI actualizó su gestor para advertir a los usuarios que ejecutaban versiones maliciosas, demostrando cómo las dependencias downstream pueden jugar un papel activo en la protección de su base de usuarios incluso cuando la vulnerabilidad upstream ocurrió fuera de su control.

Medidas proactivas en PyPI

Todas las versiones afectadas—8.3.41, 8.3.42, 8.3.45 y 8.3.46—fueron eliminadas de PyPI una vez que se aclaró el alcance completo de la vulneración. La capacidad de eliminar rápidamente paquetes maliciosos representa una salvaguarda crucial en la seguridad de la cadena de suministro, aunque la ventana durante la cual los usuarios pudieron descargar paquetes comprometidos fue un riesgo importante.

Evaluación del impacto: midiendo los daños

Estadísticas de descargas y exposición

Las versiones comprometidas estuvieron disponibles para descarga más de 12 horas antes de ser eliminadas de PyPI. Durante ese tiempo, innumerables sistemas automatizados, pipelines de CI/CD y estaciones de trabajo de desarrolladores pudieron haber descargado e instalado los paquetes maliciosos. La cantidad real de sistemas afectados puede que nunca se conozca completamente debido a la naturaleza automatizada de muchas instalaciones.

Datos de Wiz Research indicaron que Ultralytics podía encontrarse en el 10% de los entornos en la nube, demostrando la valiosa superficie de ataque que esta vulnerabilidad buscaba explotar. Solo esta estadística sugiere decenas de miles de entornos potencialmente afectados en empresas, investigación y sistemas de desarrolladores individuales.

Impacto de la minería de criptomonedas

Los sistemas que desplegaron las versiones comprometidas habrían mostrado un uso elevado y sostenido de CPU, característico de operaciones de minería de criptomonedas. En entornos en la nube, esto se traduce en mayores costos operativos. En sistemas locales, en degradación del rendimiento y mayor consumo eléctrico.

Más preocupante que el impacto financiero inmediato fue el daño reputacional y la pérdida de confianza. Organizaciones que descubrieron que estaban ejecutando software comprometido enfrentaron preguntas difíciles sobre su postura de seguridad, prácticas de gestión de dependencias y capacidades de respuesta a incidentes.

Estrategias de prevención: fortalecer pipelines de CI/CD

Sanitización y validación de entradas

La lección fundamental del ataque a Ultralytics es que toda entrada controlada por el usuario debe tratarse como potencialmente maliciosa. La solución recomendada implica sanitizar las variables controladas usando variables de entorno en lugar de interpolación directa. Esto asegura que los caracteres especiales no puedan escapar y ejecutarse como código.

En lugar de incrustar directamente valores como nombres de ramas en comandos, los desarrolladores deben usar el mecanismo de variables de entorno incorporado en GitHub Actions. Esto crea un límite claro entre datos y código, previniendo ataques de inyección sin importar qué caracteres aparezcan en la entrada controlada.

Restricciones en disparadores de workflows

Las organizaciones deben evaluar cuidadosamente qué disparadores habilitan y en qué circunstancias. El disparador pull_request_target, aunque poderoso para automatizar contribuciones externas, debe usarse con extrema precaución y solo cuando sea estrictamente necesario. Cuando sea inevitable, los workflows que lo usen deben implementar validación estricta de entradas y evitar acceder a secretos o realizar operaciones privilegiadas.

Una estrategia de defensa en profundidad implica dividir los workflows en trabajos separados: uno que realiza operaciones potencialmente inseguras con permisos mínimos, y otro que consume salidas y realiza operaciones privilegiadas solo tras validación. Esta segregación limita el alcance del daño si un componente se ve comprometido.

Pinning y verificación de dependencias

Las organizaciones deben bloquear o fijar dependencias a versiones explícitas con sumas de verificación como SHA256 o commits de git, especialmente en procesos de construcción y lanzamiento. Esto previene que actualizaciones automáticas introduzcan versiones comprometidas, aunque requiere monitoreo constante de actualizaciones de seguridad.

La tensión entre seguridad y conveniencia es evidente aquí. Las actualizaciones automáticas mantienen el software actualizado y parcheado, pero también abren ventanas para ataques en la cadena de suministro. Las organizaciones deben equilibrar automatización y control según su tolerancia al riesgo y capacidades operativas.

Trusted Publishing y credenciales de corta duración

Usar Trusted Publishers cuando esté disponible en plataformas como GitHub Actions, GitLab CI/CD, Google Cloud Build y ActiveState garantiza que las credenciales sean de corta duración y tengan un valor limitado en el tiempo si son exfiltradas. Aunque el ataque a Ultralytics demostró que esta medida no es infalible si el entorno de construcción está comprometido, reduce significativamente el riesgo de robo de credenciales que permita acceso a largo plazo.

El segundo wave del ataque a Ultralytics, donde credenciales robadas permitieron cargas directas a PyPI, subraya la importancia de la higiene de credenciales incluso con funciones de seguridad avanzadas. Las organizaciones deben implementar rotaciones rápidas de credenciales que puedan ejecutarse inmediatamente ante sospechas de compromiso.

Revisión de código para artefactos binarios

Las organizaciones deben evitar que los contribuidores suban archivos binarios u opacos, incluyendo binarios compilados, librerías, archivos comprimidos y certificados. Esto previene ataques similares al backdoor de xz-utils, donde código malicioso se ocultaba en archivos binarios y escapaba a la revisión humana o automatizada.

Requerir que todo el código sea legible y revisable como texto fuente hace mucho más difícil que los atacantes oculten funcionalidades maliciosas. Aunque atacantes determinados aún puedan encontrar formas de ofuscar intenciones maliciosas en código fuente, eliminar la opacidad de los blobs binarios cierra una vía importante de ataque.

Respuesta ante incidentes: qué hacer cuando ocurre una vulneración

Acciones inmediatas

Las organizaciones que descubran que están usando versiones comprometidas deben actuar de inmediato. Primero, identificar todos los sistemas afectados usando escáneres de dependencias y análisis de composición de software. Los sistemas que desplegaron Ultralytics 8.3.41, 8.3.42, 8.3.45 o 8.3.46 deben someterse a auditorías de seguridad para determinar si se ejecutó código malicioso y qué datos o credenciales pudieron haberse expuesto.

Desinstalar los paquetes comprometidos inmediatamente y restaurar los sistemas afectados a estados limpios conocidos. Monitorizar en busca de evidencia de actividad de minería de criptomonedas, como uso inusual de CPU, conexiones a pools de minería y procesos inesperados. Recordar que, aunque la carga desplegada era un criptominer, los atacantes con el mismo acceso podrían haber instalado amenazas más sofisticadas.

Rotación de credenciales y gestión de secretos

Las organizaciones deben rotar TODOS los secretos de larga duración tras una vulneración, ya que los atacantes probablemente exfiltraron credenciales que podrían usarse posteriormente si no se rotan. Esto incluye tokens API, contraseñas de cuentas de servicio, claves SSH y cualquier otra credencial de autenticación expuesta.

El alcance de la rotación debe ser amplio. Considerar qué credenciales puede acceder el sistema comprometido: claves de proveedores en la nube, contraseñas de bases de datos, endpoints internos y tokens de servicios de terceros. En entornos complejos, este proceso requiere coordinación cuidadosa para no interrumpir servicios productivos y mantener la seguridad.

Comunicación y transparencia

Publicar acciones tomadas y lecciones aprendidas en lugares públicos como issue trackers ayuda a otros a seguir y aprender. La transparencia cumple varias funciones: ayuda a la comunidad a entender el ataque y protegerse, demuestra responsabilidad y compromiso con la seguridad, y genera confianza en que la organización toma en serio la seguridad.

El equipo de Ultralytics, con comunicación abierta durante y después del incidente, ejemplificó una divulgación responsable y seguridad centrada en la comunidad. Compartiendo detalles sobre cómo ocurrió el ataque y qué pasos tomaron para remediarlo, permitieron que otros proyectos aprendieran de su experiencia y fortalecieran su postura de seguridad.

El futuro de la seguridad en la cadena de suministro

Desafíos sistémicos

El ataque a Ultralytics revela tensiones fundamentales en el desarrollo de software moderno. La automatización e integración que hacen poderosos a los sistemas CI/CD también crean superficies de ataque difíciles de asegurar completamente. La naturaleza colaborativa y abierta que hace prosperar al open-source también permite a atacantes enviar contribuciones maliciosas y explotar relaciones de confianza.

No son problemas que puedan resolverse con un único control de seguridad o buenas prácticas. Requieren vigilancia continua, defensa en profundidad y una cultura de seguridad que trate los riesgos de la cadena de suministro como prioridades, no como casos aislados. Las organizaciones deben invertir en herramientas de seguridad, capacitación y procesos diseñados específicamente para abordar amenazas en CI/CD y en la cadena de suministro.

Soluciones emergentes

La comunidad de seguridad desarrolla nuevos enfoques para gestionar los riesgos en la cadena de suministro. Los estándares de Software Bill of Materials (SBOM) permiten un mejor rastreo de dependencias y su procedencia. Las construcciones reproducibles aseguran que los artefactos distribuidos puedan verificarse contra el código fuente. Los marcos de atestación crean pruebas criptográficas de cómo se construyó el software y por quién.

Plataformas como GitHub están implementando nuevas funciones de seguridad específicamente diseñadas para abordar las vulnerabilidades explotadas en ataques como el de Ultralytics. Estas incluyen mejores valores predeterminados para disparadores de workflows, gestión mejorada de secretos y mejor aislamiento entre código no confiable y operaciones privilegiadas. Sin embargo, el equilibrio entre seguridad, experiencia del desarrollador y automatización sigue siendo un desafío constante.

Conclusión: un llamado de atención para la industria

El ataque de inyección de scripts en GitHub Actions a Ultralytics YOLO marca un momento decisivo en la comprensión de la seguridad en la cadena de suministro moderna. Demostró que los atacantes avanzan más allá del simple robo de credenciales y typosquatting, hacia una explotación sofisticada de los sistemas automatizados en los que confiamos para construir y distribuir software.

El impacto del incidente va mucho más allá de la carga de minería de criptomonedas. Exposo vulnerabilidades sistemáticas en cómo diseñamos los sistemas CI/CD, gestionamos dependencias y confiamos en procesos automatizados. Que una vulnerabilidad reportada y parcheada anteriormente pueda ser reintroducida y explotada con éxito resalta los desafíos de mantener la seguridad en bases de código en rápida evolución.

Para desarrolladores, equipos de seguridad y organizaciones, el ataque a Ultralytics es un recordatorio contundente: la cadena de suministro solo es tan segura como su eslabón más débil, y cada vez más, ese eslabón es la infraestructura automatizada que hemos construido para acelerar y facilitar el desarrollo. Asegurar esa infraestructura requiere vigilancia constante, defensa en profundidad y una disposición a cuestionar las implicaciones de seguridad de cada automatización e integración.

De cara al futuro, las lecciones de Ultralytics deben guiar cómo construimos, desplegamos y consumimos software. La alternativa, una cadena de suministro donde cada dependencia y cada proceso automatizado sea un potencial backdoor, es demasiado arriesgada para aceptar.

Mantente informado sobre las últimas amenazas de seguridad y mejores prácticas siguiendo a investigadores como Adnan Khan y organizaciones como Trail of Bits, ReversingLabs y la Open Source Security Foundation. Tu vigilancia hoy previene compromisos mañana.