A Look at CVE-2014-1776 via Windows Crash Reports
Posted by AlexWatson on 29 April 2014 03:12 AM
As we mentioned in our last blog entry, a new vulnerability has been discovered by researchers at FireEye in Microsoft Internet Explorer affecting Internet Explorer versions 6 through 11. Current reported attacks are targeting only Internet Explorer 9 through 11. The vulnerability allows attackers to remotely execute arbitrary code on the target machine by having the user visit a malicious website. The vulnerability has been assigned reference CVE-2014-1776. The vulnerability lies in the way Internet Explorer handles Vector Markup Language and vector graphics rendering, when Internet Explorer accesses a related object in memory that has been deleted or improperly allocated. This allows the attacker to execute arbitrary code in the context of the current user.
Microsoft has released an advisory with recommendations about how users can take steps to mitigate their vulnerability while a patch is prepared. There has been quite a bit of discussion about the impact of the vulnerability, including recommendations from both the US Department of Homeland Security and UK governments that government users avoid the use of Internet Explorer until a bug patch is released by Microsoft.
In spite of the ongoing discussions and mitigation options, not many details exist about how the exploit targets Microsoft Internet Explorer, and where it is being seen in the wild. In this blog post, we will examine application crash reports from Microsoft Windows computers that are sent via the WER (Windows Error Reporting) framework, to see if we can learn anything about possible vulnerabilities that are being exploited and/or where attacks are occurring.
Comparison to known exploits
Microsoft's threat advisory for CVE-2014-1776 recommends disabling the VGX.DLL library as a mitigation option against the exploit. This library is a core library for Internet Explorer's "Vector Markup Language" (VML) capability -- a deprecated vector graphics format that was primarily used in Microsoft Office Applications. It is interesting to see that VGX.DLL has been linked to other vulnerabilities from 2013, including CVE-2013-2551 and CVE-2013-0030, which both use memory corruption techniques that could theoretically be used to compromise IE. We have previously discussed how Microsoft Windows Error Reporting (WER), a.k.a. Dr. Watson, is an opt-out program that exists in Windows XP, Vista, 7, and 8 that sends detailed telemetry to Microsofteach time an application crashes or fails to update, or a hardware change occurs on the network. This data is incredibly valuable to Microsoft and application vendors, to help debug their applications and prioritize fixes on a massive scale. More information on how you can harness intelligence from Windows crash reports, which are sent from over 80% of PCs globally, can be found in our whitepaper.
Today, we will search crash reports for evidence of exploit-type activity happening in the VGX.DLL library within Internet Explorer. This can be used to help identify possible vulnerabilities that are being exploited by CVE-2014-1776, and can hint at possible geographic locations that are being targeted during attacks. These application crashes are generated for one of three reasons:
1. Normal application failure, such as running out of memory
2. Crash triggered during normal application use, which may be a vulnerability
3. Failed exploit activity
Searching for needles in the haystack
Let's start by looking at Windows Error Reporting application crashes that we have seen occur in the past 6 months. Out of a total of 19.8 million error reports, the following crashes occurred in Internet Explorer versions 6 - 11 inside the VGX.DLL library
We see a significant uptick in crashes starting around February 10th, 2014. Let's take a closer look to see if we can learn anything from the crash reports. Of 39 crashes observed, there are 15 distinct crash reports, grouped by the crash offset location. Two distinct crash reports emerge as being interesting.
MSIE 0-day Exploit CVE-2014-0322 - Possibly Targeting French Aerospace Association
Posted by AlexWatson on 14 February 2014 07:54 AM
CVE-2014-0322 Attack Analysis
Contributors: Alex Watson, Victor Chin - Websense Security Labs
Websense Security Labs ThreatSeeker telemetry has confirmed the existence of the Microsoft Internet Explorer 10 0-day exploit CVE-2014-0322 beginning as early as January 20 2014, predating the previously believed first use by nearly three weeks.
The CVE-2014-0322 exploit has been seen hosted and delivered from the following URL, which was first seen by Websense on January 20, 2014:
hxxp://gifas.assso.net is presumably a fake site meant to look like hxxp://gifas.asso.fr, which is a French aerospace association:
GIFAS, the French aerospace industries association, has more than 300 members, from major prime contractors and system suppliers to small specialist companies. Activities extend from civil and military aircraft and helicopters to engines, missiles and armament, satellites and launch vehicles, plus aerospace, defence and security major systems, equipment, subassemblies and associated software.
The use of the very similar domain name may indicate that the French aerospace association is the target, but this domain does not appear to be a campaign with active lures, yet.
Domain History for assso.net
An anonymous DNS registration service was originally used to register the domain "assso.net" which was updated to direct users to the malicious site on January 20, 2014.
Name Servers: NS05.DOMAINCONTROL.COM|NS06.DOMAINCONTROL.COM
Registrar Name: GODADDY.COM, LLC
As of January 28, 2014 gifts.assso.net resolved to 22.214.171.124. This IP address is geolocated to Santa Clara, Calif. We noticed the SHA1 for Tope.swf being uploaded to VirusTotal on January 20 (the same day as the fake gifas.assso.net site was set up), with no detection at the time by AV vendors. Presumably this was done by the attackers to check AV coverage for their malware before starting their attacks, further indicating that January 20 was the initial rollout of this campaign of attacks using this 0-day.
Similarity with other observations of CVE-2014-0322
As is in the HTTP stream shown below, visitors going to hxxp://gifts.assso.net are linked to include.html, which sets up the ROP exploit and "Tope.swf" Shockwave Flash file (SHA1: 910de05e0113c167ba3878f73c64d55e5a2aff9a) which is utilized after the CVE-2014-0322 use after free vulnerability to access memory through ActionScript in the SWF file.
Checking for Microsoft's Exploit Mitigation Toolkit
var steeple ="<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 'res://C:\\windows\\AppPatch\\EMET.DLL'>";
Malicious Content in Tope.swf Shockwave Flash File
Below is code located in the Tope.SWF that leads to a second stage dropper called "Erido.jpg". Code snippet below :
The code above shows the Shockwave Flash ActionScript downloading content but not actually storing it to a file. The follow-on code below shows a buffer being written and read as "little endian" to denote the order for the byte array to be executed. The _local(x) variables look to be calculations in memory which makes us believe this is an "in memory" only attack, presumably to make antivirus detection more difficult.
Analysis of the Malicious ActionScript (AS3) Code
Below is the use after free type vulnerability that is triggered when the Vector class is allocated / freed
In the code above, the string:
appears to be the culprit responsible for causing the vulnerability to return to malicious memory space allocated.
Links to DeputyDog and EphemeralHydra Campaigns
The similarities in the exploit, delivery and search for the EMET.DLL indicate that the same group of threat actors is most likely behind the malicious URL above and the attacks that have been covered by FireEye. More detailed analysis coming soon.
If you are concerned about your exposure to this vulnerability due to the use of Microsoft Internet Explorer 10 we would recommend that you consider upgrading to Internet Explorer 11. You can find out more information at Microsoft's IE page here.
This attack is known to check for the presence of Microsoft's Enhanced Mitigation Experience Toolkit (EMET). If it is found then the exploit attempt terminates. You can find out more about how to deploy EMET in Microsoft's overview here and the EMET knowledge base article.
Read more »