CVE-2016-3298: Microsoft Puts the Lid on Another IE Zero-day Used in AdGholas Campaign

Microsoft’s Patch Tuesday for October fixed another previous zero-day vulnerability in Internet Explorer (IE) via MS16-118 and MS16-126: CVE-2016-3298. Before the lid was put on it, the security flaw was employed alongside CVE-2016-3351 by operators of the AdGholas malvertising campaign, analysis and disclosure of which were made with our collaboration with Proofpoint’s @kafeine last July 2016. The campaign was notable for the economies of scale and scope it achieved in its heyday until its operations were stymied. As shared by @kafeine, it was even integrated in Neutrino exploit kit’s malvertising chain as a malicious JavaScript.

Like CVE-2013-7331, CVE-2015-2413, and CVE-2016-3351, CVE-2016-3298 is an information disclosure vulnerability. Attackers utilized these to check for the presence of local files/directories, or obtain confidential system data that can be leveraged in further attacks. They are all related to file handling protocol, which are best mitigated with file protocol-related code auditing.

Exploiting CVE-2016-3298 enables attackers to check for specific antivirus (AV) software installed in the system in order to avoid AV detection and threat research/analysis. This sounds innocuous, but determining if the system is unsecure eases—and even automates—the undertaking of sneaking malware into it.

AdGholas’s malvertising campaigns heavily relied on stealth. This is reflected by how it exploited non-critical flaws that unfortunately tend to be undetected and/or unpatched for quite some time. How was this vulnerability leveraged in their operations?

CVE-2016-3298: A Technical Rundown

Drawing on sample codes derived from an AdGholas campaign, we simplified them to a Proof of Concept (PoC) code:

The PoC code uses the Microsoft.XMLDOM ActiveX Object to check for a specific directory in the system. Microsoft.XMLDOM has a function defined as: loadXML( string ).

The parameter string can be in the format,<!DOCTYPE rootElement SYSTEM “URIreference”>. The URIreference, which points to a file containing the declarations, can be a string like: mhtml:file:filepath. With this URI (Uniform Resource Identifier)/scheme, IE’s inetcomm.dll module will call the MimeOleParseMhtmUrlW function to parse the URI.

If an attacker gave a special/custom URI, like mhtml:file:/progra~1/malwar~1, MimeOleParseMhtmUrlW will get the error file URI file:/progra~1/malwar~1 (if URIreference is the same as the special URI). The loadXML call stack will be:

Figure 2. loadXML call stack resulting from an attacker’s special URI

Figure 3. Code fragment of the CInetFile::INetAsyncOpen function

CVE-2016-3298’s key point function is urlmon!CINetFile::InetAsyncOpen. CInetFile::INetAsyncOpen calls GetFileAttributeW to get the filepath attribute. If the filepath is not present in the system, the return error code is 0x800c005. If it exists—and is a directory—return error code will be 0x800c0015. CInetFile::InetAsyncOpen error code will be assigned to parseError.errorCode. Via the error code, attackers can check if the directory exists in the system or not.

CVE-2016-3298 in Exploit Kit When integrated to exploit kit, it plays the role of a sleuth to evade detection and analysis:

It scans for presence of AV software

It checks if firewall is installed in the system

It determines if the browser is running in sandbox

It inspects the system for packet capture software

It runs the exploit if it confirms none are present in the system

Figure 4. Sample code segment in exploit kit that checks for security tools in the system

Patching CVE-2016-3298

Microsoft’s cumulative update, rolled out on October 11, covered Internet Explorer 9 to 11 on Windows clients and servers, and was accompanied with a patch for Vista, Server 2008 (SP2 and R2 SP1) and Windows 7 (SP1). The patches addressed the vulnerability by changing how the Microsoft Internet Messaging API (inetcomm.dll) handles objects in memory—inetcomm.dll’s patched version is 6.1.7601.23548; if unpatched, it’s 6.1.7601.17514.

Figure 5. Difference in MimeOleParseMhtmUrlW function for the unpatched (left) and patched version (right) using patch analysis tool PatchDiff2

The patched MimeOleParseMhtmUrlW function will check if mhtml is followed by a fileurl. If it is, it will call the URLCanonicalizeWfunction to canonicalize the fileurl. Using file:/progra~1/malwar~1 as example: after getting the canonicalized fileurl,file:///progra~1/malwar~1, the CActiveUrlRequest::Start function will return with error code 0x800c000e whether the fileurl exists on the system or not. This prevents attackers from determining whether the directory is present on the system.

Figure 6. Code fragment of the CActiveUrlRequest::Start function

Trend Micro Solutions

A vulnerable system can be exposed to a plethora of threats. Keeping it up-to-date with the latest patches plays a critical role in mitigating the risks for end-users and especially businesses. Trend Micro’s Vulnerability Protection and OfficeScan’s Intrusion Defense Firewall plug-in shield endpoints from identified and unknown vulnerability exploits before patches are deployed.