Pentesting CI/CD Methodology
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
VCS significa Sistema de Control de Versiones, estos sistemas permiten a los desarrolladores gestionar su código fuente. El más común es git y generalmente encontrarás empresas usándolo en una de las siguientes plataformas:
Github
Gitlab
Bitbucket
Gitea
Proveedores de la nube (ofrecen sus propias plataformas VCS)
Las pipelines de CI/CD permiten a los desarrolladores automatizar la ejecución de código para varios propósitos, incluyendo la construcción, prueba y despliegue de aplicaciones. Estos flujos de trabajo automatizados son activados por acciones específicas, como pushes de código, pull requests o tareas programadas. Son útiles para agilizar el proceso desde el desarrollo hasta la producción.
Sin embargo, estos sistemas necesitan ser ejecutados en algún lugar y generalmente con credenciales privilegiadas para desplegar código o acceder a información sensible.
Incluso si algunas plataformas VCS permiten crear pipelines, en esta sección solo vamos a analizar los posibles ataques al control del código fuente.
Las plataformas que contienen el código fuente de tu proyecto contienen información sensible y las personas deben tener mucho cuidado con los permisos otorgados dentro de esta plataforma. Estos son algunos problemas comunes en las plataformas VCS que un atacante podría abusar:
Leaks: Si tu código contiene leaks en los commits y el atacante puede acceder al repo (porque es público o porque tiene acceso), podría descubrir los leaks.
Access: Si un atacante puede acceder a una cuenta dentro de la plataforma VCS, podría obtener más visibilidad y permisos.
Register: Algunas plataformas solo permitirán a los usuarios externos crear una cuenta.
SSO: Algunas plataformas no permitirán a los usuarios registrarse, pero permitirán a cualquiera acceder con un SSO válido (por lo que un atacante podría usar su cuenta de github para entrar, por ejemplo).
Credentials: Nombre de usuario + Contraseña, tokens personales, claves ssh, tokens Oauth, cookies... hay varios tipos de tokens que un usuario podría robar para acceder de alguna manera a un repo.
Webhooks: Las plataformas VCS permiten generar webhooks. Si no están protegidos con secretos no visibles, un atacante podría abusar de ellos.
Si no hay secreto en su lugar, el atacante podría abusar del webhook de la plataforma de terceros.
Si el secreto está en la URL, lo mismo sucede y el atacante también tiene el secreto.
Code compromise: Si un actor malicioso tiene algún tipo de acceso de escritura sobre los repos, podría intentar inyectar código malicioso. Para tener éxito, podría necesitar eludir las protecciones de rama. Estas acciones pueden realizarse con diferentes objetivos en mente:
Comprometer la rama principal para comprometer la producción.
Comprometer la principal (u otras ramas) para comprometer las máquinas de los desarrolladores (ya que generalmente ejecutan pruebas, terraform u otras cosas dentro del repo en sus máquinas).
Comprometer la pipeline (ver la siguiente sección).
La forma más común de definir una pipeline es utilizando un archivo de configuración de CI alojado en el repositorio que la pipeline construye. Este archivo describe el orden de los trabajos ejecutados, las condiciones que afectan el flujo y la configuración del entorno de construcción. Estos archivos generalmente tienen un nombre y formato consistentes, por ejemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), y los archivos YAML de GitHub Actions ubicados en .github/workflows. Cuando se activa, el trabajo de la pipeline extrae el código de la fuente seleccionada (por ejemplo, commit / rama), y ejecuta los comandos especificados en el archivo de configuración de CI contra ese código.
Por lo tanto, el objetivo final del atacante es de alguna manera comprometer esos archivos de configuración o los comandos que ejecutan.
La ejecución de pipeline envenenada (PPE) explota permisos en un repositorio SCM para manipular una pipeline de CI y ejecutar comandos dañinos. Los usuarios con los permisos necesarios pueden modificar archivos de configuración de CI u otros archivos utilizados por el trabajo de la pipeline para incluir comandos maliciosos. Esto "envenena" la pipeline de CI, llevando a la ejecución de estos comandos maliciosos.
Para que un actor malicioso tenga éxito realizando un ataque PPE, necesita poder:
Tener acceso de escritura a la plataforma VCS, ya que generalmente las pipelines se activan cuando se realiza un push o un pull request. (Consulta la metodología de pentesting VCS para un resumen de formas de obtener acceso).
Ten en cuenta que a veces un PR externo cuenta como "acceso de escritura".
Incluso si tiene permisos de escritura, necesita asegurarse de que puede modificar el archivo de configuración de CI u otros archivos de los que depende la configuración.
Para esto, podría necesitar poder eludir las protecciones de rama.
Hay 3 sabores de PPE:
D-PPE: Un ataque Directo PPE ocurre cuando el actor modifica el archivo de configuración de CI que se va a ejecutar.
I-DDE: Un ataque Indirecto PPE ocurre cuando el actor modifica un archivo del que el archivo de configuración de CI que se va a ejecutar depende (como un archivo make o una configuración de terraform).
Public PPE o 3PE: En algunos casos, las pipelines pueden ser activadas por usuarios que no tienen acceso de escritura en el repo (y que podrían ni siquiera ser parte de la organización) porque pueden enviar un PR.
3PE Command Injection: Generalmente, las pipelines de CI/CD configuran variables de entorno con información sobre el PR. Si ese valor puede ser controlado por un atacante (como el título del PR) y es utilizado en un lugar peligroso (como ejecutar comandos sh), un atacante podría inyectar comandos allí.
Conociendo los 3 sabores para envenenar una pipeline, veamos qué podría obtener un atacante después de una explotación exitosa:
Secrets: Como se mencionó anteriormente, las pipelines requieren privilegios para sus trabajos (recuperar el código, construirlo, desplegarlo...) y estos privilegios generalmente están otorgados en secretos. Estos secretos son generalmente accesibles a través de variables de entorno o archivos dentro del sistema. Por lo tanto, un atacante siempre intentará exfiltrar tantos secretos como sea posible.
Dependiendo de la plataforma de la pipeline, el atacante podría necesitar especificar los secretos en la configuración. Esto significa que si el atacante no puede modificar la pipeline de configuración de CI (I-PPE, por ejemplo), podría solo exfiltrar los secretos que tiene esa pipeline.
Computation: El código se ejecuta en algún lugar, dependiendo de dónde se ejecute, un atacante podría ser capaz de pivotar más.
On-Premises: Si las pipelines se ejecutan en las instalaciones, un atacante podría terminar en una red interna con acceso a más recursos.
Cloud: El atacante podría acceder a otras máquinas en la nube pero también podría exfiltrar tokens de cuentas de servicio/roles IAM de ella para obtener más acceso dentro de la nube.
Platforms machine: A veces los trabajos se ejecutarán dentro de las máquinas de la plataforma de pipelines, que generalmente están dentro de una nube con sin más acceso.
Select it: A veces la plataforma de pipelines tendrá configuradas varias máquinas y si puedes modificar el archivo de configuración de CI puedes indicar dónde quieres ejecutar el código malicioso. En esta situación, un atacante probablemente ejecutará un shell inverso en cada máquina posible para intentar explotarla más.
Compromise production: Si estás dentro de la pipeline y la versión final se construye y despliega desde ella, podrías comprometer el código que va a terminar ejecutándose en producción.
Chain-bench es una herramienta de código abierto para auditar tu pila de cadena de suministro de software para cumplimiento de seguridad basado en un nuevo CIS Software Supply Chain benchmark. La auditoría se centra en todo el proceso SDLC, donde puede revelar riesgos desde el tiempo de código hasta el tiempo de despliegue.
Consulta este interesante artículo sobre los 10 principales riesgos de CI/CD según Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/
En cada plataforma que puedes ejecutar localmente encontrarás cómo lanzarla localmente para que puedas configurarla como desees para probarla.
Laboratorio Gitea + Jenkins: https://github.com/cider-security-research/cicd-goat
Checkov: Checkov es una herramienta de análisis de código estático para infraestructura como código.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
