开源AI框架TensorFlow曝CI/CD漏洞，可用于软件供应链投毒

在开源TensorFlow机器学习框架中发现的持续集成和持续交付 (CI/CD) 错误配置可能会被用来策划软件供应链攻击。攻击者可能会滥用错误配置，通过恶意拉取请求破坏 TensorFlow 的构建代理，从而对 GitHub 和 PyPi 上的 TensorFlow 版本进行供应链破坏。

成功利用这些漏洞可能会允许外部攻击者将恶意版本上传到 GitHub 存储库，在自托管 GitHub 运行器上获得远程代码执行，甚至检索tensorflow-jenkins 用户的 GitHub 个人访问令牌 (PAT) 。

TensorFlow 使用GitHub Actions来自动化软件构建、测试和部署管道。运行器是指在 GitHub Actions 工作流程中执行作业的机器，可以是自托管的，也可以由 GitHub 托管。

GitHub在其文档中指出，建议仅使用具有私有存储库的自托管运行器。因为通过创建在工作流程中执行代码的拉取请求，公共存储库的分支可能会在自托管运行器计算机上运行危险代码。

换句话说，这允许任何贡献者通过提交恶意拉取请求在自托管运行器上执行任意代码。

然而，这不会对 GitHub 托管的运行器造成任何安全问题，因为每个运行器都是短暂的，并且是一个干净、隔离的虚拟机，在作业执行结束时会被销毁。

Praetorian 表示，它能够识别在自托管运行器上执行的 TensorFlow 工作流程，随后找到来自先前贡献者的分叉拉取请求，这些请求会自动触发适当的 CI/CD 工作流程，而无需批准。

因此，想要木马化目标存储库的对手可以修复拼写错误或进行小而合法的代码更改，为其创建拉取请求，然后等到拉取请求合并才能成为贡献者。这将使他们能够在运行器上执行代码，而不会通过创建恶意拉取请求来引发任何危险信号。

对工作流日志的进一步检查表明，自托管运行程序不仅是非短暂的（从而为持久性打开了大门），而且与工作流关联的GITHUB_TOKEN权限具有广泛的写入权限。

由于 GITHUB_TOKEN 具有内容写入权限，因此它可以将版本上传到 github tensorflow releases。破坏这些 GITHUB_TOKEN 之一的攻击者可以将自己的文件添加到发布资产中。

最重要的是，内容写入权限可以被武器化，通过秘密地将恶意代码注入功能分支并将其合并到主分支中，将代码直接推送到 TensorFlow 存储库。

攻击者还可能会窃取发布工作流程中使用的 AWS_PYPI_ACCOUNT_TOKEN，以向 Python 包索引 (PyPI) 注册表进行身份验证并上传恶意 Python .whl 文件，从而有效地毒害包。

攻击者还可以使用 GITHUB_TOKEN 的权限来破坏 JENKINS_TOKEN 存储库机密，即使该机密并未在自托管运行器上运行的工作流程中使用。

随着越来越多的组织实现 CI/CD 流程自动化，类似的 CI/CD 攻击正在增加。AI/ML 公司特别容易受到攻击，因为他们的许多工作流程需要强大的计算能力，而 GitHub 托管的运行器无法提供这些计算能力，因此自托管运行器很流行。