Metodología de Pentesting CI/CD

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

VCS

VCS significa Version Control System, este sistema permite a los desarrolladores gestionar su código fuente. El más común es git y normalmente encontrarás empresas usándolo en una de las siguientes platforms:

  • Github
  • Gitlab
  • Bitbucket
  • Gitea
  • Gitblit
  • Cloud providers (ofrecen sus propias platforms VCS)

CI/CD Pipelines

Los pipelines CI/CD permiten a los desarrolladores automatizar la ejecución de código para diversos propósitos, incluyendo compilar, probar y desplegar aplicaciones. Estos flujos de trabajo automatizados se activan por acciones específicas, como pushes de código, pull requests o tareas programadas. Son útiles para agilizar el proceso desde desarrollo hasta producción.

Sin embargo, estos sistemas deben ejecutarse en algún lugar y normalmente con credenciales privilegiadas para desplegar código o acceder a información sensible.

VCS Pentesting Methodology

Note

Aunque algunas platforms VCS permiten crear pipelines, en esta sección vamos a analizar solo posibles ataques al control del código fuente.

Las platforms que contienen el código fuente de tu proyecto contienen información sensible y la gente debe tener mucho cuidado con los permisos concedidos dentro de esta platform. Estos son algunos problemas comunes en platforms 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 platform VCS podría obtener más visibilidad y permisos.
  • Register: Algunas platforms simplemente permitirán que usuarios externos creen una cuenta.
  • SSO: Algunas platforms no permitirán que los usuarios se registren, pero sí permitirán que cualquiera acceda con un SSO válido (por ejemplo, un atacante podría usar su cuenta de github para entrar).
  • Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies… hay varios tipos de tokens que un usuario podría robar para acceder de alguna manera a un repo.
  • Webhooks: Las platforms VCS permiten generar webhooks. Si no están protegidos con secretos no visibles, un atacante podría abusar de ellos.
  • Si no hay secreto configurado, el atacante podría abusar del webhook de la platform de tercero
  • Si el secreto está en la URL, ocurre lo mismo y el atacante también tiene el secreto
  • Code compromise: Si un actor malicioso tiene algún tipo de acceso de write sobre los repos, podría intentar inyectar código malicioso. Para tener éxito podría necesitar bypassear branch protections. Estas acciones pueden realizarse con distintos objetivos en mente:
  • Comprometer la main branch para comprometer producción.
  • Comprometer la main (u otras branches) para comprometer máquinas de desarrolladores (ya que normalmente ejecutan tests, terraform u otras cosas dentro del repo en sus máquinas).
  • Compromise the pipeline (consulta la siguiente sección)

Pipelines Pentesting Methodology

La forma más común de definir un pipeline es usando un archivo de configuración CI alojado en el repository que el pipeline construye. Este archivo describe el orden de los jobs ejecutados, las condiciones que afectan al flujo y la configuración del entorno de build.
Estos archivos suelen tener 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 job del pipeline descarga el código desde la fuente seleccionada (por ejemplo, commit / branch) y ejecuta los comandos especificados en el archivo de configuración CI contra ese código.

Por tanto, el objetivo final del atacante es de alguna forma comprometer esos archivos de configuración o los comandos que ejecutan.

Tip

Algunos hosted builders permiten a los contributors elegir el Docker build context y la ruta del Dockerfile. Si el context está controlado por el atacante, puedes situarlo fuera del repo (por ejemplo, “..”) para ingerir archivos del host durante el build y exfiltrar secrets. Ver:

{{#ref}} docker-build-context-abuse.md {{#endref}}

PPE - Poisoned Pipeline Execution

La ruta Poisoned Pipeline Execution (PPE) explota permisos en un repository SCM para manipular un pipeline CI y ejecutar comandos maliciosos. Los usuarios con los permisos necesarios pueden modificar archivos de configuración CI u otros archivos usados por el job del pipeline para incluir comandos maliciosos. Esto “envenena” el pipeline CI, lo que lleva a la ejecución de estos comandos maliciosos.

Para que un actor malicioso tenga éxito realizando un ataque PPE necesita poder:

  • Tener write access to the VCS platform, ya que normalmente los pipelines se activan cuando se realiza un push o un pull request. (Consulta la metodología VCS pentesting para un resumen de formas de obtener acceso).
  • Ten en cuenta que a veces un external PR cuenta como “write access”.
  • Incluso teniendo permisos de write, debe asegurarse de poder modificar el archivo de config CI u otros archivos de los que depende la config.
  • Para ello, podría necesitar poder bypassear branch protections.

Hay 3 variantes de PPE:

  • D-PPE: Un ataque Direct PPE ocurre cuando el actor modifica el archivo de config CI que se va a ejecutar.
  • I-DDE: Un ataque Indirect PPE ocurre cuando el actor modifica un archivo del que depende el archivo de config CI que se va a ejecutar (como un make file o una config terraform).
  • Public PPE or 3PE: En algunos casos los pipelines pueden ser activados por usuarios que no tienen write access en el repo (e incluso podrían no formar parte de la org) porque pueden enviar un PR.
  • 3PE Command Injection: Normalmente, los pipelines CI/CD establecerán environment variables con información sobre el PR. Si ese valor puede ser controlado por un atacante (como el título del PR) y se usa en un lugar peligroso (como ejecutar sh commands), un atacante podría inyectar comandos ahí.

Exploitation Benefits

Conociendo las 3 variantes para envenenar un pipeline, veamos qué podría obtener un atacante tras una explotación exitosa:

  • Secrets: Como se mencionó antes, los pipelines requieren privilegios para sus jobs (obtener el código, compilarlo, desplegarlo…) y estos privilegios normalmente se conceden en secrets. Estos secrets suelen ser accesibles mediante env variables o archivos dentro del sistema. Por tanto, un atacante siempre intentará exfiltrar tantos secrets como sea posible.
  • Dependiendo de la platform del pipeline, el atacante podría necesitar especificar los secrets en la config. Esto significa que si el atacante no puede modificar la CI configuration pipeline (I-PPE por ejemplo), solo podría exfiltrar los secrets que tenga ese 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 los pipelines se ejecutan on premises, un atacante podría acabar en una internal network con acceso a más recursos.
  • Cloud: El atacante podría acceder a otras máquinas en la cloud pero también podría exfiltrar IAM roles/service accounts tokens de ella para obtener más acceso dentro de la cloud.
  • Platforms machine: A veces los jobs se ejecutarán dentro de las máquinas de la platform de pipelines, que normalmente están dentro de una cloud sin más acceso.
  • Select it: A veces la platform de pipelines tendrá configuradas varias máquinas y si puedes modificar el archivo de configuración CI puedes indicar dónde quieres ejecutar el código malicioso. En esta situación, un atacante probablemente ejecutará una reverse shell en cada máquina posible para intentar explotarla más.
  • Compromise production: Si estás dentro del pipeline y la versión final se construye y despliega desde ahí, podrías comprometer el código que acabará ejecutándose en producción.

Dependency & Registry Supply-Chain Abuse

Comprometer un pipeline CI/CD o robar credenciales de él puede permitir a un atacante pasar de pipeline execution a ecosystem-wide code execution mediante backdooring de dependencies o tooling de release:

  • Install-time code execution via package hooks: publica una versión del package que añada hooks preinstall, postinstall, prepare o similares para que el payload se ejecute automáticamente en las estaciones de trabajo de developers y en los runners de CI durante la instalación de dependencies.
  • Secondary execution paths: incluso si los objetivos instalan con --ignore-scripts, un package malicioso aún puede registrar un common CLI name en el campo bin para que el wrapper controlado por el atacante se enlace mediante symlink en PATH y se ejecute más tarde cuando se use el comando.
  • Runtime bootstrapping: un pequeño installer puede descargar un segundo runtime o toolchain durante la instalación (por ejemplo Bun o un interpreter empaquetado) y luego lanzar con él el payload principal, evitando dependencias locales.
  • Credential harvesting from build environments: una vez que el código se ejecuta dentro de CI, revisa environment variables, ~/.npmrc, ~/.git-credentials, SSH keys, cloud CLI configs y tooling local como gh auth token. En GitHub Actions, revisa también secrets y artifacts específicos del runner.
  • Workflow injection with stolen GitHub tokens: un token con permisos repo + workflow es suficiente para crear una branch, commitear un archivo malicioso dentro de .github/workflows/, activarlo, recopilar los artifacts/logs producidos y luego borrar la branch temporal/la ejecución del workflow para reducir rastros.
  • Wormable registry propagation: los tokens robados de npm deben validarse para permisos de publish y para ver si evitan 2FA. Si lo hacen, enumera packages escribibles, descarga sus tarballs, inyecta un loader como setup.mjs, establece preinstall para ejecutarlo, incrementa la versión patch y republish. Esto convierte una sola compromise de CI en auto-ejecución aguas abajo en otros entornos.

Practical checks during an assessment

  • Revisa la release automation buscando hooks del package-manager añadidos a package.json, entradas bin inesperadas o incrementos de versión que solo modifiquen el release artifact.
  • Comprueba si CI almacena credenciales de registry de larga duración en archivos en texto plano como ~/.npmrc en lugar de usar OIDC de corta duración o trusted publishing.
  • Verifica si los tokens de GitHub disponibles en CI pueden escribir archivos de workflow o crear branches/tags.
  • Si se sospecha de un package comprometido, inspecciona el tarball publicado y no solo el Git repository, porque el loader/runtime malicioso puede existir solo en el artifact publicado.
  • Busca ejecución inesperada del package-manager dentro de CI, como npm install en lugar de npm ci, descargas/ejecución inesperadas de Bun o nuevos artifacts de workflow generados desde branches transitorias.

More relevant info

Tools & CIS Benchmark

  • Chain-bench is an open-source tool for auditing your software supply chain stack for security compliance based on a new CIS Software Supply Chain benchmark. The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time.

Top 10 CI/CD Security Risk

Check this interesting article about the top 10 CI/CD risks according to Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

Automatic Tools

  • Checkov: Checkov is a static code analysis tool for infrastructure-as-code.

References

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks