Discovering a zero-day vulnerability

Discovering a zero-day vulnerability demonstrates robust capabilities of PwC’s Cyber threat & vulnerability management team

PwC pentester Bryan De Houwer discovered a zero-day vulnerability in Windows 10 that, if exploited, would’ve allowed any attacker with unprivileged access to gain admin access. This privilege escalation vulnerability existed due to improper impersonation by the Diagnostics Hub Standard Collector Service upon certain file operations. Multiple versions of Microsoft Visual Studio, Windows Server 2019, Windows Server 2016 and Windows 10 were affected.

To exploit this vulnerability, an attacker would’ve required user access on the target system, effectively limiting the attack vector to local attacks only. However, the potential impact of the vulnerability would’ve been significant. The vulnerability was rated with a CVSS Base Score of 7.0, given the low privileges required to exploit the vulnerability and the high potential impact on confidentiality, integrity and availability of target systems.

Following a responsible disclosure process, details of this research were shared with Microsoft in September 2018, after which it shortly released security updates for all affected products and versions (see Microsoft’s Security Update Guide for more details on affected products/versions and corresponding security fixes). Bryan received formal acknowledgement by Microsoft for his research.

This discovery clearly demonstrates the strong capabilities of PwC Belgium’s Cyber threat & vulnerability management team. Stay tuned for more interesting discoveries to come!

Technical description of the finding

After analysing the vulnerability found by Ryan Hanson, I noted that given a collection session configured with a session ID of F0D0F753-ECCE-405C-A059-0A17E8493994 and a scratch path of C:\Users\revm\AppData\Local\Temp\test_folder\, the following events occurred when destroying the session using the DestroySession method.

(Note that the session ID can be any GUID and the scratch directory can be any location the user has write permissions to.)

  • An Event Trace Log (.etl) file was created in the scratch path: C:\Users\revm\AppData\Local\Temp\test_folder\F0D0F753-ECCE-405C-A059-0A17E8493994.m.etl
  • A Report folder was created in the scratch path: C:\Users\revm\AppData\Local\Temp\test_folder\Report.F0D0F753-ECCE-405C-A059-0A17E8493994
  • A folder with a random GUID was created in the report folder: C:\Users\revm\AppData\Local\Temp\test_folder\Report.F0D0F753-ECCE-405C-A059-0A17E8493994\9BE74A8D-73CA-45C4-95D6-A965B62C9EC8
  • The Event Trace Log file was “moved” from C:\Users\revm\AppData\Local\Temp\test_folder\F0D0F753-ECCE-405C-A059-0A17E8493994.m.etl 
    to
    C:\Users\revm\AppData\Local\Temp\test_folder\Report.F0D0F753-ECCE-405C-A059-0A17E8493994\9BE74A8D-73CA-45C4-95D6-A965B62C9EC8\F0D0F753-ECCE-405C-A059-0A17E8493994.m.etl using SetRenameInformationFile.

Vulnerability

Since the file move in step 4 was improperly impersonated. We could abuse this action to cause an arbitrary file write vulnerability to a folder which our user doesn’t have any rights to. This could be achieved by winning a race condition to replace the random GUID folder, created in step 3, with a mount point to a different location. In the following section, I explain the necessary steps to reproduce this in more detail.

In order to exploit this vulnerability, I attempted to open and lock the C:\Users\revm\AppData\Local\Temp\test_folder\F0D0F753-ECCE-405C-A059-0A17E8493994.m.etl file created in step 1. Then we waited until step 3 for the random folder C:\Users\revm\AppData\Local\Temp\test_folder\Report.F0D0F753-ECCE-405C-A059-0A17E8493994\9BE74A8D-73CA-45C4-95D6-A965B62C9EC8 to be created. Since we locked the .m.etl after step 1, I assumed that we’d block the file move in step 4. This allowed us to delete the random folder 9BE74A8D-73CA-45C4-95D6-A965B62C9EC8 and replace it with a mount point to C:\WINDOWS\system32 without having to win a race condition against the file move in step 4. We could then also replace the file contents of the C:\Users\revm\AppData\Local\Temp\test_folder\F0D0F753-ECCE-405C-A059-0A17E8493994.m.etl file with a malicious dll, before closing the file. After closing the file, the file move in step 4 succeeded, causing our malicious etl file to be written to C:\WINDOWS\system32\F0D0F753-ECCE-405C-A059-0A17E8493994.m.etl instead.

Now we could use the “Microsoft (R) Diagnostics Hub Standard Collector” service to load our malicious dll file (F0D0F753-ECCE-405C-A059-0A17E8493994.m.etl), as demonstrated by James Forshaw and gain privilege escalation to SYSTEM. The following screenshots demonstrate the results after running the exploit, a new user test was created and added to the Administrators group.

Note that it would for instance also be possible to control the name of the F0D0F753-ECCE-405C-A059-0A17E8493994.m.etl file by:

  1. Creating a mount point from C:\Users\revm\AppData\Local\Temp\test_folder\Report.F0D0F753-ECCE-405C-A059-0A17E8493994\9BE74A8D-73CA-45C4-95D6-A965B62C9EC8 to \RPC Control\.
  2. Creating a symlink from \RPC Control\F0D0F753-ECCE-405C-A059-0A17E8493994.m.etl to C:\path\to\any\file.extension.

This would’ve allow us to write to any file that our user could’ve created a symlink to, and the diagnostic service user can write to.

 

Get in touch with one of our specialists

 

Ingvar Van Droogenbroeck

Partner, Brussels, PwC Belgium

+32 047 738 1445

Email

Bart De Win

Director, Brussels, PwC Belgium

+32 47 946 7957

Email

Vito Rallo

Director, Brussels, PwC Belgium

+32 47 311 2830

Email

Bryan De Houwer

Senior associate, Brussels, PwC Belgium

+32 47 457 0568

Email

{{filterContent.facetedTitle}}

{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}
Follow PwC Belgium