绕过ACL：探索WindowsApps文件夹访问技巧

最近有很多关于Windows 11的Recall功能及其安全性的讨论，尤其是关于存储银行详情、性癖等敏感信息的数据库如何防止恶意软件窥探。剧透一下，它仅通过ACL设置为SYSTEM权限保护，因此任何权限提升（或非安全边界咳嗽）都足以泄露信息。然而，我并没有花时间在任何机器上设置Recall，而且文件可能正确地设置了ACL。因此，这篇博客不讨论那个，而是跟随Albacore在Mastodon上关于Recall和数据库安全性的讨论，其中一条toot特别引起了我的兴趣。

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

基于我对"C:\Program Files\WindowsApps"文件夹的了解，我认为这不正确，所以我决定看看是否能在非提升的资源管理器中显示它。结果由于各种原因比应有的更复杂，让我们深入探讨。

什么是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>

似乎无法访问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安全属性时。我不解释这是如何工作的，请参阅我关于AppLocker的系列文章了解条件ACE的使用，或购买我的书。这就是为什么你不能在资源管理器中列出文件夹，进程令牌没有WIN://SYSAPPID属性，因此访问被拒绝。

WIN://SYSAPPID属性是干什么的？当打包应用程序执行时，它被添加到访问令牌中，并包含有关包身份的信息。然后应用程序或内核可以引用它来检查进程所属包的信息。由于在令牌上设置此安全属性需要SeTcbPrivilege，很难欺骗。

在这种情况下，我们不需要欺骗属性的特定值，它只需要存在。我们不能创建它，但也许有一个访问令牌我们可以借用给我们访问权限。

找到合适的访问令牌

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

1
2
3
4
5
6
7


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>

它工作了！然而，这实际上不是toot最初说的。我应该能够在非提升的资源管理器窗口中显示WindowsApps文件夹。让我们尝试这样做。

完成工作

由于进程令牌是我们自己的用户并在我们自己的登录会话中，那么我们满足从该进程复制新主令牌并使用CreateProcessAsUser的标准。不幸的是，有一个大问题，如果你运行一个新的资源管理器副本，它意识到已经有一个实例运行并调用现有实例显示新窗口。因此，从来没有一个资源管理器副本会运行带有你指定令牌的UI。有一个"/SEPARATE"命令行参数你可以传递，它确实创建一个新的UI实例。不幸的是，不是你启动的进程留下来，而是通过COM生成一个新的资源管理器实例，那是托管UI的。

相反，“最简单"的方法是终止所有资源管理器实例并生成一个新的。有点苛刻，但公平IMO。你应该以非零退出代码终止，否则资源管理器实例会自动重启。然而，有第二个问题。如果你指定一个有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并以那种方式获得访问，不需要管理员；-)