Metodología de Pentesting CI/CD

Tip

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

Apoya a HackTricks

VCS

VCS significa Sistema de Control de Versiones, este sistema permite a los desarrolladores gestionar su código fuente. El más común es git y normalmente encontrarás que las empresas lo usan en una de las siguientes plataformas:

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

CI/CD Pipelines

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

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

VCS Pentesting Methodology

Note

Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.

Las plataformas que contienen el código fuente de tu proyecto almacenan información sensible y hay que tener mucho cuidado con los permisos concedidos dentro de esta plataforma. Estos son algunos problemas comunes en 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 ganar más visibilidad y permisos.
  • Register: Algunas plataformas permiten simplemente que usuarios externos creen una cuenta.
  • SSO: Algunas plataformas no permiten registro directo, pero permiten a cualquiera acceder con un SSO válido (por ejemplo, un atacante podría usar su github account 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 forma a un repo.
  • Webhooks: Las plataformas VCS permiten generar webhooks. Si no están protegidos con secrets no visibles un atacante podría abusar de ellos.
  • Si no hay un secret en su lugar, el atacante podría abusar del webhook de la plataforma tercera
  • Si el secret está en la URL, ocurre lo mismo y el atacante además tendría el secret
  • 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 puede que necesite bypassear branch protections. Estas acciones pueden realizarse con distintos objetivos:
    • Comprometer la rama main para comprometer producción.
    • Comprometer la main (u otras branches) para comprometer máquinas de desarrolladores (ya que suelen ejecutar tests, terraform u otras cosas desde el repo en sus máquinas).
  • Compromise the pipeline (revisar la siguiente sección)

Pipelines Pentesting Methodology

La forma más común de definir un pipeline es usando un archivo de configuración de CI alojado en el repository que el pipeline construye. Este archivo describe el orden de los jobs ejecutados, condiciones que afectan el flujo y la configuración del entorno de build.
Estos archivos típicamente 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 bajo .github/workflows. Cuando se dispara, el job del pipeline pulls the code desde la fuente seleccionada (por ejemplo commit / branch), y ejecuta los comandos especificados en el CI configuration file contra ese código.

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

Tip

Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., “..”) to ingest host files during build and exfiltrate secrets. See:

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

PPE - Poisoned Pipeline Execution

La Poisoned Pipeline Execution (PPE) explota permisos en un SCM repository para manipular un CI pipeline y ejecutar comandos dañinos. Usuarios con los permisos necesarios pueden modificar CI configuration files u otros archivos usados por el job del pipeline para incluir comandos maliciosos. Esto “poisons” el CI pipeline, derivando en la ejecución de esos comandos maliciosos.

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

  • Tener write access to the VCS platform, ya que normalmente los pipelines se disparan cuando se realiza un push o un pull request. (Revisar la VCS pentesting methodology para un resumen de formas de obtener acceso).
  • Nota: a veces un external PR cuenta como “write access”.
  • Incluso si tiene permisos de escritura, necesita asegurarse de que puede modificar el CI config file u otros archivos de los que el config depende.
  • Para esto, puede que necesite bypassear branch protections.

Hay 3 sabores de PPE:

  • D-PPE: Un ataque Direct PPE ocurre cuando el actor modifica el CI config file que va a ser ejecutado.
  • I-DDE: Un ataque Indirect PPE ocurre cuando el actor modifica un archivo del que el CI config se apoya (como un Makefile o una configuración terraform).
  • Public PPE or 3PE: En algunos casos los pipelines pueden ser disparados por usuarios que no tienen write access en el repo (y que puede que ni siquiera formen parte de la org) porque pueden enviar un PR.
  • 3PE Command Injection: Usualmente, los pipelines CI/CD set environment variables con información sobre el PR. Si ese valor puede ser controlado por un atacante (como el título del PR) y es usado en un lugar peligroso (por ejemplo ejecutando comandos sh), un atacante podría inyectar comandos allí.

Exploitation Benefits

Sabiendo los 3 sabores 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 (recuperar el código, build, deploy…) y estos privilegios usualmente están almacenados en secrets. Estos secrets suelen ser accesibles vía env variables o archivos dentro del sistema. Por lo tanto, un atacante siempre intentará exfiltrar la mayor cantidad de secrets posible.
  • Dependiendo de la plataforma del pipeline el atacante podría necesitar especificar los secrets en el config. Esto significa que si el atacante no puede modificar la configuración del CI (I-PPE por ejemplo), podría solo exfiltrar los secrets que ese pipeline tenga.
  • Computation: El código se ejecuta en algún lado; dependiendo de dónde se ejecute, un atacante podría pivotar más.
  • On-Premises: Si los pipelines se ejecutan on-premises, un atacante podría acabar en una red interna 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 ahí para obtener más acceso dentro del cloud.
  • Platforms machine: A veces los jobs se ejecutan dentro de las máquinas de la plataforma de pipelines, que normalmente están en una cloud sin mayor acceso.
  • Select it: En ocasiones la pipeline platform tiene configuradas varias máquinas y si puedes modificar el CI configuration file puedes indicar dónde quieres ejecutar el código malicioso. En esa situación, un atacante probablemente ejecutará un 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 builda y despliega desde él, podrías comprometer el código que terminará ejecutándose en producción.

More relevant info

Tools & CIS Benchmark

  • Chain-bench es una herramienta open-source para auditar tu software supply chain stack en cuanto a cumplimiento de seguridad basada 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.

Top 10 CI/CD Security Risk

Revisa este artículo interesante sobre los top 10 CI/CD risks según Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

Automatic Tools

  • Checkov: Checkov es una herramienta de análisis estático para infrastructure-as-code.

References

Tip

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

Apoya a HackTricks