标题 | 简介 | 类型 | 公开时间 | ||||||||||
|
|||||||||||||
|
|||||||||||||
详情 | |||||||||||||
[SAFE-ID: JIWO-2024-3273] 作者: 大猪 发表于: [2023-02-19] [2023-02-19]被用户:大猪 修改过
本文共 [508] 位读者顶过
SUMMARYA 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 AFFECTEDTests (April 06, 2022) were conducted on the following Active Directory setup:
PREREQUISITESA 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 SETUPTo 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 WRITEDue 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
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 CAUSESA 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 FIXMicrosoft 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. |