抵御依赖混淆攻击的软件供应链策略

抵御依赖混淆攻击的软件供应链策略

时间戳记：7年2023月9日下午09:XNUMX
抵御依赖混乱攻击的软件供应链策略柏拉图区块链数据智能。垂直搜索。人工智能。

“名字里有什么？我们称之为玫瑰的东西，无论换什么名字，闻起来都一样香甜。” 当莎士比亚于 2 年写下这些话（罗密欧与朱丽叶，第二幕，第二场）时，他说名字只是一种惯例。它没有内在意义。朱丽叶爱罗密欧是因为他本身，而不是他的名字。

但莎士比亚在不知情的情况下也在描述依赖性混淆攻击。

当您在代码中使用的包不是您的时，就会出现依赖性混乱。 它们具有相同的名称，但在生产中运行的不是您的代码。 同名，但一个包装闻起来像玫瑰，另一个……很臭。

最近的研究报告估计，41% 到 49% 的组织面临依赖混淆攻击的风险。 OX Security 的最新研究表明，当组织面临依赖混淆攻击的风险时，其 73% 的资产都容易受到攻击。该研究重点关注中型和大型组织（1K+、8K+, 80K+ 员工）跨多个领域（金融、游戏、技术和媒体），并发现各种规模组织的每个领域都存在风险。研究还发现，几乎所有拥有超过 1 亿用户的应用程序都在使用容易受到依赖关系混淆的依赖关系。

本文旨在帮助您了解依赖关系混淆以及如何防止它。

双人，双人

依赖项（也称为包）是软件的构建块。通常，这些软件，无论是由整个社区还是在公司内部开发，都执行共同且必要的任务。

包管理器经常用于安装依赖项并保持更新。他们扫描公共和私人注册表中的包名称，并在所有其他条件相同的情况下，选择最高版本号。攻击者利用这一点，在公共注册表上放置一个具有相同名称但版本更高的“虚拟”包。

当包管理器遇到两个相同的包（一个在公共注册表中，一个在私有注册表中）时，它会引起混乱 - 因此称为“依赖关系混乱”。由于这两个包是相同的，管理器会自动选择安装版本较高的一个 - 在这种情况下，是攻击者的恶意包。

这为劫持者提供了进入您的软件的后门。 从这一点来看，他们可以实施数据泄露、盗窃知识产权或破坏软件供应链的信任。 他们还可能违反合规规定，从而引发严厉的监管处罚。

辛劳与烦恼

依赖混淆攻击有多种方法。

  • 命名空间。 通过将恶意软件库上传到公共注册表 - 例如 Python 包索引 (PyPI) 或 JavaScript 的 npm 注册表 - 那是 命名相似 对于受信任的内部使用的库，忽略名称空间/URL 检查或不强制从私有注册表获取的系统可能会错误地引入恶意代码。 这 最近的 PyTorch 依赖混淆事件 就是这样一个例子。
  • DNS 欺骗。 通过使用 DNS 欺骗等技术，可以引导系统从恶意存储库中提取依赖项，同时显示看似合法的内部 URL/路径。
  • 脚本。 通过修改构建/安装脚本或 持续集成/持续交付 (CI/CD) 管道配置，系统可能会被欺骗从恶意源而不是本地存储库下载软件依赖项。

用心做好事

为了防止依赖性混乱，请制定这些做法。

  • 在包管理器中设置策略。 禁止包管理器将公共包优先于私有包。
  • 始终包含 .npmrc 文件。 如果您使用流行的 NPM 作为包管理器，请始终包含一个 .npmrc 文件，该文件指定在特定组织范围下从何处获取包。
  • 在公共注册表中保留包名称。 防止依赖项混淆攻击的另一种方法是在公共注册表中保留包名称，以便劫持者无法使用它，因此无法“欺骗”包管理器安装恶意包。

为了充分防止依赖混淆攻击，组织应始终使用 所有内部包的组织范围，即使发布到您的内部注册表时也是如此。 组织范围还应该在 NPM 的公共注册表中注册，从而防止任何人劫持范围并利用混乱。

包名称也应该公开注册。 例如，如果一个组织使用流行的 PIP 作为 Python 依赖项的包管理器，那么它应该创建具有严格可识别且适用于所有项目的后缀的内部包。 将同名的空包上传到公共注册表 PyPI 作为占位符。

在公共注册表中保留包名称的另一个原因是，如果其他人保留它（无论是否恶意），开发人员将不得不将私有注册表中的所有包名称更改为尚未在公共注册表中保留的包名称。 这可能是一个漫长而乏味的过程。

请务必注意，并非所有包注册表都允许用户保留包名称，因此请确保找到一个允许的包注册表。

出口，被熊追

依赖混淆攻击对全球组织构成严重且迫在眉睫的网络安全威胁。 大约一半的组织面临风险，这些组织 73% 的资产面临风险。 为了应对这一日益严重的威胁，组织必须实施强有力的预防措施并采用网络安全最佳实践。

莎士比亚的玫瑰可能预示了数百年的依赖性混淆攻击的风险，但吟游诗人的另一句话可能蕴藏着一些防范这些攻击的智慧： “让每一只眼睛都为自己进行谈判，不要相信任何代理人。” （无事生非，第二幕，场景 2）

时间戳记：

更多来自 暗读