¡Secuestro de Pipelines! Perspectiva Ofensiva en CI/CD y la Caza de Credenciales
Hola a todos. Soy arquitecto de seguridad en la nube y, con más de una década de experiencia en el sector, he visto cómo la automatización de CI/CD (Integración Continua/Entrega Continua) ha pasado de ser algo opcional a la piedra angular de la entrega de software. Sin embargo, en esta carrera por la velocidad, un aspecto crítico que se subestima es la superficie de ataque que representan estos pipelines completamente automatizados.
El Problema Real: Los Pipelines como Objetivo Prioritario
En un proyecto real donde migramos a una arquitectura serverless basada en microservicios, nos enfrentamos al clásico desafío de la gestión de secretos. Al principio, dependíamos demasiado de variables de entorno o secrets managers (como AWS Secrets Manager o HashiCorp Vault) configurados con permisos demasiado amplios en las cuentas de servicio de runners de Jenkins o GitLab.
El problema es simple pero puede tener consecuencias nefastas: un atacante no necesita vulnerar el entorno de producción (por ejemplo, un cluster de Kubernetes o una máquina virtual en Azure). Le basta con comprometer un paso en el pipeline de CI/CD. ¿Por qué? Porque el pipeline suele tener permisos privilegiados para desplegar, modificar o incluso cargarse infraestructura como código (IaC) en entornos de staging o producción, usando herramientas como Terraform o Ansible.
Un fallo habitual que detectamos es que un pipeline comprometido a través de una dependencia de terceros maliciosa o una configuración insegura del runner podría ejecutar código arbitrario con los permisos de la cuenta de servicio del propio pipeline. El objetivo ofensivo claro es la exfiltración de credenciales o la inyección de backdoors en el código fuente o las imágenes Docker que se están construyendo.
Enfoque Práctico: Caza de Credenciales y Artefactos
Mi perspectiva en este artículo es puramente ofensiva, demostrando lo sencillo que puede ser abusar de configuraciones deficientes.
El escenario de ataque se centra en dos vectores principales:
- Abuso de Tokens y Variables de Entorno: Si un atacante consigue inyectar un script sencillo (quizás mediante una Pull Request maliciosa o un compromiso del repositorio), puede rastrear rápidamente tokens de acceso. Por ejemplo, en un runner de GitLab o GitHub Actions, bastaría con ejecutar
envo buscar archivos de configuración comunes (como~/.aws/credentials,~/.kube/config) para revelar las credenciales de despliegue. Estas credenciales a menudo tienen permisos de escritura en registros de imágenes (ACR, ECR) o incluso permisos para actualizar configuraciones de despliegue en herramientas como ArgoCD o Flux. - Inyección en la Cadena de Suministro (Supply Chain): Un objetivo más avanzado es inyectar código malicioso directamente en el artefacto final. Esto podría ser un binario modificado en una imagen Docker o un módulo Terraform con una puerta trasera. El pipeline, al generar el artefacto, lo firma y lo envía a producción, garantizando la persistencia del ataque. La ausencia de una SBOM (Software Bill of Materials) correcta dificulta enormemente al equipo de seguridad la identificación de componentes y dependencias manipuladas.
La Solución y su Impacto: Zero Trust en el Pipeline
La defensa contra estos ataques ofensivos exige aplicar un modelo de Confianza Cero (Zero Trust) directamente al pipeline.
| Principio | Aplicación Técnica |
|---|---|
| Principio de Mínimo Privilegio (POLP) | Implementar OIDC/Workload Identity (ej. AWS IAM Roles for Service Accounts o Azure Workload Identity) para que los runners NUNCA almacenen credenciales de larga duración. Los tokens deben ser efímeros y específicos para la tarea actual (ej. un token solo puede hacer un terraform apply a un recurso y nada más). |
| Separación de Responsabilidades | Crear pipelines distintos para build y deploy. El pipeline de build no debe tener permisos para tocar la infraestructura de producción. El pipeline de deploy solo debe tener permisos para su entorno específico. |
| Inmutabilidad y Firma de Artefactos | Utilizar herramientas de firma (como Sigstore/Cosign) para asegurar que solo los artefactos que han pasado todas las pruebas y han sido firmados por un sistema de CI/CD de confianza puedan ser desplegados por ArgoCD o Flux. Esto garantiza la integridad de la cadena de suministro. |
Conclusiones: Lecciones Aprendidas
La lección más importante que quiero transmitiros es: vuestro pipeline de CI/CD es vuestro nuevo perímetro de seguridad. Los atacantes lo saben.
Si sois arquitectos o ingenieros, vuestra tarea prioritaria es auditar los permisos de las cuentas de servicio de vuestros pipelines. No deis por sentada la seguridad. Haced la prueba ofensiva vosotros mismos: si podéis haceros con las credenciales, un atacante también puede. Al adoptar POLP en vuestros runners y utilizar OIDC en lugar de claves estáticas, elimináis el vector ofensivo más jugoso: el secuestro de credenciales persistentes.