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 generalmente encontrarás empresas usándolo en una de las siguientes plataformas:
Github
Gitlab
Bitbucket
Gitea
Proveedores de 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 ocurren ciertas acciones: Un push, un PR, cron... Son muy ú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 generalmente con credenciales privilegiadas para desplegar código.
Metodología de Pentesting VCS
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:
Filtraciones: Si tu código contiene filtraciones en los commits y el atacante puede acceder al repo (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 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 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 ocurre 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 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:
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 el pipeline (ver la siguiente sección).
Metodología de Pentesting de Pipelines
La forma más común de definir un pipeline es mediante un archivo de configuración CI alojado en el repositorio que construye el pipeline. 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 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 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 - Ejecución de Pipeline Envenenado
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 una solicitud de extracción. (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 repo (y que pueden 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 se usa 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 generalmente se otorgan 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 del pipeline, el atacante podría necesitar especificar los secretos en la configuración. Esto significa que si el atacante no puede modificar el pipeline de configuración 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.
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 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 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.
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/
Laboratorios
En cada plataforma que puedes ejecutar localmente encontrarás cómo lanzarla localmente para que puedas configurarla como desees para probarla.
Laboratorio 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
Last updated
