Tale of a Windows Error Reporting Zero-Day (CVE-2019-0863)

This post is also available in: 日本語 (Japanese)

In December 2018, a hacker who goes by the alias ‘SandboxEscaper’ publicly disclosed a zero-day vulnerability in the Windows Error Reporting (WER) component. Digging deeper into her submission, I discovered another zero-day vulnerability, which could be abused to elevate system privileges. According to the Microsoft advisory, attackers exploited this bug as a zero-day in the wild until the patch was released in May 2019.

So how did this bug work exactly?

Microsoft WER Under the Hood

The Windows Error Reporting tool is a flexible event-based feedback infrastructure designed to gather information about hardware and software problems that Windows can detect, report the information to Microsoft, and provide users with any available solutions.

For example, if Windows encounters a system crash or a failure, an error report is generated and stored under the WER report queue directory (C:\ProgramData\Microsoft\Windows\WER\ReportQueue), where each report gets its own subdirectory and a unique Report.wer INI file with the relevant metadata. To enable all processes to report their failures, the ReportQueue directory is writable for all users, as you can see below:

Figure 1. Windows Error Reporting queue directory

After a report is generated, it has to be sent to Microsoft for further analysis. This interaction can be triggered in several ways, one of which is by using a scheduled task called Windows Error Reporting\QueueReporting. This task is interesting from a security perspective because:

• It runs with System permissions, as defined in the ‘Security Options’ section of the task.
• It can be triggered on demand.
• It runs a dedicated binary code with a fixed command line argument – wermgr.exe -upload.

Figure 2. Windows Error Reporting Task Schedule

After it executes, wermgr.exe interacts with the pending report files and directories. It reads the files, parses them, copies them to other directories, and sometimes even deletes them. Point being, now we have a high privileged component accessing files that can be written by any user. If not implemented with caution, this could introduce some serious security vulnerabilities.

Abusing Filesystem Links

Windows supports different types of filesystem links, that can be used to point files and directories to other target files and directories. Quite simply, once the links are scanned and reparsed, they redirect the user to the target path(s). From a security perspective, the greatest threat comes from abusing hard links and mount points since users can link them to files or directories to which they have no writing permissions in the first place.

The example below depicts how a user with no writing permissions to kernel32.dll can create a link between c:\temp\Dir\x.dll and C:\Windows\System32\kernel32.dll. Being able to redirect to more privileged components is essentially all a hacker needs, enabling him to read, write and even delete sensitive, critical files.

Figure 3. Creating a hard link to a file that the user does not have privileges to writespa

Explaining the Bug

In short, the hacker exploits the ability of WER to change file permissions in order to assign himself read, write, edit and delete permissions to any other file he wants, by linking files in the report directory to different target files on the computer, using the above-mentioned filesystem linking.

In more detail, this is the full bug scenario:

• Step 1: wermger.exe parses all files in the report directories, one by one, and submits them to Microsoft.
• Step 2: When wermger.exe detects a corrupt Report.wer INI file, it will eventually delete it, however first it changes the file’s DACL properties by adding the process executer permission to delete this file.
• Exploit: The hacker exploits the short window of opportunity that occurs between the time wermger.exe reads the file’s DACL, and the time it takes for it to add the delete permission to the file. If the attacker creates a link between such a file to any other file on the system, after the DACL is read, wermgr.exe will incorrectly modify the security descriptor of the other file. We can all agree this is a very, very bad scenario.

Step 1:

The first thing wermgr.exe -upload does is call the wermgr!DoCoreUpload function, which lists all the subdirectories under ReportQueue. It reads the error reports and submits them to Microsoft:

Step 2:

When wermgr.exe encounters a corrupt Report.wer INI file, it changes its DACL in order to later on delete it. More specifically,

1. First, wermgr!DeleteCorruptedReportFromStore lists all the files under the report’s subdirectory;
2. Then, wermgr!PreparePathForDeletion modifies the permissions for each file. This is where the core bug resides, since this function reads the file’s security descriptor using kernel32!GetFileSecurity and calls kernel32!SetFileSecurity to apply the delete descriptor to the file.

Creating the link at the exact right time is extremely difficult, yet a persistent hacker will try again and again until he succeeds. Attackers are likely to target executable files (DLLs, EXEs or scripts) and override them with malicious payload, knowing they will later on be executed with System permissions.

Traps Provides Behavior-based Protection

Palo Alto Networks Traps for endpoint protection and response stops threats on endpoints and coordinates enforcement with network and cloud security to prevent successful cyberattacks. Traps stops malware, exploits and ransomware by observing attack techniques and behaviors, incorporating Machine Learning (ML) and Artificial Intelligence (AI) to automatically detect and respond to sophisticated attacks. To prevent this bug, the Behavioral Threat Protection (BTP) feature in Traps would monitor malicious behaviors across a sequence of events, and immediately terminate the attack when it was detected. In addition, Traps Local Analysis via ML prevents malicious payloads from executing.

To learn more about Traps, visit us at ttps://www.paloaltonetworks.com/products/secure-the-endpoint/traps.