在开源 TensorFlow 机器学习框架中发现的持续集成与持续交付(CI/CD)配置错误,可能被利用来发起供应链攻击。
TensorFlow 是谷歌的开发者创造的一款开源的深度学习框架,于 2015 年发布。TensorFlow 现已被公司、企业与创业公司广泛用于自动化工作任务和开发新系统,其在分布式训练支持、可扩展的生产和部署选项、多种设备(比如安卓)支持方面备受好评。
Praetorian 的研究员 Adnan Khan 和 John Stawinski 在本周发布的一份报告中表示,这些配置错误可能被黑客利用来“通过恶意拉取请求破坏 TensorFlow 的构建代理,从而对 GitHub 和 PyPi 上的 TensorFlow 版本进行供应链破坏”。
通过利用这些漏洞,黑客可将恶意版本上传到 GitHub 仓库,并获得自托管 GitHub 运行器(runner)上的远程代码执行权限,甚至检索 tensorflow-jenkins 用户的 GitHub 个人访问令牌(PAT)。
TensorFlow 使用 GitHub Actions 自动化软件构建、测试和部署流程。运行器指的是执行 GitHub Actions 工作流中任务的机器,可以自托管,也可以由 GitHub 托管。
GitHub 在其文档中写道,“建议用户仅在私有仓库中使用自托管运行器,因为公共仓库的分支可能通过创建执行危险代码的工作流拉取请求,在您的自托管运行器机器上运行潜在危险的代码。”
换言之,这允许任何贡献者通过提交恶意拉取请求,在自托管运行器上执行任意代码。
然而,这并不会对 GitHub 托管的运行器构成任何安全问题,因为每个运行器都是短暂的,并且是一个干净、隔离的虚拟机,在任务执行结束后就会被销毁。
Praetorian 表示,它能够识别在自托管运行器上执行的 TensorFlow 工作流,随后发现以前的贡献者提交的分支拉取请求自动触发了相应的 CI/CD 工作流,且无需批准。
因此,一个想要对目标仓库进行木马化的黑客是这样操作的,他会修正一个拼写错误或进行一个小但合法的代码更改,为此创建一个拉取请求,然后等待拉取请求被合并,以成为一个贡献者。这将使他们能够在创建恶意拉取请求时执行代码,而不会引起任何警告。
对工作流日志的进一步检查表明,自托管运行器不仅是非短暂性的(从而为持久性打开了大门),而且与工作流相关的 GITHUB_TOKEN 也附带了广泛的写入权限。
研究人员指出“因为 GITHUB_TOKEN 拥有 contents:write 权限,它可以上传版本到 https://github[.]com/tensorflow/tensorflow/releases/,黑客如果破坏这些 GITHUB_TOKEN,就可以在发布资产中添加他们自己的文件。”
最重要的是, contents:write 权限可以武器化,通过直接向 TensorFlow 仓库推送代码,秘密地将恶意代码注入到一个特性分支,并将其合并到主分支。
不仅如此,黑客还可以窃取发布工作流中使用的 AWS_PYPI_ACCOUNT_TOKEN,以向 Python 包索引(PyPI)注册表进行身份验证,并上传恶意 Python .whl 文件,以便有效地污染包。
研究人员说,“黑客还可以利用 GITHUB_TOKEN 的权限来危及 JENKINS_TOKEN 仓库密钥,尽管这个密钥并未在自托管运行器上运行的工作流中使用。”
在 2023 年 8 月 1 日进行了负责任的披露后,项目维护人员于 2023 年 12 月 20 日解决了这些漏洞,要求批准从所有 fork pull 请求提交的工作流,包括以前的贡献者提交的工作流,并将在自托管运行器上运行的工作流的 GITHUB_TOKEN 权限更改为只读。
“随着越来越多的组织自动化他们的 CI/CD 流程,类似的 CI/CD 攻击正在增加。”研究人员说道,“AI/ML 公司尤其脆弱,因为他们的许多工作流需要大量的计算能力,而 GitHub 托管的运行器是无法提供的,因此自托管运行器很普遍。”
两位研究人员都透露,几个公共 GitHub 存储库,包括与 Chia Networks,Microsoft DeepSpeed 和 PyTorch 相关的存储库,容易受到通过自托管 GitHub Actions 运行器进行恶意代码注入的影响。
转自FreeBuf.COM,原文链接:https://www.freebuf.com/news/390133.html
封面来源于网络,如有侵权请联系删除