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

最近有很多关于Windows 11的Recall功能及其安全性的讨论。特别关注的是存储银行详情、性癖好等敏感信息的数据库如何防范恶意软件窥探。剧透警告：它仅通过ACL设置为SYSTEM权限保护，因此任何权限提升（或非安全边界咳咳）都足以泄露信息。

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

“@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>

它工作了！然而，这实际上不是原始消息所说的。我应该能在非提升权限的资源管理器窗口中显示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并以这种方式获得访问权限，无需管理员；-)