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.
| CVE | ActiveX | Object | Protocol | Affected Browser |
| CVE-2013-7331 | Yes | xmldom | res | IE |
| CVE-2015-2413 | No | null | res | IE |
| CVE-2016-3351 | No | null | mineType | IE/Edge |
| CVE-2016-3298 | Yes | xmldom | mhtml | IE |
Figure 1. Information disclosure vulnerabilities in Microsoft’s IE and Edge browsers
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:
function directory_exist(e) {
var r;
try {
r = new ActiveXObject("Microsoft.XMLDOM");
r.async = 0;
file_path = "mhtml:file:/progra~1/malwar~1"
r_s = '<!DOCTYPE _ SYSTEM "' + file_path + '">';
r.loadXML(r_s )
} catch (s) {
alert( s.toString( ))
}
return r && r.parseError.errorCode
}
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.
Trend Micro™ Deep Security™ protects networks through this Deep Packet Inspection (DPI) rule:
- 1007985-Microsoft Internet Explorer Information Disclosure Vulnerability (CVE-2016-3298)
TippingPoint customers are protected from attacks exploiting this vulnerability with this MainlineDV filter:
- 25148: HTTP: Microsoft Internet Explorer Internet Messaging API Information Disclosure Vulnerability
With additional analysis by Brooks Li.
Hat tip to @kafeine for sharing the sample from which we made the PoC code.
