This post is about a local privilege escalation vulnerability in Malwarebytes Anti-Malware 3. It can be abused by any local user to gain full control over the system. It is based on #AVGater, a class of Anti-Virus vulnerabilities related to the handling of quarantined files. It has been verified on a fully patched english Windows 7 x64 running Malwarebytes Free 3.0.5.1299.

The underlying issue is that the Quarantine feature can be abuse to write arbitrary files to any filesystem location with full SYSTEM level permissions.

The first step in this attack is that a file with the name version.dll has to be quarantined from an otherwise empty folder. A good trick to do so is to simply rename a well-known malware to version.dll. I prepared such a sample here. Download it to ~\Desktop\X\version.dll and trigger a manual scan to get it detected.

As soon as the following dialog is shown, replace the already detected malware with our payload.

The prepared payload mimics the Windows library version.dll. However, instead of providing any real functionality it simply logs the current user to C:\Users\Public\user.txt. You can download the full source here.

int DllMain(void* hinst, unsigned long* reason, void* reserved) {
	system("cmd /c \"whoami >> C:\\Users\\Public\\user.txt\"");
	exit(1);
	return 0;
}

Then finish the quarantine process and reboot the system. Now delete the previously created and now empty folder X and replace it with a directory junction as shown below.

Finally restore the quarantined file.

Because of the directory junction the library version.dll is restored to C:\Program Files\Malwarebytes\Anti-Malware.

After a reboot our “malicious” version.dll is loaded by the Windows service “Malwarebytes Service” (mbamservice.exe). As this service uses the SYSTEM account, we gained full control over the computer. This is also documented as the current user is logged to C:\Users\Public\user.txt.

Suggested solution

It should be impossible to restore files to filesystem locations containing a directory junction.

Timeline

• 14.1.2017: The issues has been documented and reported
• 19.1.2017: Vendor starts investigation
• 26.1.2017: Issue confirmed – Fix implemented
• 27.3.2017: Update fully deployed
• 11.10.2017: Public release