Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Recently we released the Microsoft Security Intelligence Report volume 14. The report initially presented data showing reduced Java malware detections in Q3 2012 and gaining prevalence in Q4 of 2012. During a later review of the backend data, we found that we were missing some detection counts from our initial calculations. We have revised the data, and Figure 1 shows the updated graph.
Figure 1 Machine count of detections for each exploit categories
From Figure 1, what we can see clearly is the sudden rise in Java exploitation, as explained in the conclusion. As the HTML/JS category is usually used in delivering other exploit vectors (for example, Blacole pages leading to other Java and PDF, SWF exploits), Java malware is the most prevalent exploit vector that actually tries to exploit vulnerabilities in the software since 2011 .
Figure 2 shows the breakdown of individual Java exploits. In 2012 we saw four different Java vulnerabilities were used most, CVE-2012-1723, CVE-2012-0507, CVE-2012-4681, CVE-2012-5076. Details or guidelines for each vulnerability are available in the following articles:
An interesting case of JRE sandbox breach (CVE-2012-0507)
The rise of a new Java vulnerability - CVE-2012-1723
Protecting yourself from CVE-2012-4681 Java exploits
A technical analysis on new Java vulnerability (CVE-2012-5076)
The prevalence of CVE-2011-3544, which was found in late 2011, went down drastically after CVE-2012-0507 was discovered in Q1 of 2012. And we see this trend continue through the whole year.
Figure 2 Breakdown trends of Java exploits
The first half of 2012 was dominated by malware abusing CVE-2012-0507, but malware abusing CVE-2012-1723 overtook the trend in Q3 replacing CVE-2012-0507 resulting in the detection count of CVE-2012-0507 dropping just after the CVE-2012-1723 vulnerability was found in August 2012. After CVE-2012-1723 was discovered in early Q3, the appeal for malware authors to use CVE-2012-0507 diminished; however, exploits abusing CVE-2012-0507 didn't completely die, even in Q4.
In Q3 and Q4 of 2012 two new vulnerabilities, CVE-2012-4681 and CVE-2012-5076, were found. But we didn't observe any prevalence of Java malware abusing these newer vulnerabilities above malware abusing the older Java vulnerabilities, CVE-2012-0507 and CVE-2012-1723. The reason behind this might be that only Java 7 installations were vulnerable to CVE-2012-4681 and CVE-2012-5076, whereas CVE-2012-0507 and CVE-2012-1723 also target Java 6. As there are still many users that use Java 6, the malware writers might have tried to target Java 6 installations by including older vulnerabilities in the exploit package. We can assume that, for this reason, they didn't do away with the older vulnerabilities.
So there were two kinds of Java vulnerabilities that appeared in 2012 overall: One is the category that applies to both multiple versions of Java including Java 6 and 7, and the other are the vulnerabilities that only applies to Java 7. So when new vulnerabilities that are only applicable to Java 7 are discovered, the attacker's strategy was usually to combine it with older vulnerabilities that cover more versions of Java. In that way, they could achieve more coverage than just using a single exploit in one package.
Table 1 Details of CVE-IDs
If you look at Table 1, you can see that only one out of four vulnerabilities was a 0-day. Three out of four vulnerabilities were used when there were updates available at the time of outbreak. So, we can assume that updating users' software to the most recent version of Java might have prevented a lot of malware infections that were distributed through Java vulnerabilities. Even the case of CVE-2012-4681, where the exploit was distributed as a 0-day in the first place, it took less than a week for the vendor to release the update for users. So from a security point of view, users would have benefited from promptly updating their software.
The Java vulnerabilities we are talking here are not memory corruption issues. The issues lie in the access check failure to data structures, packages or fields of classes, etc. So, when the vulnerable software is exposed to the malicious Java exploits, the success rate of the exploitation is usually very high compared to memory corruption vulnerabilities. This might be one reason why Java malware has become so prevalent.
In conclusion, overall we saw a huge increase in Java malware activity last year, and Java malware shows a high success rate in exploitation. But, many times the Java vulnerabilities are adopted by malware writers after the updates from the Oracle is released, so, you should update your Java installation regularly whenever you - see any alert from Java Auto Update to reduce your chance of being vulnerable to these and similar exploits.
Jeong Wook (Matt) OhMMPC