MrBruh's Epic Blog

MSI Center - How to gain SYSTEM privileges in seconds

After finding severe vulnerabilities in both AMD’s and ASUS’s OEM software, I wanted to expand my horizons by finding issues in more gaming products.

I ended up settling on MSI Center, because it seems to come preinstalled on all of their laptops and pre-built desktops, meaning any vulnerability I found would likely have widespread implications.

Downloading and Extraction

The first step in this process is to always download the offline installer.

A lot of these companies either block the installer from running on unsupported hardware or only allow for the installation of a small selection of their software.

Once you have a copy of the offline installer, you need to run it through Detect-It-Easy and pray. If you get lucky, it might just tell you what software is being used to package MSI Center.

In our case, we got lucky, and it told us that MSI Center is packaged using something called Inno Setup.

msicenter_die

There is a tool made specifically for this situation called innoextract.

msicenter_innoextract

After extracting the installer and the .appxbundle contained within (it’s just a .zip file), it was time to decompile the executables.

Decompilation

There were a total of 170 executables (including DLLs), with the majority of them being written using C#. For them, I made a bash script to decompile all of them using ilspycmd.

find . ( -name "*.exe" -o -name "*.dll" ) -exec file {} + | grep Mono | wc -l
find . ( -name "*.exe" -o -name "*.dll" ) -exec file {} + | grep -v Mono | wc -l

For the remainder that were written in C++, I chose the top ~10 most interesting files and threw them into IDA and then exported their complete decompilation as a .c file.

After doing all that, I had come to the conclusion that there were simply way too many files to be able to look at each one individually. Instead, I had to just search for common weaknesses and hope I would find something.

One of the things I grepped for was CreateNamedPipe. (A named pipe is a way for different processes on your computer to communicate with each other.)

The vulnerability

MSI’s ‘Notebook Foundation’ service spawns a named pipe on boot that any authenticated user can interact with.

CreateNativePipeSecurity("D:(A;OICI;GRGW;;;AU)(A;OICI;GA;;;BA)");
CreateNamedPipe("\\\\.\\pipe\\MSI_SERVICE_2", PIPE_ACCESS_DUPLEX);

It provides the following commands that can be triggered:

As you might have guessed, these are incredibly dangerous tools to be exposing to any authorised user (including ones without local admin).

They could be abused by malware to disable Windows Defender or gain system-level privileges.

The PoC (Proof of Concept)

Historically, MSI has primarily relied on security by obscurity to protect against exploitation. They created a custom protocol for communicating with the pipe and required all messages to be encrypted using 3DES (an outdated and insecure cipher by today’s standards).

  1. Open a connection to the MSI_SERVICE_2 named pipe.
  2. Register an application using a random string (e.g., ABCD123).
  3. Encrypt your PC:REXE command using 3DES and use the client name as the key.
  4. The Notebook Foundation service attempts to brute-force the decryption by trying all the registered client names until one works.
  5. If the decryption is successful, it runs the payload as LocalSystem.

For the Proof of Concept I created, I only made it launch cmd.exe to show it can be used to escalate privileges. However, malware would likely run an arbitrary PowerShell command or script.

I recently discovered that this exploit can also be triggered remotely via SMB on a LAN, resulting in Remote Code Execution (RCE). However, because the named pipe only responds to authenticated users, successful exploitation requires valid login credentials for the target machine.

Reporting

When I sent a report of this vulnerability to MSI via their PSIRT email, I received a concerning response:

Remote Server returned '554 5.2.2 mailbox full; STOREDRV.Deliver.Exception: QuotaExceededException.MapiExceptionShutoffQuotaExceeded;'

What this basically meant was that the mailbox for receiving vulnerability reports was full and was refusing to accept any additional emails.

Not only had it refused to accept my vulnerability report, but it had likely been this way for an unknown period of time and had dropped other people’s vulnerability reports too, not just mine.

Because of this concerning development, I started reaching out to my contacts to find an MSI employee who could help remedy the situation.

In the end, Steve Burke, who runs Gamers Nexus, helped me get in touch with an employee from MSI. However, it turned out that all that effort was in vain as my report had actually managed to reach MSI after all, despite their mail servers giving the exact opposite impression.

After this minor hiccup, the experience with MSI was actually quite pleasant. They prepared a patch for the vulnerability within two days of me reporting it and told me which MSI Center release it was to be bundled with, and when they planned to release the new version.

Unfortunately, MSI did not have the ability to issue a CVE for this, so they suggested I request one via MITRE or a third-party CNA.

As of writing, it has been about a month, and my submission is still in review by VulDB. They state that due to a large amount of new submissions, the wait time is ~4 weeks, so hopefully the review will conclude shortly.

Donations

So far, for the vulnerabilities I have reported to Google, ASUS, AMD, TP-Link, Netgear, MSI (and more), they have paid out a total of $0 in bug bounties.

If you found this article interesting or useful, you can buy me a coffee via my Ko-fi: https://ko-fi.com/mrbruhh

Timeline (DD/MM/YYYY)