我如何通过依赖混淆(Dependency Confusion)入侵了苹果、微软和其他几十家公司

前情提要：

作者提出了一种称为依赖混淆(Dependency Confusion)的漏洞，通过搜集内部库名称，并在pip、npm等平台上传恶意库文件，成功在Apple、Paypal等内部执行命令，获得10w+$赏金。

从我开始学编程，我就对下面这种命令的可信程度非常感兴趣

pip install package_name

一些编程语言(如python)，官方提供了一种简单的方法来安装依赖，这些库都存储在公共代码库，任何人都可以上传供其他人使用。

除了python之外，Node语言有npm命令，Ruby有gems命令。当从这些公共库下载使用别人上传的代码时，你本质上就已经信任了这些发布者在你的电脑上运行代码，这种盲目的信任会被攻击者进行恶意利用吗？

当然可以~

2020年和Justin Gardner (@Rhynorater) 一起尝试测试PayPal时，他在GitHub上找到了一段有趣的Node.js代码。

这段代码是PayLal内部使用的，在package.json文件中，除了一些公共的库之外，也有一些内部私有的库。这些私有库很可能是PayPal内部托管的，在公共npm库中不存在。

这就引出了几个问题：

• 如果使用这几个私有库名字上传恶意代码到npm会发生什么？PayPal内部项目会开始使用这几个公开的新库而不是私有的库吗？

• 开发者或者自动化的系统会自动执行这些库里的代码吗？

• 如果想法成立的话，我能获得一份赏金吗？

• 这种想法对其他公司有效吗？

我的想法是首先找到目标使用的没有在公开平台注册的私有库的名字，然后在公开平台使用这些名字上传包含恶意代码的node库到npm平台。当这些库被执行时，我就会收到响应。

必须说明所有的测试都是经过授权的，请不要未授权进行测试。

幸运的是，npm 允许在安装包时自动执行任意代码，我可以写一个恶意代码库，自动收集安装此库的计算机的一些基本信息。

为了能够通过收集的信息辨别出目标、同时避免收集过多敏感信息的，我决定仅记录每个安装者的用户名、主机名和当前路径，这些数据足以帮助安全团队根据我的报告识别可能存在漏洞的系统，同时避免我的测试被误认为是攻击。现在还剩下一件事——我如何将这些数据返回给我？

大部分公司内部都进行了严格的网络限制，我决定尝试DNS来泄露数据。

通过 DNS 协议将信息发送到我的服务器并不是必需的，但它确实确保了流量在流出时不被阻止或检测到。 将数据进行十六进制编码，添加到 DNS 查询中，该查询直接或通过中间解析器到达我的自定义权威名称服务器。

测试的方法已经明确了，现在要做的是扩大测试的范围

第一个方法是寻找其他类似的公共库平台进行测试。因此，我将代码移植到 Python 和 Ruby，以便能够分别将类似的包上传到 PyPI（Python Package Index）和 RubyGems。

此测试最重要的部分是找到尽可能多的库名称。

经过一整天的搜索，我在 GitHub以及各种互联网论坛上的帖子中找到了一些公司内部使用的库名称。并且我发现查找私有库名称的最佳位置是在 javascript 文件中。在javascript项目中包含packegs.json文件非常普遍，这些文件中很容易泄露内部路径以及一些require调用的私有库。

苹果、Yelp 和特斯拉可以通过这种方式获取到不少私有库名称。

2020 年下半年，在@streaak 的帮助下，我们自动扫描了目标公司的数百万个域名，并提取到数百个尚未在 npm 公开平台注册的私有库名称。

然后，我上传代码到各个公开平台并开启监听......

成功率简直惊人

迄今为止，我们在超过 35 个目标中检测到了这种类型的漏洞（我将其称为依赖混淆Dependency Confusion）。 绝大多数受影响的公司属于 1000 名以上员工的大型公司，这反映大型组织内私有平台使用率较高。

由于 javascript 依赖项名称更容易找到，记录的回调中几乎 75% 来自 npm 包。

在我上传一个名为 shopify-cloud 的 Ruby gem 后，仅几个小时加拿大电子商务巨头 Shopify 的内部系统就自动安装了它，然后尝试运行其中的代码。Shopify 团队在一天之内就进行了修复，并提供了 30,000 美元的赏金。同样Apple 为存在的漏洞给予了 30,000 美元的奖励。受影响的项目似乎与苹果的身份验证系统（Apple ID）有关。

后续陆续通过监听收到了PayPal 、Netflix、Yelp 和 Uber等大型公司， 其中PayPal给予了3 万美元的赏金。大多数赏金都是按照漏洞奖金的顶格给的，这也说明了依赖混淆的严重程度。

进一步的研究：

尽管许多大型科技公司已经意识到这种类型的漏洞，并且已经在其基础设施中修复了该漏洞。但我相信仍然可以找到新的、更好的方法来获取更多、更准确的内部包名称，从而进一步扩大漏洞的影响范围。

文章翻译自https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

点击原文跳转至原文阅读

欢迎加入知识星球，学习国内外最新的漏洞赏金案例、挖掘技巧：

原文始发于微信公众号（bugbounty）：我如何通过依赖混淆(Dependency Confusion)入侵了苹果、微软和其他几十家公司