Observations on the recent Java 0-day exploits in the wild

Recently the Internet has been abuzz with news of an unpatched (0-day) exploit for the latest version of Java. The vulnerability is critical because it can exploit a fully patched version of Windows, Linux or Mac OS X. Also, it can do all this without users knowledge or consent. All that is needed is have Java 7 installed and a visit to a website that contains a malicious Java applet. A patch from Oracle that addresses this vulnerability may not be released until the 16th of October.

In the past week, Fox-IT detected attempts to exploit the Java vulnerability on a large scale. The perpetrators did not use the code that everyone is concentrating on. In this case some malicious JavaScript was first used to load the Java archive into the clients Java virtual machine. Subsequently, it was checked if the client was running Java 7, which is the version of Java that is vulnerable. If the system is vulnerable, it was attacked with custom exploit code. Once the jar is executed, a malicious exe is downloaded and then the computer is compromised. It is reassuring to know that even if someone attempts to compromise systems in a new way and uses a known methodology to do so, it can still be detected; as was the case here.

The executables that were dropped by the exploit code consisted of a new sample of the Hermes Trojan, and various versions of ZeuS including Citadel, Ice-IX, Gameover-ZeuS and other customized versions. Analysis of the Hermes sample, as well as the command and control servers that it was configured to connect to, has shown that the perpetrator of this attack was previously responsible for the large scale infections by Dorifel using a Citadel botnet, as described previously on our blog.

Interestingly enough, the exploit code that was used to exploit unsuspecting visitors appears to have been compiled on August 17th, which predates most known exploits for this vulnerability, even the one referenced in other blog posts related to a targeted attack using an exploit kit from East-Asian origin. The timeline makes it interesting, as it is even closer to the date that the VulnDisco Java 0-day was announced on the 10th of August. It could very well be that the vulnerability was circulating in the underground and some people picked it up along the line, or even that someone ripped it from VulnDisco.

The variety of malware that was distributed suggests this exploit kit is used as a service, which was recently discovered when large amounts of traffic were sent to it originating from compromised OpenX servers that are used for advertorial purposes. One of the compromised OpenX servers was amongst others used by OmroepWest.nl. Much more effort was put into this exploit to make sure that it would not be detected by Anti Virus products when compared to the other exploits in the wild. Additionally, the domains that were used by the exploit kit were changed frequently to avoid blacklisting and the IP addresses were often rotated as well. The domains were sub-domains of the popular DynDNS service: dyndns-at-home.com, dyndns-ip.com, dyndns.biz, dyndns.info, dyndns.org and dyndns.tv. The type and variety of malware that was distributed to various countries, suggests that it was likely that it was actively offered in the Russian-speaking underground community in the past weeks.

The unpatched Java vulnerability poses a severe security risk, as the software is widely used on systems in corporate, consumer and governmental environments. The vulnerability can be exploited to compromise Windows, Mac OS X and Linux systems. Given the amount of systems that can be affected, the readily available exploit code and the expectation that the vulnerability will not be patched for a significant amount of time, it is only a matter of time before this vulnerability will be exploited in even greater numbers. Also with the 0-day exploit having been added to the most popular exploit kit out there, Blackhole, we expect that the exposure of systems will become even higher as will the success rate of exploitation.

To protect oneself it is recommended to uninstall Java, unless it is used for tasks that are essential. In those cases, it is recommended to disable Java in the web browsers that are installed on the system. References to guides how to disable Java in some of the most used browsers: Chrome, Firefox, Safari.

Update 31-8: Oracle has issued an update to Java 7 which addresses the vulnerability. More details here.

Update 3-9:  The earlier mentioned compilation date of the 17th of August was not related to the actual 0day exploit directly, we shared the samples with the industry and Moshe Basanchig from Trustwave responded that the earlier files found, only appeared to exploit CVE-2012-1723, and not CVE-2012-4681. All Jar files were exploiting CVE-2012-1723 and used the same obfuscator and had similarities due to the CVE-2012-1723 exploit and referenced ProtectionDomain, hence my confusion. Only the files from the 27th of August and onward exploited CVE-2012-4681 for 1.7 versions of Java and CVE-2012-1723 for other versions. Thanks to the excellent practical analysis of Immunity’s Esteban Guillardoy  it was easy to verify. Sorry for any confusion this might have caused.

It is interesting as the exploit kit appeared to gain traction on the 22nd of August and has distributed a large variety of malware which we expected to be related to the java 0day exploit, but it is not. While this exploit kit is definitely of a managed variant it also has some different properties. For example, another centrally managed exploit kit commonly referred to as Redkit, allows one to upload an executable and send traffic (visitors) to the exploit kit. The individual customers are differentiated using a numbered file which corresponds to the customer account and after successful exploitation the relevant customer malware is installed. Also the Bomba exploit kit (2010) and Incognito exploit kit (2011) are references of this type of service.

In this case however there is no distinguishing of customers to the exploit kit, all traffic has an identical landing page, and the only difference being made is the geo-location and relevant malware offered for that country is installed. This type of service is called a loads service where a customer pays for an X amount of infections for a certain country or list of countries. Another example of such a loads service was the Bredolab related loads service in 2010, which had huge volumes of traffic being converted into infected systems.

Still I am surprised by the amount of different malware that has been distributed by this service using dyndns domains, since it was only recently started, so it remains a mystery to me why it is suddenly so popular. The seemingly randomly generated domains which lead to this exploit kit are generated by a javascript domain generator which used a set of keywords and selects 4 keywords based on input parameters which are Hour, Day, Month and Year. The domain generator which was in use, is no longer used at this moment as the domains are not active.

The keywords used:
fox v junk five n r man out yes u qw solve but ea x im low zero go one too seven zeta do four key dry nine wide park hi a echo six two code

Generated domains:
date: 0:00 28-8-2012
domain: hxxp://foxwidecodea .dyndns-at-home .com
date: 1:00 28-8-2012
domain: hxxp://vparkfoxecho .dyndns-at-home .com
date: 2:00 28-8-2012
domain: hxxp://junkhivsix .dyndns-at-home .com
date: 3:00 28-8-2012
domain: hxxp://fiveajunktwo .dyndns-at-home .com
date: 4:00 28-8-2012
domain: hxxp://nechofivecode .dyndns-at-home .com
date: 5:00 28-8-2012
domain: hxxp://rsixnfox .dyndns-at-home .com
date: 6:00 28-8-2012
domain: hxxp://mantworv .dyndns-at-home .com
date: 7:00 28-8-2012
domain: hxxp://outcodemanjunk .dyndns-at-home .com
date: 8:00 28-8-2012
domain: hxxp://yesfoxoutfive .dyndns-at-home .com
date: 9:00 28-8-2012
domain: hxxp://uvyesn .dyndns-at-home .com …

The last domain in the list can be seen in the wireshark traffic log as seen in the blog, with a matching timestamp.

Barry Weymes, Michael Sandee et al.