通过隐藏的供应链链接开发财富 500 强企业

RONI CARTA | LUPIN

关键词：NPM， 供应链攻击， 依赖项混淆， 黑客攻击， 赏金， HASHICORP

引言

软件供应链变得日益复杂，无数的依赖关系构成了现代应用程序的主干。尽管这种复杂性存在，但许多针对这些依赖关系的攻击却出奇地简单。虽然花费了大量时间确保单个包的安全性和功能性，但它们之间的连接却常常被忽视。

行业关注的焦点往往是依赖关系的内部工作——验证代码是否安全且最新。然而，这种方法忽视了这些依赖关系与第三方来源建立的外部链接，这些链接可能引入漏洞。通过忽视这些关系，我们冒着暴露我们的系统于攻击的风险，这些攻击利用了对这些外部连接的信任。

这就是我们的软件供应链安全工具Depi发挥作用的地方。Depi不仅仅关注单个组件，而是突出了它们之间被忽视的薄弱环节。它精确地指出了攻击者可能如何破坏这些连接，为您提供了对软件供应链中潜在威胁的更清晰视图。Depi帮助将焦点从内部代码安全转移到保护更广泛的依赖网络。
在今天的文章中，我们将探讨Depi如何识别针对Consul的软件供应链攻击（SCA），Consul是HashiCorp的开源服务发现和网络自动化工具，以及它对一家财富500强公司的影响，该公司因此支付了17,000美元的漏洞赏金。

一切是如何开始的

在Depi的开发过程中，向广泛的行业专家咨询以塑造工具以满足公司的需求是非常重要的。我们咨询的关键人物之一是Caleb Sima。

Caleb是网络安全领域的知名人物，拥有数十年的道德黑客、应用安全和安全策略经验。他共同创立并领导了几个以安全为重点的公司，并在主要技术公司担任过高管职位。如果您计划在网络安全领域推出SaaS，Caleb是您需要交谈的人。

他提供了宝贵的反馈，并要求我们展示工具的能力。为了测试其有效性，他建议扫描HashiCorp的开源仓库，看看Depi能发现什么。

我们接受了挑战并开始扫描。然后我们发现了一些有趣的东西：

在consul/ui/packages/consul-ui/package.json 文件中定义了易受攻击的软件包，如下所示：

{  "devDependencies": {    "consul-lock-sessions": "*",  }}

这个包被标记为devDependency，设置为从注册表中拉取任何版本。然而，在这种情况下，预期的行为是包管理器首先检查../package.json文件，因为这是一个工作区目录：

{  "private": true,  "description": "Monorepo for Consul UI, packages and addons.",  "license": "MPL-2.0",  "author": "HashiCorp",  "workspaces": {    "packages": [      "packages/*"    ]  },  "scripts": {    "doc:toc": "doctoc README.md",    "compliance": "npm-run-all compliance:*",    "compliance:licenses": "license-checker --summary --onlyAllow 'Python-2.0;Apache*;Apache License, Version 2.0;Apache-2.0;Apache 2.0;Artistic-2.0;BSD;BSD-3-Clause;CC-BY-3.0;CC-BY-4.0;CC0-1.0;ISC;MIT;MPL-2.0;Public Domain;Unicode-TOU;Unlicense;WTFPL' --excludePackages '[email protected];[email protected];[email protected];[email protected];[email protected];[email protected]'"  },  "devDependencies": {    "doctoc": "^2.0.0",    "license-checker": "^25.0.1",    "npm-run-all": "^4.1.5"  },  "resolutions": {    "xmlhttprequest-ssl": "^1.6.3",    "ember-basic-dropdown": "3.0.21"  },  "engines": {    "node": "18"  }}

在这种情况下，consul-lock-sessions 包应该从 ../packages/consul-lock-sessions 中。一些包管理器，如 yarn Classic 或 npm，通过检查父目录来正确检测我们在工作区中。但是，对于 pnpm 来说，情况并非如此。如果有人要执行以下命令：

git clone [email protected]:hashicorp/consul.gitcd consul/ui/packages/consul-ui/pnpm install

包管理器将在上游注册表 （registry.npmjs.org） 中搜索 consul-lock-sessions。这开启了一个可能的攻击场景，特别是对于在 monorepo 设置中使用 pnpm 的开发人员——至少我们最初是这么认为的。剧透警告：事情变得更有趣了。

在开始开发之前，我们注意到一件奇怪的事情。几个包的定义方式相同，但未被 Depi 标记：

{  "devDependencies": {    "consul-acls": "*",    "consul-lock-sessions": "*",    "consul-nspaces": "*",    "consul-partitions": "*",    "consul-peerings": "*",  }}

这样做的原因是注册表之前已经发布了这些包，这些包后来被取消发布。在查询注册表的 API 时，我们收到了 200 响应（而不是预期的 404），但没有版本数据。结果如下所示：

$ curl https://registry.npmjs.org/consul-lock-sessions | jq{  "_id": "consul-lock-sessions",  "name": "consul-lock-sessions",  "time": {    "created": "YYYY-MM-DDTHH:mm:ss.xx1Z",    "3000.0.0": "YYYY-MM-DDTHH:mm:ss.xx1Z",    "modified": "YYYY-MM-DDTHH:mm:ss.xx1Z",    "3001.0.0": "YYYY-MM-DDTHH:mm:ss.xx1Z",    "unpublished": {      "time": "YYYY-MM-DDTHH:mm:ss.xx1Z",      "versions": [        "3000.0.0",        "3001.0.0"      ]    }  }}

这表明之前有人曾尝试利用此漏洞但没有成功，因为该软件包后来已从注册表中删除。

我们发现，在这种状态下，包仍然是可认领的。

我们从这种行为中学到了东西，并改变了Depi在npm上检测可认领包的方式。在运行新的扫描后，Depi发现了以下漏洞：

很好，我们现在准备好利用这个漏洞了。

利用

我们联系了Caleb，安排了一个演示，展示在Consul上对pnpm的利用。当时我们认为只有浏览特定目录的pnpm用户容易受到这种攻击。鉴于所需的用户交互水平，我们决定认领包以构建一个完整的端到端演示，以呈现给HashiCorp。我们认领了注册表上的包，设置了一个在安装时向我们的服务器发送pingback的回调，以演示远程代码执行。

这是通过添加一个preinstall命令完成的，该命令泄露目标的主机名、whoami和路径。这些详细信息允许道德黑客验证正确的系统已执行命令，并帮助公司识别允许依赖混淆发生的确切配置错误位置。这个探针在事件响应中很有用，特别是当有多个潜在故障点时，如开发人员机器、CI管道或生产服务器。

我们在周五向Caleb展示了演示，他提出在下周一将我们介绍给HashiCorp的团队。由于这个漏洞当时并不十分严重（至少我们当时知道的是这样），并且不能被恶意行为者滥用，因为我们已经接管了包，我们没有过多考虑周末的等待。

然而，在演示后几个小时，我们却在pingback服务器上收到了一个意外的提醒：

{  "pwd"=>"/Users/REDACTED/src/consul/ui/packages/consul-ui/node_modules/consul-peerings/node_modules/axios",   "whoami"=>"REDACTED",   "hostname"=>"REDACTED.internal.fortune500.tld"}

我的第一反应是给我的兄弟Holmes发消息，对我们发现的东西感到兴奋。结果我们收到了来自财富500强公司内部机器的pingback，主机名是认领HashiCorp包后收到的。

更有趣的是，pingback中的User-Agent并不是我们预期的pnpm，而是npm：

{   "headers": {        "accept": "*/*",        "accept-encoding": "gzip, br",        "connection": "Keep-Alive",        "npm-in-ci": "false",        "npm-scope": "",        "pacote-pkg-id": "registry:undefined@https://redacted.tld/consul-lock-sessions",        "pacote-req-type": "tarball",        "referer": "install",        "user-agent": "npm/6.14.15 node/v14.19.0 darwin arm64",      }}

这表明我们最初的假设（只有 pnpm 易受攻击）是错误的。其他包管理器（如 npm）也容易受到工作区中默认依赖项混淆的影响。

向财富 500 强公司披露

我们的下一步是负责任地向受影响的公司披露这个问题。受到这个漏洞影响的财富500强公司正在运行漏洞赏金计划。他们的计划最好的一点是为漏洞猎人提供的透明度和支持，帮助增强他们的发现。这种透明度和合作反映了一个管理良好的漏洞赏金计划的成熟度。我们相信他们会迅速而公正地处理这个依赖混淆的披露。

报告在不到一天的时间内被分类，两周内，我们收到了最高奖金17,000美元。

公司积极与道德黑客接触，并保持开放的渠道以接收负责任的披露至关重要，当发现漏洞时。这种合作有助于及早识别潜在威胁，并允许组织在它们被恶意利用之前解决它们。在我们的例子中，与这家公司的合作是公司应该如何与道德黑客合作以确保全面评估和及时解决的一个很好的例子。

同样重要的是正确评估供应链攻击。这些类型的漏洞可能会产生深远的影响，与道德黑客紧密合作以充分理解范围至关重要。这家公司促进了关于软件供应链攻击（SCA）的有洞察力的讨论，强调了在漏洞赏金计划中进行仔细评估的必要性。这种开放对话确保这些复杂的威胁得到适当处理，公司和黑客合作有效降低风险。

有趣的是，没有任何安全扫描器捕获了我们的小规模数据泄露，但npm仍然控制了包并禁止了我们的账户。发生的事情是，受影响的公司通过电子邮件联系了npm，要求他们撤下我们认领的包，甚至在我们提交报告之前，作为他们安全流程的一部分。通过这样做，他们错过了使用pingback探针调查哪个开发人员、管道或服务器配置错误的机会，留下了修复中的盲点。npm团队最终以以下消息认领了包：

安全保管包：此包包含恶意代码，已被npm安全团队从注册表中移除。发布了一个占位符，以确保用户在未来不受影响。

由于这个原因，即使对于Consul的旧版本，这个漏洞也不再可被利用。

向 HashiCorp 披露

在我们首次披露后不久，Caleb将我们与HashiCorp的安全团队联系起来。他们收到了报告的编辑版本，并迅速采取行动解决漏洞。团队实施了补丁，将package.json文件中的通配符依赖替换为本地文件引用。原始配置：

"consul-acls": "*","consul-lock-sessions": "*","consul-nspaces": "*","consul-partitions": "*","consul-peerings": "*",

已更新为：

"consul-acls": "file:../consul-acls","consul-lock-sessions": "file:../consul-lock-sessions","consul-nspaces": "file:../consul-nspaces","consul-partitions": "file:../consul-partitions","consul-peerings": "file:../consul-peerings",

当被问及为什么他们选择该协议而不是像 这样的命名空间解决方案时，HashiCorp 解释说，许多文件都包含硬编码引用。切换到命名空间包需要大量重构，从而使文件协议成为更简单、更快速的修复。您可以在此处的安全公告中找到更多详细信息。file:@namespace/package

总之，这个漏洞影响了HashiCorp Consul和Consul Enterprise的开发工作流程，从版本1.12.0到1.19.0。虽然它没有影响生产环境，但问题已在Consul 1.17.7、1.18.3和1.19.1中解决。这个问题源于2022年3月引入的模糊依赖解析，这使得Lupin & Holmes团队能够在npm注册表上发布一个“恶意”包，并在受影响的开发环境中运行任意代码。这个漏洞已经被修复，方法是明确使用file:协议来引用本地包。

使用预构建Consul二进制文件的客户不受影响，但那些从源代码构建Consul UI的客户应该升级到修补过的版本。

安全研究的一个有趣的点是，尽管HashiCorp不提供带有财务奖励的漏洞赏金计划，但他们仍然重视识别和协调披露安全漏洞的努力。他们提供了如何向他们报告漏洞的指导。请参阅 HashiCorp 的漏洞报告。

结论

Depi 在保护软件供应链方面发挥着关键作用，通过识别依赖关系之间常被忽视的链环中的漏洞。在这种情况下，Depi不仅在HashiCorp的Consul开发环境中标记了一个攻击向量，还突出了简单的配置错误可能导致的重大风险。通过关注更广泛的依赖网络，Depi帮助组织领先于供应链攻击，更好地保护他们的系统。

漏洞赏金计划对我们的研究和开发过程至关重要。它们为我们的Lupin & Holmes团队提供了一个现实世界的测试场，以发现和验证新类型的漏洞，然后我们可以将这些漏洞纳入Depi的检测能力。通过这些计划与道德黑客的合作确保我们在软件供应链安全方面保持领先地位，根据从现实世界场景中获得的经验不断改进我们的工具。

我们要向Caleb Sima表示衷心的感谢，感谢他的指导，以及HashiCorp团队在整个过程中的快速响应、透明度和开放沟通。特别是HashiCorp的ProdSec团队和Consul R&D团队。他们愿意合作，确保漏洞得到迅速解决，强化了研究人员、道德黑客和安全团队之间合作的重要性，以保持软件生态系统的安全。

建议点击公众号右上角“三个点”，

将本公众号设置为星标

后期发布优质岗位不错过。

原文始发于微信公众号（b1gpig信息安全）：利用隐藏供应链链接攻击财富500强企业