Making Client-side Java Secure with Bromium vsentry

Making Client-side Java Secure with Bromium vsentry

Making Client-side Java Secure Client-side Java has become somewhat of an IT pariah, primarily as a result of the growing list of Java vulnerabilities and updates which mushroomed over the last year. Apple and Google have advised users to disable browser plugins for Java and Microsoft FixIt blocks Java from Internet Explorer, to prevent drive-by attacks. Even the US Department of Homeland Security has warned users to disable client-side Java. While these responses are rational, they are only relevant in a consumer context, and few consumer websites today rely on Java. By contrast, enterprises are heavily dependent on Java, for both client and server applications. If you re in enterprise IT, you know Java is here to stay. The good news is that Java can be made completely secure. So you can continue to use existing enterprise applications, and not fear the consequences of a mistaken click by a user or a rogue attack by a compromised website. Why Do Malware Writers Target Java? Enterprise IT Pros know that they depend on client-side Java, and sometimes on specific versions of the Java Runtime Environment. A company might be targeted using Java based attacks from the web, because it has (or depends on having) an out-of-date version of the JRE on its PCs so that users can access enterprise applications, such as the Oracle ERP suite. But companies are just as dependent on other legacy applications, including old versions of browsers and.net, and on vulnerable versions of Windows. So why the concern about Java? Perhaps it is the fact that attackers always look for the weakest point in a target s defenses. The powerful features available to attackers within the JVM have withstood the best efforts of the security industry to find a good defense. Numerous efforts have been made to find a reliable way to detect malicious Java code with little success. Obfuscation, polymorphism, code injection, the list of techniques available to attackers to hide their intentions is large and seems to grows larger every month.

Java, like all complex application and OS software environments, is vulnerable because it offers a large attack surface. In addition to offering all of the key functions and services that any OS needs to offer a programmer, it presents a runtime environment that is consistent across all supported OS platforms, for both clients and servers. Java is therefore a perfect target for the malware writer: complex, and with many dependencies on third party components: the OSes and their UI frameworks, libraries, browsers, web servers (to distribute the applications) and of course the complex JVM runtime itself, which has to support floating point arithmetic and other complex functions. The problem becomes exacerbated if you consider non-oracle JVMs. In other words, managing the security of Java is not only an Oracle problem. Unfortunately, Java s many benefits have also made it a target because of its ubiquity and platform independence. It meets the economic needs of malware writers: One can target a massive number of deployed systems with one piece of malware, or single out a specific high value target with confidence because the JRE is the same on all supported platforms whether Windows, Mac, or Linux. A single compromise has and will continue to succeed across platforms. But apart from its ubiquity and current popularity with hackers, Java is not particularly more insecure than other commercial applications, nor is Oracle particularly remiss in its security methodology. All software is vulnerable. And if suddenly the JRE were perfectly secure, would this end the endpoint security woes we face? No. The vulnerable code base on PCs includes everything, from the OS, to apps and their plugins. As soon as Java has been patched sufficiently for a while, attackers will find other ways in. In other words, the problem isn t Java.

User Training Doesn t Solve the Problem Is the problem the You in User? Every one of us makes the occasional mistake, and IT Pros are no better at avoiding missteps than the general user base. Yes, training may reduce mistakes, but won t stop all mistakes. There are many documented failed attempts to train users not to click on seemingly unsafe links or files, and so we must assume that user training will never succeed since the attacker is always a step ahead of the trainer. So, (unpatched) Java, and un-trainable users are with us to stay. Endpoint Protection and OS Vendors Can t Help OS vendors can only distribute patches when new vulnerabilities emerge. That doesn t help to protect the end point from attack, and leaves enterprises vulnerable for months at a time. And Endpoint Protection vendors find themselves in a bind when it comes to Java. A Java applet is a binary program that may or may not be signed. While it is possible to restrict the JRE to running only signed applications, it is also possible for malware writers to steal code signing certificates to forge the authenticity of their code. Beyond this, traditional legacy Host-based Intrusion Prevention Systems (HIPS) can at best recognize a particular applet as malicious, but once it is running, they are cannot block or stop it, which is among the reasons Java is so effective for the attacker. Until now, the security industry has had nothing more useful to offer than advice on how to un-install, or update the Java plugin. Apple removed Java from Safari last October, and as previously mentioned, Microsoft FixIt now blocks Java from IE. For its part, Oracle has repeatedly promised to fix Java once and for all, and has embarked on a series of modifications to how Java applications work, to try to contain the problem. Nandi Ramani, who leads the software development team building the Java platform, wrote the following in a recent blog entitled Maintaining the security-worthiness of Java is Oracle s priority : In JDK 7.2, Oracle added enhanced security warnings before executing applets with an old Java runtime... In JDK 7.10, Oracle introduced a security slider configuration option,. Further, with the release of JDK 7.21, Oracle introduced the following:

1. With this update users can prevent the execution of any applets if they are not signed. 2. The default plug-in security settings were changed to further discourage the execution of unsigned or self-signed applets. This change is likely to impact most Java users, and Oracle urges organizations to sign [their] Applets 3. While Java provides the ability to check the validity of signed certificates the feature is not enabled by default because of a potential negative performance impact. In the interim, we have improved our static blacklisting to a dynamic blacklisting mechanism * *https://blogs.oracle.com/security/entry/maintaining_the_security_worthiness_of (underlines added by Bromium) Oracle s approach is rational, but does not address the root problem, namely the fact that we must assume that all software will always be vulnerable. Instead, the aforementioned approach: 1. Puts the onus on the user to do the right thing 2. Makes Java harder to use, and therefore complicates the user experience 3. Attempts to leverage black-listing for known malware to try to block new attacks an approach that has consistently failed in the anti-virus industry. Bromium vsentry Makes Java Secure Bromium vsentry eliminates security challenges from Java and other vulnerable software. It protects the endpoint from all untrustworthy content and applications while ensuring that users enjoy an unchanged native user experience. vsentry allows: Today s vulnerable applications & plugins (Flash, Java, Silverlight, Chrome, Firefox, IE, Word, Powerpoint, Excel, PDF, media etc) to run as intended by the vendor, New mobile-centric, cloud based applications for consumers or enterprises, to deliver a user experience that fully empowers the user, and Offers complete, hardware based security. Bromium vsentry uses hardware isolation to protect the system from all malware known and unknown. Every untrusted application or file is processed in an independently hardware-isolated micro-vm which will defeat any attack, by design. The attacker cannot gain access to enterprise networks or data, or persist an attack on the endpoint. Moreover,

the attack will be automatically discarded as soon as the user closes the task window (or the browser tab). No remediation. No change to the applications or to the end user experience. And if the endpoint is attacked, Bromium LAVA will provide live attack visualization, with complete forensic analysis - delivered instantly to the SOC. Bromium micro-virtualization is the only absolutely reliable way to defeat all advanced malware, including Java based attacks. The Microvisor hardware-isolates each untrusted user task within a micro-vm, using CPU features developed for virtualization. The Microvisor hardware isolates the execution of each task using Intel VT, protecting the OS and its file system, the network infrastructure, and all valuable data from malware. How does vsentry manage both enterprise Java applications and malware delivered via the web or untrusted documents? Each browser tab is opened in a separate micro-vm, which is a hardware-isolated runtime environment with highly restricted access to networks, files and the desktop environment. In the example below, a compromised micro-vm (in this example a FAKEAV anti-virus attack crafted in Java) is independently and separately isolated from all other tabs in the browser including the Oracle ERP application.

As the user types into the ERP application, all user input is directed solely to that task, and not to any other tasks on the desktop, including the FAKEAV browser tab. The attacker, whose Java based attack succeeded in the highly restricted environment of a micro-vm, has no access to the enterprise network, or to any enterprise data (the file system) or to the desktop as a whole, and therefore cannot persist his attack. As soon as the user closes the browser tab, the entire task will be discarded, naturally remediating the PC from the attack. The protection afforded by a micro-vm is so substantial that it malware would need to break the CPU in order to compromise the system. The entire code base of the microvisor and all code that could be exploited by malware in an attempt to escape the micro-vm containment, is O(100KLOC). And even if this code is compromised, the system is designed to fail safe untrustworthy tasks may not execute, but the user will still have full access to their IT provisioned LOB applications (including enterprise Java applications), and will have the full protection of traditional AV. By contrast, any failure to detect, on the part of AV, or any break out from the sandbox will cause complete system compromise. The Bromium architecture is designed assuming compromise. Conclusion Micro-virtualization allows Bromium vsentry to offer protection that is tens of thousands of times more resilient than any existing protection mechanism essentially making it too expensive for an attacker to attempt to compromise the endpoint. It leverages three key innovations: Hardware isolation: drastically reduces the code base required for isolation. To break out of its isolated task environment (a micro-vm), malware would need to

break the CPU s hardware isolation designed for virtualization: Intel VT - in effect breaking the CPU. Granular task isolation in micro-vms: Protects kernel and application computation at a granular level. Each independent Java application runs in its own separately isolated micro-vm, independent of all others. Each has a highly restricted environment that prevents access to enterprise networks or data, while still preserving an intuitive, native user experience. Micro-VM Introspection: affords insights that are not available to in-os detection methods, by taking advantage of the hypervisor s privileged role in the system. This permits live attack visualization and analysis without false positives, and provides a full kill-chain for forensic analysis, including signature generation for malware payloads. Bromium HQ 20813 Stevens Creek Blvd, Suite 150 Cupertino, CA 95014 info@bromium.com +1.408.598.3623 Bromium UK Ltd Lockton House 2nd Floor, Clarendon Road Cambridge CB2 8FH +44 1223 314914 For more information refer to www.bromium.com Contact Us: sales@bromium.com