CircleCI Security
Last updated
Last updated
Apprenez et pratiquez le Hacking AWS :HackTricks Formation AWS Red Team Expert (ARTE) Apprenez et pratiquez le Hacking GCP : HackTricks Formation GCP Red Team Expert (GRTE)
CircleCI est une plateforme d'Intégration Continue où vous pouvez définir des modèles indiquant ce que vous voulez qu'elle fasse avec du code et quand le faire. De cette manière, vous pouvez automatiser les tests ou les déploiements directement depuis la branche principale de votre dépôt, par exemple.
CircleCI hérite des permissions de github et bitbucket liées au compte qui se connecte. Lors de mes tests, j'ai vérifié que tant que vous avez des permissions d'écriture sur le dépôt dans github, vous pourrez gérer ses paramètres de projet dans CircleCI (définir de nouvelles clés ssh, obtenir des clés api de projet, créer de nouvelles branches avec de nouvelles configurations CircleCI...).
Cependant, vous devez être un administrateur de dépôt pour convertir le dépôt en projet CircleCI.
Selon la documentation, il existe différentes manières de charger des valeurs dans des variables d'environnement à l'intérieur d'un workflow.
Chaque conteneur exécuté par CircleCI aura toujours des variables d'environnement spécifiques définies dans la documentation comme CIRCLE_PR_USERNAME, CIRCLE_PROJECT_REPONAME ou CIRCLE_USERNAME.
Vous pouvez les déclarer en texte clair à l'intérieur d'une commande :
Vous pouvez les déclarer en texte clair à l'intérieur de l'environnement d'exécution :
Vous pouvez les déclarer en texte clair à l'intérieur de l'environnement de build-job :
Vous pouvez les déclarer en texte clair à l'intérieur de l'environnement d'un conteneur :
Ce sont des secrets qui ne seront accessibles que par le projet (par n'importe quelle branche). Vous pouvez les voir déclarés dans https://app.circleci.com/settings/project/github/<org_name>/<repo_name>/environment-variables
La fonctionnalité "Importer des Variables" permet d'importer des variables d'autres projets vers celui-ci.
Ce sont des secrets qui sont à l'échelle de l'organisation. Par défaut, n'importe quel repo pourra accéder à n'importe quel secret stocké ici :
Cependant, notez qu'un groupe différent (au lieu de Tous les membres) peut être sélectionné pour donner accès aux secrets à des personnes spécifiques. C'est actuellement l'un des meilleurs moyens d'augmenter la sécurité des secrets, en ne permettant pas à tout le monde d'y accéder mais seulement à certaines personnes.
Si vous avez accès au VCS (comme github), vérifiez le fichier .circleci/config.yml de chaque repo sur chaque branche et recherchez des secrets en texte clair potentiels stockés là.
En vérifiant le code, vous pouvez trouver tous les noms de secrets qui sont utilisés dans chaque fichier .circleci/config.yml. Vous pouvez également obtenir les noms de contexte à partir de ces fichiers ou les vérifier dans la console web : https://app.circleci.com/settings/organization/github/<org_name>/contexts.
Pour exfiltrer TOUS les SECRETS de projet et de contexte, vous devez juste avoir un accès ÉCRIT à juste 1 repo dans toute l'organisation github (et votre compte doit avoir accès aux contextes mais par défaut, tout le monde peut accéder à chaque contexte).
La fonctionnalité "Importer des Variables" permet d'importer des variables d'autres projets vers celui-ci. Par conséquent, un attaquant pourrait importer toutes les variables de projet de tous les repos et ensuite exfiltrer toutes ensemble.
Tous les secrets de projet sont toujours définis dans l'environnement des jobs, donc il suffit d'appeler env et de l'obfusquer en base64 pour exfiltrer les secrets dans la console de log web des workflows :
Si vous n'avez pas accès à la console web mais que vous avez accès au dépôt et que vous savez que CircleCI est utilisé, vous pouvez simplement créer un workflow qui est déclenché toutes les minutes et qui exfiltre les secrets vers une adresse externe :
Vous devez spécifier le nom du contexte (cela exfiltrera également les secrets du projet) :
Si vous n'avez pas accès à la console web mais que vous avez accès au dépôt et que vous savez que CircleCI est utilisé, vous pouvez simplement modifier un workflow qui est déclenché toutes les minutes et qui exfiltre les secrets vers une adresse externe :
Créer simplement un nouveau .circleci/config.yml dans un dépôt ne suffit pas à déclencher une build circleci. Vous devez l'activer en tant que projet dans la console circleci.
CircleCI vous offre la possibilité d'exécuter vos builds sur leurs machines ou sur les vôtres. Par défaut, leurs machines sont situées dans GCP, et vous ne pourrez initialement rien trouver de pertinent. Cependant, si une victime exécute les tâches sur ses propres machines (potentiellement, dans un environnement cloud), vous pourriez trouver un point de terminaison de métadonnées cloud avec des informations intéressantes.
Remarquez que dans les exemples précédents, tout était lancé à l'intérieur d'un conteneur docker, mais vous pouvez également demander à lancer une machine VM (qui peut avoir des autorisations cloud différentes) :
Ou même un conteneur docker avec accès à un service docker distant :
Il est possible de créer des tokens utilisateur dans CircleCI pour accéder aux points de terminaison de l'API avec les accès des utilisateurs.
https://app.circleci.com/settings/user/tokens
Il est possible de créer des tokens de projet pour accéder au projet avec les permissions données au token.
https://app.circleci.com/settings/project/github/<org>/<repo>/api
Il est possible d'ajouter des clés SSH aux projets.
https://app.circleci.com/settings/project/github/<org>/<repo>/ssh
Il est possible de créer un cron job dans une branche cachée dans un projet inattendu qui fuit toutes les variables d'environnement contextuelles chaque jour.
Ou même de créer dans une branche / modifier un job connu qui fuit tous les contextes et les secrets des projets chaque jour.
Si vous êtes propriétaire d'un github, vous pouvez autoriser des orbes non vérifiés et en configurer un dans un job comme porte dérobée.
Vous pouvez trouver une vulnérabilité d'injection de commande dans certaines tâches et injecter des commandes via un secret en modifiant sa valeur.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
