Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md']

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -6,51 +6,51 @@
 
 ## 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**:
+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 que lo usan en una de las siguientes **plataformas**:
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Cloud providers (ofrecen sus propias plataformas VCS)
+- Proveedores cloud (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.
+Los CI/CD pipelines permiten a los desarrolladores **automatizar la ejecución de código** para diversos fines, incluyendo construir, probar y desplegar aplicaciones. Estos flujos de trabajo automatizados se **disparan 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 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.
+> Incluso si algunas plataformas VCS permiten crear pipelines, en esta sección solo vamos a analizar posibles ataques al control del código fuente.
 
-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:
+Las plataformas que contienen el código fuente de tu proyecto contienen información sensible y la gente necesita ser muy cuidadosa 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).
+- **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 permitirán simplemente que usuarios externos creen una cuenta.
+- **SSO**: Algunas plataformas no permitirán que los usuarios se registren, pero sí permitirán que cualquiera acceda con un SSO válido (así que un atacante podría usar su cuenta de github para entrar, por ejemplo).
 - **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)
+- **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 secret configurado, el atacante podría abusar del webhook de la plataforma de terceros
+- Si el secret está en la URL, ocurre lo mismo y además el atacante también tiene el secret
+- **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 quizá necesite **bypassear branch protections**. Estas acciones pueden realizarse con diferentes objetivos en mente:
+- Comprometer la rama principal para **comprometer production**.
+- Comprometer la rama principal (u otras ramas) para **comprometer las máquinas de los desarrolladores** (ya que normalmente ejecutan tests, terraform u otras cosas dentro del repo en sus máquinas).
+- **Comprometer el pipeline** (ver 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.
+La forma más común de definir un pipeline es usando un **CI configuration file alojado en el repositorio** 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 normalmente 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 **descarga el código** de la fuente seleccionada (p. ej. 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**.
+Por lo tanto, el objetivo final del atacante es de alguna manera **comprometer esos configuration files** 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:
+> Algunos builders hosted permiten a los contributors elegir el Docker build context y la ruta del Dockerfile. Si el context está controlado por el atacante, puede fijarlo fuera del repo (por ejemplo, "..") para ingerir archivos del host durante el build y exfiltrar secrets. Ver:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,57 +58,78 @@ Por tanto, el objetivo final del atacante es de alguna manera **comprometer esos
 
 ### 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.
+La ruta Poisoned Pipeline Execution (PPE) explota permisos en un repositorio SCM para manipular un CI pipeline y ejecutar comandos dañinos. Los usuarios con los permisos necesarios pueden modificar los CI configuration files u otros archivos usados por el job del pipeline para incluir comandos maliciosos. Esto “envenena” el CI pipeline, llevando a la ejecución de estos comandos maliciosos.
 
-Para que un actor malicioso tenga éxito realizando un ataque PPE necesita:
+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 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**.
+- Tener **write access a la plataforma VCS**, ya que normalmente los pipelines se disparan cuando se realiza un push o un pull request. (Consulta la VCS pentesting methodology para un resumen de formas de obtener acceso).
+- Ten en cuenta que 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 o los otros archivos de los que depende la config**.
+- Para ello, puede necesitar poder **bypassear branch protections**.
 
-Hay 3 sabores de PPE:
+Hay 3 variantes 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í**.
+- **I-DDE**: Un ataque **Indirect PPE** ocurre cuando el actor **modifica** un **file** del que depende el CI config file que va a ser ejecutado (como un make file o una terraform config).
+- **Public PPE or 3PE**: En algunos casos los pipelines pueden ser **disparados por usuarios que no tienen write access en el repo** (y que quizá ni siquiera forman parte de la org) porque pueden enviar un PR.
+- **3PE Command Injection**: Normalmente, los CI/CD pipelines **configurará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 commands ahí**.
 
 ### Exploitation Benefits
 
-Sabiendo los 3 sabores para envenenar un pipeline, veamos qué podría obtener un atacante tras una explotación exitosa:
+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 (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**.
+- **Secrets**: Como se mencionó antes, los pipelines requieren **privilegios** para sus jobs (recuperar el código, construirlo, desplegarlo...) y estos privilegios normalmente se **conceden en secrets**. Estos secrets suelen ser accesibles mediante **env variables o archivos dentro del sistema**. Por lo tanto, un atacante siempre intentará exfiltrar tantos secrets como sea posible.
+- Dependiendo de la plataforma del pipeline, el atacante **podría necesitar especificar los secrets en la config**. Esto significa que, si el atacante no puede modificar el CI configuration pipeline (**I-PPE** por ejemplo), podría **solo exfiltrar los secrets que ese pipeline ya tiene**.
+- **Computation**: El código se ejecuta en algún lugar; dependiendo de dónde se ejecute, un atacante podría hacer pivoting más allá.
+- **On-Premises**: Si los pipelines se ejecutan on premises, un atacante podría terminar en una **internal network con acceso a más resources**.
+- **Cloud**: El atacante podría acceder a **otras máquinas en la cloud** pero también podría **exfiltrar** tokens de roles IAM/service accounts **de ella** para obtener **más acceso dentro de la cloud**.
+- **Platforms machine**: A veces los jobs se ejecutarán dentro de las **machines de la plataforma de pipelines**, que normalmente están dentro de una cloud con **sin más access**.
+- **Select it:** A veces la **plataforma de pipelines tendrá configuradas varias machines** 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á una reverse shell en cada machine posible para intentar explotarla más a fondo.
+- **Compromise production**: 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 production**.
+
+### Dependency & Registry Supply-Chain Abuse
+
+Comprometer un CI/CD pipeline o robar credenciales de él puede permitir a un atacante pasar de **pipeline execution** a **ecosystem-wide code execution** al backdoorear dependencies o tooling de release:
+
+- **Install-time code execution via package hooks**: publicar una versión de paquete que añada `preinstall`, `postinstall`, `prepare`, u hooks similares para que el payload se ejecute automáticamente en las workstations de los desarrolladores y en los CI runners durante la instalación de dependencias.
+- **Secondary execution paths**: incluso si los targets instalan con `--ignore-scripts`, un paquete malicioso todavía puede registrar un **common CLI name** en el campo `bin` para que el wrapper controlado por el atacante se enlace mediante symlink dentro de `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 el payload principal con él, evitando requisitos de 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, busca 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/`, dispararlo, recoger los artifacts/logs producidos y luego borrar la branch/workflow run temporal para reducir trazas.
+- **Wormable registry propagation**: los tokens robados de npm deben validarse para permisos de **publish** y comprobar si bypassan 2FA. Si lo hacen, enumera los packages escribibles, descarga sus tarballs, inyecta un loader como `setup.mjs`, establece `preinstall` para ejecutarlo, incrementa la versión patch y republícalos. Esto convierte un compromiso de CI en auto-ejecución downstream en otros entornos.
+
+#### Practical checks during an assessment
+
+- Revisa la automatización de release en busca de hooks del package-manager añadidos a `package.json`, entradas `bin` inesperadas o bumps 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 workflow files o crear branches/tags.
+- Si se sospecha de un paquete comprometido, inspecciona el tarball publicado y no solo el Git repository, porque el loader/runtime malicioso puede existir solo en el published artifact.
+- Busca ejecución inesperada de package-manager dentro de CI como `npm install` en lugar de `npm ci`, descargas/ejecución inesperadas de Bun, o nuevos workflow artifacts generados desde transient branches.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/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**](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.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) es una herramienta open-source para auditar tu software supply chain stack en busca de compliance de seguridad basada en un nuevo [**CIS Software Supply Chain benchmark**](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 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/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Consulta este artículo interesante sobre los top 10 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/)
 
 ### Labs
 
-- En cada plataforma que puedas ejecutar localmente encontrarás cómo lanzarla localmente para que la configures como quieras y probarla
+- En cada plataforma que puedas ejecutar localmente encontrarás cómo lanzarla localmente para que puedas configurarla como quieras para probarla
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** es una herramienta de análisis estático para infrastructure-as-code.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** es una herramienta de static code analysis para infrastructure-as-code.
 
 ## References
 
 - [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)
+- [The npm Threat Landscape: Attack Surface and Mitigations](https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/)
+- [Checkmarx Security Update: April 22, 2026](https://checkmarx.com/blog/checkmarx-security-update-april-22/?p=108469)
 
 
 {{#include ../banners/hacktricks-training.md}}