Pentesting CI/CD Methodology
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 normalmente encontrarás empresas que lo utilizan en una de las siguientes plataformas:
Github
Gitlab
Bitbucket
Gitea
Proveedores de la nube (ofrecen sus propias plataformas VCS)
Pipelines
Los pipelines permiten a los desarrolladores automatizar la ejecución de código (para construir, probar, desplegar... propósitos) después de que ciertas acciones ocurren: Un push, un PR, cron... Son extremadamente útiles para automatizar todos los pasos desde el desarrollo hasta la producción.
Sin embargo, estos sistemas necesitan ser ejecutados en algún lugar y usualmente con credenciales privilegiadas para desplegar código.
Metodología de Pentesting de VCS
Aunque algunas plataformas VCS permiten crear pipelines, en esta sección vamos a analizar solo ataques potenciales al control del código fuente.
Las plataformas que contienen el código fuente de tu proyecto contienen información sensible y es necesario 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 repositorio (porque es público o porque tiene acceso), podría descubrir los leaks.
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 simplemente permiten a usuarios externos crear una cuenta.
SSO: Algunas plataformas no permiten a los usuarios registrarse, pero permiten a cualquiera acceder con un SSO válido (así que un atacante podría usar su cuenta de github para entrar, por ejemplo).
Credenciales: Nombre de usuario+Contraseña, tokens personales, llaves 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 un secreto en su lugar, 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 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 burlar las protecciones de rama. Estas acciones pueden realizarse con diferentes objetivos en mente:
Comprometer la rama principal para comprometer la producción.
Comprometer la rama principal (u otras ramas) para comprometer las máquinas de los desarrolladores (ya que suelen ejecutar 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 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 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
El camino de Ejecución de Pipeline Envenenado (PPE) explota los 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 normalmente los pipelines se activan cuando se realiza un push o un pull request. (Revisa la metodología de pentesting de VCS para un resumen de formas de obtener acceso).
Nota que a veces un PR externo cuenta como "acceso de escritura".
Incluso si tiene permisos de escritura, necesita estar seguro de que puede modificar el archivo de configuración CI u otros archivos en los que se basa la configuración.
Para esto, podría necesitar ser capaz de burlar las protecciones de rama.
Hay 3 sabores de PPE:
D-PPE: Un ataque PPE Directo ocurre cuando el actor modifica el archivo de configuración CI que va a ser ejecutado.
I-DDE: Un ataque PPE Indirecto ocurre cuando el actor modifica un archivo en el que se basa el archivo de configuración CI que va a ser ejecutado (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 quizás ni siquiera sean parte de la organización) porque pueden enviar un PR.
Inyección de Comandos 3PE: Normalmente, los pipelines CI/CD establecerá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 se utiliza 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 suelen ser otorgados en secretos. Estos secretos suelen ser 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 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 ese pipeline tiene.
Computación: 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 lejos.
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.
Cloud: El atacante podría acceder a otras máquinas en la nube pero también podría exfiltrar tokens de roles/servicios de IAM desde 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 suelen estar 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 reverso en cada máquina posible para intentar explotarla más.
Comprometer la 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 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 Cadena de Suministro de Software CIS. La auditoría se centra en todo el proceso de SDLC, donde puede revelar riesgos desde el tiempo de código hasta el tiempo de despliegue.
Top 10 Riesgos de Seguridad CI/CD
Revisa este interesante artículo sobre los 10 principales riesgos de CI/CD según Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/
Laboratorios
En cada plataforma que puedas ejecutar localmente encontrarás cómo lanzarla localmente para que puedas configurarla como quieras para probarla
Laboratorio de Gitea + Jenkins: https://github.com/cider-security-research/cicd-goat
Herramientas Automáticas
Checkov: Checkov es una herramienta de análisis de código estático para infraestructura como código.
Referencias
Última actualización
