Vulnerabilidades en Pipelines

En la última década se ha hablado mucho de las metodologías DevSecOps, y cómo estos procesos automatizados pueden ir aplicando una sanitización a toda la infraestructura de nuestras aplicaciones. Este punto de interés ha hecho evolucionar la forma en la que analizamos los sistemas. Se dejó de visualizar y auditar las aplicaciones desde el último punto (cuando se encuentra en producción) hacia atrás, cambiándolo por un enfoque dinámico e interactivo que acompaña al clásico ciclo de desarrollo seguro del software desde el inicio.

Está claro que este cambio de perspectiva ayuda mucho a la forma en la que encaramos los proyectos y la arquitectura de las aplicaciones, como consecuencia de ello cada desarrollo es cada vez más robustos en términos de seguridad. Ahora los analistas de seguridad acceden a la información a tiempo y pueden generar alertas tempranas para evitar tener que asumir un costo mayor a la hora de subsanar una vulnerabilidad durante el ciclo de desarrollo.

Ahora si bien las aplicaciones resultan más robustas, los atacantes se ven obligados a planificar nuevos vectores de ataque asociados a los nuevos recursos, estos recursos están asociados a la forma en la que automatizamos las tareas de protección y a la arquitectura que utilizamos para diseñar nuestro enfoque DevSecOps, entre ellos uno de los puntos más importantes son los Pipelines.

Un Pipeline

Un pipeline es un conjunto de procesos y herramientas utilizados para recopilar datos en bruto de múltiples fuentes, analizarlos y presentar los resultados en un formato comprensible, esto en un flujo de DevSecOps es crucial ya que está asociado al proceso de análisis y mejora continua relacionado puntualmente con el código. Cabe destacar que no solo se usa para los flujos de desarrollo seguro, sino que se utiliza en amplios rubros relacionados con el análisis de datos.

Los pipelines son herramientas muy potentes y útiles, por lo que el procesamiento de esa información o la manipulación de esa información suele ser de gran interés para los atacantes.

Pipeline CI/CD
(Continuous Integration/Continuous Development)

Un Pipeline de CI / CD es el componente fundamental del desarrollo de software automatizado. Si bien el término se ha utilizado para describir muchos aspectos diferentes de la informática, en gran parte de la industria de DevOps, usamos “Pipelines” para ilustrar las amplias aplicaciones de comportamientos y procesos involucrados en la integración continua (CI).

Dentro de estas funcionalidades nuevas encontramos las siguientes potenciales vulnerabilidades que podrían estar afectando ahora mismo los pipelines que se desplieguen de forma desatendida.

Broken Authentication en CI/CD

Los descuidos respecto del diseño de la autorización y autenticación de los canales de CI y CD pueden ocurrir en el momento en donde se diseña el esquema de roles y permisos, algunos de los siguientes ejemplos se pueden evitar teniendo el adecuado proceso que valide todas estas configuraciones. Entre todos los métodos podemos encontrar los siguientes;

 • Agregar aprobador no autorizado utilizando permisos de admin;
 • En este escenario, un atacante con permisos de administrador en el canal de integración continua (CI) agrega a un usuario no autorizado como aprobador, posiblemente eludiendo las comprobaciones de seguridad necesarias.
Ej: ci-tool add-approver --pipeline pipeline-name --user unauthorized-user

 • Autenticación Débil:
 • En este escenario, un atacante aprovecha los mecanismos de autenticación débiles para obtener acceso de administrador a la herramienta de integración continua (CI) y manipular la configuración de los aprobadores, realizando por ejemplo un ataque de fuerza bruta.
Ej :ci-tool login --username admin --password weakpassword

 • Manipulación de Token:
Ej: ci-tool --api-token stolen-token add-approver --pipeline pipeline-name --user unauthorized-user

Mal manejo de Secretos

Los pipelines se conectan constantemente a recursos asociados a otras aplicaciones, servicios o en su defecto credenciales particulares asociadas a recursos productivos importantes. Tener un correcto manejo de secretos es esencial para evitar las cuestiones enumeradas a continuación:

 • Incorrecta autorización de repositorios:
 • En este escenario, un atacante obtiene acceso a un pipeline CI/CD que interactúa con un gestor de secretos y se aprovecha de permisos débiles para recuperar credenciales sensibles.
Ej: ci-tool get-secrets --repository malicious-repo --secret-manager secretmanager-nam

 • Inyección de código:
 • El atacante envía un código malicioso manipulado hacia un repositorio legítimo, que cuando es ejecutado en el pipeline, captura secretos o se aprovecha de ellos para poder realizar acciones no autorizadas.
Ej: echo "echo $SECRET_VARIABLE" >> main.py

 • Obtener credenciales de la consola de admin de CI/CD:
 • Recuperar el acceso a AWS y secret keys desde una consola de admin CI/CD para luego pasarlas como variables de entorno:
Ej: export AWS_ACCESS_KEY_ID=$(aws ssm get-parameter --name /path/to/access_key - -with-decryption --query Parameter.Value --output text) export AWS_SECRET_ACCESS_KEY=$(aws ssm get-parameter --name /path/to/secret_key --with-decryption --query Parameter.Value --output text) pipeline-stage-command

 • Recuperar un secreto de Hashicorp Vault y pasarlo como una variable al stage del pipeline:
Ej: export SECRET=$(vault kv get -format=json secret/path/to/secret | jq -r '.data.key') pipeline-stage-command

 • Recuperar un secreto de Kubernetes desde la consola de admin y hacerlo pasar como un volumen montado en la etapa del pipeline;
Ej: kubectl create secret generic my-secret --from-literal=username=<username> -- from-literal=password=<password>
kubectl create volume secret my-secret-volume --secret=my-secret pipeline-stage-command --volume=my-secret-volume:/secrets

Entorno de producción expuesto por mala configuración

La misma historia que ocurre en las aplicaciones que estos pipeline verifican. Por lo general asociada a un arrastre de error o un equivocado enfoque en la sensación de seguridad aplicada a la configuración de los pipelines CI/CD.

 • Variables de entorno mal configuradas:
 • Este ejemplo procede de la identificación de variables mal configuradas y el aprovechamiento de estas variables con el fin de ganar acceso no autorizado a distintos recursos.
Ej: ci-tool get-secrets --repository legitimate-repo --secret-manager $MISCONFIGURED_VARIABLE

 • Modificación de una configuración no autorizada:
 • En este escenario el ataque puede ganar acceso al pipeline y modificar la configuración del ambiente de producción.
Ej: # Modify the production environment configuration file echo "MALICIOUS_SETTING = True" >> production.config

 • Scripts mal configurados:
 • El atacante puede identificar el desarrollo de un script mal configurado y aprovecharse del mismo para modificar el ambiente de producción.
Ej: # Exploit misconfigured deployment script to modify production configuration ci-tool run-deployment-script --script "sed -i 's/ALLOW_PUBLIC_ACCESS = False/ALLOW_PUBLIC_ACCESS = True/' production.config"

 • Administrador de configuraciones inseguro:
 • A continuación podemos visualizar un ejemplo de código en donde podemos encontrar esta falla. En el ejemplo que se muestra en la siguiente captura, la función deploy es parte de un script. El parámetro repo_url pretende ser un repositorio de git válido. Sin embargo debido a una impropia validación de la entrada un atacante podría inyectar comandos arbitrarios adicionándolos al parametro repo_url. En este caso el atacante puede agregar el comando (rm -rf /) para borrar el filesystem entero.

Código:

Potencial repositorio malicioso:

 • Almacenamiento de credenciales inseguro::
 • En el ejemplo mostrado en la captura, la función list_buckets utiliza el SDK de AWS para interactuar con Amazon S3. El código depende del comportamiento predeterminado de búsqueda de credenciales del SDK, que verifica varios archivos de configuración en busca de las credenciales de AWS. Sin embargo, el pipeline tiene una falla de seguridad en la que las credenciales de AWS se almacenan de manera insegura. Un atacante puede ejecutar un comando (cat ~/.aws/credentials) para recuperar las credenciales de AWS y potencialmente obtener acceso no autorizado a los recursos de AWS.

Todos estos puntos son importantes para poder evitar el efecto conocido como “snowball”, en donde el arrastre del error, ocurre a lo largo de todas las cadenas de desarrollo implementadas dentro de nuestro CI/CD. Es por eso que atacar estos errores de raíz suele ser una gran utilidad para tener un problema mayor a futuro.

Herramientas que nos pueden ayudar

Como veremos a continuación el uso de componentes externos sigue dando dolores de cabeza en el caso de que no tengan los mismos una respectiva validación.

 • Trufflehog:
 • TruffleHog, es un escáner de datos sensible para repositorios Git. Escanea la URL del repositorio Git especificado (https://example.com/git-repo.git) utilizando coincidencia de patrones de expresiones regulares y análisis de entropía para identificar información potencialmente sensible, como claves API, contraseñas y otros secretos almacenados en el repositorio.

 • Circleci:
 • Este comando utiliza la herramienta CLI de CircleCI para simular la ejecución de un archivo de configuración de CircleCI (config.yml) de manera local. Empaqueta el archivo de configuración utilizando "circleci config pack" y luego ejecuta el archivo de configuración empaquetado utilizando "circleci local execute". Esto puede ayudar a identificar configuraciones incorrectas, vulnerabilidades o prácticas inseguras dentro de la canalización de CI/CD definida en el archivo de configuración de CircleCI.
Ej: docker run -v $(pwd):/src -w /src -t circleci/circleci-cli:latest circleci config pack .circleci > config.yml && circleci local execute -c config.yml

 • Snyk:
 • Es una popular herramienta de escaneo de seguridad, para probar todos los proyectos y subproyectos en el directorio actual. Snyk escanea el código fuente y sus dependencias, verificando vulnerabilidades conocidas, prácticas de codificación inseguras y otros problemas de seguridad. Esto ayuda a identificar y abordar debilidades de seguridad introducidas por prácticas de codificación inseguras.
Ej: snyk test --all-projects --all-sub-projects

 • npm:
 • El comando npm audit , está integrado en el Administrador de Paquetes de Node (npm), para llevar a cabo una auditoría de seguridad de las dependencias en un proyecto Node.js. Este comando comprueba las dependencias del proyecto en la Base de Datos Nacional de Vulnerabilidades (NVD) y genera un informe que destaca cualquier vulnerabilidad conocida y prácticas de codificación inseguras. Esto ayuda a identificar y abordar problemas de seguridad introducidos por dependencias implementadas de manera insegura o desactualizadas.

 • Análisis de dependencias de terceros:
 • OWASP Dependency - Check, una herramienta ampliamente utilizada para identificar vulnerabilidades conocidas en las dependencias del proyecto. Escanea el proyecto ubicado en <ruta al proyecto>, analiza las dependencias generando un informe de HTML (--format HTML) que destaca cualquier dependencia insegura y/o componentes vulnerables.
Ej: OWASP-Dependency-Check --scan <path-to-project> --format HTML

Conclusión

Tal como identificamos en este post hemos repasado varios puntos interesantes a la hora de comprender que si implementamos mecanismos automatizados en pos de mejorar la seguridad de nuestras aplicaciones, esto no significa que debamos prestar menos atención a la forma en la que diseñamos nuestro flujo de automatización. La atención a la seguridad tiene que permanecer constante en todos los aspectos de nuestra arquitectura y tiene que ser mejorada con la misma frecuencia y atención que todos nuestros activos.