本文来自微信民众号：量子位，原文题目：《黑入苹果特斯拉竟云云容易！这位鬼才的攻击方式火了，微软等35家公司一起悬赏》，作者：边策、金磊

论攻击科技巨头有多灾？

异常容易，而且是简朴到极致的那种。

只需要制造虚伪的pip、npm软件包，就可以轻松攻破微软、苹果、特斯拉、PayPal、Yelp等数十家科技公司服务器。

没错，就是我们再熟悉不外的那些安装下令。

这是一位名叫Alex Birsan的黑客最近发现的伟大破绽：只要上传和科技公司内部软件包名字相同的“李鬼”，就可以让他们在不知不觉中熏染恶意软件。

波及局限之广、攻击方式之简朴，令人咋舌。

Birsan由此发现了30多家科技公司的存在破绽，有两家公司已经奖励他3万美元的的bug赏金。

怎么一回事

事情起源于2020年炎天。

另一位黑客在网上分享了一段GitHub上有趣的Node.js源代码。这段代码原来仅供PayPal内部使用。

Birsan发现，package.json文件列出了安装软件所需的种种依赖项：

其中有来自npm的公共软件包，也有PayPal内部的私有软件包（红色），后者是由PayPal内部托管，这些软件包在公共npm注册表中搜索不到。

Birsan因此发生了许多的疑问：

若是有人冒充PayPal私有软件包的名字，将恶意代码上传到npm会发生什么？

PayPal的内部项目是否有可能因此使用冒充的软件包，而不是原来的私有软件包？

系统是否会由于安装冒充软件包而运行恶意代码？

若是这种攻击方式行得通，可以从中获得科技公司的破绽赏金吗？

这种攻击还会对其他公司起作用吗？

攻击方式

带着这些想法，Birsan将同名的“恶意” Node程序包上传到npm注册表，这样PayPal的程序员若是安装他们的私有软件包，就会被假的软件诱骗和替换。

固然，Birsan的“恶意软件”并不包罗损坏身分，它只有一个功效，当对方使用npm安装上与原软件同名的“李鬼”时，就会发送信息通知Birsan。

“恶意软件”将返回用户名、主机名、安装路径等信息，一方面可以辅助公司平安团队凭据这些信息确定可能受到攻击的系统，同时还可以制止将Birsan的测试误以为是现实的攻击。

不外，要让安装假软件的服务器向自己发出信息并不容易。由于公司内部电脑都受到防火墙的珍爱，DNS渗透是解决办法。

Birsan通过DNS协议将信息发送到他的服务器，Birsan数据经由十六进制编码，将数据伪装成DNS查询的一部分，DNS查询直接或通过中心解析器到达了他自定义的服务器。

通过这种攻击方式，他纪录了每台计算机下载软件包的纪录。

寻找攻击目的

有了攻击的基本设计，Birsan决议寻找更多可能的攻击目的。

首先就是把攻击的软件生态局限扩大，除了Node.js外，他还将代码移植到Python和Ruby上，这样使用PyPI和RubyGems的公司也会受到影响。

接下来就是寻找各大公司的私有软件包名称。

在搜索了整整几天后，Birsan发现，可以在GitHub以及主要软件包托管服务中找到，也可以通过种种互联网论坛上的帖子。

甚至没必要那么贫苦，实在找到私有程序包名称的最佳位置，是在各家公司的javascript文件。

这和前面在package.json找到依赖项类似。同样，require()这些文件中泄露的内部路径或挪用也可能包罗依赖项名称。

苹果、Yelp和特斯拉都可以通过这种方式找到。下面就是从Yelp网站上发现的依赖项。

接下来，就最先“攻击”了。

攻击效果若何？

“成功率简直让人受惊。”

Brisan在按照上述方式举行攻击后，不禁发出这样的感伤。

他将这样的bug叫做依赖性杂乱 （dependency confusion），并称已经在跨越35个组织、所有三种测试编程语言中，均有发现：

有一点异常明确：非法占用有用的内部包名称，险些成了一种万无一失的攻击方式。

绝大多数受此影响的公司，规模都是跨越1000名员工的，这很可能反映出大型公司内部库的使用率很高。

由于Javascript 依赖名称更容易找到，险些75% 的已纪录回调来自 npm 包，但这并不一定意味着 Python 和 Ruby 不易受到攻击：

事实上，只管在我的搜索过程中只能识别出8个组织的内部Ruby gem名称，但其中有4个公司很容易由于RubyGems而发生“依赖性杂乱”。

Brisan还举了个例子。

加拿大电商巨头Shopify就中过招，然后他们为了修复这个bug，特意设立了3万美元的赏金。

无独有偶，在去年8月，他向npm上产了一个Node包，这个包的代码被苹果内部的多台电脑中执行。

苹果为此也设立的3万美元的奖励，但当这位黑客向苹果反映“这个破绽可能允许威胁参与者在苹果 ID 中注入’后门’”，苹果公司却不这么以为：

在运营服务中实现“后门”需要更庞大的事宜序列。

但与此同时，苹果也确实证实，通过使用 npm 包手艺，苹果服务器上的远程代码执行是可以实现的。

最后，Birsan劝说人人不要随意实验，由于他研究的35家公司，都有公共破绽赏金设计或允许通过私有协议对平安性举行测试。

若是未经公司授权，请不要实验这种测试！

大公司缘何一再中招？

看到这里，或许你也会发生疑问：

为什么会发生这种情形？

大公司在面临这样的攻击时，为何会云云懦弱？

Brisan示意，大公司不愿意透露其在“修复”过程中的细节信息，但在他与平安团队相同过程中，却发现了些有意思的事情。

例如，造成Python“依赖性杂乱”的罪魁祸首，似乎就是错误地使用了一个名为extra-index-url的“design by insecure”下令行参数。

当同时使用这个参数和pip install library，来指定你自己的包索引时，虽然到达的效果和预期差不多，但现实上 pip 在幕后做的事情是这样的：

检查指定的（内部）包索引上是否存在库。

检查公共包索引（PyPI）中是否存在库。

以找到的版本为准举行安装。若是两个版本的软件包都存在，则默认从版本号较高的源码安装。

因此，若是将一个名为库9000.0.0的包上传到PyPI，就会导致上述例子中的依赖关系被“挟制”。

虽然这种事情是广为人知的，但若是在GitHub上搜索“extra-index-url”，就可以找到一些属于大型组织的易受攻击剧本——包罗一个影响微软.NET Core组件的bug。

这个破绽可能允许在.NET Core中添加“后门”，但不幸的是，微软并没有把这个破绽放在“.NET错误赏金设计”的局限内。

还会有新攻击方式

对此，Brisan以为，虽然现在许多大型公司已经意识到了这个bug的存在，也在它们的基础设施中举行了修复，但照样有更多需要被发现的器械。

详细而言，他信赖要是存在一种更伶俐的新方式来泄露内部包名称，那么将会暴露出更多更容易受到攻击的系统。

而若是寻找替换的编程语言和存储库作为目的，就会发现一些分外的“依赖性杂乱”bug的攻击面。

……

云云看来，大型公司还需要在这种看似基础的破绽上，再下点功夫了。

参考链接：

https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610