It has long been known that cyber criminals exploit application vulnerabilities to download malware on unsuspecting user endpoints. An analysis of IBM’s threat intelligence data reveals that the most-targeted applications during the month of December 2013 were: Java, Adobe Acrobat Reader and Web browsers.
It is unsurprising that these are the top-targeted user applications. After all, these are common applications found on most user endpoints, and they have vulnerabilities that can be exploited to deliver malware to the machine. In addition, these are applications that can receive and process external content — HTML code, email attachments and more. This means that a cyber criminal can create “weaponized” content: files or documents that contain exploits that take advantage of vulnerabilities in the viewer/processing application. Weaponized content is typically delivered to the user via spear-phishing messages or exploit sites. Once the user opens the file or document using a vulnerable application, the exploit causes a chain of events that ends with the delivery of the malware to the user’s machine and infection without the user’s awareness.
Exploited applications during the month of December 2013 included:
Java: A Powerful Yet Dangerous Application
Fifty percent of the exploits observed by the IBM Security Trusteer research team in December 2013 targeted Java vulnerabilities. This means that Java is still the top-targeted application. Java is a high-risk application that exposes organizations to advanced attacks. It has numerous vulnerabilities that can be exploited to deliver malware and compromise users’ machines. Once on the endpoint, it is extremely difficult to prevent its malicious execution. However, the powerful capabilities of Java have made it a very popular platform for developing enterprise applications. Today, Java can be found in every enterprise environment, and because organizations are highly dependent on Java applications, it is impractical to remove it from the enterprise environment, as some recommend. Since organizations can’t eliminate Java from their environments, it is not surprising that adversaries and cyber criminals are using malicious Java code to infiltrate them.
A Rise in Java Code Exploits
During 2013, there has been a significant increase in the number of exploits targeting Java vulnerabilities. This is a result of the discovery of new zero-day vulnerabilities and the introduction of exploits into popular exploit kits. In past X-Force Trend and Risk reports, we discussed how exploit kits such as the Blackhole and Cool exploit kits were found to be using unpatched Java vulnerabilities to escape the Java sandbox in order to install malware on victims’ machines. In 2013, this popular trend continued.
Java Exploits: Native vs. Applicative
Java vulnerabilities can allow two different types of exploits: native exploits and applicative exploits. Most of the exploits that target vulnerabilities in end user applications, like Internet Explorer, Chrome or MS Office applications, execute natively. A native exploit results in running native shell code. This is accomplished by techniques such as buffer overflow, use-after-free and more. To protect against native exploits, there are a number of native OS-level protections like address space layout randomization (ASLR), Data Execution Prevention (DEP) and general security protections like Structured Exception Handler Overwrite Protection (SEHOP), heap-spraying code protection (NOZZLE), Stack Pivoting protection, Export Address Table Access Filtering (EAF) and many more.
However, taking a closer look at Java exploits reveals that the more common type of Java exploit is an applicative exploit (in this example, Java Layer Exploits). Unlike native exploits, which target the application memory, the applicative exploits aim to break the Java security manager: Java applications run within a virtual machine (JVM). The Java security manager is a class that manages the external boundary of the JVM, controlling how Java applet code executing within the JVM can interact with resources outside the JVM. Applicative exploits abuse vulnerabilities that break the Java security model. Once the security model is broken, nothing prevents the Java applet from running critical operations that should not be performed.
It is more difficult to defend against Java applicative exploits, which allow the applet to gain unrestricted privileges, making malicious activities seem legitimate at the OS level. This means that, unlike native exploits, Java applicative exploits completely bypass the native OS-level protections.
Java applicative exploits don’t generate buffer overflow; thus, they are not prevented by methods such as DEP, ASLR, SEHOP and others discussed above.
IBM Recommendations
Since organizations can’t eliminate Java from their environments, it’s important to secure these applications and prevent the execution of malicious Java code. However, the native Java protections that are available today are very limited in their capabilities, especially against zero-day threats.
To prevent Java exploits and malware-based infiltrations, it is important to restrict execution only to known, trusted Java files. Organizations that struggle to manage and maintain a complete list of all known, trusted files should at least restrict execution to files that have been signed by trusted vendors or downloaded from trusted domains; otherwise, untrusted Java files should not be allowed to freely execute within the enterprise environment. Restriction of untrusted Java allows organizations to safely run their business without exposing themselves to such risk.
Trusteer Apex
IBM Security Trusteer Apex Advanced Malware Protection is a software solution that protects enterprise endpoints against advanced malware. It prevents malware delivery and infection via exploitation of vulnerabilities in Java and other end user applications. Because it is not dependent on patch availability or advanced information about the threat, it effectively protects against both unknown zero-day threats and known threats. In addition, Trusteer Apex restricts the execution of unknown, untrusted Java code on the endpoint to prevent malicious data access and exfiltration.
Download the IBM X-Force Threat Intelligence Quarterly – 2Q 2014 report to read more about trends in attack behaviors across platforms and industries.
Director of Enterprise Security at Trusteer, an IBM Company