揭秘新的供应链攻击：一研究员靠它成功入侵微软、苹果等 35 家科技公司

最近，一名安全研究员利用一种新颖的软件供应链攻击成功入侵了 35 家大型科技公司的内部系统，这些公司包括微软、苹果、PayPal、特斯拉、Uber、Yelp、Shopify、Netflix。在向这些公司提交安全报告后，他获得超过 13 万美元的奖金。

据悉，此类攻击利用了开源生态系统的一个设计缺陷：依赖关系混乱。攻击者先把恶意软件上传到开源存储库中，比如 PyPI、npm 和 RubyGems，此后它们会自动地分发到下游的公司的内部应用中。

与传统的误植域名攻击（typosquatting attacks）不同，这种特殊的供应链攻击更复杂，并且无需攻击者进行其他操作。

去年，安全研究者 Alex Birsan 在与另一名研究者 Justin Gardner 一起工作时冒出一个想法。当时，Gardner 向 Birsan 分享了一个清单文件（manifest file）package.json，它来自一个 npm 包，而它正被 PayPal 内部所使用。

Birsan 注意到一些清单文件包并没有出现在公共的 npm 存储库，但是，它却代替了 PayPal 创建的私有 npm 包。

于是，他产生一个疑问：如果创建一个同名的公开 npm 包，那么软件在构建时，开发人员是优先使用私有的，还是公开的版本？

为测试这一假说，Birsan 开始搜索私有内部包的名称。这些私有的内部的包可以从 GitHub 存储库的清单文件或公司的 CDN 中找到，但却不在公共开源存储库中。

此后，这名研究员开始在开源存储库（比如 npm、PyPI 和 RubyGems）中创建同名的冒牌项目。这些冒牌项目都位于 Birsan 的 GitHub 真实账户下，并且有一个清晰地免责声明，解释“软件包不包含任何有用的代码，只是用于安全研究目的”。

他很快意识到，公开的软件包会比私有的软件包优先度更高。Birsan 还注意到，某些情况下，像 PyPI 包，版本更高的软件包优先度更高，无论它是私有的还是公开的。

利用这一方法，他通过发布公司内部在用的同名的公开软件包，实施了一系列成功的供应链攻击，轻松地入侵微软、苹果、PayPal、特斯拉、Uber、Yelp、Shopify、Netflix。

Birsan 说：“与误植域名或品牌劫持不同，依赖关系混乱不需要攻击者任何的手工操作。”

据奇安信代码安全事业部技术专家章磊解释，由于各种包的依赖关系，是通过包管理器/托管平台计算出来的，并不是由各个科技公司自己制订。而开源包管理器/托管平台的计算规则，譬如高版本优先、公开软件包优先等，并不能规避常见的安全隐患。

“本次攻击事件中，所谓的依赖关系混乱主要是由于包管理器/托管平台的依赖关系计算、软件包维护等方面的安全机制缺失造成的。”他向 InfoQ 解释。

此外，章磊还介绍了依赖混淆的另一种攻击方式：

攻击者通过窃取开源项目维护者的账号，植入后门程序，然后再发布开源软件的新版本，从而无差别攻击所有开源项目的使用者。

以 CVE-2019-13354 为例，攻击者通过入侵了开发者的 Rubygems.org 维护账号，随后发布了 strong_password 的 0.0.7 版本，并植入后门程序。而在 CVE-2019-15224 中，项目维护者的密码很早前泄露，并且他多年来未登录并修改密码。攻击者在窃取账号后，发布了带有后门程序的 1.16.13 版本。

“由于 Ruby 包管理器支持的自动升级机制，所有未固定依赖版本的项目，在重新构建的过程中，都可能会引入上述攻击者植入的恶意开源软件。”章磊说。

在 Birsan 看来，基于这项研究，他让知名的高科技公司意识到了这种攻击，而这些公司也已经在基础架构中实施了某些缓解措施。

但是，这事并未结束。这样的攻击在以后还有可能出现和增长，尤其是未解决依赖混淆的开源平台和生态。

各种开源软件生态的包管理器/托管平台，比如 Maven、npm、PyPI、Composer 等，对于各种流程、机制等的设计，主要是从研发效率出发，并没有系统地考虑过安全性。并且，随着软件开发过程中，开源软件的使用越来越多、越来越频繁，开源软件已经成为当今软件开发的核心基础设施。

章磊称，“安全的本质在于对抗。这就必然导致开源软件的安全问题愈演愈烈，这些包管理器、托管平台自身的安全性缺失也越来越受到重视。”

对很多企业来说，它们已经成为开源软件的用户。在采用开源软件时，应该如何防范或规避此类安全问题？

他提出了三点建议：

1. 企业需要引入一些开源治理的系统或工具，梳理自身使用的各种开源软件，形成开源软件的资产清单；

2. 制订开源软件的相关制度，规范开源组件/软件引入的流程，比如强制使用受控范围限定（频道、名字空间、前缀等）内的开源软件，或在开发时通过固定版本、完整性校验等方式规避依赖混淆攻击，并通过引入私有仓库来进行辅助管理，比如强制所有开源软件来源于同一个私有仓库，避免同时使用多个仓库

3. 在现有的开源生态形势下，其实无法完全防范或规避类似的开源软件安全隐患。企业需要持续跟进开源生态的安全动态，结合企业自身的开源资产，及时进行开源安全事件的响应。

章磊认为，短期看，开源依赖混乱是难以彻底治理的，它需要社区、托管平台、开发者和终端用户的通力合作，才能逐步达到理想的程度。

从社区、开源基金会的角度，应当制订一系列开源软件依赖相关的标准，逐渐影响并统一各个开发生态管理依赖的方式。“这也是依赖关系彻底治理的最基础的一环”。

从托管平台方面，可以从安全角度出发，审视自身的流程设计、框架机制等各方面，从而尽可能规避依赖关系混乱带来的安全隐患。这被视为依赖关系治理最亟待解决的一环。

从开发者角度，在架构设计阶段，进行开源软件选型时应该关注开源软件的安全风险，比如开源软件是否存在已知漏洞、是否存在开源协议风险、开源项目的开发者及维护者的相关信息等，把开源软件的安全风险作为开源软件选型的重要因素。

他提到，在开发阶段，开发者可以利用奇安信开源卫士、BlackDuck 专业化开源软件安全治理工具将开源软件安全分析融入到开发测试流程中，这样能在开发过程中及时发现引入了哪些开源软件、这些开源软件之间的依赖关系如何、是否存在已知安全漏洞、开源协议风险等，提前发现安全风险，进行及时修正。

从企业角度，应将开源软件安全治理作为软件安全的重中之重。企业应建立开源软件引入和退出机制，在软件开发到运维的过程中使用专业的自动化工具持续检测和发现开源软件资产及风险，持续跟踪开源软件漏洞情报，进行漏洞响应。对于外包开发的软件项目，应该在立项之初就提出针对开源软件的安全要求，并在验收时进行检查。