CircleCI Security
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
CircleCI es una plataforma de Integración Continua donde puedes definir plantillas indicando lo que quieres que haga con algún código y cuándo hacerlo. De esta manera, puedes automatizar pruebas o despliegues directamente desde la rama principal de tu repositorio, por ejemplo.
CircleCI hereda los permisos de github y bitbucket relacionados con la cuenta que inicia sesión. En mis pruebas verifiqué que mientras tengas permisos de escritura sobre el repositorio en github, podrás gestionar la configuración del proyecto en CircleCI (configurar nuevas claves ssh, obtener claves api del proyecto, crear nuevas ramas con nuevas configuraciones de CircleCI...).
Sin embargo, necesitas ser un administrador del repositorio para convertir el repositorio en un proyecto de CircleCI.
Según la documentación hay diferentes maneras de cargar valores en variables de entorno dentro de un flujo de trabajo.
Cada contenedor ejecutado por CircleCI siempre tendrá variables de entorno específicas definidas en la documentación como CIRCLE_PR_USERNAME, CIRCLE_PROJECT_REPONAME o CIRCLE_USERNAME.
Puedes declararlas en texto claro dentro de un comando:
Puedes declararlos en texto claro dentro del entorno de ejecución:
Puedes declararlos en texto claro dentro del entorno de build-job:
Puedes declararlos en texto claro dentro del entorno de un contenedor:
Estos son secretos que solo van a ser accesibles por el proyecto (por cualquier rama). Puedes verlos declarados en https://app.circleci.com/settings/project/github/<org_name>/<repo_name>/environment-variables
La funcionalidad de "Importar Variables" permite importar variables de otros proyectos a este.
Estos son secretos que son a nivel de organización. Por defecto, cualquier repositorio podrá acceder a cualquier secreto almacenado aquí:
Sin embargo, ten en cuenta que se puede seleccionar un grupo diferente (en lugar de Todos los miembros) para dar acceso a los secretos solo a personas específicas. Esta es actualmente una de las mejores maneras de aumentar la seguridad de los secretos, para no permitir que todos accedan a ellos, sino solo algunas personas.
Si tienes acceso al VCS (como github), revisa el archivo .circleci/config.yml de cada repositorio en cada rama y busca posibles secretos en texto claro almacenados allí.
Revisando el código puedes encontrar todos los nombres de los secretos que están siendo utilizados en cada archivo .circleci/config.yml. También puedes obtener los nombres de contexto de esos archivos o revisarlos en la consola web: https://app.circleci.com/settings/organization/github/<org_name>/contexts.
Para exfiltrar TODOS los SECRETOS del proyecto y contexto, solo necesitas tener acceso de ESCRITURA a solo 1 repositorio en toda la organización de github (y tu cuenta debe tener acceso a los contextos, pero por defecto todos pueden acceder a cada contexto).
La funcionalidad de "Importar Variables" permite importar variables de otros proyectos a este. Por lo tanto, un atacante podría importar todas las variables del proyecto de todos los repositorios y luego exfiltrar todas juntas.
Todos los secretos del proyecto siempre se establecen en el entorno de los trabajos, por lo que solo llamar a env y ofuscarlo en base64 exfiltrará los secretos en la consola de registro web de los flujos de trabajo:
Si no tienes acceso a la consola web pero tienes acceso al repositorio y sabes que se utiliza CircleCI, puedes crear un flujo de trabajo que se dispare cada minuto y que exfiltre los secretos a una dirección externa:
Necesitas especificar el nombre del contexto (esto también exfiltrará los secretos del proyecto):
Si no tienes acceso a la consola web pero tienes acceso al repositorio y sabes que se utiliza CircleCI, puedes modificar un flujo de trabajo que se activa cada minuto y que exfiltra los secretos a una dirección externa:
Crear un nuevo .circleci/config.yml en un repositorio no es suficiente para activar una construcción de circleci. Necesitas habilitarlo como un proyecto en la consola de circleci.
CircleCI te da la opción de ejecutar tus construcciones en sus máquinas o en las tuyas. Por defecto, sus máquinas están ubicadas en GCP, y al principio no podrás encontrar nada relevante. Sin embargo, si una víctima está ejecutando las tareas en sus propias máquinas (potencialmente, en un entorno en la nube), podrías encontrar un punto final de metadatos en la nube con información interesante.
Ten en cuenta que en los ejemplos anteriores se lanzó todo dentro de un contenedor de docker, pero también puedes pedir que se lance una máquina VM (que puede tener diferentes permisos en la nube):
O incluso un contenedor de docker con acceso a un servicio de docker remoto:
Es posible crear tokens de usuario en CircleCI para acceder a los endpoints de la API con el acceso del usuario.
https://app.circleci.com/settings/user/tokens
Es posible crear tokens de proyectos para acceder al proyecto con los permisos otorgados al token.
https://app.circleci.com/settings/project/github/<org>/<repo>/api
Es posible agregar claves SSH a los proyectos.
https://app.circleci.com/settings/project/github/<org>/<repo>/ssh
Es posible crear un trabajo cron en una rama oculta en un proyecto inesperado que está filtrando todas las variables de contexto env todos los días.
O incluso crear en una rama / modificar un trabajo conocido que filtrará todo el contexto y los secretos de los proyectos todos los días.
Si eres un propietario de github, puedes permitir orbs no verificados y configurar uno en un trabajo como puerta trasera.
Puedes encontrar una vulnerabilidad de inyección de comandos en alguna tarea e inyectar comandos a través de un secreto modificando su valor.
