Are Your GitHub Artifacts Leaking Tokens?
Palo Alto Networks Unit 42 research uncovered a common problem among open-source GitHub projects that could expose secrets, and even allow attackers to inject malicious code into GitHub Actions workflows.
GitHub Actions workflows often use secrets, such as cloud service and GitHub tokens, to perform certain actions, and many users may not be aware that these tokens could end up exposed when they are included in publicly available artifact files on open-source repos.
Artifact files are automatically created and stored during GitHub Action workflows in order to preserve certain data, such as test reports and compiled code, for further analysis or deployment, Palo Alto Senior Staff Researcher Yaron Avital explained in a blog post published Tuesday.
Avital said he followed a “hunch” that these often-overlooked artifacts could potentially contain sensitive data and soon found that his hunch was correct — artifacts published on publicly available open-source repositories, including popular projects from large companies like Google, Microsoft and Red Hat, frequently contained both working tokens for external cloud services and two types of GitHub tokens: GITHUB_TOKEN and ACTIONS_RUNTIME_TOKEN.
These artifacts are automatically output by GitHub Actions workflows and stored for up to 90 days, with project maintainers potentially unaware that these artifacts exist, are publicly available or contain secrets.
Additionally, Avital found that automatically generated GitHub tokens, which were not part of the original repository code and created by default to enable running of authenticated git commands against the repository, were also frequently found in public artifact files and could enable attackers to inject malicious code into projects.
How attackers could leverage artifacts to compromise GitHub projects
Out of the two types of GitHub tokens Avital found in artifacts, the ACTIONS_RUNTIME_TOKEN was easier to exploit, as these JSON Web Tokens, which are used by several GitHub actions to manage caching and artifacts, expire about six hours after being created.
The researchers created an automated process that tracks the creation of artifacts containing ACTIONS_RUNTIME_TOKEN, downloads the artifacts, extracts the token within the six-hour time limit and replaces the original artifact with a new one.
An attacker could potentially use a similar process to replace artifacts with files containing malicious code, risking remote code execution (RCE) if that artifact is used in another job.
On the other hand, Avital was initially unable to exploit GITHUB_TOKEN due to the token expiring at the end of the job and before the artifact containing it is generated. However, with the release of version 4 of the artifacts feature in February, it became possible to download artifacts while a workflow was still running, meaning artifacts containing GITHUB_TOKEN could be leaked before the token expired.
While the time window to extract GITHUB_TOKEN before it expired was typically small, even using an automated process, Avital found he could steal and exploit the leaked tokens in time if there were enough steps between the artifact upload and the end of a job.
Avital also managed to improve the success of GITHUB_TOKEN exploitation through an optimized process he called RepoReaper, which saved time by selective extracting only the git config file from compressed artifacts and using the target repository’s REST API extract and exploit the token.
Because most workflows Avital examined had write permissions on the project repository, even when this was not necessary, having access to GITHUB_TOKEN enabled him to perform any write operation — as a proof-of-concept, he used RepoReaper to create a harmless branch on the open-source project clair.
An attacker could use their own version of RepoReaper to scan workflows for GITHUB_TOKEN and automatically use it to push their own malicious code on the target repo.
How to secure tokens from GitHub Actions artifacts
As mentioned, open-source project maintainers may not be aware that artifacts containing potentially sensitive data and tokens are published on their repos; additionally, they may not be aware of the generation of GITHUB_TOKEN during their workflows, which is triggered by default even when it is not necessary for the given job.
To prevent leaking these tokens and potentially risking project compromise, project maintainers should review artifact creation and privilege levels across their CI/CD pipelines, ensuring artifacts containing secrets are not automatically published and granting least permissions necessary for runner tokens throughout their workflow, Avital said.
Avital reported leaked secrets to dozens of maintainers of popular open-source projects utilized by millions of other users, enabling the maintainers to prevent the automatic publishing of sensitive artifacts. The issue was also reported to GitHub, which categorized the issue as information, meaning that users are responsible for properly configuring and securing their own artifacts.
Palo Alto Networks also created a custom open-source action that automatically blocks the upload of artifacts that may contain secrets.
READ MORE HERE
