Microsoft recently fixed 129 vulnerabilities (across its range of software products). Eleven errors are critical and should be corrected as soon as possible.

Attackers (local) can use group policy errors to take over entire Windows enterprise systems. Microsoft has now released a patch to fix the bug. This means that vulnerable user accounts can place malicious DLLs on the system.

The problem (CVE-2020-1317) affects one of the most basic mechanisms for centrally managing the settings of Windows computers and users in Active Directory environments: the so-called group policies. The bug is also old and is present in all versions of Windows for Windows Server 2008 desktops and servers.

Microsoft describes:

“An elevation of privilege vulnerability exists when Group Policy does not properly check 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 of the affected system. "

How an attacker could exploit the vulnerability in Group Policy:

Group Policy settings are saved on Windows systems as Group Policy Objects (GPO). The domain administrator can distribute them from the domain controller over the network. By default, Group Policy updates are not instant, it takes time. For this reason, Windows includes a tool called GPUpdate.exe that the user can use to request GPO updates (from the domain controller).

CyberArk in a blog post:

“Interestingly, a group policy update can be requested manually by a local non-privileged user. So if you find a bug in the Group Policy update, you can always trigger it yourself to allow for a possible attack. ”

The service called GPSVC performs the Group Policy updates called the svchost.exe process. With the highest possible permissions, this service runs as expected in the context of NT AUTHORITY \ SYSTEM.

Group Policy updates can be associated with a computer, site, domain, or organizational unit. The service saves it as a file called Applied-Object.xml, which is then renamed to the type of object to which the policy applies. For example, a policy for printers would be translated to Printers \ Printers.xml. GPO updates associated with an organizational unit that target all users and computers in the domain are stored in a location on the computer in the %localappdata% directory that each local user can access.

The service does not change its context and permissions for the local user who requested the update, but instead writes the file with LocalSystem permissions. Nonprivileged users can use GPUpdate.exe to trigger file writes with LocalSystem privileges in a directory they have access to.

Finally, the user can create a symlink specifying the location of the target file to be written, e.g. Printers.xml is associated with a system file that is located in a protected Windows directory such as C: \ Windows \ System32 \ and contains many files that are run by the operating system kernel. This means that when the GPSVC tries to write the Printers.xml file to a location that is accessible to the user, e.g. the file in C: \ Windows \ System32 \ can even be because it works with system permissions.

To address the vulnerability in the GPO, Microsoft had to correct how Group Policy checked access. This was certainly not easy as it is a basic mechanism for Windows administration. CyberArk reported the problem last June. Microsoft therefore needed a whole year to publish an update. Patches for all affected operating systems had to be developed.