CVE-2020-16939：Windows 组策略 DACL 覆盖权限升级

十月，Microsoft发布了一个修补程序来纠正Windows组策略客户端中的漏洞。该漏洞可能允许攻击者以提升的权限执行代码。安全研究员Nabeel Ahmed向ZDI程序报告了此漏洞。他很亲切地提供了详细的文章和概念证明，详细介绍了ZDI-20-1254 / CVE-2020-16939。*

此漏洞滥用了SetSecurityFile组策略更新期间在上下文中执行的操作NT AUTHORITY\SYSTEM。对特定文件夹内的所有文件执行此操作。攻击者可以创建与另一个文件夹的目录连接，从而获得对该文件夹内容的完整权限。

此漏洞与CVE-2019-0841和CVE-2020-1317相似，但最终结果相同，只是此漏洞是由组策略更新触发的。

介绍

从Windows 8.1开始，就开始使用组策略缓存。出于性能目的，它将组策略的副本保留在本地缓存中。用户GPO设置存储在中%programdata%\Microsoft\GroupPolicy\Users，而计算机GPO设置存储在中%windir%\System32\GroupPolicy\DataStore。

漏洞

如前所述，当发生组策略更新时，策略将在本地缓存。我们对“用户GPO设置”缓存位置尤其感兴趣%programdata%\Microsoft\GroupPolicy\Users。这很有趣，因为%programdata%默认情况下即使是低特权用户也可以写。

我们首先来看一下gpupdate在Windows中以低特权用户身份启动命令时文件的外观。我们将使用Sysinternals的Process Monitor来查看各种文件操作。

我们将使用ProcMon过滤器并突出显示以下屏幕截图中显示的设置：

图1-进程监视器过滤器设置

图2-进程监视器突出显示设置

该gpupdate /target:user /force命令的输出如下所示：

图3-Procmon输出组策略更新用户GPO

当我们向下滚动操作列表并跳过与流程创建相关的部分时，我们很快就会开始看到SetSecurityFile显着执行的操作而没有模拟（缺少突出显示）。如果书面的自由访问控制列表（DACL）太宽容，那可能很重要。

图4-确定的“ SetSecurityFile”操作

稍后我们将看到，编写的某些DACL是允许的，从而完全控制了攻击者。但是，我们仍然没有可利用的条件，因为这些位置中的文件对于进行特权升级没有用处。为了尝试重定向这些DACL写入，以便将它们应用于对我们有用的文件，我们可以尝试在文件夹层次结构中放置目录连接。这可能导致组策略更新过程改为打开我们选择的目标文件夹，然后在其中写入DACL。

查看文件夹上的权限，我们注意到第一个障碍：如果已经发生了组策略更新，您会注意到在%programdata%\Microsoft\GroupPolicy\Users目录下，将基于每个域用户为其创建一个附加目录SID。此文件夹的权限不允许我们写。文件夹的所有者是Administrators组，并且该Users组仅具有从%programdata%\Microsoft文件夹继承的读取和执行权限。

图5

但是，如果我们向下移动文件夹结构并分析每个文件夹，则您会注意到一个小的差异。所述sysvol的文件夹下%programdata%\Microsoft\GroupPolicy\Users\<SID>\Datastore\0\的文件夹具有低特权用户作为文件夹（在下面的截图看到的）的所有者：

图6

由于低特权用户是sysvol文件夹的所有者，因此他们可以更改该文件夹的权限而不会出现太大问题。为此，低特权用户应禁用继承，然后向自己授予“完全控制”权限。

一旦完成，低特权用户就可以在sysvol目录下写入文件，并且在NT AUTHORITY\SYSTEM运行组策略更新时，该文件夹下的每个文件夹和文件都将受到DACL写入操作。

现在，这开始变得越来越有趣。通过在sysvol其中与选定位置的连接处创建一个新文件夹，我们可以控制组策略服务将打开的文件和文件夹。在下面的实验中，我们要求它转到C:\Program Files (x86)\Microsoft，并且它服从于低特权用户设置的Directory Junction。

图7-组策略服务后面是目录连接（重新分配点）

但是，通过放置目录连接来控制流并不一定意味着低特权用户可以滥用它来获取有用的东西。我们感兴趣的有用部分是DACL写操作。在目录联结“重定向”之后，写入操作会发生吗？

图8

在上面的屏幕截图中，您可以看到DACL权限确实被成功覆盖。

下一个问题是书面的DACL是否足够宽容，从而为攻击者提供了特权升级的途径。 Alas, no:

图9-DACL权限之前

图10-组策略更新和目录结点重新解析后的DACL权限

在成功地将其解析到多个位置之后，我注意到当DACL写入过程由于SYSTEM用户没有足够的特权而突然中断，或者由于所讨论的文件正在使用中而被写入时，写入的权限实际上授予了低特权用户Full Control权限。

图11-访问错误导致DACL写入过程被停止

一种强制错误的方法是在完成写入DACL操作之前删除连接点。可以使用机会锁（oplock）检测删除交界点的正确时刻 。

Exploit

我们可以使用此行为full control通过使用联结点和oplock来设置文件夹/文件（其中SYSTEM拥有权限或SYSTEM是文件的所有者）上的文件许可权。

图12-低特权用户对VMware Tools文件夹没有足够的特权

如您所见，我们当前以没有管理特权的普通用户身份登录。在此示例中，我们将尝试控制VMware Tools位于中的文件C:\Program Files\VMware。目前，我们仅对文件夹和其中的文件具有读取/执行权限。

我们创建了组策略的高速缓存中的结点文件夹sysvol指向C:\Program Files\VMware。连接点的名称应以开头$。我们还创建了另一个文件夹，其中包含一个随机文件。在该随机文件上，我们设置了一个OpLock，因此可能导致错误。

一旦触发了OpLock，我们将删除连接点并释放OpLock。由于DACL写入仅部分起作用，并且删除了联结点，因此Full Control保留了权限。成功利用后，当前用户对目标文件夹及其中的文件拥有完全权限。用户现在可以修改文件的内容，从而导致特权升级。

图13 –低特权用户现在对“ VMware Tools”文件夹具有完全权限

下面是第二个示例，其中低特权用户尝试劫持其中的文件C:\Windows\System32\config。在这种情况下，OpLock永远不会触发，因为该操作已被DACL写入操作失败的先前文件暂停。但是，config文件夹中的部分内容具有新的DACL（包括SAM文件）。

图14-低特权用户现在对“ SAM”文件具有完全权限

概念证明

我提供了一个PoC（https://github.com/thezdi/PoC/tree/master/...），它可以自动执行劫持。它应该以没有管理权限的低特权用户身份执行。

1. 将PoC提取到本地硬盘上普通用户可写的位置。
2. 通过传递一个参数来执行PoC可执行文件，该参数指定您要将连接点重定向到的文件夹的路径。例如： FolderTakeover.exe C:\Windows\System32\Tasks