被盗的 GitHub 令牌助长了一场活动，该活动植入了恶意的 GitHub Actions 工作流，以窃取仓库和云凭据。

一个名为 Gheist 的威胁行为者正在将受损的 GitHub 账户变成凭据收集平台。通过在私有仓库中植入恶意的 GitHub Actions 工作流，攻击者可以暴露仓库和环境机密，然后通过 GitHub API（应用程序编程接口） 检索这些机密，并在删除活动证据之前将其取走。

自 9 月 15 日由 Wiz Research 追踪以来，该活动已在超过 850 个受损账户中留下超过 13,500 个恶意分支，涵盖个人项目和企业私有仓库。

该活动的武器是 GitHub Actions，即该平台的自动化服务，攻击者利用它将窃取的访问权限转化为收集到的凭据。该自动化会创建一个分支，添加一个名为“sync-check”的工作流，该工作流试图将机密打印到执行日志中，通过 GitHub API 检索这些日志，并在几秒钟后删除工作流运行记录。

“由于机密是通过 GitHub 自己的 API 离开的，因此没有攻击者域名或出站连接可供阻止，”Wiz 研究人员在一篇博客文章中表示。

GitHub 引入了一项控制措施，将公共仓库中可能恶意的工作流运行挂起，等待协作者批准。Wiz 报告称，该措施成功阻止了公共仓库中的 Gheist 运行执行。然而，该保护措施并未扩展到私有仓库或 GitHub Enterprise Server，研究人员在这些地方观察到了成功执行及后续活动。

使用 Base32 编码绕过机密掩码

观察到 Gheist 行为者利用了 GitHub Actions 的机密掩码机制与工作流访问敏感值方式之间的差距。

当机密值逐字出现在日志中时，GitHub 会对其进行掩码处理。然而，Gheist 创建的工作流在打印这些机密之前会对其进行 base32 编码，因此它们不再匹配原始值。结果，它们出现在日志中而未被掩码。在使用部署环境（如生产环境）的仓库中，Gheist 创建了多个工作流作业，以针对特定环境的机密。

这可能不仅暴露了存储在仓库级别的机密，还暴露了用于运行生产系统的敏感凭据。

Gheist 随后演变为针对自托管的 GitHub Actions 运行器。其新增的 sync-host 作业试图在运行器主机上搜索 API 令牌、私钥、环境文件、云凭据和其他敏感数据。它还试图访问 Docker（容器化平台） 套接字、云实例元数据和 Kubernetes（容器编排平台） 服务账户令牌。

Wiz 指出，演变后的变体包含实现缺陷，因此不应假定每个目标凭据都能成功提取。

更广泛的云安全问题

Wiz 观察到，在恶意工作流运行以枚举 AWS Secrets Manager 数小时后，同一组织的云凭证仍在使用。CloudTrail 记录还显示，攻击者创建的分支上的工作流承担了 AWS 角色，这提供了执行证据，即使 GitHub 日志不可用。

Wiz 将可能的凭证来源追溯到信息窃取日志和在早期供应链泄露中暴露的令牌，包括 3 月的 Trivy 泄露事件。研究人员还发现受影响账户与其他恶意活动之间存在重叠，包括重命名仓库以分发破解软件诱饵，以及试图滥用 GitHub Actions 获取免费计算资源。

安全团队被建议搜索匹配“ci-sync-”后跟六个随机字符的分支、标题为 ci: sync config 的提交，以及完成后不久即被删除的工作流运行。他们还应调查与这些分支相关的云角色承担情况，撤销受损令牌，并轮换受影响工作流可访问的每个仓库、组织和环境机密。研究人员警告说，删除分支或运行并不能逆转凭证暴露。

本文最初发表于 CSO。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：InfoWorld

原创地址：https://www.infoworld.com/article/4241628/gheist-turns-github-actions-into-a-secret-extraction-service-2.html