Arbitrary file write in Visual Studio Updater Service

TL;DR

An elevation of privilege vulnerability (CVE-2020-0899) exists when the Visual Studio Updater Service (VSIX Auto Update) improperly handles file hard links and path redirection through junctions or mount points, resulting in low privileged users being able to create new or take Full Control of arbitrary existing files.

Description

Visual Studio creates the scheduled task VSIX Auto Update to regularly check for updates at a given time. The task executes VSIXAutoUpdate.exe in the context of the local SYSTEM account and writes data to the MachineStorage.dat and MachineStorage.dat.bak files in the C:\ProgramData\Microsoft Visual Studio directory. Everyone has Full Control over these files, hence they can be replaced with file hard links pointing to arbitrary files. The task will overwrite both the content and the security descriptor of the target file. Further analysis also revealed that Users have Write access to the parent directory, hence it can be turned into a junction or a mount point. Low privileged users can leverage this vulnerability to create new or take Full Control of arbitrary existing files.

The below screenshot shows the detailed property list of the VSIX Auto Update task obtained by executing the schtasks /query /fo LIST /v command.

Exploitation via hard link

1. Create a file hard link from C:\ProgramData\Microsoft Visual Studio\MachineStorage.dat to C:\Windows\win.ini.
2. Wait for the VSIX Auto Update task to run automatically or manually trigger an update.
3. The C:\Windows\win.ini file has had its security descriptor rewritten to grant Full Control to Everyone.

PoC

The below screenshots show the events related to MachineStorage.dat captured by Process Monitor. We can see that VSIXAutoUpdate.exe is executed in the context of the local SYSTEM account. It first overwrites the content then also overwrites the security descriptor of the target file.

The below screenshot shows the exploitation flow using James Forshaw’s Symbolic Link Testing Tools targeting the win.ini file on a virtual machine running Windows 10, version 1909 (10.0.18363.418).

Exploitation via mount point

1. Create a mount point from C:\ProgramData\Microsoft Visual Studio to C:\Windows\System32.
2. Wait for the VSIX Auto Update task to run automatically or manually trigger an update.
3. The MachineStorage.dat and MachineStorage.dat.bak files have been created in the protected C:\Windows\System32 folder and Everyone has Full Control over these files.

PoC

The below screenshot shows the events related to the VSIXAutoUpdate.exe process captured by Process Monitor when using a mount point. We can see that VSIXAutoUpdate.exe is executed in the context of the local SYSTEM account. The process first creates the MachineStorage.dat and MachineStorage.dat.bak files in the protected C:\Windows\System32 folder then modifies the security descriptor of the files to grant Full Control to Everyone.

The below screenshot shows the exploitation flow using James Forshaw’s Symbolic Link Testing Tools turning the C:\ProgramData\Microsoft Visual Studio folder into a mount point to C:\Windows\System32 on a virtual machine running Windows 10, version 1909 (10.0.18363.418).

Note

What sparked my interest in the beginning was another scheduled task called BackgroundDownload, which was auto-executed when the computer was idle for 10 minutes. This task executed the BackgroundDownload.exe in the context of the local SYSTEM account and behaved exactly the same as VSIXAutoUpdate.exe: overwrote the content and the security desciptor of the target file. However, when I started investigating this issue in another test environment the BackgroundDownload task was configured to run in the context of a regular user account. In addition to that the next Visual Studio update completely deleted the BackgroundDownload task. Long story short, I could not reproduce the issue. Anyway, the below screenshot shows the same actions performed by BackgroundDownload.exe on the MachineStorage.dat file.

Timeline

⬅️ 2020-02-05: Reported issue to MSRC.
➡️ 2020-02-05: MSRC opened case 56421.
⬅️ 2020-02-17: Requested status update.
➡️ 2020-02-20: MSRC indicated that this is a duplicate.
⬅️ 2020-02-20: Requested information about my related submissions.
➡️ 2020-02-24: MSRC indicated that my related submissions are duplicates.
⬅️ 2020-03-10: Requested status update.
➡️ 2020-03-10: MSRC indicated that the fix is ready and assigned CVE-2020-0899.
➡️ 2020-04-14: Coordinated public release of advisory.

References

• CVE-2020-0899 - Security Update Guide - Microsoft - Microsoft Visual Studio Elevation of Privilege Vulnerability
• Symbolic Link Testing Tools