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 is a Continuos Integration platform where you can define templates indicating what you want it to do with some code and when to do it. This way you can automate testing or deployments directly from your repo master branch for example.
CircleCI inherits the permissions from github and bitbucket related to the account that logs in. In my testing I checked that as long as you have write permissions over the repo in github, you are going to be able to manage its project settings in CircleCI (set new ssh keys, get project api keys, create new branches with new CircleCI configs...).
However, you need to be a a repo admin in order to convert the repo into a CircleCI project.
According to the docs there are different ways to load values in environment variables inside a workflow.
Every container run by CircleCI will always have specific env vars defined in the documentation like CIRCLE_PR_USERNAME, CIRCLE_PROJECT_REPONAME or CIRCLE_USERNAME.
You can declare them in clear text inside a command:
You can declare them in clear text inside the run environment:
You can declare them in clear text inside the build-job environment:
You can declare them in clear text inside the environment of a container:
These are secrets that are only going to be accessible by the project (by any branch). You can see them declared in https://app.circleci.com/settings/project/github/<org_name>/<repo_name>/environment-variables
The "Import Variables" functionality allows to import variables from other projects to this one.
These are secrets that are org wide. By default any repo is going to be able to access any secret stored here:
However, note that a different group (instead of All members) can be selected to only give access to the secrets to specific people. This is currently one of the best ways to increase the security of the secrets, to not allow everybody to access them but just some people.
If you have access to the VCS (like github) check the file .circleci/config.yml of each repo on each branch and search for potential clear text secrets stored in there.
Checking the code you can find all the secrets names that are being used in each .circleci/config.yml file. You can also get the context names from those files or check them in the web console: https://app.circleci.com/settings/organization/github/<org_name>/contexts.
In order to exfiltrate ALL the project and context SECRETS you just need to have WRITE access to just 1 repo in the whole github org (and your account must have access to the contexts but by default everyone can access every context).
The "Import Variables" functionality allows to import variables from other projects to this one. Therefore, an attacker could import all the project variables from all the repos and then exfiltrate all of them together.
All the project secrets always are set in the env of the jobs, so just calling env and obfuscating it in base64 will exfiltrate the secrets in the workflows web log console:
If you don't have access to the web console but you have access to the repo and you know that CircleCI is used, you can just create a workflow that is triggered every minute and that exfils the secrets to an external address:
You need to specify the context name (this will also exfiltrate the project secrets):
If you don't have access to the web console but you have access to the repo and you know that CircleCI is used, you can just modify a workflow that is triggered every minute and that exfils the secrets to an external address:
Just creating a new .circleci/config.yml in a repo isn't enough to trigger a circleci build. You need to enable it as a project in the circleci console.
CircleCI gives you the option to run your builds in their machines or in your own. By default their machines are located in GCP, and you initially won't be able to fid anything relevant. However, if a victim is running the tasks in their own machines (potentially, in a cloud env), you might find a cloud metadata endpoint with interesting information on it.
Notice that in the previous examples it was launched everything inside a docker container, but you can also ask to launch a VM machine (which may have different cloud permissions):
Or even a docker container with access to a remote docker service:
It's possible to create user tokens in CircleCI to access the API endpoints with the users access.
https://app.circleci.com/settings/user/tokens
It's possible to create projects tokens to access the project with the permissions given to the token.
https://app.circleci.com/settings/project/github/<org>/<repo>/api
It's possible to add SSH keys to the projects.
https://app.circleci.com/settings/project/github/<org>/<repo>/ssh
It's possible to create a cron job in hidden branch in an unexpected project that is leaking all the context env vars everyday.
Or even create in a branch / modify a known job that will leak all context and projects secrets everyday.
If you are a github owner you can allow unverified orbs and configure one in a job as backdoor
You can find a command injection vulnerability in some task and inject commands via a secret modifying its value
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
