Windows Installer, Exploiting Custom Actions

18 Jul 2024 - 发布者 Adrian Denkiewicz

一年多前，我发布了关于Windows Installer服务的研究。文章详细解释了MSI修复过程如何在提升的上下文中执行，但缺乏模拟可能导致任意文件删除和类似问题。微软承认了该问题（作为CVE-2023-21800），但从未直接修复。相反，重定向防护的引入缓解了msiexec进程上下文中的所有符号链接攻击。当时，我对这个解决方案并不特别满意，但找不到任何绕过方法。

重定向防护确实按预期工作，因此我花时间从其他角度攻击Windows Installer服务。发现了一些漏洞（CVE-2023-32016），但我始终觉得微软处理模拟问题的方式并不完全正确。这个未修复的行为在另一轮研究中变得非常有用。

本文描述了影响最新Windows 11版本的未修补漏洞。它说明了如何利用该问题提升本地用户权限。经过半年的处理，漏洞提交被关闭，原因是无法重现。我将演示其他人如何重现该问题。

自定义操作

在Windows Installer领域，自定义操作是用户定义的操作，用于扩展安装过程的功能。在Windows Installer内置功能不足的情况下，自定义操作是必要的。例如，如果应用程序需要根据用户环境动态设置特定的注册表键，可以使用自定义操作来实现。另一个常见用例是当安装程序需要执行复杂任务，如自定义验证或与其他软件组件交互，而标准MSI操作无法单独处理时。

总的来说，自定义操作可以通过不同方式实现：

• 使用公开的C/C++ API编译到自定义DLL中
• 在WSX文件中内联VBScript或JScript片段
• 在WSX文件中显式调用系统命令

所有上述方法都受到影响，但为简单起见，我们将重点关注最后一种类型。

让我们看一个包含一些自定义操作的示例WSX文件（poc.wsx）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Product Id="{12345678-9259-4E29-91EA-8F8646930000}" Language="1033" Manufacturer="YourCompany" Name="HelloInstaller" UpgradeCode="{12345678-9259-4E29-91EA-8F8646930001}" Version="1.0.0.0">
        <Package Comments="This installer database contains the logic and data required to install HelloInstaller." Compressed="yes" Description="HelloInstaller" InstallerVersion="200" Languages="1033" Manufacturer="YourCompany" Platform="x86" ReadOnly="no" />

        <CustomAction Id="SetRunCommand" Property="RunCommand" Value="&quot;[%USERPROFILE]\test.exe&quot;" Execute="immediate" />
        <CustomAction Id="RunCommand" BinaryKey="WixCA" DllEntry="WixQuietExec64" Execute="commit" Return="ignore" Impersonate="no" />
        <Directory Id="TARGETDIR" Name="SourceDir">
            <Directory Id="ProgramFilesFolder">
                <Directory Id="INSTALLFOLDER" Name="HelloInstaller" ShortName="krp6fjyg">
                    <Component Id="ApplicationShortcut" Guid="{12345678-9259-4E29-91EA-8F8646930002}" KeyPath="yes">
                        <CreateFolder Directory="INSTALLFOLDER" />
                    </Component>
                </Directory>
            </Directory>
        </Directory>
        <Property Id="ALLUSERS" Value="1" />
        <Feature Id="ProductFeature" Level="1" Title="Main Feature">
            <ComponentRef Id="ApplicationShortcut" />
        </Feature>
        <MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." Schedule="afterInstallValidate" />

        <InstallExecuteSequence>
            <Custom Action="SetRunCommand" After="InstallInitialize">1</Custom>
            <Custom Action="RunCommand" After="SetRunCommand">1</Custom>
        </InstallExecuteSequence>
    </Product>
</Wix>

这看起来是一个完美的WSX文件。它定义了InstallExecuteSequence，由两个自定义操作组成。SetRunCommand被安排在InstallInitialize事件之后立即运行。然后，RunCommand应该在SetRunCommand完成后立即启动。

SetRunCommand操作简单地设置RunCommand属性的值。[%USERPROFILE]字符串将被扩展为当前用户配置文件目录的路径。这是通过安装程序使用USERPROFILE环境变量的值实现的。扩展过程涉及在运行时检索环境变量的值，并用该值替换[%USERPROFILE]。

第二个操作，也称为RunCommand，使用RunCommand属性并通过调用WixQuietExec64方法执行它，这是一种安静安全地执行命令的好方法（不产生任何可见窗口）。Impersonate=“no"选项使命令能够以LocalSystem的完整权限执行。

在健康系统上，任何低权限用户都无法访问管理员的USERPROFILE目录。RunCommand执行的任何文件都不应直接由非特权用户控制。

我们涵盖了一个相当简单的示例。实现预期的自定义操作实际上相当复杂。可能会犯很多错误。操作可能依赖不受信任的资源，它们可能产生可劫持的控制台实例，或者以比必要更多的权限运行。这些危险的错误可能在未来的博客文章中涵盖。

测试安装程序

有了WiX工具集，我们可以将XML转换为MSI文件。请注意，我们需要启用额外的WixUtilExtension来使用WixCA：

1
2

candle .\poc.wxs 
light .\poc.wixobj -ext WixUtilExtension.dll

poc.msi文件应在当前目录中创建。

根据上面的WSX文件，一旦安装初始化，我们的自定义操作应该运行”[%USERPROFILE]\test.exe"文件。我们可以设置ProcMon过滤器来查找该事件。记得还要启用"Integrity"列。

我们可以使用任何管理员帐户（这里是Almighty用户）安装应用程序：

1

msiexec /i C:\path\to\poc.msi

ProcMon应记录CreateFile事件。文件不存在，因此尝试了其他文件扩展名。

通过运行安装修复过程可以重现相同的操作序列。命令可以指向特定的C:/Windows/Installer/*.msi文件或使用我们在WSX文件中定义的GUID：

1

msiexec /fa {12345678-9259-4E29-91EA-8F8646930000}

如果Almighty用户触发了修复过程，结果应该完全相同。

另一方面，请注意如果安装修复是由另一个非特权用户启动的情况：lowpriv。

是用户的环境设置了可执行路径，但命令仍然以系统级完整性执行，没有任何用户模拟！这导致了直接的权限提升。

作为最终确认，lowpriv用户将在C:/Users/lowpriv/test.exe路径下植入一个add-me-as-admin类型的有效负载。安装过程在test.exe运行期间不会完成，但处理这种行为相当简单。

可选地，为修复命令添加/L*V log.txt以获取详细日志。中毒的属性应该很明显：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

MSI (s) (98:B4) [02:01:33:733]: Machine policy value 'AlwaysInstallElevated' is 0
MSI (s) (98:B4) [02:01:33:733]: User policy value 'AlwaysInstallElevated' is 0
...
Action start 2:01:33: InstallInitialize.
MSI (s) (98:B4) [02:01:33:739]: Doing action: SetRunCommand
MSI (s) (98:B4) [02:01:33:739]: Note: 1: 2205 2:  3: ActionText
Action ended 2:01:33: InstallInitialize. Return value 1.
MSI (s) (98:B4) [02:01:33:740]: PROPERTY CHANGE: Adding RunCommand property. Its value is '"C:\Users\lowpriv\test.exe"'.
Action start 2:01:33: SetRunCommand.
MSI (s) (98:B4) [02:01:33:740]: Doing action: RunCommand
MSI (s) (98:B4) [02:01:33:740]: Note: 1: 2205 2:  3: ActionText
Action ended 2:01:33: SetRunCommand. Return value 1.

中毒的变量

msiexec.exe中的修复操作可以由标准用户启动，同时自动提升其权限以执行某些操作，包括MSI文件中定义的各种自定义操作。值得注意的是，并非所有自定义操作都以提升的权限执行。具体来说，操作必须明确标记为Impersonate=“no”，安排在InstallExecuteSequence和InstallFinalize事件之间，并使用commit、rollback或deferred作为执行类型才能以提升的权限运行。

未来，我们可能会发布其他材料，包括用于查找满足上述条件的受影响安装程序的工具集。

提升的自定义操作可能使用环境变量以及Windows Installer属性（参见属性完整列表）。我观察到以下属性可以被调用修复过程的标准用户"中毒"：

• “AdminToolsFolder”
• “AppDataFolder”
• “DesktopFolder”
• “FavoritesFolder”
• “LocalAppDataFolder”
• “MyPicturesFolder”
• “NetHoodFolder”
• “PersonalFolder”
• “PrintHoodFolder”
• “ProgramMenuFolder”
• “RecentFolder”
• “SendToFolder”
• “StartMenuFolder”
• “StartupFolder”
• “TempFolder”
• “TemplateFolder”

此外，以下环境变量通常被软件安装程序使用（此列表并非详尽无遗）：

• “APPDATA”
• “HomePath”
• “LOCALAPPDATA”
• “TEMP”
• “TMP”（同时，一个单独的补丁引入了SystemTemp概念并修复了这两个变量。感谢@pfiatde指出！）
• “USERPROFILE”

这些值通常用于构建自定义路径或作为系统命令参数。中毒的值可以改变命令的意图，可能导致命令注入漏洞。

请注意，描述的问题本身不可利用。利用易受攻击的自定义操作的MSI文件必须已经安装在机器上。但是，该问题可能对执行本地权限提升的渗透测试人员或作为持久化机制很有用。

披露时间线

该问题的详细信息于2023年12月1日报告给微软安全响应中心。该漏洞在报告时的最新Windows Insider Preview版本上得到确认：26002.1000.rs_prerelease.231118-1559。

我们要求微软重新打开票证，并且在发布之前与微软分享了博客文章草稿。

截至目前，该问题仍未修复。我们确认它影响了当前最新的Windows Insider Preview版本10.0.25120.751。

其他相关文章：

• Windows Installer EOP (CVE-2023-21800) - 2023年3月21日
• SSRF Cross Protocol Redirect Bypass - 2023年3月16日
• Let’s speak AJP - 2022年11月15日
• Diving Into Electron Web API Permissions - 2022年9月27日
• Regexploit: DoS-able Regular Expressions - 2021年3月11日
• Researching Polymorphic Images for XSS on Google Scholar - 2020年4月30日
• One Bug To Rule Them All: Modern Android Password Managers and FLAG_SECURE Misuse - 2019年8月22日
• Jackson gadgets - Anatomy of a vulnerability - 2019年7月22日