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

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

此漏洞与CVE-2019-0841（Windows DACL权限覆写权限提升漏洞，该漏洞允许低权限的用户通过覆写目标文件的权限来劫持属于NT AUTHORITY\SYSTEM的文件。成功利用就可以使低权限的用户获得对目标文件的完全控制权限。）和CVE-2020-1317（Windows组策略中的漏洞，Windows的组策略机制已经存在很久了。它被认为是在域环境中分发设置的相对安全的方法，不管是打印机设置、备份设备设置，还是其他什么设置。因此，组策略需要与许多组件交互，许多交互就意味着存在许多潜在的漏洞。）相似，但最终结果相同，只是此漏洞是由组策略更新触发的。

漏洞介绍

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

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

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

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

进程监视器过滤器设置

进程监视器高亮显示设置

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

Procmon输出组策略更新用户GPO

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

“SetSecurityFile”操作标识

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

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

但是，如果我们向下移动文件夹结构并分析每个文件夹，则你会注意到一个小的差异。 ％programdata％\ Microsoft \ GroupPolicy \ Users \

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

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

这个过程很有趣，通过在sysvol中创建一个连接到所选位置的新文件夹，我们可以控制组策略服务将打开哪些文件和文件夹。在接下来的实验中，我们告诉它去C：\ Program Files（x86）\ Microsoft，它自然地遵循了由低权限用户所建立的Directory Junction。

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

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

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

下一个问题是编写的DACL是否足够宽松，如果宽松就可以为攻击者提供权限升级的路径：

以前的DACL权限

组策略更新和目录连接重新解析后的DACL权限

在成功地将其解析到多个位置之后，我注意到当由于系统用户没有足够的权限或者由于所使用的文件在使用中而导致DACL写入进程突然中断时，写入的权限实际上授予了低权限用户的完全控制权限。

访问漏洞导致DACL写入进程被停止

强制执行漏洞的一种方法是在完成写入DACL操作之前删除连接点，可以使用机会锁(oplock)检测删除连接点的正确时刻。

漏洞利用

我们可以使用此行为通过使用连接点和操作锁来设置文件夹/文件（其中SYSTEM具有完全控制权限或SYSTEM是文件所有者）的文件权限。

低权限用户在VMware Tools文件夹上的权限不足

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

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

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

低权限用户现在拥有“VMware Tools”文件夹的全部权限

下面我们将找第二个示例，其中低权限用户尝试劫持C：\ Windows \ System32 \ config中的文件。在这种情况下，操作锁永远不会被触发，因为当DACL写入操作失败时，操作会被上一个文件中止。但是，config文件夹中的部分内容具有新的DACL，包括SAM文件。

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

概念验证

我提供了一个PoC，可自动执行劫持，它应该作为没有管理权限的低权限用户执行。

1.将PoC解压缩到本地硬盘上一个普通用户可以写的位置。

2.通过传递一个参数来执行PoC可执行文件，该参数指定你要将连接点重定向到的文件夹的路径，例如FolderTakeover.exe C:\Windows\System32\Tasks。

本文翻译自：https://www.zerodayinitiative.com/blog/2020/10/27/cve-2020-16939-windows-group-policy-dacl-overwrite-privilege-escalation如若转载，请注明原文地址：