This post is about a local privilege escalation vulnerability in Emsisoft Anti-Malware. It allows any local user to abuse the virus quarantine to get local SYSTEM level access. It has been verified on a fully patched english Windows 7 x64 for Emsisoft Anti-Malware 12.1.0.6970. This issue itself is based on #AVGater, a class of Anti-Virus vulnerabilities related to the handling of quarantined files. 

The underlying issue is that the Emsisoft Anti-Malware’s quarantine interface can be abused to restore files as SYSTEM to any filesystem location. The following screenshot shows the starting point for our attack. We – as a local non-admin user – manually added a malicious version.dll from within an newly created folder (like ~\Desktop\X) into the virus quarantine using the “Add file” button.

This version.dll exports all the same functions as the one from Microsoft. However there is no real functionality within it except a few system calls within its DLLMain that add a new user as soon as it is loaded.

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

In the next step we start with the real magic: Windows Junction Points (https://technet.microsoft.com/en-us/library/cc753194%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396)

To do that remove the empty parent folder (~\Desktop\X) and replace it with a junction point using mklink that points to Emsisoft Anti-Malware’s application folder.

To finally trigger the issue simply restore the previously quarantined version.dll. As the original path now contains a junction and the restore process is carried out as SYSTEM our version.dll gets places into the Program Files directory. This clearly proofs the privilege escalation: A normal user should not be able to do that.

Now simply reboot the system. During the start of the automatically loaded “Emsisoft Protection Service” Windows service the malicious version.dll gets loaded and our new user attacker is added to the system.

Suggested solution

It should be impossible to restore files to filesystem locations containing a directory junction. One solution could be to always restore files to a temporary folder first (like the users temp folder) and then let the user-mode application do the move to the final path. Thereby it is guaranteed that files can only be restored to folders where the current user has write permissions.

Timeline

• 02.12.2016: The issues has been documented and reported
• 06.12.2016: Vendor was able to reproduce and started to work on a fix
• 14.12.2016: Fixed in Beta release
• 15.12.2016: Update pushed into production
• 11.10.2017: Public release