1315: windows privilege raising vulnerability based on error reporting mechanism

Posted by santillano at 2020-04-17

The vulnerability was announced by @ clavoillotte on October 8, 2019

Affected products: Windows 10, Windows Server 2019 (older versions may also be affected, but not tested)

Vulnerability type: local privilege promotion

Summary: the windows error reporting service performs some sensitive file (involving permissions) operations on ordinary user writable files, which may be used by attackers to rename / move files that can only be read by system privileges. Ordinary permission users can use it to enhance their permissions.

重命名/移动 SYSTEM

This vulnerability has been fixed by a security patch released by windows in October 2019.

It was independently discovered by David cash.


When the error reporting service of windows is triggered (for example, after a program crash), the wermgr.exe process will look for the report file in the directory% programdata% \ Microsoft \ windows \ we \ reportqueue \ * * * * * \*, where the directory% programdata% \ Microsoft \ windows \ we \ reportqueue can be read by ordinary users. After the service finds and reads the existing report file report.wer, it creates a temporary file report.wer.tmp, writes it, and finally renames the file (setrename information file) to report.wer to overwrite the existing report file.

wermgr.exe %ProgramData%\Microsoft\Windows\WER\ReportQueue\*_*_*_*_* %ProgramData%\Microsoft\Windows\WER\ReportQueue Report.wer Report.wer.tmp Report.wer

As shown below, file rename operations can be observed from procmon when generating reports through failfast() of PowerShell:

FailFast() Procmon

These operations are performed under the system permission, and the files and directories involved in the operations can be created by ordinary users through werfault.exe, without the help of symbolic links.

SYSTEM WerFault.exe

As a result, ordinary privileged users can use this vulnerability to rename / move files with system privileges.

SYSTEM 重命名/移动

In fact, users can control the directories targeted by these operations, because ordinary users can point a directory to any location through NTFS junction, and modifying the file content will also affect other sensitive files pointed to.

Although ordinary users cannot create "real" NTFS symbolic links for system files by default, they can associate the object directory mount points resolved to \ RPC control \ with the object management symbolic links resolved to the target to construct a "pseudo symbolic link", as shown by James Forshaw (1 and 2). For more information on this, please refer to the detailed documentation.

\RPC Control\

Therefore, through the following settings:

C:\ProgramData\Microsoft\Windows\WER\ReportQueue\a_b_c_d_e -> \RPC Control (NTFS junction)

\RPC Control\Report.wer -> C:\Windows\System32\evil.dll(object manager symbolic link)

File creation related to C: \ programdata \ Microsoft \ windows \ we \ reportqueue \ a \ B \ C \ D \ report.wer will directly affect the appearance of C: \ windows \ system32 \ evil.dll file.

C:\ProgramData\Microsoft\Windows\WER\ReportQueue\a_b_c_d_e\Report.wer C:\Windows\System32\evil.dll

Of course, in order to achieve stable utilization, some obstacles need to be overcome, such as the file read by wermgr must be a valid report file, and the time of link operation, but these problems can be easily solved by oplocks.


Ordinary users can use rename operation to set the following "pseudo symbolic link" to create or replace files that can only be operated by system permission:

SYSTEM C:\path\to\payload.dll SYSTEM C:\Windows\System32\evil.dll


I have provided a PoC demonstration for windows 10 1903. Specifically, when you run the test exploit function, create a% systemroot% \ evil.txt file that can be written by ordinary users. The content of the file is test.

Test-Exploit %SystemRoot%\evil.txt test

The following is a demonstration video, which is used to implant a malicious DLL file and obtain a system permission shell:

SYSTEM 视频地址:


Microsoft has released security patches and warnings that users can update through daily channels.



September 22, 2019: vulnerability report to manufacturer

September 23, 2019: vulnerability of manufacturer confirmation

2019-09-27: the manufacturer replied that this vulnerability will be fixed in the patch next Tuesday

October 8, 2019: the manufacturer has released patches and repair suggestions

October 8, 2019: details of vulnerability announced

本文由白帽汇整理并翻译,不代表白帽汇任何观点和立场 来源: