标题 简介 类型 公开时间
关联规则 关联知识 关联工具 关联文档 关联抓包
参考1(官网)
参考2
参考3
详情
[SAFE-ID: JIWO-2024-3273]   作者: 大猪 发表于: [2023-02-19]  [2023-02-19]被用户:大猪 修改过

本文共 [508] 位读者顶过

SUMMARY

A standard domain user can exploit Arbitrary File Write/Overwrite with NT AUTHORITY\SYSTEM under certain circumstances if Group Policy “File Preference” is configured. I reported this finding to ZDI and Microsoft fixed this in CVE-2022-37955 [出自:jiwo.org]

VERSIONS AFFECTED

Tests (April 06, 2022) were conducted on the following Active Directory setup:

  • Domain computer: Windows 10/Windows 11 & Windows Insider 11/Windows Member Server 2022, latest releases and fully patched
  • Domain controller: Windows Server 2016/2019/2022 with Active Directory functional level 2016

PREREQUISITES

A  Files preference Domain Group Policy has to be configured.

According to Microsoft this policy allows you to:

If such a policy is configured and a standard user has write access to the source and destination folder (not so uncommon scenario), it is possible to perform file write/overwrite with SYSTEM privileges by abusing symlinks thus elevating privileges to Administrator/SYSTEM.

Advertisements
<iframe id="inline-ad-0_iframe" frameborder="0" src="about:blank" class="ata-frame" style="height:250px;width:300px;">
REPORT THIS AD

A standard user can easily verify the presence and configuration of such a policy by looking for “Files.xml” in the SYSVOL share of the domain controllers.

GPO SETUP

To achieve the arbitrary file write exploitation, it is required to create a new Group Policy “File Preference”

In the following screenshot the setup of the policy:

In this example, the policy will copy the file source.dat from c:\sourcedir to dest.dat in c:\destdir.

The key point here is that these operations are performed without impersonation, running under the SYSTEM context.

ARBITRARY FILE WRITE

Due to the incorrect handling of links created via Windows Objectmanager’s symbolic links, it is possible to exploit this operation and place user-controlled content in any System protected location.

EXPLOITATION STEPS

  1. Create the directories if they do not exist and ensure “destdir” is empty
  2. Copy a malicious dll/exe or whatever in c:\sourcedir with the name “source.dat”
  3. Create a symbolic link pointing destination  destdir/file to a system-protected directory:
  4. Perform a gpupdate /force

As can be noticed from the previous screenshot, the domain user was able to copy a file in a system protected directory by controlling the contents and the name.  The screenshot of “procom” tool confirms the operations:

Having the possibility to create a user-controlled file in protected directories opens endless privilege escalation possibilities. One of the easiest ways is to overwrite “Printconfig.dll” located in “C:\Windows\System32\spool\drivers\x64\3” with the malicious dll, and instantiate the PrintNotify object which will force the service to load our malicious PrintConfig.dll, granting us a SYSTEM shell:

To replicate the findings reported in this report, Defender was disabled.

POSSIBLE CAUSES

A possible root problem can be identified within the function located in gpprefcl.dll which does not properly check the presence of junction points and symlinks:

THE FIX

Microsoft enforced the Redirection Guard for the Group Policy Client to prevent a process from following a junction point if it was created with a lower integrity level.


This successfully resolved all the security issues with Group Policy processing, many of which had been reported and partially addressed.

评论

暂无
发表评论
 返回顶部 
热度(508)
 关注微信