近日,有攻击者通过 CI/CD 工作流中的 GitHub Actions 工具窃取了谷歌、微软、AWS 和 Red Hat 等多个知名开源项目的 GitHub 身份验证令牌。
窃取这些令牌的攻击者可在未经授权的情况下访问私有存储库、窃取源代码或向项目中注入恶意代码。
Palo Alto Networks Unit 42 发现这个情况后,立刻敦促所有受到影响的企业立刻采取行动。但由于 GitHub 暂未对此有所行动,因此根本问题仍未解决。
鉴于这种情况,GitHub 用户需要了解风险,评估自己所面临的风险,并采取措施防止未来发生泄密事件。
GitHub 操作生成的工件,来源:GitHub Unit 42
GitHub 令牌泄露
Unit 42 的报告强调了一系列因素,包括不安全的默认设置、用户错误配置和不充分的安全检查,这些都可能导致 GitHub 令牌泄漏,他们称之为 “ArtiPACKED ”攻击。
第一个风险点是 “actions/checkout ”操作,该操作通常用于 GitHub 工作流,以克隆版本库代码,使其在工作流运行期间可用。
默认情况下,该操作会将 GitHub 标记持久化到本地 .git 目录(隐藏)中,这是工作流中验证操作所必需的。
如果用户误将整个签出目录作为工件的一部分上传,git 文件夹内的 GitHub 标记现在就会暴露。
公开暴露的 GitHub 令牌,来源:GitHub Unit 42
该文件夹中可能包含的其他敏感信息包括 API 密钥、云服务访问令牌和各种账户凭据。
在 CI/CD 过程中生成的工件(如构建输出和测试结果)也会因错误的工件上传而发生类似的暴露,这些工件的存储和访问时间长达三个月。
另一个故障点是使用环境变量存储 GitHub 标记的 CI/CD 管道。如果工作流中的操作或脚本有意或无意记录了这些变量,这些记录就会作为人工制品上传。
Unit 42指出,当 “CREATE_LOG_FILE ”属性设置为 “True ”时,“super-linter ”操作可以创建包含环境变量的详细日志。
最终,攻击者会在短暂的 GitHub 令牌过期前从日志中提取并使用这些令牌。GitHub 令牌在工作流作业持续期间保持有效,因此其利用潜力因情况而异。
GitHub 内部用于缓存和管理工件的 “Actions_Runtime_Token ”有效期通常为 6 小时,利用窗口很小。
而自定义秘密和令牌(如 API 密钥或云服务的访问令牌)的生命周期各不相同,从几分钟到永不过期不等。
Unit 42介绍了一种攻击方案,该方案可识别使用 GitHub Actions 的项目或公共源,并使用自动脚本扫描它们,以确定可提高工件生成可能性的标准。
另一套脚本可以自动从目标软件仓库的 CI/CD 管道中下载工件,对于公共软件仓库来说这个过程并不复杂。
攻击流,资料来源:Unit 42
缓解措施
Unit 42 发现了以下 14 个可能受到影响的大型开源项目,并建议它们立即采取补救措施:
- Firebase(谷歌)
- OpenSearch Security(AWS)
- 克莱尔(红帽)
- 活动目录系统(Adsys)(Canonical)
- JSON 模式(微软)
- TypeScript Repos 自动化、TypeScript Bot 测试触发器、Azure Draft(微软)
- CycloneDX SBOM(OWASP)
- 鳕鱼
- Libevent
- 用于 Apache Kafka 的 Guardian(Aiven-Open)
- Git 附件(Datalad)
- Penrose
- Deckhouse
- Concrete-ML (Zama AI)
Unit 42建议 GitHub 用户应尽量避免在上传的工件中包含整个目录,对日志进行消毒,并定期检查 CI/CD 管道配置。同时,应调整 “actions/checkout ”等危险操作的默认设置,以避免凭证持久化。此外,工作流中使用的令牌权限应设置为必要的最低权限,以限制它们被暴露时造成的损害。
参考来源:GitHub Actions artifacts found leaking auth tokens in popular projects
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022