The patch of the vulnerability in Windows Group Policy not to be overlooked

Yesterday, Microsoft delivered 129 patches to fix flaws in several of its software, from Windows and Office to Visual Studio, Azure DevOps and Microsoft Apps for Android. Eleven of these vulnerabilities are classified as “critical” and must be corrected immediately. But one particular vulnerability could be easily overlooked and allow hackers with local access to take full control of corporate Windows systems. The flaw, referenced CVE-2020-1317, affects one of the most fundamental mechanisms for centrally managing the settings of Windows machines and users in Active Directory environments: Group Policy or Group Policy. More importantly, the flaw is old and exists in all desktop versions of Windows and in all server versions starting with Windows Server 2008.

Microsoft considers the flaw to be serious. “The elevation of privilege flaw is exploitable when Group Policy’s access check is incorrect. If an attacker successfully exploits this vulnerability, they can run processes in an elevated context. To exploit the vulnerability, the attacker must first log into the system, and then run a specially crafted application to take control of the affected system. Microsoft’s security advisory does not contain any further information, but according to CyberArk researchers who discovered the vulnerability, it is quite serious.

Exploiting Group Policy Vulnerability

In Windows systems, Group Policy or Group Policy settings are stored as Group Policy Objects (GPOs). These GPOs can be distributed by the domain administrator over the network from the domain controller. However, Group Policy updates are not instantaneous by default and usually take time to propagate across a network. It is for this reason that Windows includes a tool called GUpdate.exe that users can run to request GPO updates from the domain controller instead of waiting. “Interestingly, a local user without privileges can manually request a Group Policy update,” CyberArk security researchers said in a blog post. “So if you happen to find a bug in the Group Policy update process, you can trigger it yourself at will, making it easier for a potential attack.”

Group Policy updates are managed by a service called GPSVC which runs under the process svchost.exe, which manages many services in Windows. As expected, this service runs with the highest possible privileges, in the context of the NT AUTHORITYSYSTEM. Group Policy updates can be tied to a machine, site, domain, or organizational unit, and the service saves them to a file called Applied-Object.xml, which is then renamed based on the type of object to which the policy applies. For example, a policy on printers will be translated into PrintersPrinters.xml. Researchers found that updates to Group Policy Objects (GPOs) tied to an organizational unit—these updates target all users and computers in the domain—are saved to a location on the computer under the %localappdata%accessible to any local user.

Also, by performing this operation, the service does not transfer its context and privileges to the local user who requested the update – a transfer known as impersonation in Windows API parlance – but it performs the file write operation with local system privileges. Therefore, this mechanism provides for a situation where an unprivileged user can use GUpdate.exe to trigger file write operations with LocalSystem privileges to a directory it has access to.

The last step in this exploit chain is for the user to create a symbolic link that connects to the location of the target file 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 are located. This means that when the GPSVC tries to write the file Printers.xml in the place accessible to the user, it will actually be directed to a file in the directory C:WindowsSystem32which it can do, since it runs with system privileges.

This is how CyberArk researchers describe the different stages:

– List the Group Policy globally unique identifiers (GUIDs) present in C:UsersuserAppDataLocalMicrosoftGroup PolicyHistory.

– If you have multiple GUIDs, check which directory was updated recently.

– Go to this directory and the subdirectory, which is the user’s SID security identifier.

– Look at the last modified directory. This varies depending on the environment. In the example chosen here, it was the directory Printers.

– Delete the file Printers.xml in the directory Printers.

– Create an NTFS mount point to RPC Control + an Object Manager symbolic link with Printers.xml pointing at C:WindowsSystem32whatever.dll.

– Open your favorite terminal and launch gpupdate.

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

The value of privilege escalation loopholes

In general, vulnerabilities that facilitate privilege escalation are not considered “critical” because to exploit them, attackers must already have even limited access to the local computer. However, attackers have several solutions to gain access to a system: using phishing emails containing malicious attachments, causing drive-by downloads, exploiting vulnerabilities in any application. Therefore, it is standard security practice for users of a Windows system to have limited privileges and for the applications they run to have limited privileges, i.e. the least possible privileges to be able to operate.

Due to improvements in the security architecture of modern operating systems and efforts by developers to reduce their attack surface, it is quite rare to find a vulnerability that can be exploited remotely without authentication on a network or the Internet, which gives direct and complete access to the system. Today, most attacks use exploit chains that combine multiple vulnerabilities, and privilege escalation flaws are an important part of those chains, and often the last step before the attacker takes control of the exploit. whole system.

Unfortunately, privilege escalation vulnerabilities are still common. As proof, as part of a research project conducted over a period of one year by CyberArk researchers, they found 60 such flaws in the products of major software vendors. On Windows, privilege escalation flaws are commonly found in the kernel and third-party drivers, but also in various system services, as is the case here. “These types of bugs are very common,” said CyberArk Labs researcher Eran Shimony. “During our research project, we found a lot of vulnerabilities of a similar nature, which means that developers are not fully aware of these vulnerabilities, but they are easy to avoid, so it would be great if they paid attention” .

To fix the Group Policy Objects (GPO) vulnerability, Microsoft had to patch the way Group Policy controls access, which probably wasn’t very straightforward, given that it’s a fundamental mechanism of Windows management. CyberArk first reported the issue to Microsoft in June last year. It therefore took the publisher a year to develop the update delivered yesterday. Microsoft also had to develop patches for all affected operating systems that are now out of support, but for which customers can still have extended subscription contracts for certain products that entitle them to security updates. This is particularly the case with Windows Server 2008, Windows Server 2012 and Windows 7.