Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/

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

@@ -1,4 +1,4 @@
-# Pentesting CI/CD Methodology
+# Metodología de Pentesting CI/CD
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -12,92 +12,92 @@ VCS significa **Sistema de Control de Versiones**, estos sistemas permiten a los
 - Gitlab
 - Bitbucket
 - Gitea
-- Proveedores de nube (ofrecen sus propias plataformas VCS)
+- Proveedores de la nube (ofrecen sus propias plataformas VCS)
 
-## CI/CD Pipelines
+## Pipelines CI/CD
 
-Las pipelines de 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.
+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**.
 
-## VCS Pentesting Methodology
+## Metodología de Pentesting VCS
 
 > [!NOTE]
-> Incluso si algunas plataformas VCS permiten crear pipelines, en esta sección solo analizaremos los posibles ataques al control del código fuente.
+> 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:
 
-- **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 obtener **más visibilidad y permisos**.
-- **Register**: Algunas plataformas solo permitirán a los usuarios externos crear una cuenta.
+- **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).
-- **Credentials**: 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 repo.
+- **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.
-- **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, podría necesitar **eludir las protecciones de rama**. Estas acciones pueden realizarse con diferentes objetivos en mente:
+- **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 repo en sus máquinas).
-- **Comprometer la pipeline** (ver la siguiente secció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).
 
-## Pipelines Pentesting Methodology
+## Metodología de Pentesting de Pipelines
 
-La forma más común de definir una pipeline es utilizando un **archivo de configuración de CI alojado en el repositorio** que la 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 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 en .github/workflows. Cuando se activa, el trabajo de la pipeline **extrae el código** de la fuente seleccionada (por ejemplo, commit / rama), y **ejecuta los comandos especificados en el archivo de configuración de CI** contra ese código.
+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 - Poisoned Pipeline Execution
+### PPE - Ejecución de Pipeline Envenenado
 
-El camino de la Ejecución de Pipeline Envenenada (PPE) explota permisos en un repositorio SCM para manipular una pipeline de CI y ejecutar comandos dañinos. Los usuarios con los permisos necesarios pueden modificar archivos de configuración de CI u otros archivos utilizados por el trabajo de la pipeline para incluir comandos maliciosos. Esto "envenena" la pipeline de CI, llevando a la ejecución de estos comandos maliciosos.
+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 ser capaz de:
+Para que un actor malicioso tenga éxito realizando un ataque PPE, necesita poder:
 
-- Tener **acceso de escritura a la plataforma VCS**, ya que generalmente las 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).
+- 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 de CI u otros archivos de los que depende la configuración**.
-- Para esto, podría necesitar ser capaz de **eludir las protecciones de rama**.
+- 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 de CI** que va a ser ejecutado.
-- **I-DDE**: Un ataque **Indirecto PPE** ocurre cuando el actor **modifica** un **archivo** del que el archivo de configuración de CI que va a ser ejecutado **depende** (como un archivo make o una configuración de terraform).
-- **Public PPE o 3PE**: En algunos casos, las pipelines pueden ser **activadas por usuarios que no tienen acceso de escritura en el repo** (y que podrían no ser parte de la organización) porque pueden enviar un PR.
-- **3PE Command Injection**: Generalmente, las pipelines de CI/CD **configurarán 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 es **utilizado** en un **lugar peligroso** (como ejecutar **comandos sh**), un atacante podría **inyectar comandos allí**.
+- **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í**.
 
-### Exploitation Benefits
+### Beneficios de la Explotación
 
-Conociendo los 3 sabores para envenenar una pipeline, veamos qué podría obtener un atacante después de una explotación exitosa:
+Conociendo los 3 sabores para envenenar un pipeline, veamos qué podría obtener un atacante después de una explotación exitosa:
 
-- **Secrets**: Como se mencionó anteriormente, las 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 de la pipeline, el atacante **podría necesitar especificar los secretos en la configuración**. Esto significa que si el atacante no puede modificar la pipeline de configuración de CI (**I-PPE** por ejemplo), podría **solo exfiltrar los secretos que tiene esa 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 las pipelines se ejecutan en las instalaciones, 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 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**.
-- **Platforms machine**: 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**.
-- **Select it:** A veces la **plataforma de pipelines tendrá configuradas varias máquinas** y si puedes **modificar el archivo de configuración de 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.
-- **Compromise production**: Si estás dentro de la pipeline y la versión final se construye y despliega desde ella, podrías **comprometer el código que va a terminar ejecutándose en producción**.
+- **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**.
 
-## More relevant info
+## Más información relevante
 
-### Tools & CIS Benchmark
+### Herramientas y Benchmark CIS
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) es una herramienta de código abierto para auditar tu cadena de suministro de software para 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 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 CI/CD Security Risk
+### 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/)
 
-### Labs
+### Laboratorios
 
-- En cada plataforma que puedes ejecutar localmente encontrarás cómo lanzarla localmente para que puedas configurarla como desees para probarla.
+- 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)
 
-### Automatic Tools
+### 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.
 
-## References
+## 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)