黑客的工作在咱们普通人看来，更像是一门看不懂的“玄学”。但这项玄学的背地，很多看起来高深莫测的网络攻击，应用的都是非常简单却无效的办法。
最近，一位名叫 Alex Birsan 的黑客，正式通过一种非常简单却实用的办法，发现了 30 多家科技公司存在的破绽，并因而取得了高额的破绽赏金。
上面是这位黑客在集体博客中的自述，咱们能够通过这篇文章理解一下玄学背地的故事。
作者：Alex Birsan
原文链接：https://medium.com/@alex.birs…
自从我开始学习如何编程以来，我始终对这一句简略的代码指令有些纳闷：
pip install package_name
某些编程语言（例如 Python）应用一种简略的官网办法来为我的项目装置依赖项。这些安装程序通常与公共代码存储库绑定，在那里任何人都能够自在上传代码包供别人应用。
当下载和应用其余起源的安装包时，咱们基本上是信赖其发行者在咱们的机器上运行代码。那么这种自觉的信赖会被歹意行为者利用吗？
答案是当然能够。
任何程序包托管服务都无奈保障其用户上传的所有代码均不含恶意软件。过来的钻研表明，「域名抢注（利用包名称的错字版本进行的攻打）」在取得对寰球随机 PC 的拜访方面十分无效。
其余家喻户晓的依赖项攻打门路包含应用各种办法来毁坏现有软件包，或以不再存在的依赖项名称上传恶意代码。
想法
在 2020 年冬季尝试与我入侵 PayPal 时，Justin Gardner（@Rhynorater）分享了在 GitHub 上发现的乏味的 Node.js 源代码。
该代码是供外部 PayPal 应用的，并且在其 package.json 文件中仿佛蕴含公共和公有依赖项的混合 —— 来自 npm 的公共软件包以及非公共软件包的名称，这些很可能是 PayPal 外部的公有软件包，由 PayPal 外部托管。因为这些名称过后在公共 npm 注册表中不存在。
这个逻辑会引起一些问题：
- 如果以这些名称将恶意代码上传到 npm 会产生什么？PayPal 的一些外部我的项目是否有可能开始默认为新的公共软件包而不是公有软件包？
- 开发人员或者一些自动化零碎会开始在库中运行这些软件包吗？
- 如果这种办法行得通，咱们能够借助这个形式从科技企业取得破绽赏金吗？
- 这种攻打还会对其余公司起作用吗？
事不宜迟，我开始制订打算来答复这些问题。
这个想法是将我本人的“歹意”Node 程序包以所有无人认名的名称上载到 npm 注册表中，这将从装置它们的每台计算机上“打电话回家”。如果最终将任何软件包装置在 PayPal 领有的服务器上，则其中的代码会立刻告诉我。
在这一步中，我感觉很重要的一点是，必须明确指出，在此钻研过程中所针对的每个组织都已容许通过公共破绽赏金打算或通过私人协定来对其安全性进行测试。未经受权，请勿尝试这种测试。
“总是 DNS”
值得庆幸的是，npm 容许在装置软件包时主动执行任意代码，这使我能够轻松创立一个 Node 软件包，该软件包收集无关通过其 preinstall 脚本装置在其上的每台计算机的一些根本信息。
为了在基于数据辨认组织的能力与防止收集太多敏感信息之间获得均衡，我决定只记录用户名，主机名和每个惟一装置的以后门路。与内部 IP 一起应用的数据就足够了，能够帮忙平安团队依据我的报告确定可能受到攻打的零碎，同时防止将我的测试误认为是理论的攻打。
当初剩下的一件事 —— 如何将这些数据还给我？
晓得大多数可能的指标都将位于受良好爱护的公司网络外部，我认为 DNS 浸透是解决之道。
通过 DNS 协定将信息发送到我的服务器对于测试自身是否失常工作不是必不可少的，但它的确确保了在出站时不太可能阻止或检测到流量。
数据通过十六进制编码，并用作 DNS 查问的一部分，该 DNS 查问间接或通过两头解析器达到了我的自定义名称服务器。服务器配置为记录每个接管到的查问，本质上记录了下载软件包的每台计算机的记录。
多多益善
有了攻打的根本打算，当初是时候发现更多可能的指标了。
第一个策略是寻找相似的生态系统进行攻打。因而，我将代码移植到了 Python 和 Ruby 上，以便可能别离将类似的软件包上传到 PyPI（Python 软件包索引）和 RubyGems。
然而能够说，该测试最重要的局部是找到尽可能多的相干依赖项名称。
在搜寻了一些指标公司的公有软件包名称的整整几天后，发现能够在 GitHub 以及次要软件包托管服务（偶尔公布的外部软件包外部）甚至外部的次要软件包托管服务中找到许多其余名称，或者各种互联网论坛上的帖子。
然而，到目前为止，找到公有程序包名称的最佳地位居然是在各家公司或平台的的 javascript 文件中。
显然，package.json 蕴含 javascript 我的项目依赖项名称的外部文件在其构建过程中会嵌入到公共脚本文件中，从而裸露外部包名称，这是很常见的。同样，require() 这些文件中透露的外部门路或调用也可能蕴含依赖项名称。苹果、Yelp 和特斯拉只是以这种形式公开外部名称的公司的一些例子。
在 2020 年下半年，因为 @streaak 的帮忙和他杰出的侦察技能，咱们可能主动扫描属于指标公司的数百万个域，并提取数百个尚未在 npm 注册表中申明的 javascript 程序包名称。
而后，我将代码上传到所有找到的名称下的包托管服务中，并期待回调。
后果
成功率几乎是惊人的。
从开发人员在本人的计算机上犯下的一次性谬误，到外部或基于云的构建服务器配置不当，再到零碎易受攻击的开发管道，一件事很显著：抢占无效的外部软件包名称简直是一种不会失败的办法。一些最大的科技公司的网络，能够近程执行代码，并且可能容许攻击者在构建过程中增加后门。
迄今为止，我曾经在超过 35 种组织中的所有三种通过测试的编程语言中检测到了这种类型的破绽，我将这种破绽称为「依赖混同」。绝大多数受影响的公司属于 1000 多名员工类别，这很可能反映了大型组织外部应用外部软件库的普遍性。
因为更容易找到 javascript 依赖项名称，简直所有已记录的回调中有 75% 来自 npm 软件包 —— 但这并不一定意味着 Python 和 Ruby 不太容易受到攻打。实际上，只管在我的搜寻过程中只能辨认出属于八个组织的外部 Ruby 名称，但事实证明，其中有四家公司很容易通过 RubyGems 造成依赖混同。
加拿大电子商务巨头 Shopify 是这样的公司之一，其构建零碎 shopify-cloud 仅在我上传 Ruby 几个小时后主动装置了一个名为 Ruby 的 Ruby gem，而后尝试在其中运行代码。Shopify 团队在一天之内筹备好修复程序，并为发现问题的我提供了 30,000 美元的破绽赏金。
在我于 2020 年 8 月上传到 npm 的 Node 包中的代码在其网络内的多台计算机上执行之后，苹果也提供了 30,000 美元的处分。受影响的我的项目仿佛与 Apple 的身份验证零碎（内部称为 Apple ID）无关。
当我提出这个破绽可能容许威逼者向 Apple ID 注入后门的想法时，Apple 并不认为这种影响程度能够精确地示意问题所在，而是说：
在经营服务中实现后门须要更简单的事件序列，并且这是一个带有附加含意的十分特定的术语。
然而，Apple 的确确认应用此 npm 软件包技术能够在 Apple 服务器上执行近程代码。依据软件包装置的流程，该问题在我报告的两周内失去解决，但仅在公布此帖子之前不到一天就授予了赏金破绽。
在针对其余公司的其余几次胜利攻打中，能够看到在外部服务器和集体开发人员的 PC 上都装置了雷同主题的 npm 软件包，其中一些装置通常是在软件包上载后数小时甚至数分钟进行的。
实际上，大多数已授予的 Bug 赏金都设置为每个程序的策略所容许的最高数额，有时甚至更高，这证实了依赖混同 bug 的严重性通常很高。其余受影响的公司包含 Netflix，Yelp 和 Uber。
“这不是一个谬误，这是一个性能”
只管有大量的依赖混同的发现，但一个细节在某种程度上依然是（当初依然是）尚不分明：为什么会这样？此类破绽的次要本源是什么？
能够了解，大多数受影响的组织都不愿走漏无关其根本原因和缓解策略的更多技术细节，然而在我的钻研过程中以及与平安团队的沟通中的确呈现了一些乏味的细节。
例如，Python 依赖关系凌乱的罪魁祸首仿佛是谬误地应用了“设计不平安”命令行参数 --extra-index-url。应用此参数 pip install library 指定您本人的包索引时，您可能会发现它能够按预期工作，然而 pip 幕后的实际操作是这样的：
- 查看指定（外部）包索引上是否存在库
- 查看 公共 包索引（PyPI）是否存在库
- 装置找到的任何版本。如果两个软件包均存在，则默认从具备 更高版本号 的源进行装置。
因而，library 9000.0.0在下面的示例中，上传名为 PyPI 的程序包将导致依赖关系被劫持。
只管这种行为曾经广为人知，但仅在 GitHub 上搜寻 --extra-index-url 就足以找到一些属于大型组织的易受攻击的脚本 —— 包含一个影响 Microsoft .NET Core 组件的谬误。可怜的是，该破绽可能容许向 .NET Core 增加后门程序，但该破绽在 .NET Bug 赏金打算中未被发现。
Ruby 的 gem install --source 工作形式也与此相似，然而我无奈确定其用法是否是我发现的根本原因。
当然，更改 --extra-index-url 为 --index-url 是一种疾速而间接的解决办法，然而事实证明，依赖混同的其余一些变体很难失去解决。
与此同时，Microsoft 还提供了相似的名为 Azure Artifacts 的程序包托管服务。依据我的一份报告，对该服务进行了一些小的改良，以确保它能够为依赖项混同破绽提供牢靠的解决办法。乏味的是，没有通过测试 Azure Artifacts 自身发现此问题，而是通过胜利攻打 Microsoft 本人的基于云的 Office 365 来发现此问题，该报告失去了 Azure 可能取得的最高处分 40,000 美元。
将来的钻研？
只管许多大型科技公司曾经意识到这种破绽，并已在其基础架构中对其进行了修复，或者正在致力施行缓解措施，但我依然感到还有很多发现的感觉。
具体来说，我置信找到透露外部程序包名称的新办法将揭示更多易受攻击的零碎，而寻找代替的编程语言和指标存储库将揭示依赖混同谬误的其余攻击面。
话虽这么说，无论您的教训程度如何，我都竭诚激励您花一些工夫在脑海中尝试一下该想法 —— 无论它是否与依赖项治理安全性相干。