Token Permissions
ID |
token_permissions |
Severity |
critical |
Family |
CI/ CD tools |
Tags |
cicd-sec-06, cicd-security, infrastructure, reachable, security, supply-chain |
Description
Does the project declare tokens in CI/CD as read-only?
This check determines whether the project automated workflows' tokens are set to read-only by default. Excessive permissions may be abused by adversaries to perform unintended operations on the CI/CD system leveraging such excess privileges.
Security
Setting token permissions to read-only follows the principle of least privilege. This is important because attackers may use a compromised token with write access to push malicious code into the project.
Azure Devops
If the build service account has write permission, then pipelines may perform unintended changes; this is a potential security misconfiguration to check. See Manage build service account p0ermissions for full details.
The detector checks if the Build Service account has write permission at project level or at any project repository.
GitHub
For assessing GITHUB_TOKEN permissions, the detector computes a compliance level according to the write permissions granted in the permissions key in the workflow’s file.
The highest compliance level is awarded when the permissions definitions in each workflow file are set as read-only at the top level and the required write permissions are declared at the run-level.
One point is reduced from the level if all jobs define permissions but no top level permissions are present. This configuration is secure, but there is a chance that when a new job is added to the workflow, its job permissions could be left undefined because of human error.
Additionally, points are reduced if certain write permissions are defined for a job.
GitHub workflow handle several types of permissions with different weights in compliance level.
Write permissions causing a small reduction to compliance level:
-
statuses- May allow an attacker to change the result of pre-submit checks and get a PR merged. -
checks- May allow an attacker to remove pre-submit checks and introduce a bug. -
security-events- May allow an attacker to read vulnerability reports before a patch is available. However, points are not reduced if the job utilizes a recognized action for uploading SARIF results. -
deployments- May allow an attacker to charge repo owners by triggering VM runs, and a tiny chance an attacker can trigger a remote service with code they own if the server accepts code/location variables unsanitized.
Write permissions causing a large reduction to compliance level:
-
contents- Allows an attacker to commit unreviewed code. However, points are not reduced if the job utilizes a recognized packaging action or command. -
packages- Allows an attacker to publish packages. However, points are not reduced if the job utilizes a recognized packaging action or command. -
actions- May allow an attacker to steal GitHub secrets by approving to run an action that needs approval.
GitLab
There is an ephemeral token created by GitLab for running each job, which is injected as the CI_JOB_TOKEN predefined variable. The token is valid only while the pipeline job runs. After the job finishes, you cannot use the token anymore.
The CI_REGISTRY_TOKEN is an alias used for access to GitLab registry.
|
The token has the same permissions to access the API as the user that caused the job to run. A user can cause a job to run by taking action like pushing a commit, triggering a manual job, or being the owner of a scheduled pipeline. Therefore, this user must be assigned to a role that has the required privileges.
A job token can access a project’s resources without any configuration, but it might give extra permissions that are not necessary.
GitLab documentation says in Disable the job token scope allowlist:
It is a security risk to disable the allowlist. A malicious user could try to compromise a pipeline created in an unauthorized project. If the pipeline was created by one of your maintainers, the job token could be used in an attempt to access your project.
Besides the CI_JOB_TOKEN, access tokens (personal or at project/group scopes) can be passed as variables to GitLab jobs. Access tokens used in CI/CD should have the minimal privileges('scopes' in GitLab terms) required for the job operation. There are divided into 'read' scopes (read_user, read_api, read_repository, read_registry, create_runner) and 'write' scopes (api, write_repository, write_registry, sudo, admin_mode). See access token scopes for full details.
The detector tries to identify which variables are referenced in CI/CD jobs. The detector will report a misconfiguration for each access token with excessive write scopes that is referenced in a CI/CD job.
| As it is impossible for the detector to know with 100% certainty if an access token was referenced by using the GitLab api, it assumes that variable and access token name match. |
Mitigation / Fix
Azure Devops
Set Administer build permissions as Not set or Deny for Build Service user as described in Set pipeline permissions.
GitHub
Set permissions as read-all or contents: read as described in GitHub documentation.
To help determine the permissions needed for project workflows, the StepSecurity online tool could be used, by ticking on "Restrict permissions for GITHUB_TOKEN". You may also tick on "Pin actions to a full length commit SHA" to fix issues found by the Pinned-dependencies check.