Video Screencast Help
Security Response

Internet Explorer Zero-Day Used in Watering Hole Attack: Q&A

Created: 31 Dec 2012 21:38:44 GMT • Updated: 23 Jan 2014 18:10:42 GMT • Translations available: 日本語
Symantec Security Response's picture
+2 2 Votes
Login to vote

In a recent blog, Symantec reported on a new Internet Explorer zero-day being actively exploited in the wild. Microsoft has since released Security Advisory 2794220 which confirms the Microsoft Internet Explorer 'CDwnBindInfo' Use-After-Free Remote Code Execution Vulnerability (CVE-2012-4792) is a zero-day vulnerability which affects Internet Explorer 8, Internet Explorer 7, and Internet Explorer 6.

The following Q&A briefly outlines what is known about the watering hole attack, the Internet Explorer zero-day, and the protection Symantec has in place.
 

What is a watering hole attack?

A watering hole attack is a method of targeting sites which are likely to be visited by targets of interest. The attacker will compromise the site and inject JavaScript or HTML to redirect victims to additional malicious code. The compromised site is then left “waiting” to exploit users who visit through drive-by downloads.
 

Figure 1. Watering hole attacks
 

Symantec has published research surrounding watering hole attacks (The Elderwood Project) which details targets, growing trends, and attack platforms seen since 2009.
 

How did this watering hole attack work?

This new Internet Explorer zero-day compromised the website of a U.S.-based think-tank organization so that, when a victim visited, JavaScript was executed which performed numerous checks and then exploited the browser.

First, the attack checked that the browser accessing the page was Internet Explorer 8. Next, it checked if Flash was installed, and finally it checked the system language (specifically looking for Chinese, Taiwan Chinese, United States English, Russian, Japanese, or Korean). If any of the checks failed, the victim was redirected to a blank page. If all of the above checks passed, the attack then proceeded to load a cookie to indicate a compromised system. If the victim visited this page again within seven days of being compromised, they were redirected to a blank page.

Next, an additional check was performed on the installed version of Java. Specifically, the attack looked for Java version 6 and, if found, a Flash object was loaded using a CLSID. This loaded malicious Shockwave Flash File—today.swf—was responsible for the heap-spray. An iFrame was also created which linked to a news.html page and contained the exploit code for Internet Explorer 8.

This exploit code targeted users running Windows 7 and Windows XP. The Flash object contained ActionScript code which was used to build shellcode based on the operating system version and language packs installed. The ActionScript built specific shellcodes depending on the version of Windows encountered. For Windows 7 it used Return-Oriented Programming (or ROP-chains) to build shellcode.
 

Figure 2. Steps in watering hole attack

 

While the browser is being exploited through the news.html iFrame, a GET request was made from the original compromised page to download a xsainfo.jpg file that was stored in Internet Explorer's Temporary Internet Files. This is an encoded dynamic-link library (DLL) binary which was the payload of the attack.

When the Flash object was loaded, it performed a heap-spray and injected the shellcode used to locate the xsainfo.jpg file, decode it, and store it in the %Temp%/flowertep.jpg file.

Next, a request was sent for the robots.txt file which gets de-obfuscated and then used to load the malicious payload (flowertep.jpg) using techniques to by-pass DEP and ASLR on Windows 7.

The method employed to deliver the payload is unusual as it initially downloads the payload before exploitation occurs. This is a technique known as a drive-by-cache attack where the malware is downloaded first and the shellcode is used to load the malicious payload instead of downloading it.
 

What is the zero-day vulnerability?

According to Microsoft, the vulnerability exists in the way that Internet Explorer accesses an object in memory that has been deleted or has not been properly allocated, allowing for memory corruption which could allow an attacker to execute arbitrary code. This is known as a use-after-free vulnerability.

At this time Symantec cannot disclose further information in relation to the vulnerability in question. Microsoft is working around the clock to have a full security update available.
 

What is the final payload?

As previously mentioned, the xsainfo.jpg file contains the final encrypted payload and the flowertep.jpg file contains a decrypted malicious DLL.
 

Figure 3. Final payload
 

When the flowertep.jpg file gets executed it will first drop the final malicious payload temporarily to the %Temp%\shiape.exe file. From there it will move the file to its final location as the %CommonProgramFiles%\DirectDB.exe file. Additionally, it will append random junk data to the end of the file so that the file has different hash value every time, but the first 0xe000 bytes are always the same.

Looking at both files we can notice that the dropper flowertep.jpg file has a portable executable timestamp which indicates the file was compiled on “Wed Dec 12 11:06:04 2012”. The final payload DirectDB.exe file is much older and originates from “Thu Mar 01 00:29:20 2012”.

Both files the dropper flowertep.jpg file and the DirectDB.exe file are detected as Backdoor.Bifrose.N.

Backdoor.Bifrose is a threat family initially seen in 2004 and has seen many evolutions over the years. This latest variant of Backdoor.Bifrose.N is similar to Backdoor.Bifrose.M but, unlike the previous variant, does not use TOR for the network communication as described in a previous Symantec blog. The threat implements common back door functionality such as uploading, downloading, and executing files.
 

How prevalent is this attack?

Initial Symantec telemetry relating to this zero-day attack suggests that the number of computers affected is presently limited. The victims of this attack seem to predominantly be in North America. Due to the location and nature of the website that was compromised to host the zero-day, this keeps in line with the idea of the zero-day being used as a targeted watering-hole attack.
 

Figure 4. Heatmap of Symantec detections related to this zero-day watering hole attack
 

What can I do to prevent and mitigate against this attack?

Microsoft has released a Technet blog for this vulnerability outlining ways to block code execution. At the top of their list is upgrading to Internet Explorer to 9 or 10 which does not include the vulnerable code.

Symantec protects customers against this attack with the following detections:

Antivirus

Intrusion Prevention Signatures

Conclusion

The use of zero-day exploits in targeted attacks is certainly not a new phenomenon. Many high profile incidents like Hydraq (also known as Aurora), Stuxnet, and Duqu used one or more zero-day exploits to accomplish their goal. As detailed in the Symantec Elderwood Project paper, we have seen zero-day usage increasing in such attacks. However, most attackers still use common, publicly available, exploits to carry out their attack. In this particular case, use of a zero-day exploit suggests a high level of sophistication requiring access to resources and skills which would normally be outside most hackers' capabilities.