GitHub Actions 安全漏洞危及著名开源项目

GitHub Actions 中的安全漏洞已经危害了 Google、Microsoft、AWS 和 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 中的一个严重安全漏洞导致谷歌、微软、AWS 和红帽等公司维护的几个备受瞩目的开源项目的身份验证令牌被曝光。此缺陷允许未经授权访问私有存储库并插入恶意代码。

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.

GitHub Actions 是一个与 GitHub 深度集成的持续集成和持续交付（CI/CD）平台。它于 2018 年推出，允许用户直接在 GitHub 存储库中自动化构建、测试和部署管道。

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.

Palo Alto Networks 的 Unit 42 发现了此漏洞，该机构发现这些代币无意中被公开。令人惊讶的是，尽管情况很严重，GitHub 仍决定不纠正根本问题。相反，他们建议用户采取措施来保护其工作流程工件。这一决定让许多用户变得脆弱和沮丧。

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.

Unit 42 的调查强调了可能导致此漏洞的几个问题，包括不安全的默认配置和用户错误。一个主要问题涉及“actions/checkout”功能，该功能默认将 GitHub 令牌存储在本地 .git 目录中。如果此目录包含在工件上传中，则令牌将被公开。

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.

此漏洞还会影响其他敏感信息，例如 API 密钥和云访问令牌，这些信息可能会通过这些工件泄露。构建输出和测试结果最多可存储 90 天，任何对存储库具有读取权限的人都可以访问。

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.

当 CI/CD 管道将 GitHub 令牌存储在环境变量中时，会遇到另一个漏洞。如果工作流中的任何操作或脚本记录这些环境变量，它们可能会无意中暴露。例如，在“super-linter”操作中启用“CREATE_LOG_FILE”属性可以记录这些变量。

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.

此漏洞的利用可能因暴露的令牌类型而异。例如，如果 GitHub 令牌泄露，它可用于从日志文件中提取凭据并在它们过期之前使用它们。 GitHub 令牌通常在其工作流程作业的持续时间内有效，而用于缓存和工件管理的“Actions_Runtime_Token”的有效期为六个小时。这为攻击者提供了有限的机会。

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.

然而，Unit 42 进行的研究还表明，这些代币包括对第三方云基础设施的访问，而不仅仅是 GitHub。这引发了进一步的安全问题，因为包含这些代币的人工数据被发现可以公开访问长达三个月。恶意行为者可以自动检索工件、提取令牌，并使用它们将恶意代码推送到存储库。

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.

为了演示此漏洞，研究人员在一个开源项目中创建了一个分支，展示了在处理恶意工件的运行程序上进行远程代码执行 (RCE) 的潜力。他们还开发了概念验证 (PoC) 操作来审核秘密的源目录，如果检测到任何秘密暴露风险，则阻止工件上传。

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.

这项研究的结果已提交给 GitHub 的错误赏金计划，但该问题被归类为信息性问题，表明用户有责任保护上传的工件。尽管 GitHub 的反应有限，但我们还是与网络威胁联盟 (CTA) 分享了这些见解，以便成员能够部署保护措施并阻止潜在的网络威胁。