TensorFlow CI/CD 漏洞使供应链易遭投毒攻击

Praetorian 公司的研究员 Adnan Khan 和 John Stawinski 发布报告指出，攻击者可滥用这些配置不当问题，“以恶意pull请求攻陷 TensorFlow 的构建代理，从而对 GitHub 和 PyPi 上的 TensorFlow 发布发动供应链攻击。“

成功利用这些漏洞可导致外部攻击者将恶意发布上传到 GitHub 仓库，再自托管的 GitHub runner 上获得远程代码执行权限，甚至检索tensorflow-jenkins 用户的 GitHub 个人访问令牌 (PAT)。

TensorFlow 使用 GitHub Actions自动化软件构建、测试和部署管道。Runner即在 GitHub Actions 工作流中执行任务的机器，它即可自托管，也可托管在 GitHub 上。

GitHub 在文档中提到，“我们推荐仅使用具有私有仓库的自托管 runner。这是因为公开仓库的fork 可能会在你自托管的 runner 机器上运行危险的代码，方法就是创建可在工作流中执行代码的 pull 请求。“换句话说，它使任何贡献者提交恶意 pull 请求，在自托管 runner 上执行任意代码。然而，它并不会对 GitHub 托管的 runner 产生造成任何安全隐患，因为每个 runner 都是短暂的，而且会在任务执行结束后被毁坏的清洁的、被隔离的虚拟机。

研究人员指出能够找到在自托管 runner 上执行的 TensorFlow 工作流，随后从无需同意即可在合适的 CI/CD 工作流中自动触发的之前的贡献者，找到fork pull 请求。

因此，寻求木马化目标仓库的攻击者可修复输入错误或做出微小但合法的代码变更，创建pull请求，之后等待 pull 请求合并，成为贡献者。这样就能使攻击者在 runner sans 上执行代码，通过创建恶意 pull 请求触发警报。

进一步分析工作流日志发现，自托管的 runner 不仅是非短暂性的（获得持久性），而且与工作流相关联的 GITHUB_TOKEN权限还拥有广泛的写权限。研究人员表示，“因为GITHUB_TOKEN 具有 contents:write 权限，因此它能够将发布上传到 https://github[.]com/tensorflow/tensorflow/releases/。攻陷其中一个‘GITHUB_TOKEN’ 的攻击者可将自身文件增加到 Release Assets 中。”

此外，contents:write 权限可被武器化，通过间接把恶意代码注入特性分支并将其合并到主分支的方法，将代码直接推送到 TensorFlow 仓库。不止如此，攻击者可窃取发布工作流中使用的 AWS_PYPI_ACCOUNT_TOKEN以认证到 PyPI 注册表中，并上传恶意的 Python .whl 文件，从而投毒程序包。

研究人员表示，“攻击者还能使用 GITHUB_TOKEN 的权限攻陷 JENKINS_TOKEN 仓库机密，即使该机密并非用于在子托管 runner 上运行的工作流中。”

研究人员在2023年8月1日负责任披露后，项目维护人员在2023年12月20日修复，方法是要求同意所有从fork pull 请求提交的工作流，并为在自托管runner 上运行的工作流的 GITHUB_TOKEN 权限更改为只读。

研究人员提到，“随着越来越多的组织机构将其CI/CD进程自动化，类似的CI/CD攻击正在增长。AI/ML企业的工作流要求大量计算力，而 GitHub 托管的 runner 并不具备这种计算力，因此自托管runner 变得流行，所以AI/ML 企业尤其易受攻击。”

不久前，多个GitHub 公开仓库如与 Chia networks、微软 DeepSpeed 和 PyTorch 相关联的公开仓库易受经由自托管 GitHub Actions runner 的恶意代码注入攻击。

    觉得不错，就点个 “在看” 或 "赞” 吧~