9.2 KiB
Pentesting CI/CD Methodology
{{#include ../banners/hacktricks-training.md}}
VCS
VCS significa Version Control System, estos sistemas permiten a los desarrolladores gestionar su source code. 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 (they offer their own VCS platforms)
CI/CD Pipelines
CI/CD pipelines permiten a los desarrolladores automatizar la ejecución del code para varios propósitos, incluyendo build, test y deploy de aplicaciones. Estos workflows automatizados se disparan por acciones específicas, como code pushes, pull requests, o tareas programadas. Son útiles para optimizar el proceso desde el desarrollo hasta production.
Sin embargo, estos sistemas necesitan ser ejecutados en algún lado y normalmente con credenciales privilegiadas para deploy code o acceder a información sensible.
VCS Pentesting Methodology
Note
Incluso si algunas VCS platforms permiten crear pipelines para esta sección vamos a analizar solo ataques potenciales al control del source code.
Las platforms que contienen el source code de tu proyecto contienen información sensible y la gente debe tener mucho cuidado con los permisos otorgados dentro de esa platform. Estos son algunos problemas comunes en VCS platforms que un atacante podría abusar:
- Leaks: Si tu code 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 VCS platform podría obtener más visibilidad y permisos.
- Register: Algunas platforms simplemente permiten a usuarios externos crear una cuenta.
- SSO: Algunas platforms no permiten registro, pero permiten que cualquiera entre 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 forma a un repo.
- Webhooks: VCS platforms permiten generar webhooks. Si no están protegidos con secretos 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 de terceros
- Si el secret está en la URL, sucede lo mismo y el atacante además tendría el secret
- Code compromise: Si un actor malicioso tiene algún tipo de write access 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:
- Comprometer la main branch para comprometer production.
- Comprometer la main (u otras branches) para comprometer las máquinas de los developers (ya que suelen ejecutar tests, terraform u otras cosas del repo en sus máquinas).
- Comprometer el pipeline (revisa la siguiente sección)
Pipelines Pentesting Methodology
La forma más común de definir un pipeline es usando un CI configuration file 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 build environment.
Estos archivos típicamente tienen un nombre y formato consistente, por ejemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), y los GitHub Actions YAML files ubicados bajo .github/workflows. Cuando se dispara, el pipeline job pulls the code desde la fuente seleccionada (p. ej. commit / branch), y ejecuta los comandos especificados en el CI configuration file contra ese code.
Por lo tanto el objetivo final del atacante es de alguna manera comprometer esos configuration files o los comandos que ejecutan.
PPE - Poisoned Pipeline Execution
El 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 pipeline job para incluir comandos maliciosos. Esto "envenena" el CI pipeline, llevando a la ejecución de esos comandos maliciosos.
Para que un actor malicioso tenga éxito realizando un PPE necesita poder:
- Tener write access to the VCS platform, ya que usualmente los pipelines se disparan cuando se realiza un push o un pull request. (Revisa la VCS pentesting methodology para un resumen de maneras de obtener acceso).
- Nota que a veces un external PR cuenta como "write access".
- Incluso si tiene permisos de write, necesita estar seguro de que puede modificar el CI config file u otros archivos de los que el config depende.
- Para esto, podría necesitar poder bypassear branch protections.
Hay 3 sabores de PPE:
- D-PPE: Un ataque Direct PPE ocurre cuando el actor modifica el CI config file que se va a ejecutar.
- I-DDE: Un ataque Indirect PPE ocurre cuando el actor modifica un file del que el CI config que se va a ejecutar depende (como un make file o un terraform config).
- Public PPE or 3PE: En algunos casos los pipelines pueden ser triggered por users que no tienen write access en el repo (y que quizás ni siquiera forman parte de la org) porque pueden enviar un PR.
- 3PE Command Injection: Usualmente, CI/CD pipelines set environment variables con información sobre el PR. Si ese valor puede ser controlado por un atacante (como el title del PR) y es usado en un lugar peligroso (como ejecutar sh commands), un atacante podría inyectar comandos ahí.
Exploitation Benefits
Conociendo los 3 sabores para envenenar un pipeline, veamos qué podría obtener un atacante tras una explotación exitosa:
- Secrets: Como se mencionó previamente, los pipelines requieren privilegios para sus jobs (retrieve the code, build it, deploy it...) y estos privilegios usualmente se otorgan en secrets. Estos secrets suelen ser accesibles vía env variables o files dentro del sistema. Por lo tanto un atacante siempre intentará exfiltrar la mayor cantidad de secrets posible.
- Dependiendo de la plataforma de pipeline el atacante podría necesitar especificar los secrets en el config. Esto significa que si el atacante no puede modificar la CI configuration pipeline (I-PPE por ejemplo), podría solo exfiltrar los secrets que ese pipeline tenga.
- Computation: El code 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 terminar 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 allí 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 usualmente están en una cloud sin acceso adicional.
- Select it: A veces la platform de pipelines tendrá varias máquinas configuradas y si puedes modificar el CI configuration file puedes indicar dónde quieres ejecutar el código malicioso. En esta 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 deploya desde ahí, podrías comprometer el code que terminará corriendo en production.
More relevant info
Tools & CIS Benchmark
- Chain-bench es una herramienta open-source para auditar tu software supply chain stack por seguridad y cumplimiento basada en un nuevo CIS Software Supply Chain benchmark. La auditoría se enfoca en todo el SDLC, donde puede revelar riesgos desde code time hasta deploy time.
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
- En cada platform que puedas ejecutar localmente encontrarás cómo lanzarla localmente para que puedas configurarla como quieras y probarla
- Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat
Automatic Tools
- Checkov: Checkov es una herramienta de análisis estático para infrastructure-as-code.
References
{{#include ../banners/hacktricks-training.md}}