GitHub主要仓库泄露访问令牌，代码与云环境面临风险

对一些大型公司的主仓开源库中GitHub Actions工作流生成的构建工件进行的分析显示 ，这些工件中包含了对第三方云服务以及GitHub本身的库泄敏感访问令牌，此外，露访GitHub在今年对工件功能进行的问令一项改动引入了一种竞争条件
，攻击者可以利用这一点来滥用此前无法使用的牌代GitHub令牌
。

Palo Alto Networks的码云面临研究员Yaron Avital进行的调查发现，在数十个公共库中存储的环境工件中发现了机密信息 ，其中一些库对应的模板下载风险项目由Google、Microsoft、主仓Amazon AWS、库泄Canonical 、露访Red Hat 、问令OWASP等大型组织维护，牌代这些令牌提供了对各种云服务和基础设施、码云面临音乐流媒体服务等的环境访问权限
。

“这使得恶意行为者能够通过访问这些工件 ，潜在地破坏这些机密信息所授予访问权限的服务 ，”Avital在报告中写道
，“在我们此次研究中发现的大多数易受攻击的项目中，免费模板最常见的泄露是GitHub令牌的泄露，这使得攻击者能够对触发的GitHub库采取行动  ，这可能导致恶意代码的推送，通过CI/CD管道流入生产环境 ，或访问存储在GitHub库和组织中的机密信息。”

机密信息如何被包含在工件中

GitHub Actions是一种CI/CD服务
，允许用户在GitHub或自己的基础设施中设置工作流，以自动化代码构建和测试
，源码下载这些工作流在.yml文件中使用YAML语法定义，当库中发生特定触发器或事件时会自动执行。例如 ，新代码提交可能会触发一个操作来编译和测试该代码并生成报告
 。

Actions工作流通常会生成构建工件 ，这些工件可以是编译后的二进制文件
、测试报告 、日志或其他执行工作流及其各个作业所产生的文件，这些工件会被存储90天，并且可以被其他工作流或同一工作流的一部分所使用 。在开源项目中，这些工件通常对所有人可见 

然而 ，高防服务器在工作流执行过程中
，常常会将访问令牌临时存储在容器的环境变量或其他临时文件中，以便作业能够访问完成所需的外部工具和服务
。因此 ，必须格外小心 ，确保这些机密信息在工作流完成后不会离开该环境 。

Avital发现的一个示例是，一个被许多项目使用的流行代码静态检查工具生成了一个日志，该日志包括了环境变量；该日志随后被保存为一个工件。代码静态检查工具是静态代码分析工具，云计算用于查找错误 、漏洞和风格问题 ，以提高代码质量 。

更常见的是，通过使用actions/checkout命令创建库的本地克隆，以执行作业时暴露了GitHub令牌。作为这一过程的一部分，会创建一个临时的GITHUB_TOKEN并将其保存到本地.git文件夹中 ，以允许执行经过认证的git命令，该令牌应为临时令牌，香港云服务器并在工作流完成后停止工作，但如果暴露，仍然有方法可以滥用它。

“根据我的观察
，用户通常——也是错误地——将他们整个checkout目录作为工件上传 ，”Avital在他的报告中写道
，“该目录包含存储持久化GITHUB_TOKEN的隐藏.git文件夹，导致公开可访问的工件中包含了GITHUB_TOKEN
。”

Avital在工件中发现的另一个GitHub令牌是ACTIONS_RUNTIME_TOKEN ，它在调用特定的GitHub Actions时存储在环境变量中，例如actions/cache和actions/upload-artifact。与仅在工作流运行期间有效的GITHUB_TOKEN不同 ，ACTIONS_RUNTIME_TOKEN即使在工作流完成后仍然有效六小时，因此存在较大的滥用风险 。

“我自动化了一个流程
 ，可以下载工件，提取ACTIONS_RUNTIME_TOKEN ，并使用它来替换该工件为恶意版本，”这位研究人员写道，“后续的工作流作业通常依赖于之前上传的工件，这类情况为远程代码执行（RCE）打开了大门，攻击者可以在运行作业的Runner上执行恶意工件 。如果开发人员下载并执行了恶意工件，也可能导致工作站被入侵 。”

新的GITHUB_TOKEN竞态条件

如前所述
，GITHUB_TOKEN在工作流完成时失效，工件只有在工作流完成后才可用 ，然而
，自今年二月起，情况发生了变化。

GitHub Actions Artifacts的第4版引入了在工作流运行期间通过用户界面或API下载工件的功能，这是社区请求的一项功能，在许多情况下非常有用 ，例如在批准发布前审查工件 ，或在有许多作业的工作流中尽早获取工件，以节省完成所有作业所需的时间 
。

但随着Avital发现GITHUB_TOKEN经常在工件中暴露，这一新功能也引入了一个攻击者可能利用的竞态条件
 ：如果攻击者知道工作流何时开始 ，他们可以尝试在工作流尚未完成时获取工件并提取GITHUB_TOKEN，因为此时该令牌仍然有效
。

成功率因工作流而异 。在许多情况下，生成工件是作业执行的最后一步之一 ，因此下载工件、提取令牌并进行恶意操作的时间窗口非常小，然而，一些工作流在生成工件后还有更多步骤，因此只需找到这些工作流即可。正如Avital指出的那样，已经切换到v4版本工件API的项目列表正在迅速增长  ，因为v3版本计划在11月弃用。

为了扩大攻击范围和可以针对的工作流数量 ，这位研究人员通过创建一个恶意工作流显著提高了攻击的性能。该恶意工作流运行在GitHub的基础设施上，并在目标库中的某个工作流执行时触发。恶意工作流每秒发送数十个API请求
，以便立即检测到工件生成并下载它
。虽然工件是归档的，但研究人员创建了一个脚本，只提取包含令牌的git配置文件，而不是解压整个工件，从而显著提高了攻击的效率
。

缓解措施

为了帮助防御此类攻击 
，这位研究人员创建了一个名为upload-secure-artifact的自定义GitHub操作 ，其他人可以将其包含在他们的工作流中
，以扫描生成的工件中的机密信息，并在检测到任何机密信息时阻止其上传。

“GitHub弃用Artifacts V3应该促使使用该工件机制的组织重新评估他们的使用方式，”研究人员写道，“根据最小权限原则减少runner令牌的工作流权限，并审查CI/CD管道中的工件创建过程。”