GitHub Actions Security Vulnerability Compromises Notable Open-Source Projects

A security vulnerability in GitHub Actions has compromised several notable open-source projects maintained by companies like Google, Microsoft, AWS, and Red Hat.

A critical security vulnerability in GitHub Actions has led to the exposure of authentication tokens for several high-profile open-source projects maintained by companies like Google, Microsoft, AWS, and Red Hat. This flaw has enabled unauthorized access to private repositories and the insertion of malicious code.

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that is deeply integrated with GitHub. It was launched in 2018 and allows users to automate their build, test, and deployment pipelines directly within their GitHub repositories.

This vulnerability was identified by Palo Alto Networks' Unit 42, which discovered that these tokens were unintentionally becoming public. Surprisingly, despite the gravity of the situation, GitHub has decided not to rectify the underlying problem. Instead, they have recommended that users take steps to secure their workflow artifacts. This decision has left many users vulnerable and frustrated.

Unit 42's investigation highlighted several issues that can contribute to this vulnerability, including insecure default configurations and user errors. One primary issue involves the ‘actions/checkout' feature, which defaults to storing the GitHub token in the local .git directory. If this directory is included in artifact uploads, the token becomes exposed.

This vulnerability also affects other sensitive information, such as API keys and cloud access tokens, which might be leaked through these artifacts. Build outputs and test results are stored for up to 90 days and can be accessed by anyone who has read permissions to the repository.

Another vulnerability is encountered when CI/CD pipelines store GitHub tokens in environment variables. If any actions or scripts within the workflow log these environment variables, they can be unintentionally exposed. For example, enabling the ‘CREATE_LOG_FILE' property in the ‘super-linter' action can log these variables.

The exploitation of this vulnerability can vary depending on the type of token that is exposed. For instance, if a GitHub token is leaked, it can be used to extract credentials from log files and use them before they expire. GitHub tokens are typically valid for the duration of their workflow jobs, while the ‘Actions_Runtime_Token,' which is used for caching and artifact management, remains valid for six hours. This provides a limited window of opportunity for attackers.

However, the research conducted by Unit 42 also showed that these tokens include access to third-party cloud infrastructures, not just GitHub. This raises further security concerns, as artifactual data, containing these tokens, were found to be publicly accessible for up to three months. Malicious actors could automate the retrieval of artifacts, extract tokens, and use them to push malicious code to repositories.

To demonstrate this vulnerability, the researchers created a branch in an open-source project, showing the potential for remote code execution (RCE) on the runner handling the malicious artifact. They also developed a proof of concept (PoC) action to audit the source directory for secrets, blocking artifact uploads if any secret exposure risk was detected.

The findings of this research were submitted to GitHub's bug bounty program, but the issue was classified as informational, suggesting that users bear the responsibility to secure uploaded artifacts. Despite the limited response from GitHub, the insights were shared with Cyber Threat Alliance (CTA) to allow members to deploy protective measures and thwart potential cyber threats.