绕过ACL：访问受保护的WindowsApps文件夹

最近关于Windows 11的Recall功能及其安全性的讨论很多。特别是关于存储银行详情、性癖等敏感信息的数据库如何防范恶意软件窃取的讨论。剧透警告：该数据库仅通过ACL限制为SYSTEM访问，因此任何权限提升都足以泄露信息。

不过，我并未在自己的设备上设置Recall，而且这些文件可能确实被正确设置了ACL。因此，本文不讨论Recall，而是关注Albacore在Mastodon上关于Recall数据库安全性的讨论，其中一条消息引起了我的兴趣：

“@DrewNaylor 文件资源管理器始终以非提升权限运行，管理员虽然可以访问C:\Program Files\WindowsApps，但无论怎么尝试，不破坏ACL就无法在文件资源管理器中打开它。”

基于我对"C:\Program Files\WindowsApps"文件夹的了解，我认为这并不正确，因此决定尝试在非提升权限的explorer中显示该文件夹。由于各种原因，这比想象中更复杂，让我们深入探究。

什么是WindowsApps文件夹？

WindowsApps文件夹用于存储打包应用程序的系统安装，如UWP、Desktop Bridge、计算器等。确实，如果尝试从非提升权限的应用程序查看该文件夹，会收到访问被拒绝的错误：

1
2


PS> ls 'C:\Program Files\WindowsApps\'
ls : Access to the path 'C:\Program Files\WindowsApps' is denied.

微软为何这样做？如果让我猜测，这是为了阻止用户浏览到打包应用程序并双击可执行文件，从而因无法运行而感到困惑。打包应用程序大多是普通的PE文件，但不能直接执行。相反，需要调用涉及COM和/或容器API的复杂序列来设置运行时环境。

这个猜测似乎合理，因为如果你知道打包应用程序的名称，完全可以列出其内容，只有顶层的WindowsApps文件夹被阻止访问。

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


PS> ls 'C:\Program Files\WindowsApps\Microsoft.WindowsCalculator_11.2403.6.0_x64__8wekyb3d8bbwe'
    Directory: C:\Program Files\WindowsApps\Microsoft.WindowsCalculator_11.2403.6.0_x64__8wekyb3d8bbwe
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        2024-05-15     19:42                AppxMetadata
d-----        2024-05-15     19:42                Assets
-a----        2024-05-15     19:42          54073 AppxBlockMap.xml
-a----        2024-05-15     19:42          11431 AppxManifest.xml
-a----        2024-05-15     19:42          12255 AppxSignature.p7x
-a----        2024-05-15     19:42        4179968 CalculatorApp.dll
-a----        2024-05-15     19:42          19456 CalculatorApp.exe
<SNIP>

检查ACL

无法访问WindowsApps文件夹的原因似乎是ACL。因此，我们从管理员PowerShell提示符检查ACL：

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


PS> Format-Win32SecurityDescriptor 'C:\Program Files\WindowsApps\' -MapGeneric
Path: C:\Program Files\WindowsApps\
Type: File
Control: DaclPresent, DaclAutoInherited, DaclProtected
<SNIP>
 - Type  : AllowedCallback
 - Name  : BUILTIN\Users
 - SID   : S-1-5-32-545
 - Mask  : 0x001200A9
 - Access: GenericExecute|GenericRead
 - Flags : None
 - Condition: Exists WIN://SYSAPPID

我移除了所有输出，只保留了最后一个ACE，因为这是重要的部分。ACL的其余部分没有其他引用普通用户的ACE，只有管理员。它显示BUILTIN\Users组应该获得读取和执行访问权限，但前提是用户的访问令牌中存在WIN://SYSAPPID安全属性。

这就是无法在资源管理器中列出文件夹的原因：进程令牌没有WIN://SYSAPPID属性，因此访问被拒绝。

WIN://SYSAPPID属性的作用

当执行打包应用程序时，该属性会被添加到访问令牌中，并包含有关包标识的信息。然后，应用程序或内核可以引用它来检查进程所属包的信息。由于在令牌上设置此安全属性需要SeTcbPrivilege，因此很难伪造。

在这种情况下，我们不需要伪造属性的特定值，它只需要存在。我们无法创建它，但也许可以借用现有的访问令牌来获得访问权限。

寻找合适的访问令牌

很可能有一个以用户身份运行的进程设置了WIN://SYSAPPID属性。由于该进程的主令牌应该是同一用户，因此我们可以模拟它来访问WindowsApps文件夹。首先，让我们找到一个具有合适令牌的进程：

1
2
3
4
5
6


PS> $ps = Get-NtProcess -FilterScript { 
 Use-NtObject($token = Get-NtToken -Process $_ -Access Query, Duplicate) { 
     "WIN://SYSAPPID" -in $token.SecurityAttributes.Name -and -not $token.AppContainer 
 }}
PS> $ps.Count
7

此脚本枚举所有可访问的进程，然后过滤到只有令牌具有WIN://SYSAPPID属性的进程。我们还过滤掉任何App Container令牌，因为它们可能也无法访问该文件夹，而且处理它们更麻烦。我们还确保可以打开令牌进行Duplicate访问，因为我们需要调用DuplicateToken从主令牌获取模拟令牌。在此示例中，有7个进程符合我们的条件。

最后，我们可以通过获取模拟令牌、模拟它然后枚举WindowsApps文件夹来测试访问。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


PS> $token = Get-NtToken -Process $ps[0] -Duplicate
PS> Invoke-NtToken $token { 
    ls 'C:\Program Files\WindowsApps\' 
}
    Directory: C:\Program Files\WindowsApps
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        2024-05-31     07:50                Deleted
d-----        2020-09-25     07:18                DeletedAllUserPackages
d-----        2019-12-07     01:53                Microsoft.Advertising...
<SNIP>

成功了！然而，这实际上并不是原始消息所说的内容。我应该能够在非提升权限的explorer窗口中显示WindowsApps文件夹。让我们尝试实现这一点。

完成工作

由于进程令牌是我们自己的用户并且在我们自己的登录会话中，因此我们满足从该进程复制新主令牌并使用CreateProcessAsUser的条件。不幸的是，有一个大问题：如果运行新的explorer副本，它会发现已有实例在运行，并调用现有实例显示新窗口。因此，永远不会有一个使用你指定令牌运行UI的explorer副本。

有一个"/SEPARATE"命令行参数可以传递，它会创建新的UI实例。不幸的是，不是你启动的进程留存，而是通过COM生成新的explorer实例，该实例托管UI。

相反，“最简单"的方法是终止所有explorer实例并生成一个新的。有点粗暴，但我认为公平。你应该使用非零退出代码终止，否则explorer实例将自动重新启动。

然而，还有第二个问题。如果你指定带有WIN://SYSAPPID属性的主令牌，你会发现进程启动后该属性不再存在。这是因为内核在为进程构建新令牌时会剥离此属性。有多种方法可以解决此问题，但最简单的方法是挂起启动进程，然后使用NtSetInformationProcess将令牌交换为带有属性的令牌。创建后设置令牌不会剥离属性。将所有内容整合在一起：

1
2
3
4
5
6


PS> $ex = Get-NtProcess -Name 'explorer.exe'
PS> $ex.Terminate(1)
PS> $token = Get-NtToken -Process $ps[0] -Duplicate -TokenType Primary
PS> $p = New-Win32Process "explorer.exe" -CreationFlags Suspended
PS> Set-NtToken -Process $p -Token $token
PS> Resume-NtProcess -Process $p

现在你可以导航到WindowsApps文件夹并查看结果。

希望这能让你对尝试绕过ACL的思考过程有所了解。

更新 2024/06/05 - 事实证明我关于Recall安全的看法是错误的。他们使用我在本文中描述的相同技术，只是他们需要特定的WIN://SYSAPPID，例如"MicrosoftWindows.Client.AIX_cw5n1h2txyewy”。你可以通过打开AIXHost.exe实例，获取其令牌并使用该令牌访问数据库文件来获取此属性的令牌。或者，由于文件由用户拥有，你可以直接重写文件的DACL并以这种方式获得访问权限，无需管理员权限 ;-)

绕过ACL访问限制的技术解析

本文详细解析了如何通过获取带有WIN://SYSAPPID属性的访问令牌来绕过WindowsApps文件夹的ACL访问限制，包含完整的PowerShell操作步骤和技术原理分析。