Technology News

latest updates from easySERVICE™

Why Java Remains a Top Security Risk



It is amazing how much of our world runs on Java or JavaScript, its web-enabled cousin. ATMs fueling the cash economy; hospital scanners monitoring patient health; security systems protecting our homes; websites supporting media and commerce; and mobile devices enabling our business and social lives — these are just a few of our “life support” systems that rely upon these programming languages.

Java’s ease of portability among platforms has contributed to its widespread adoption (it runs on over three billion devices worldwide). Unfortunately, this widespread adoption has made Java a natural target for cybercriminals, who exploit the vulnerabilities of current and previous versions to spread malware, steal data and fulfill other malicious objectives.

How Attacks Exploit Java Vulnerabilities

To understand and mitigate an organization’s potential exposure to Java vulnerabilities, it is vital to first understand Java’s role in today’s complex, multi-staged attacks. Let’s start by describing what Websense has identified as the seven stages of an advanced attack that comprise the threat kill chain. (Note that not all threats need to use every stage.)

This document illustrates the significant threats that can target Java vulnerabilities, and can help you understand your mitigation options and best practices to minimize the associated risks.

Recon: Cybercriminals peruse personal, professional and social media websites for information to help them create seemingly trustworthy “lures” that link to compromised websites under their control.

Lure: Using information collected in the RECON stage, cybercriminals create innocuous-looking email, social media or other “lures” that can fool users into clicking links to compromised websites.

Redirect: In their lures, cybercriminals may use links that “redirect” users to safe-looking or hidden web pages that contain exploit kits, exploit code or obfuscated scripts.

Exploit Kit: Once a user has clicked on a link to a compromised website, an exploit kit scans the victim’s system to find open vulnerabilities or zero-day threats — the first step toward further infiltration.

Dropper File: Once the exploit kit has found an opening, the cybercriminal delivers a “dropper file” to infect the victim’s system. The dropper file may contain software that executes on the victim’s system to begin the process of finding and extracting valuable data.

Call Home: Once the dropper file infects the target system, it “calls home” to a command-and-control server to download additional programs, tools or instructions.

Data Theft: The end-game of most modern cyberattacks, the data theft stage completes the threat kill chain. Cybercriminals steal intellectual property, personally identifiable information or other valuable data.

Cybercriminals tend to attack the latest vulnerabilities of any framework or application, Java or otherwise, because they typically assume previous versions have been patched and therefore rendered unassailable. Yet as our research suggests, this assumption is baseless regarding the Java install base — the huge number of endpoints running older versions of Java makes them an unusually tempting target of attack.

The longer a particular Java vulnerability has been known, the easier it is to exploit; in crafting their Java attacks, many cybercriminals simply use an existing exploit kit with little or no modification. And as new vulnerabilities are discovered, hackers quickly update existing kits and create new kits to exploit them. For example, within only one week of the release of V1.6_45 and V1.7_21, cybercriminals released new or updated exploit kits to attack the new vulnerabilities they had swiftly discovered.

Therefore, with no lengthy and costly development cycles, and because exploit kits can be quickly obtained, tweaked and distributed, Java attacks have the potential to impact more people in less time than other attacks — and with predictable, proven and far-ranging results.

Once identified, Java vulnerabilities are documented and assigned a common vulnerabilities and exposures (CVE) value. Table 1 lists the Java CVEs in existence during the March 2013 study; the percentage of users vulnerable to each CVE; and the exploit kits that attacked them.

Studies repeatedly proved that most end points continued to run older versions of Java and therefore remained extremely exposed to exploitation in 2013, our researchers predict Java will remain highly exploitable and highly exploited throughout 2014. They also anticipate additional, related repercussions throughout the threat landscape. These include:

  • With numerous proven Java exploits to choose from, cybercriminals will devote more time to finding new uses for tried-and-trusted attacks or to crafting other aspects of their advanced, multi-stage attacks.
  • Their success with Java exploits is encouraging cybercriminals to look elsewhere for similar opportunities. Our researchers are paying particular attention to Flash, web-kits and several other popular platforms that, like Java, are popular, readily exploited and inconsistently updated.
  • Cybercriminals will reserve the use of zero-day Java exploits for targeting high-value networks with good Java patching practices.

What You Can Do

There is no simple, single solution for addressing Java exploits. Rather, there are a handful of approaches to consider. Best practices typically recommend the frequent and regular patching of software installations to fix their vulnerabilities and protect them from attack. But the patching of Java presents unique risks organizations must carefully consider.

The challenge is that many core business processes and applications rely on a particular version of Java, and can’t afford the potential disruption a patch might cause. Organizations must therefore weight the risk of an attack against the potential of a loss in productivity — a significant consideration.

Fortunately, there are potential workarounds that could afford an acceptable balance between safety and productivity. For example, an organization could apply a patch for an earlier version of Java that is nonetheless compatible with its existing system requirements.

There are still other options to reduce the risks caused by Java vulnerabilities. Organizations can combine these approaches to best suit particular situations and resources.

  • Uninstall Java. A multi-staged trial uninstallation can determine the impact on core processes and systems without disrupting the entire organization. The trial results will show where Java must remain in use and therefore be properly secured, and where Java can safely be uninstalled. (Fortunately, fewer and fewer of the most popular websites require Java, and only a small percentage of these provide core business services, so the potential impact on productivity is lessening.)
  • Use different browsers for different tasks. A browser with regular settings yet disabled for Java could be used for everyday web tasks, while another browser with higher security settings could be dedicated for tasks that require the use of Java.
  • Deploy real-time defenses with global threat intelligence. This offers the best overall protection, short of uninstalling all Java components from business machines and devices (an unrealistic solution for most organizations). An ideal security solution can identify known and unknown threats in real time and employ behavioral sandboxing to test and observe how malicious code operates.


To promote the safe, productive use of Java-powered applications and devices, it is crucial to understand the potential risks and impacts of these exploitive attacks.

Java is a fundamental part of many business systems and a powerful tool for productivity, ensuring its place within organizations worldwide. However, the challenges with patching and managing Java make it highly vulnerable to cybercriminal attack. Maintaining productivity while protecting systems requires a balanced approach, and the kind of advanced real-time defenses and global threat intelligence.


One comment on “Why Java Remains a Top Security Risk

  1. StellarPhoenixS
    July 21, 2014

    Reblogged this on Stellar Phoenix Solutions.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: