论攻击科技巨头有多难？
非常容易，而且是简单到极致的那种。
只需要制造虚假的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
