利用 CocoaPods 服务器中的一个 RCE 漏洞，投毒数百万款app

数字化时代，软件无处不在。软件如同社会中的“虚拟人”，已经成为支撑社会正常运转的最基本元素之一，软件的安全性问题也正在成为当今社会的根本性、基础性问题。

随着软件产业的快速发展，软件供应链也越发复杂多元，复杂的软件供应链会引入一系列的安全问题，导致信息系统的整体安全防护难度越来越大。近年来，针对软件供应链的安全攻击事件一直呈快速增长态势，造成的危害也越来越严重。

为此，我们推出“供应链安全”栏目。本栏目汇聚供应链安全资讯，分析供应链安全风险，提供缓解建议，为供应链安全保驾护航。

注：以往发布的部分供应链安全相关内容，请见文末“推荐阅读”部分。

我用 Signal iOS app 和朋友们沟通。我是 Signal 的真爱粉，而我对真爱项目的回馈方式之一是尝试从中找出 bug。

浏览该 app 来源时首先吸引我的是 Podfile，它列出了 Signal 的 CocoaPods 依赖关系。我和程序包管理器的渊源颇深，所以首先想到的是尝试从 CocoaPods 服务器中找出bug。如果能找到影响使用 CocoaPods 的所有 app 的 bug，还费力气黑 Signal 干嘛？

当向 CocoaPods 上传程序包规范时，它会尝试确保我们不会不慎链接到私有库。它会执行如下操作：

这样做会带来几个问题。最重要的问题是攻击者对 @specification.source[:git] 和 ref.to_s 具有完全控制，因此可利用它们将标记传递给 git。git ls-remote 选用可选标记 –upload-pack 评估 shell 中的内容。因此，如果 @specification.source[:git] 等于 --ls-remote="$(echo THIS WAS PROBABLY UNEXPECTED)" github.com，而 ref.to_s 被解释为一个本地仓库，那么我们就可以在 CocoPods 服务器中运行攻击者的命令。

如下是我最终使用的 exploit：

之后，我思考了 CocoaPods 对这个世界提供的价值多么巨大，单从节约开发人员的时间角度来看就能看到！再看看世界上有多少大型企业都在使用这款软件。再想想安全审计的成本有多高。

对于使用依赖关系管理器的人来说：

• 考虑 vendoring 依赖关系并仔细审计其更新（vendoring 的概念并未有确切定义，可以理解为拷贝一份项目中使用的第三方依赖关系，以防止版本冲突等问题）。

• 你使用的依赖关系管理器中可能存在 bug，如果项目的安全敏感度高，则应该认真仔细地思考这个攻击向量。

对于编写依赖关系管理器的人来说：

如果想确保依赖关系管理器的安全，应当将如下因素作为有毒废弃物：

• 程序包内容

• 版本控制软件

依赖关系管理器服务器通常想暴露关于程序包的某些元数据（有毒废弃物），并经常通过借助某些版本控制软件（有毒废弃物）来实现。最好不要这样做，但如果必须这么做，则应该使用沙箱。

几个月前，我在 proxy.golang.org 中找到了一个 RCE 漏洞，它被暴露于某款易受攻击的版本控制软件。不过由于我无法逃逸它所使用的沙箱而得以完全缓解。

最后，感谢 CocoaPods 维护人员神速修复该漏洞！

奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的

产品线。