Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
In this page you will find:
A summary of all the impacts of an attacker managing to access a Github Action
Different ways to get access to an action:
Having permissions to create the action
Abusing pull request related triggers
Abusing other external access techniques
Pivoting from an already compromised repo
Finally, a section about post-exploitation techniques to abuse an action from inside (cause the mentioned impacts)
For an introduction about Github Actions check the basic information.
If you can execute arbitrary code in GitHub Actions within a repository, you may be able to:
Steal secrets mounted to the pipeline and abuse the pipeline's privileges to gain unauthorized access to external platforms, such as AWS and GCP.
Compromise deployments and other artifacts.
If the pipeline deploys or stores assets, you could alter the final product, enabling a supply chain attack.
Execute code in custom workers to abuse computing power and pivot to other systems.
Overwrite repository code, depending on the permissions associated with the GITHUB_TOKEN.
This "secret" (coming from ${{ secrets.GITHUB_TOKEN }} and ${{ github.token }}) is given when the admin enables this option:
This token is the same one a Github Application will use, so it can access the same endpoints: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps
Github should release a flow that allows cross-repository access within GitHub, so a repo can access other internal repos using the GITHUB_TOKEN.
You can see the possible permissions of this token in: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token
Note that the token expires after the job has completed.
These tokens looks like this: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7
Some interesting things you can do with this token:
Note that in several occasions you will be able to find github user tokens inside Github Actions envs or in the secrets. These tokens may give you more privileges over the repository and organization.
It's possible to check the permissions given to a Github Token in other users repositories checking the logs of the actions:
This would be the easiest way to compromise Github actions, as this case suppose that you have access to create a new repo in the organization, or have write privileges over a repository.
If you are in this scenario you can just check the Post Exploitation techniques.
In case members of an organization can create new repos and you can execute github actions, you can create a new repo and steal the secrets set at organization level.
If you can create a new branch in a repository that already contains a Github Action configured, you can modify it, upload the content, and then execute that action from the new branch. This way you can exfiltrate repository and organization level secrets (but you need to know how they are called).
You can make the modified action executable manually, when a PR is created or when some code is pushed (depending on how noisy you want to be):
There are different triggers that could allow an attacker to execute a Github Action of another repository. If those triggerable actions are poorly configured, an attacker could be able to compromise them.
pull_requestThe workflow trigger pull_request will execute the workflow every time a pull request is received with some exceptions: by default if it's the first time you are collaborating, some maintainer will need to approve the run of the workflow:
As the default limitation is for first-time contributors, you could contribute fixing a valid bug/typo and then send other PRs to abuse your new pull_request privileges.
I tested this and it doesn't work: Another option would be to create an account with the name of someone that contributed to the project and deleted his account.
Moreover, by default prevents write permissions and secrets access to the target repository as mentioned in the docs:
With the exception of
GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository. TheGITHUB_TOKENhas read-only permissions in pull requests from forked repositories.
An attacker could modify the definition of the Github Action in order to execute arbitrary things and append arbitrary actions. However, he won't be able to steal secrets or overwrite the repo because of the mentioned limitations.
Yes, if the attacker change in the PR the github action that will be triggered, his Github Action will be the one used and not the one from the origin repo!
As the attacker also controls the code being executed, even if there aren't secrets or write permissions on the GITHUB_TOKEN an attacker could for example upload malicious artifacts.
pull_request_targetThe workflow trigger pull_request_target have write permission to the target repository and access to secrets (and doesn't ask for permission).
Note that the workflow trigger pull_request_target runs in the base context and not in the one given by the PR (to not execute untrusted code). For more info about pull_request_target check the docs.
Moreover, for more info about this specific dangerous use check this github blog post.
It might look like because the executed workflow is the one defined in the base and not in the PR it's secure to use pull_request_target, but there are a few cases were it isn't.
An this one will have access to secrets.
workflow_runThe workflow_run trigger allows to run a workflow from a different one when it's completed, requested or in_progress.
In this example, a workflow is configured to run after the separate "Run Tests" workflow completes:
Moreover, according to the docs: The workflow started by the workflow_run event is able to access secrets and write tokens, even if the previous workflow was not.
This kind of workflow could be attacked if it's depending on a workflow that can be triggered by an external user via pull_request or pull_request_target. A couple of vulnerable examples can be found this blog. The first one consist on the workflow_run triggered workflow downloading out the attackers code: ${{ github.event.pull_request.head.sha }}
The second one consist on passing an artifact from the untrusted code to the workflow_run workflow and using the content of this artifact in a way that makes it vulnerable to RCE.
workflow_callTODO
TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR
We have mentioned all the ways an external attacker could manage to make a github workflow to execute, now let's take a look about how this executions, if bad configured, could be abused:
In the case of pull_request, the workflow is going to be executed in the context of the PR (so it'll execute the malicious PRs code), but someone needs to authorize it first and it will run with some limitations.
In case of a workflow using pull_request_target or workflow_run that depends on a workflow that can be triggered from pull_request_target or pull_request the code from the original repo will be executed, so the attacker cannot control the executed code.
However, if the action has an explicit PR checkout that will get the code from the PR (and not from base), it will use the attackers controlled code. For example (check line 12 where the PR code is downloaded):
The potentially untrusted code is being run during npm install or npm build as the build scripts and referenced packages are controlled by the author of the PR.
A github dork to search for vulnerable actions is: event.pull_request pull_request_target extension:yml however, there are different ways to configure the jobs to be executed securely even if the action is configured insecurely (like using conditionals about who is the actor generating the PR).
Note that there are certain github contexts whose values are controlled by the user creating the PR. If the github action is using that data to execute anything, it could lead to arbitrary code execution:
From the docs: You can make an environment variable available to any subsequent steps in a workflow job by defining or updating the environment variable and writing this to the GITHUB_ENV environment file.
If an attacker could inject any value inside this env variable, he could inject env variables that could execute code in following steps such as LD_PRELOAD or NODE_OPTIONS.
For example (this and this), imagine a workflow that is trusting an uploaded artifact to store its content inside GITHUB_ENV env variable. An attacker could upload something like this to compromise it:
As mentioned in this blog post, this Github Action allows to access artifacts from different workflows and even repositories.
The thing problem is that if the path parameter isn't set, the artifact is extracted in the current directory and it can override files that could be later used or even executed in the workflow. Therefore, if the Artifact is vulnerable, an attacker could abuse this to compromise other workflows trusting the Artifact.
Example of vulnerable workflow:
This could be attacked with this workflow:
If an account changes it's name another user could register an account with that name after some time. If a repository had less than 100 stars previously to the change of name, Github will allow the new register user with the same name to create a repository with the same name as the one deleted.
So if an action is using a repo from a non-existent account, it's still possible that an attacker could create that account and compromise the action.
If other repositories where using dependencies from this user repos, an attacker will be able to hijack them Here you have a more complete explanation: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/
In this section we will talk about techniques that would allow to pivot from one repo to another supposing we have some kind of access on the first one (check the previous section).
A cache is maintained between wokflow runs in the same branch. Which means that if an attacker compromise a package that is then stored in the cache and downloaded and executed by a more privileged workflow he will be able to compromise also that workflow.
Workflows could use artifacts from other workflows and even repos, if an attacker manages to compromise the Github Action that uploads an artifact that is later used by another workflow he could compromise the other workflows:
Check the following pages:
If you are injecting content into a script it's interesting to know how you can access secrets:
If the secret or token is set to an environment variable, it can be directly accessed through the environment using printenv.
If the secret is used directly in an expression, the generated shell script is stored on-disk and is accessible.
For a JavaScript actions the secrets and sent through environment variables
For a custom action, the risk can vary depending on how a program is using the secret it obtained from the argument:
The way to find which Github Actions are being executed in non-github infrastructure is to search for runs-on: self-hosted in the Github Action configuration yaml.
Self-hosted runners might have access to extra sensitive information, to other network systems (vulnerable endpoints in the network? metadata service?) or, even if it's isolated and destroyed, more than one action might be run at the same time and the malicious one could steal the secrets of the other one.
In self-hosted runners it's also possible to obtain the secrets from the _Runner.Listener_** process** which will contain all the secrets of the workflows at any step by dumping its memory:
Check this post for more information.
It's possible to make Github actions that will build and store a Docker image inside Github. An example can be find in the following expandable:
As you could see in the previous code, the Github registry is hosted in ghcr.io.
A user with read permissions over the repo will then be able to download the Docker Image using a personal access token:
Then, the user could search for leaked secrets in the Docker image layers:
Even if Github try to detect secret values in the actions logs and avoid showing them, other sensitive data that could have been generated in the execution of the action won't be hidden. For example a JWT signed with a secret value won't be hidden unless it's specifically configured.
(Technique from here) First of all, any PR raised is clearly visible to the public in Github and to the target GitHub account. In GitHub by default, we can’t delete a PR of the internet, but there is a twist. For Github accounts that are suspended by Github, all of their PRs are automatically deleted and removed from the internet. So in order to hide your activity you need to either get your GitHub account suspended or get your account flagged. This would hide all your activities on GitHub from the internet (basically remove all your exploit PR)
An organization in GitHub is very proactive in reporting accounts to GitHub. All you need to do is share “some stuff” in Issue and they will make sure your account is suspended in 12 hours :p and there you have, made your exploit invisible on github.
The only way for an organization to figure out they have been targeted is to check GitHub logs from SIEM since from GitHub UI the PR would be removed.
The following tools are useful to find Github Action workflows and even find vulnerable ones:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
