# Metodología de Pentesting CI/CD {{#include ../banners/hacktricks-training.md}}
## VCS 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) ## Pipelines CI/CD Los pipelines 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**. ## Metodología de Pentesting VCS > [!NOTE] > 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: - **Filtraciones**: Si tu código contiene filtraciones en los commits y el atacante puede acceder al repositorio (porque es público o porque tiene acceso), podría descubrir las filtraciones. - **Acceso**: Si un atacante puede **acceder a una cuenta dentro de la plataforma VCS**, podría obtener **más visibilidad y permisos**. - **Registro**: 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). - **Credenciales**: 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 repositorio. - **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. - **Compromiso de código:** Si un actor malicioso tiene algún tipo de acceso **de escritura** sobre los repositorios, 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 repositorio en sus máquinas). - **Comprometer el pipeline** (ver la siguiente sección). ## Metodología de Pentesting de Pipelines La forma más común de definir un pipeline es utilizando un **archivo de configuración CI alojado en el repositorio** que el 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 del pipeline **extrae el código** de la fuente seleccionada (por ejemplo, commit / rama) y **ejecuta los comandos especificados en el archivo de configuración 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**. ### PPE - Ejecución de Pipeline Envenenado La ruta de Ejecución de Pipeline Envenenado (PPE) explota permisos en un repositorio SCM para manipular un pipeline CI y ejecutar comandos dañinos. Los usuarios con los permisos necesarios pueden modificar archivos de configuración CI u otros archivos utilizados por el trabajo del pipeline para incluir comandos maliciosos. Esto "envenena" el pipeline 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 los 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 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 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 CI que se va a ejecutar **depende** (como un archivo make o una configuración de terraform). - **PPE Público o 3PE**: En algunos casos, los pipelines pueden ser **activados por usuarios que no tienen acceso de escritura en el repositorio** (y que podrían ni siquiera ser parte de la organización) porque pueden enviar un PR. - **Inyección de Comandos 3PE**: Generalmente, los pipelines 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 se **usa** en un **lugar peligroso** (como ejecutar **comandos sh**), un atacante podría **inyectar comandos allí**. ### Beneficios de la Explotación Conociendo los 3 sabores para envenenar un pipeline, veamos qué podría obtener un atacante después de una explotación exitosa: - **Secretos**: Como se mencionó anteriormente, los 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 del pipeline, el atacante **podría necesitar especificar los secretos en la configuración**. Esto significa que si el atacante no puede modificar la configuración del pipeline CI (**I-PPE** por ejemplo), podría **solo exfiltrar los secretos que tiene ese pipeline**. - **Cómputo**: 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 allá. - **On-Premises**: Si los pipelines se ejecutan en las instalaciones, un atacante podría terminar en una **red interna con acceso a más recursos**. - **Nube**: 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**. - **Máquina de plataformas**: 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**. - **Seleccionarlo:** A veces la **plataforma 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á un shell inverso en cada máquina posible para intentar explotarla más. - **Comprometer producción**: Si estás dentro del pipeline y la versión final se construye y despliega desde él, podrías **comprometer el código que va a terminar ejecutándose en producción**. ## Más información relevante ### Herramientas y Benchmark CIS - [**Chain-bench**](https://github.com/aquasecurity/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 [**benchmark de Seguridad de Cadena de Suministro de Software CIS**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). 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 Riesgos de Seguridad CI/CD 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/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Laboratorios - En cada plataforma que puedes ejecutar localmente encontrarás cómo lanzarlo localmente para que puedas configurarlo como desees para probarlo. - Laboratorio Gitea + Jenkins: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) ### Herramientas Automáticas - [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** es una herramienta de análisis de código estático para infraestructura como código. ## Referencias - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422) {{#include ../banners/hacktricks-training.md}}