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.

More from Software Vulnerabilities

FYSA – Critical RCE Flaw in GNU-Linux Systems

2 min read - Summary The first of a series of blog posts has been published detailing a vulnerability in the Common Unix Printing System (CUPS), which purportedly allows attackers to gain remote access to UNIX-based systems. The vulnerability, which affects various UNIX-based operating systems, can be exploited by sending a specially crafted HTTP request to the CUPS service. Threat Topography Threat Type: Remote code execution vulnerability in CUPS service Industries Impacted: UNIX-based systems across various industries, including but not limited to, finance, healthcare,…

X-Force discovers new vulnerabilities in smart treadmill

7 min read - This research was made possible thanks to contributions from Joshua Merrill. Smart gym equipment is seeing rapid growth in the fitness industry, enabling users to follow customized workouts, stream entertainment on the built-in display, and conveniently track their progress. With the multitude of features available on these internet-connected machines, a group of researchers at IBM X-Force Red considered whether user data was secure and, more importantly, whether there was any risk to the physical safety of users. One of the most…

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today