什么鬼？我能通过依赖混淆攻击在 Halo 游戏服务器中执行命令，微软不 care？！ – 作者:奇安信代码卫士

研究员可以利用依赖混淆攻击在 Halo Microsoft 服务器中执行命令，但微软安全响应中心 (MSRC) 表示并非问题。

神秘依赖关系 “swift-search”遭劫持

研究员 Ricardo Iramar dos Santos在 https://github.com/symphonyoss/SymphonyElectron （开源包 SymphonyElectron）上查找 bug 时，发现文件 https://github.com/symphonyoss/SymphonyElectron/blob/main/package.json 上npm 包使用了一个名神秘依赖关系 “swift-search”。但是该包并未出现在公开的 npmjs.com 注册表上，而是发布在 https://www.npmjs.com 上，因此研究员在多个版本下发布了一个包并提供了一个很不错的预安装。这样，当有人安装了该包时作者就会知道。

该攻击即“依赖混淆”攻击。“混淆攻击”表示的是检索某软件包的依赖关系时，多种开源库管理器中存在继承弱点。如果项目使用了私有的、内部创建的依赖关系且公开库中存在具有相同名称的依赖关系时，它将为开发工具在关于指向哪个依赖关系方面制造“混淆”。具有相同名称的公开依赖关系将被拉取到开发环境中而不是意向的私有仓库。因此，“依赖混淆”或劫持攻击可使攻击者在自动化的供应链攻击中将恶意代码注入内部应用程序中。今年3月，攻击者利用“依赖混淆“技术利用恶意代码成功攻击35家著名企业。

目前，dos Santos创建的伪造版本已被从 npm 公共库中永久删除。

dos Santos 所创建的包中包含的代码评估易受依赖关系混淆攻击的系统中的敏感参数，并更新至研究员的 PoC 服务器中。

这些字段和文件包括：

1、系统主机名和账户用户名

2、环境变量 (env)

3、OS 名称和版本信息

4、系统的公共 IP 地址（IPv4 或 IPv6）

5、/etc/hosts 文件

6、/etc/passwd 文件

7、/etc/shadow 文件

被黑的微软 Halo 游戏服务器响应

向 npm 注册表发布该包的几小时后，dos Santos在 Burp Collaborator 实例中得到了微软服务器的响应。DNS 查询源自 13.66.137.90（它是微软的一个 DNS 服务器），之后是来自51.141.173.203的POST请求，它也是微软的一个 IP 地址（英国）。

inetnum: 51.140.0.0–51.145.255.255org: ORG-MA42-RIPEnetname: MICROSOFTdescr: Microsoft Limited UKcountry: GB

访问https://51.141.173.203时，dos Santos注意到证书的 CN 字段指向 “*.test.svc.halowaypoint.com”，说明它是微软提供的一种服务。dos Santos通过预安装脚本执行的其中一个命令是 “env”。如下可看到可从服务器提取的env 输出的某些行。

DEPLOYMENT_BASEPATH=/opt/runner​USER=runner​npm_config_user_agent=npm/6.14.12 node/v12.22.1 linux x64 ci/github-actions​GITHUB_ENV=/home/runner/work/_temp/_runner_file_commands/set_env_73c3242d-3ebe-4fef-b35e-4c01f044ff0b​PIPX_HOME=/opt/pipx​GRAALVM_11_ROOT=/usr/local/graalvm/graalvm-ce-java11–21.0.0.2​AZURE_EXTENSION_DIR=/opt/az/azcliextensions​npm_package_description=swift-search​ImageVersion=20210412.1​SWIFT_PATH=/usr/share/swift/usr/bin​GITHUB_RUN_ID=773121366​GOROOT_1_16_X64=/opt/hostedtoolcache/go/1.16.3/x64​ANT_HOME=/usr/share/ant​RUNNER_TRACKING_ID=github_ade7a12e-905e-4b34-b09e-b3ddda770183​HOMEBREW_CELLAR=”/home/linuxbrew/.linuxbrew/Cellar”​npm_package_name=swift-search

说明微软服务器遭 dos Santos 的依赖关系劫持攻击。BleepingComputer 证实称，halowaypoint.com 子域名中出现的SSL证书确实将微软公司列为其背后的组织机构，而 51.141.173.203 的 WHOIS 记录也将微软列为所属公司。但无法找到能够将 IP 地址51.141.173.203 和微软域名或 SSL 证书关联在一起的反向查询记录，这说明漏洞报告提交后，该 IP 地址被下线。

MSRC的迷惑行为

微软向BleepingComputer 表示，“我们调查后认为底层问题已经在收到漏洞报告前解决了。”另外微软指出漏洞报告引用了由第三方变更引入的一个问题，且目前并未有证据表明客户受影响。

dos Santos 在博客文章中提到：

于是，我有了一个糟糕的主意：把漏洞告知微软安全响应中心。由于从某种程度上讲我是偶然发现该漏洞的，所以认为不会收到回复。微软的回复如下：“我们评估后认为该问题应该直接报告给 SymphonyElectron 的维护人员。感谢和我们分享该信息。MSRC 不会采取任何措施，我将关闭该案件。”什么？！这并非MSRC第一次对漏洞置之不理，我相信这次也并非最后一次。让人惊讶的是，一小时后我收到了 MSRC 发送的另一份邮件，内容是“另外，还有一件事。您有通过 PoC 复现这个问题的时间戳吗？”

等等！MSRC 先是表明这个漏洞与它无关，现在又想要复现？虽然本打算忘掉这个报告，但还是向他们解释了这个漏洞。我写了一份详细的邮件解释为何它是一个严重漏洞，并以如下内容结尾：“我会等待你们证实我所写的内容，时间截止到明天结束之前。如果你们不回复或者不同意我的内容，没关系，这说明你们认为它不是问题，我将在 Medium 上发布我们所讨论所有内容。”接下来的几天，我收到了回复邮件称，“我将会请工程师审计你所发的内容，我将尽快与你同步消息。”

虽然我不会泄露这个发件人的姓名，但这是我第一次从 MSRC 收到的带姓名的邮件。两天后我要求同步信息但未收到回复。又过了两天，我编写了如下邮件，再次尝试和他们取得联系：“由于我没有收到任何回复，你们也没有提供针对报告任何位置的 ETA，因此我将给你们一个最后期限。如果在6月23日之前未收到任何关于该漏洞的解决方案，我认为你们同意发布该报告的所有内容。”

来源：freebuf.com 2021-07-09 11:36:28 by: 奇安信代码卫士