非常容易，而且是简单到极致的那种。

只需要制造虚假的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的攻击面。

……

如此看来，大型公司还需要在这种看似基础的漏洞上，再下点功夫了。