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:ProgramDataMicrosoftWindowsWERReportQueue), 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 ReportingQueueReporting. 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 ..
Support the originator by clicking the read the rest link below.
){kind=link}