In advance of the Internet Explorer zero-day referenced by the CVE-2014-0322 patch that will commence on patch Tuesday the March 11, we thought it would be helpful to look at how this exploit was utilized in the lure stage, since this may unveil some of the tactics used by crimeware and targeted attack actors in this day and age. We've seen this latest zero-day employed by targeted attacks involving a cybersquatted domain that appeared to target the French Aerospace Association, as we described in our previous blog post on the subject. Since then, exploit instances utilizing CVE-2014-0322 have been carried out in crimeware attacks in the wild, and it seems that the exploit source code used in the initial attacks was made available publicly, which contributed to the usage of the zero-day.

The exploit code availability in the public domain led to additional exploit instances popping up in the wild and was seen coming from compromised websites by actors that were looking to make a quick profit from the security hole. In this blog, we're going to take a look at the initial cybersquatted website used to employ the zero-day and different high-profile websites that served the zero-day for crimeware propagation. Specifically, we're going to look at the lure stage of the attacks to understand how code was used in that stage with the ultimate aim of redirecting victims to the exploit.

Top websites seen injected with malicious code leading to the exploit utilizing CVE-2014-0322:

The lure in the initial attacks appears to have been a cybersquatted domain, @ hxxp://gifas.assso.net, taking advantage of the legitimate domain, hxxp://gifas.asso.fr, that is part of the French Aerospace Association. The attack effectively employed the fake domain with some copied content from the legitimate website along with an additional *iFrame* the led to the exploit located on the same host at hxxp://gifas.assso.net/include.html. We can see that there are still references on the cybersquatted website that the code was copied from another website in the form of a "watermark" tag below the iFrame that indicates <!-- saved from ...

[click to enlarge]

The fake gifas.assso.net is hosted on IP address 147.255.229.61. This IP seems to host some other hosts with malicious code. We found the IP hosted update19.homelinux.org, which is an exact replica of gifas.assso.net and is probably a test bed before launching the actual attack.

High-profile compromises utilizing CVE-2014-0322

As described, the code that manages to exploit CVE-2014-0322 was available publicly and from that point, it's very easy for different actors to employ or more like "copy and paste" the exploit code and to change the dropper payload to what they desire to infect users with. Of course, different lure websites are needed to be utilized to propagate infections. One of the best ways to achieve that is through compromised websites and by seamlessly redirecting browsing users to the exploit, a very common method used in the crimeware domain for years. Websense Security Labs™ noticed that there were some website injections that utilized CVE-2014-0322. In this case, in particular, we noticed that what will bring the best form of "revenue" to the actors behind those infections is not necessarily the quantity of compromised websites the exploit is served from, but rather, the quality, or in other words, the popularity of the compromised websites actors manage to get under their control can play a big part in maximizing the number of infections, and indeed we saw some popular websites utilizing this new zero-day in various ways.

A high profile website injected with code leading to the zero-day was a very popular transportation website in Japan called "Hatbus" @ hxxp://www.hatobus.co.jp/ which was first spotted by security researcher @PhysicalDrive0 on Feb 23rd 2014. "Hatbus" offers local residents and tourists bus travel information and other travel services. The website enjoys a weekly visit count of ~25,000 visits with a substantial amount if its traffic originating from referrals of other top travel websites in Japan:

[Images above are courtesy of similarweb.com]

At the moment, hatobus.co.jp appears to be down for maintenance with a message letting us know that the website has been breached. Looking at some telemetry, we can confirm that the website was breached and served code leading to the exploit utilizing CVE-2014-0322 through a sneaky iFrame. The iFrame that seamlessly redirected browsing users to the exploit was buried in one of the Javascript files that were served by the web server specifically at hxxp:// www.hatobus.co.jp/js/rollover.js. All it required was a one liner that writes an iFrame to the page to achieve the mischief:

[click to enlarge]

Interestingly enough, the exploit code was hosted on hatobus.co.jp as well, @ hxxp://www.hatobus.co.jp/images/ie.html, which means that the browsing user is lured and exploited under one domain. This approach takes the punch out of some security solutions since no suspicious redirects to other websites are in play. All the attack stages are served from one domain from start to finish.

Making it a classic case of a copycat, it was observed that the exploit code was identical to the one that was used by the cybersquatted website gifas.assso.net, but with one difference: there was an additional exploit served aimed at Java users and a counter set by the attackers to know exactly how many visiting users hit their malicious script. The Java exploit was referenced by an additional iFrame that would load a JAR file to take advantage of CVE-2013-2465. Upon successful exploitation, a file is dropped that appears to be a Banker that specifically targeting users of those Japanese banking websites: jp-bank.japanpost.jp & mizuhobank.co.jp.

[click to enlarge]

Additional high-profile websites that got compromised and served a "copycat" exploit for CVE-2014-0322 were the Taiwanese English School website (hxxp://www.english.com.tw) and the Hong Kong University Chemistry Department (hxxp://www.chemistry.hku.hk), the latter was again a case of using an iFrame to redirect browsing users to a copy of the exploit. It's interesting to note that on the Taiwanese English School website, the exploit was actually included on the *main* page of the website and no iFrame or other forms of redirect were encompassed. This bold approach has been seen before on compromised websites, however it's rare to see an exploit utilized in such a manner:

[click to enlarge]

It's evident that the repercussions of exploit code of an unpatched vulnerability that found its way to the public domain can have quite an impact; exploit code that has been crafted for a targeted attack is virtually later on copied and used to drop crimeware binaries. We could see that the exploit code for CVE-2014-0322 was encompassed and served in a variety of ways as it "evolved" in scale: starting from being utilized on a cybersquatted lure website used in a low-volume and selected "under the radar" targeted attacks to being served through hidden iframes and exploit code that was directly placed on compromised websites with the ultimate aim to impact as many browsing users as possible with crimeware.

The usage of iFrame tags to seamlessly redirect users to malicious code is an old and popular method especially when a compromised website is used as a lure; iFrames are still used widely for legitimate purposes over the web. We don't see a reason why this trend will cease to be a popular choice as a way to redirect to malicious code by malware actors. This on-going and quite old trend may raise some questions from the defensive side: how can the ongoing phenomena of malicious iFrames be answered? They have long been a popular method of choice in the arsenal of actors behind crimeware and targeted attacks. To tackle the subject, one requires a close familiarity with the "ins and outs" of the web. It's a challenge to distinguish a legitimate iFrame from a malicious one since both may have similar suspicious traits. However, it is possible to distinguish malicious iFrames from legitimate by calculating the probability of a malicious outcome through the different contexts that are available in real-time. The more context available, the better the accuracy can be; context can be, for example, where is the iFrame leading the user to? What are the different iFrame tag features? What website served the iFrame? Is it in a risk category? Was it compromised before? Websense Advanced Classification Engine, or ACE, has a dedicated engine designated to detect malicious iFrames and can assess the context of an iFrame and if the elements are found to pose a potential risk the redirection to the iFrame is blocked in real-time; the approach is done through embedding a machine learning algorithm that allows ACE to reach a decision (see image of simplified process below).

While it's important to employ security solutions to protect against cyber-attacks, it's also important to remember to update your local software and patch your operating system. The patch Tuesday advance notification for fixing CVE-2014-0322 can be found here.