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
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
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.
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.
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.
- Create the directories if they do not exist and ensure “destdir” is empty
- Copy a malicious dll/exe or whatever in c:\sourcedir with the name “source.dat”
- Create a symbolic link pointing destination destdir/file to a system-protected directory:
- 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.
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:
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.
Thats all 😉