Local attackers can use Group Policy flaw to take over enterprise Windows systems

Microsoft fixed 129 vulnerabilities today across its entire range of software products, from Windows and Office to Visual Studio, Azure DevOps and Microsoft Apps for Android. Eleven of those flaws are critical and should be patched immediately, but one particular vulnerability could be easily overlooked and could allow hackers with local access to take full control of enterprise Windows systems.

The issue, tracked as CVE-2020-1317, affects one of the most basic mechanisms for centrally managing the settings of Windows computers and users in Active Directory environments: Group Policy. More importantly, the flaw is old and exists in all Windows versions for desktops and servers beginning with Windows Server 2008. Microsoft rates it as important and describes it as such:

“An elevation of privilege vulnerability exists when Group Policy improperly checks access. An attacker who successfully exploited this vulnerability could run processes in an elevated context. To exploit the vulnerability, an attacker would first have to log on to the system, and then run a specially crafted application to take control over the affected system.”

The company’s advisory has no other information aside from that, but according to researchers from CyberArk who discovered the vulnerability, it is quite serious.

How an attacker can exploit the Group Policy vulnerability

Group Policy settings are stored on Windows systems as Group Policy Objects (GPO) and they can be distributed by the domain administrator over the network from the domain controller. However, Group Policy updates are not instant by default and usually take time to propagate over a network, which is why Windows includes a tool called GPUpdate.exe that users can run to request GPO updates from the domain controller instead of waiting for them.

“Interestingly enough, a Group Policy update can be requested manually by a local non-privileged user,” the security CyberArk security researchers said in a blog post. “So, if you manage to find a bug in the Group Policy update process, you can trigger it yourself whenever you want to — making a potential attack easier.”

The Group Policy updates are handled through a service called GPSVC that runs under the svchost.exe process, which handles many services in Windows. As expected, this service runs with the highest possible privileges, in the context of NT AUTHORITYSYSTEM.

Group Policy updates can be linked to a machine, site, domain or organizational unit and the service will save them as a file called Applied-Object.xml, which is then renamed to the type of object the policy applies to. For example, a policy on printers would be translated to PrintersPrinters.xml. The researchers found that GPO updates linked to an Organizational Unit — which target all users and computers in the domain — are saved in a location on the computer under the %localappdata% directory which is accessible to any local user.

Furthermore, while performing this operation the service does not switch its context and privileges to the local user who requested the update — known as user impersonation in Windows API language — but performs the file writing operation with LocalSystem privileges. Therefore, this mechanism provides for a situation where a non-privileged user can use GPUpdate.exe to trigger file write operations with LocalSystem privileges into a directory they have access to.

The last step in the exploit chain is for the user to create a symlink that links the targeted file location that will be written–for example, Printers.xml–to a system file located in a protected Windows directory such as C:WindowsSystem32 where many files executed by the operating system kernel live. This means when the GPSVC attempts to write the Printers.xml file in the user-accessible location, it will actually be directed to write a file in C:WindowsSystem32, which it can do because it operates with system privileges.

The CyberArk researchers describe the steps as such:

1. List the group policy GUIDs you have in C:UsersuserAppDataLocalMicrosoftGroup PolicyHistory.
2. If you have multiple GUIDs, check which directory was updated recently.
3. Go inside this directory and into the sub-directory, which is the user SID.
4. Look at the latest modified directory. This will vary in your environment. In my case, it was the Printers directory.
5. Delete the file, Printers.xml, inside the Printers directory.
6. Create an NTFS mount point to RPC Control + an Object Manager symlink with Printers.xml that points on C:WindowsSystem32whatever.dll.
7. Open your favorite terminal and run gpupdate.

The reason why the ability of non-privileged users to write files in protected OS directories is dangerous is because it can be used for a so-called DLL hijacking attack. The C:WindowsSystem32 directory is one of the first locations many applications or the OS searches when they want to load a particular DLL. If a malicious user can place a DLL with a specific name and malicious code in that directory, it will be executed by a service or application with LocalSystem privileges giving that code full control over the computer.

The value of privilege escalation flaws

Privilege escalation vulnerabilities do not generally receive critical severity ratings because to exploit them, attackers need to already have limited access to the local computer. However, attackers can gain access to a system in many ways, including phishing emails with malicious attachments, drive-by downloads, exploiting vulnerabilities in any application. That’s why it’s basic security practice for users on a Windows system to have limited privileges and the applications they run to have limited privileges — the least possible privilege they need to operate.

Due to improvements in the security architecture of modern operating systems and the developers’ efforts to reduce their attack surface, it’s quite rare to find a vulnerability that is remotely exploitable without authentication over a network or the internet and which directly results in complete system access. Most attacks these days use exploit chains that combine multiple vulnerabilities, and privilege escalation flaws are an important piece of those chains — the last step before the attacker gains control over the entire system.

Unfortunately, privilege escalation vulnerabilities are still common and this is one of over 60 such flaws found by the CyberArk researchers across products from major vendors as part of a year-long research project. On Windows, privilege escalation flaws are commonly found in kernel and third-party drivers, but also in various system services, like in this case.

“These types of bugs are very common,” Eran Shimony, researcher at CyberArk Labs, tells CSO. “During our research project, many of the vulnerabilities we found were of a similar nature, which means developers are not fully aware of these types of vulnerabilities, but they are easy to avoid so it would be wonderful if they would do it.”

Addressing the GPO vulnerability required Microsoft to correct how Group Policy checks access which was probably not an easy thing considering it’s a fundamental mechanism for Windows management. CyberArk first reported the issue to Microsoft in June last year, so it took the company a year to release an update. That might also be because it had to develop patches for all affected operating systems that are out of regular support but for which customers might still have extended security update subscriptions, including Windows Server 2008, Windows Server 2012 and Windows 7.