Maxthon Browser for Windows - Unquoted Search Path and Potential Abuses (CVE-2019-16647)


October 23rd, 2019

Peleg Hadar

Security Researcher, SafeBreach Labs

Introduction

SafeBreach Labs discovered a new vulnerability in the Maxthon 5 Browser for Windows. In this post, we describe the CVE-2019-16647 vulnerability we found in the Maxthon 5 Browser for Windows. We then demonstrate how this vulnerability could have been exploited by an attacker, during a post-exploitation phase; in order to achieve privilege escalation, persistence and in some cases defense evasion. The exploitation technique involves implanting an arbitrary unsigned executable which is executed by a signed service that runs as NT AUTHORITY\SYSTEM.

Note: In order to exploit this vulnerability, the attacker needs to have Administrator privileges.

Maxthon 5 Browser

Maxthon (formerly named MyIE2) is a freeware web browser developed by Maxthon Ltd., which is based in Beijing, China. According to the company’s website, 670 million users use it as a default browser.

Parts of the software run as a Windows service executed as “NT AUTHORITY\SYSTEM,” which provides it with very powerful permissions and capabilities.

Vulnerability

Discovery

In our initial exploration of the software, we targeted the “MxService” (MxService.exe), because:

  • It runs as NT AUTHORITY\SYSTEM - the most privileged user account. This kind of service might be interesting to attackers when looking for privilege escalation to SYSTEM, which is very useful and powerful.
  • The executable of the service is signed by “Maxthon Technology Co, Ltd.” If the hacker finds a way for a malicious payload to be executed by MxService, the service can be used as an application whitelisting bypass.
  • This service automatically starts once the computer boots, which means that it’s a potential target for an attacker to be used as a persistence mechanism.

In our exploration, we found that after the “MxService” service was started, the MxService.exe signed process was executed as NT AUTHORITY\SYSTEM.

We noticed an interesting behavior once the service’s process was executed:

sb.png

As can be seen, services.exe looked for a missing EXE file (C:\Program.exe) before it found and executed the real executable file.

PoC Demonstration

In order to test this privilege escalation vulnerability, we compiled an EXE file (unsigned) which writes the following to the filename of a txt file:

  1. The name of the process which loaded it
  2. The username which executed it

sb2-0002.png

sb3-0002.png

Our arbitrary unsigned EXE file was executed as NT AUTHORITY\SYSTEM by a legitimate process (without changing the service’s path or overwriting any file).

Root Cause Analysis

The root cause can actually be found in the installation phase.

Once the user opens the installer of the Maxthon Browser, an executable named “MxInstall.exe” is written to a temporary folder.

One of the things this executable does is to create the service using the WinAPI CreateServiceW function.


Before it does that, it calls sprintf in order to format the buffer which contains the path of the service executable:

sprintf(&BinaryPathName, “%sBin\\MxService.exe, MaxthonPath);

The BinaryPathName buffer is passed to CreateServiceW:
sb4-0002.png

In our case “”%sBin\\MxService.exe” turns into:

"C:\Program Files (x86)\Maxthon5\Bin\MxService.exe"

The service path buffer is not a quoted string, which is the root cause of the unquoted search path vulnerability.

The final path contains a space (“Program Files”), and the CreateServiceW function doesn’t know whether it’s part of the path or whether it’s an argument, so it tries to parse it by itself:

  1. C:\Program.exe
  2. C:\Program Files (x86)\Maxthon5\Bin\MxService.exe

According to the CreateServiceW function documentation in MSDN:
lpBinaryPathName

The fully qualified path to the service binary file. If the path contains a space, it must be quoted so that it is correctly interpreted. For example, "d:\my share\myservice.exe" should be specified as ""d:\my share\myservice.exe"".

Potential Malicious Uses and Impact.

Below we show three possible ways that an attacker could have leveraged the CVE-2019-16647 vulnerability we discovered and documented above.

Whitelisting Bypass

The vulnerability gives attackers the ability for malicious payloads to be executed by a signed service. This ability might be abused by an attacker for different purposes such as execution and evasion, for example: Application Whitelisting Bypass.

Persistence Mechanism

The vulnerability also gives attackers the ability to execute malicious payloads in a persistent way, each time the service is loaded. That means that once the attacker drops a malicious EXE file in one of the paths we mentioned earlier, the service will load the malicious code each time it is restarted. This way the malicious payload might not be detected by security products, because the service process which executes the attacker’s payload is signed, and executes it “natively.” No suspicious action is required by the attacker. The serviceit just executes the malicious executable once it is started.

Privilege Escalation

The vulnerability provides an attacker with the ability to gain NT AUTHORITY\SYSTEM access as an Administrator.

Affected Versions

Maxthon Browser 5 for Windows - 5.1.0 to 5.2.7

Timeline

Sep 3rd, 2019 - Vulnerability reported to Maxthon

Sep 17th, 2019 - Maxthon has confirmed the vulnerability

Sep 27th, 2019 - Maxthon has issued CVE-2019-16647

Oct 8th, 2019 - Status update from Maxthon

Oct 9th, 2019 - Maxthon has shared a timeline for a new version deployment

Related Posts