近年来，针对软件开发人员和供应商的供应链攻击变得愈发普遍。这些攻击的主要目标是通过恶意软件感染合法应用程序来获得对源代码、构建过程或更新机制的未经授权访问。然后，通过滥用供应商-客户信任关系，他们可以迅速感染大量不知情地安装受感染包的组织。对于本地开发的应用程序，组织的用户和供应商可能会受到影响。考虑到潜在的收益，供应链成为恶意行为者的一个有吸引力的目标也就不足为奇了。

攻击者实施供应链攻击的一种方式是利用“依赖项混淆”（Dependency Confusion）。在这些类型的攻击中，恶意行为者会试图利用使用第三方软件库的常见做法，并利用软件包管理器自动下载并安装应用程序所需的软件包。虽然这不是一种新的攻击类型，但研究人员惊讶地发现近一半的组织容易受到这种类型的攻击。

这一点尤其值得关注，因为供应链攻击的影响可能是巨大的，对组织、供应商和客户都是毁灭性的。在本文中，我们将解释依赖项混淆攻击是如何发生的，以及可以实施哪些措施来最小化这种风险。

执行概要

• 根据Orca云安全平台的研究数据显示，近一半（49%）的组织容易受到依赖项混淆攻击。
• 依赖项混淆攻击是一种供应链攻击，攻击者将恶意包发布到与流行包同名的公共包存储库中。这会导致包管理器在不知情的情况下从公共存储库下载恶意包。
• 攻击者可以采取“机会主义”的方法，他们会上传多个与流行的包依赖项同名的恶意包，或者他们可以在知道特定库中使用哪些文件名的情况下发起有针对性的攻击。
• 如果成功，依赖项混淆攻击可能会产生灾难性的后果，感染安装恶意包的所有供应商客户。然后，这些组织可能会受到未经授权的访问、数据盗窃、勒索软件等攻击。
• 通过确保开发人员审查和验证他们的包，并使他们的依赖项保持最新，可以降低依赖项混淆风险。

什么是依赖项混淆攻击？

依赖项混淆攻击是一种利用现代开发环境和包管理器——例如Node package Manager （NPM）和Python package Index（PyPI）——运行方式的攻击。简而言之，如果组织的软件构建使用私有的、内部创建的依赖项，而该依赖项在公共开源存储库中不存在，那么依赖项混淆就会起作用。攻击者能够在公共存储库上以相同的名称注册具有更高版本号的依赖项。然后，很大的可能是，攻击者创建的具有更高版本号的（公共）依赖项——而非组织的内部依赖项——将被拉入软件构建中。

这种攻击的简单化和自动化特质，使其日渐受到攻击者的青睐。得益于在多个开源生态系统中发现的固有设计缺陷，依赖项混淆能够在攻击者端通过最小的努力甚至是自动化的方式发挥作用。

2021年2月，通过利用PyPI、npm和RubyGems等常用生态系统中的这个简单缺陷，道德黑客Alex Birsan成功地入侵35家大型科技公司，并为此获得了超过130,000美元的漏洞赏金奖励。在Birsan的研究成果披露几天后，数以千计的依赖项混淆模仿包开始涌入PyPI、npm 和其他生态系统。

2022年12月下旬，攻击者在PyPI上上传了一个恶意的“torchtriton”依赖项，该依赖项与官方PyTorch库上的依赖项共享相同的名称。由于在Python生态系统中获取依赖项时，PyPI通常会被优先考虑，因此在安装期间会提取恶意包，而不是PyTorch的合法包。

在2022年春季的一个依赖项混淆攻击案例中，某些版本的“node-ipc”包包含恶意代码，可以覆盖或删除俄罗斯和白俄罗斯用户系统上的任意文件。

一个令人惊讶的普遍问题

通过分析Orca平台扫描的云环境中存储的NPM和PyPI包，研究人员发现多达49%的组织至少有一个易受攻击的资产，超过28%的组织有50个或更多的资产可能容易受到依赖项混淆攻击。

【依赖项混淆是一个非常普遍的问题】

被认为易受攻击的软件包包括对公共存储库中不存在的软件库的依赖项，这意味着恶意行为者可以将具有相同名称的库上传到公共存储库，“欺骗”包管理器下载该库，因为这是包管理器的默认配置方式。

公共注册VS私有注册

公共注册表是所有人（包括开发人员、组织和攻击者）都可以公开访问的包的存储库。公共包注册表的示例包括NPM和PyPI。另一方面，私有注册表是只有授权用户和组织才能访问的包的存储库。私有注册表通常由组织用于存储和管理特定于其需求且不打算用于公共用途的包。对私有注册表的访问通常受到身份验证和授权机制的限制。

在供应链攻击方面，由于公共注册表的开放性，它们更容易受到这些类型的攻击。攻击者可以将恶意包注入注册表，然后开发人员可以在不知情的情况下在其项目中使用这些包。这可能导致安全事件，例如数据盗窃、未经授权的访问或其他类型的攻击。

私有注册表虽然攻击者难以访问，但也不能幸免于供应链攻击。攻击者可以通过其他方式获得对私有包的访问权，例如利用注册表中的漏洞或泄露授权用户的凭据。

例如，在NPM包的情况下，攻击者可以创建一个与合法包同名的恶意包，并将其上传到npmjs.com（NPM的官方包存储库）。当开发人员在其包. json文件中指定对合法包的依赖项并运行npm安装时，包管理器将安装攻击者的包，而不是合法的包，导致依赖项混淆攻击成功。然后，恶意包可以泄露敏感信息或在开发人员的计算机上执行任意代码。

依赖项混淆攻击的PoC

下面我们将讨论如何实现依赖混淆攻击的概念证明（PoC）：

让我们以组织X为例，该组织在其内部CI/CD过程中使用了许多NPM包，包括一些著名的NPM包。除此之外，还有一个名为production-x-company-internal1的包，顾名思义，它是一个内部包，没有在npm公共注册表中注册。

研究人员Alex Birsan描述的依赖项混淆技术可以被恶意的个人利用，以获取有关公司云基础设施的机密信息。这种攻击依赖于组织的NPM CI/CD流程中的特定弱点，包括使用来自公共注册表的包。此外，攻击者必须了解公共注册表中不可用的内部包。通过创建和上传与其中一个内部包同名的恶意包，攻击者可以欺骗CI/CD进程获取恶意包。这允许他们执行供应链攻击并可能检索敏感数据。

攻击者创建一个包含恶意有效负载的包，该包存储在index.js文件中。攻击者的目标是窃取与AWS云提供商相关的敏感信息，包括配置和凭证文件以及来自AWS IMDSv2服务" http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance/ "的数据来检索IMDS机密数据。

除了主要变量之外，攻击者还试图获取其他信息，例如主机名、用户名和主机的UID。

最后的有效负载，以及将被发送到远程Burp Collaborator的四个自定义标头（header），显示在上面的屏幕截图中。

攻击者的最后一步是发布软件包，使其公开，然后等待受害者安装其恶意软件包。

我们可以从上面的截图中看到，攻击者能够成功地向Burp Collaborator发送POST请求，并从易受攻击的主机中提取敏感数据。自定义标头填充了获得的信息，如屏幕截图所示。

依赖项混淆风险缓解建议

下面我们列出了可以遵循的最佳实践，以降低NPM和PIP中依赖项混淆攻击的风险。需要注意的是，没有任何的缓解策略是万无一失的，组织应该将这些策略组合起来实施，以降低成功攻击的风险。

• 包名称验证：确保项目中使用的所有包的名称都是已知且可信的。这可以通过在将每个包添加到依赖项之前验证其源代码和维护者来实现。此外，还可以使用npm的npm audit命令或pip的pip check命令等工具来检测依赖项中的任何漏洞或不一致性。
• 包签名：利用包签名来验证包的真实性。例如，npm有一个包签名特性，它允许维护者签名他们的包，并提供一个加密的保证，保证包没有被修改过。
• 使用私有包注册表：考虑使用私有包注册表来托管内部依赖项。这有助于降低攻击者引入与您的依赖项名称相似的恶意包的风险。
• 自动安全扫描：实现自动安全扫描，定期检查依赖项是否存在漏洞和其他安全问题。这有助于在恶意软件包造成危害之前捕获它们。
• 代码审查：进行定期的代码审查，以确保在系统中执行的代码是已知和可信的。这可以帮助捕获任何可能通过依赖项混淆攻击引入的恶意代码。
• 监控软件包下载：监控软件包下载以检测任何异常活动。这有助于及早识别潜在的依赖项混淆攻击，并采取适当的行动。
• 定期更新依赖项：定期更新依赖项，以确保及时解决任何安全漏洞。这有助于降低攻击者利用依赖项中已知漏洞的风险。

原文链接：

https://orca.security/resources/blog/dependency-confusion-supply-chain-attacks/