Update 5-1-2014: We can confirm Cisco customers have been targets of this attack. For the latest coverage information and additional details see our new post on the VRT blog.
The recent discovery of a new Internet Explorer zero-day exploit underlines how exposed web browsers are to vulnerabilities for which a patch is yet to be released. Cisco is aware of the issue and is releasing IPS signature 4256-0 and Snort signatures 30794, 30803 to detect the exploitation of this vulnerability. You can read more details from Cisco here.
The vulnerability affects Internet Explorer versions 6 to 11 running on Windows. Microsoft has released an advisory detailing how users can mitigate the exploitation of the vulnerability in the absence of a full patch. These mitigations include:
- Deploy “Enhanced Mitigation Experience Toolkit 4.1”. This optional update makes it harder for malware writers to exploit memory vulnerabilities and helps to block attacks that use these techniques.
- Unregister VGX.dll. This library is required to use Vector Markup Language (VML), a now deprecated vector graphics format previously used in Microsoft Office applications. Interestingly, this is not the first time that this particular library has been implicated in vulnerabilities.
The attack involves a malicious Flash SWF file creating a vector object that is passed to the browser. The zero-day bug is then triggered, corrupting the memory allocated to this object. This memory corruption allows the SWF file to inject a malicious payload into the memory. When the browser attempts to access the vector object, the malicious payload is executed and the attacker can take control of the machine.
This attack mechanism is reminiscent of the technique used by VUPEN to win the Pwn2Own 2013 competition by compromising IE 10. This attack also involved exploiting memory corruption vulnerability in VGX.dll, the same library used in today’s vulnerability (see CVE-2013-2551. Indeed, this in turn is reminiscent of another VML buffer overrun vulnerability in VGX.dll. CVE-2013-0030 also involved memory corruption and could be exploited to compromise Internet Explorer versions 6 to 9.
Looking through the lists of CVEs shows that the same dll has been implicated in three other vulnerabilities since 2006, CVE-2006-4868, CVE-2007-1749 and CVE-2011-1266. All of these vulnerabilities involved errors in the way memory was allocated by the dll that allowed attackers to execute code on affected machines, very similar to the attack that we are seeing today.
Given that this particular library has been implicated in six vulnerabilities and that Vector Markup Language is now deprecated in favour of SVG, maybe the best mitigation technique is to follow Microsoft’s advice and to unregister the dll for good. Three major vulnerabilities affecting this library have been discovered in the last 14 months, how many more have yet to be found or used?
Craig Williams contributed to this post.
Given the US Department of Homeland Security announcement this morning, should we stop using Internet Explorer until a patch becomes available?
Thats a very good question. Ultimately, the answer depends on your apatite for risk and the nature of the data that you handle. If the data on your desktop is particularly sensitive, maybe its time to switch to another browser until a patch is available. However, the real danger was before the zero day was identified and published when there was no protection whatsoever.
This won’t be the last zero day. Keeping systems fully patched is very important but I think most important is to protect your most important systems and to monitor their use so you can swiftly identify malicious access. There are many ways that attackers could get inside your network, zero days are only one of these, but by being able to spot attackers when they get in, you can protect your most important assets and take action to remediate the breach.
More important when will IPS signature with 4256-0 be released.
+1 to Jeff
Signature 4256-0 was published today. You can find the details below.
Cert.org specifies “the vulnerability does not reside in VGX.DLL. This library is used in current exploits, so unregistering it will prevent those specific exploits from working, rather than blocking access to the vulnerability.” in their vulnerability note.
Comments are closed.