Arbitrary Write Privilege Escalation - CVE-2024-50804

This writeup provides an overview of the recently discovered arbitrary write vulnerability in the MSI Center Pro 2.1.37.0 software for MSI branded machines. MSI has also acknowledged the vulnerability and cooperated with me to deliver a patch. In my final email correspondence with MSI on November 15th 2024, MSI confirmed with me the patch and updated software were successfully released to the Microsoft store. Sure enough, when I browsed the microsoft store per their link below, I could see the new version listed on November 14, 2024.

Here’s the final email I received and confirmation of the fixed version release! See below:

Nov 15, 2024, 5:06 AM

Hi Robbie, MSI Center Pro 2.1.41.0 has been released on Microsoft Store that includes fixes for the two reported vulnerabilities (The Arbitrary Write Vulnerability & the privilege escalation vulnerability).

https://apps.microsoft.com/detail/9nq4lgt81kgc?hl=zh-TW≷=TW

We’ve put your name on MSI’s PSIRT Hall of Fame to show our appreciation. Thanks again for the great work and effort.

https://csr.msi.com/global/product-security-advisories

If we have started programs for doing additional research and consulting work in the future, we will be sure to reach out to you.

Have a nice weekend,

MSI PSIRT Team

CVE-2024-50804 - An Overview

Funny thing is, this was just a simple effort in reviewing local privilege escalation techniques. I started along the path of learning about symlink/junction arbitrary write vulnerabilities. I was first of all intrigued by the fact that a standard user could point symlinks and junctions to privileged directories, such as c:\windows\system32.

I then started looking in to this more intentionally, using procmon and opening the various apps I had installed on my MSI laptop. I wanted to see if any odd read/write behavior stood out. I eventually stumbled upon an interesting discovery - A SYSTEM process writing to the ProgramData folder and renaming a file that I had control over. This is when I really started to get amped. 😸 Let’s dive in and I’ll explain how this initial discovery led to an exciting journey into learning all about arbitrary write local privilege escalation using windows symlinks/junctions!

Software Affected: MSI Center Pro 2.1.37.0

Summary

An Arbitrary write vulnerability exists within the C:\ProgramData\MSI\One Dragon Center\Data\Data folder for the MSI Center Pro software. This vulnerability presents an opportunity for elevation of privilege to NT AUTHORITY/SYSTEM due to the file in question, Device_DeviceID.dat.bak, being written to by a SYSTEM level process.

Discovery

It was observed by yours truly that many config/log files located within the C:\ProgramData\MSI\One Dragon Center\Data\Data directory were being written to by the NT AUTHORITY/SYSTEM user. This can oftentimes allow for more extensive permissions being granted by default to even a standard user. This on its own is not indicative of compromise, as log files can have explicit permissions preventing abuse of inherited permissions from ProgramData. However, in the case of this vulnerability, there exists a weakness with how the .dat files are created within the Data directory.

The Vulnerability Explained

A SYSTEM arbitrary write vulnerability exists due to how two files are handled by the C:\Program Files (x86)\MSI\One Dragon Center\MSI.CentralServer.exe process. The two files in question are Device_DeviceID.dat and Device_DeviceID.dat.bak, respectively. The Device_DeviceID.dat is created after the Device_DeviceID.dat.bak is renamed to Device_DeviceID.dat.

IMAGE A

We can interrupt this process by creating a pseudo-symbolic link that points Device_DeviceID.dat.bak to an arbitrary file we have control over (See Image B). This will force the renamed Device_DeviceID.dat to transform into a symlink and take on the inheritable permissions of the C:\ProgramData\MSI\One Dragon Center\Data\Data directory. This will also allow our currently logged in STANDARD user the ability to delete the newly converted Device_DeviceID.dat symlink file, as can be seen in Image C below. Otherwise, this file could not be deleted except by a user from the Administrators group (See Image D).

Here’s how everything plays out when we start the program, C:\Program Files (x86)\MSI\One Dragon Center\MSI.CentralServer.exe. The process will begin to write to the .bak file, which will then link to our file, and then get renamed to the final .dat file.

IMAGE B

IMAGE C

IMAGE D

Now the previously secured Device_DeviceID.dat file can be easily deleted with new permissions applied to the symbolically linked newly created .dat file. See newly applied permissions in Image E below:

IMAGE E

Why does this matter?

Once the Data folder is emptied, a directory junction can be created and we can then begn to craft our exploit. We will create two Object Manager based, RPC control symbolic links:

The first symlink will be for the .bak file pointing to our writeable payload, located in the c:\temp folder:

The second symlink will be to our privileged target directory we wish to write to. I chose the C:\Program Files (x86)\Microsoft\EdgeUpdate directory where we will transfer a custom crafted .dll payload to that directory and load it using the task scheduler, thus gaining NT AUTHORITY/SYSTEM privileges.

The first symlink will force the .bak file to take on the permissions of our payload. We then apply those permissions to the second symlink which transfers to the target file.

Here’s the code snippit that accomplishes this:

I figured I would just share the video I submitted to the MSI team to make this next part easier to understand:

(Watching this back, im cringing at my sleep deprived self recording this in like 2 takes and I somehow couldn’t articulate the very simple fact that placing a DLL in the same directory as the executable will make the executable load that DLL 😸 Never miss an opportunity to be humbled right? 😄)

That’s it! Thanks for reading

TIMELINE

September 6, 2024:

Contacted MSI at psirt@msi.com via their responsible disclosure policy:

https://csr.msi.com/global/product-security-advisories

September 15th, 2024:

MSI confirms receiving vulnerability report and would review findings

September 26th, 2024:

PSIRT MSI team required more information

September 27th, 2024:

Sent PSIRT team two video walkthroughs of exploiting the arbitrary write vulnerability

October 4th, 2024:

MSI confirms vulnerability and applies a fix to prevent the .bak file from being manipulated during the file rename operation

November 15th, 2024: I received confirmation from MSI that the updated, patched version of the software had been released to the Microsoft store. 😸