New Java Vulnerability Used in Targeted Attacks

August 28, 2012 - 0 Comments

Security researchers discovered a Java vulnerability (documented in IntelliShield alert 26751) that attackers are using to install malicious software on a victim’s systems. No software updates are available that correct the vulnerability (Updates are now available, see Part 2 of the blog).  The attacks are currently limited in nature. There have been few reports of attacks that rely on the vulnerability. Now that Metasploit developed a functional exploit, continued attacks that leverage this vulnerability increase in likelihood as time goes on. US-CERT has issued a related vulnerability note. Administrators can monitor this and other ongoing activity at the Cisco Security Intelligence Operations portal.

It is not yet clear what attackers hope to gain out of the attacks observed in the wild. Goals may differ between individual attacks. Current exploits appear to install a malicious software dropper that may install other malicious software, but to what end is unknown. Attackers may attempt to install malicious software that monitors keyboard input and network communication, hoping to gain user credentials for either external resources to aid in fraudulent activity or to access other internal systems within the targeted site.

Simply applying vendor patches won’t be enough to protect against exploitation because the current version of Java, which at the time of this publication is Java version 7 update 6, is affected by the vulnerability. Environments that have not updated to Java 7 may not be at risk, as reports indicate older versions of Java 6 may not be vulnerable to exploitation. Although software updates are not yet available, administrators and users should be prepared to apply updates when available from Oracle. This is also a good opportunity for administrators to evaluate how systems are updated in their environments. However, even without available patches, there are some measures administrators can take to protect systems in their environments.

Typical exploit scenarios involve web-based attacks that target Java plug-ins within web browsers such as Microsoft Internet Explorer or Mozilla Firefox. When a user visits an attacker-controlled website, malicious Java applets that are designed to exploit the vulnerability target the underlying Java software application vulnerability. Disabling the Java plug-in within those browsers removes that exploit vector.

Users must also first visit a website that hosts malicious content for an attack to occur. Using web reputation filtering solutions, such as the Cisco Ironport Web Security Appliance, can block known malicious sites before users visit those sites and become victims of an attack. User education and training can also help prevent users from accessing malicious websites. Policies and technical controls should also govern how critical systems can access external sites.

Signature-based detections in IPS devices can block attempts to exploit this vulnerability. Cisco IPS signature packages that contain these signatures are available in signature pack S664.

Host-based intrusion prevention systems and anti-virus defenses on end-user hosts can help protect against the aftermath of exploitation. Known exploits of the vulnerability attempt to install malicious software on vulnerable systems. Properly-configured and up-to-date protections may prevent and block malicious software that is installed after a successful exploit.

Whatever actions administrators take, they must determine the amount of risk their environment can tolerate. If Java on end-user systems support critical operations, it may be impossible to disable Java in users’ browsers. Preventing access of untrusted third-party websites may also be impractical or unpopular. Signature-based detections may not be available in certain environments. Currently, chances of exploitation are thought to be low. That risk goes up with time until a patch is available. Until patches are available, administrators are advised to take precautions, as necessary, in their environments.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.