Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
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 nube (ofrecen sus propias plataformas VCS)
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.
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 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).
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.
El camino 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 no ser parte de la organización) porque pueden enviar un PR.
Inyección de Comandos 3PE: Generalmente, los pipelines 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í.
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.
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. 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.
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/
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
Checkov: Checkov es una herramienta de análisis de código estático para infraestructura como código.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
