Maxthon Browser for Windows - Unquoted Search Path and Potential Abuses (CVE-2019-16647)
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 (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.
In our initial exploration of the software, we targeted the “MxService” (MxService.exe), because:
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:
As can be seen, services.exe looked for a missing EXE file (C:\Program.exe) before it found and executed the real executable file.
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:
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).**
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:
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:
C:\Program Files (x86)\Maxthon5\Bin\MxService.exe
According to the CreateServiceW function documentation in MSDN:
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""``
Below we show three possible ways that an attacker could have leveraged the CVE-2019-16647 vulnerability we discovered and documented above.
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.
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.
The vulnerability provides an attacker with the ability to gain NT AUTHORITY\SYSTEM access as an Administrator.
Maxthon Browser 5 for Windows - 5.1.0 to 5.2.7
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