Java Exploits: Offense and Defense

Source Presentation

Presented at the (ISC)2 Twin Cities Chapter October 2012 Meeting on October 24, 2012 by Matthew J. Harmon, IT Risk Limited, LLC. Harmon brought 20 years of information security experience (CISSP, GSEC, GCIH, CISO, ISO 27001 Lead Auditor) as a Community SANS Instructor for SEC 401 (Security Essentials Bootcamp), SEC 504 (Incident Handling, Exploits and Hacking Techniques), and SEC 464 (Hacker Guard for Systems Administrators). He also served as a Security Researcher, Interim CISO and Security Director, Penetration Tester, Security Architect, Incident Handler, and Computer Archeologist (Forensic Analyst), as well as an ISO Standards Developer – Chairman of US Technical Advisory Group 7 (Security), Liaison to Sub-Committee 27 (IT Security Techniques).

Why We Are Here

Client-side vulnerabilities (Java, Flash, iTunes) are a serious attack vector that is largely uncontrolled. Security practitioners need to raise awareness of these risks and recommend business-appropriate controls.

The presentation covers Oracle Java vulnerabilities and exploits, technical defense measures, and policy-based defensive measures. No exploit code was released or demonstrated – many effective exploits were already in the wild, and there was no need to add insult to injury. When the presentation was originally planned, it was expected that the October Java SE 7 Update 7 patch would fix the sandbox; it didn’t, and the next expected update was February 2013.

Published Research

Other security researchers had well-documented vulnerabilities in the Oracle Java Sandbox:

The Problem Is Built-In

The exploit code demonstrated how easily the Java SecurityManager could be disabled. A disableSecurity() method creates a Statement calling System.setSecurityManager with a null argument, grants AllPermission through a crafted ProtectionDomain with a CodeSource of file:///, and injects a permissive AccessControlContext into the Statement via reflection using sun.awt.SunToolkit.getField. Once localStatement.execute() runs, the security sandbox is gone.

Numbers Speak Volumes

23 of the 50 Oracle JRE vulnerabilities released in 2012 had a CVSS Score of 10. A CVSS score of 10 means game over: complete compromise of confidentiality, integrity and availability, without authentication. These vulnerabilities enabled code execution, denial of service, and bypass attacks. Reference: cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html.

Oracle’s Secure Coding Guidelines for Java

Was Oracle following their own guidelines?

  • SEC00-J: Do not allow privileged blocks to leak sensitive information across a trust boundary
  • SEC05-J: Do not use reflection to increase accessibility of classes, methods, or fields

References: kb.cert.org/vuls/id/636312 and oracle.com/technetwork/java/seccodeguide-139067.html.

Technical Defense Measures

Whitelisting

Until the track record of Oracle’s Java improves, applets should be considered hostile. The good news is that under Windows, Group Policies have Zone Mappings. To forbid Java in the Internet Zone, set: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3 Key 1C00 = 0. Reference: laws.qualys.com/2012/08/new-java-0-day-disclosed.html.

Click-to-Run

Default deny Java applets. Google Chrome and Firefox have the option of requiring the user to click on Java Applets before activating them. Click-to-Run helps prevent drive-by exploitation. Not as effective as whitelisting, but a good control. Reference: laws.qualys.com/2012/08/new-java-0-day-disclosed.html.

A Stronger Local Sandbox: Invincea

Invincea runs all major client-side applications in a virtual machine, evaluates application behavior against a known good baseline, and appears similar to Cube OS where every application runs in its own virtual machine. Strength in numbers. Reference: invincea.com.

An In-Line Sandbox: FireEye

Similar to Invincea, however FireEye runs as an in-line appliance. It ties in with malware analysis services. Strength in numbers. Reference: fireeye.com.

Policy-Based Defensive Measures

Security Policies

What is the business case for keeping Java around? If you don’t have a business requirement for allowing Java in your environment, remove it. Certification and accreditation doesn’t only apply to computers that run in your environment – it applies to the software running on those machines as well. Evaluate the risk of allowing Java to run uncontrolled. Reference: arstechnica.com/information-technology/2012/10/ars-asks-is-using-java-on-a-desktop-worth-the-security-risks/.

Critical Security Controls 1 Through 5

  1. Inventory of Authorized and Unauthorized Devices
  2. Inventory of Authorized and Unauthorized Software
  3. Secure Configurations for Hardware and Software on Laptops, Workstations, and Servers
  4. Continuous Vulnerability Assessment and Remediation
  5. Malware Defenses

Reference: sans.org/critical-security-controls/.

Final Comments

We’ve reached a point where client-side exploitable vulnerabilities are far more common than daemon or service vulnerabilities. These exploits, tied with social engineering and specifically phishing, leave our user populations vulnerable. Patching alone isn’t an effective measure – hostile software is running in our environments and we are not in control. Our adversaries aren’t disclosing the vulnerabilities they discover, so we shouldn’t wait.


Presented by Matthew J. Harmon, IT Risk Limited, LLC. matthew@itriskltd.com. IT Risk Ltd. performs IT risk assessments, penetration testing and incident response, leads security research and participates in international standards development. Presentation available at github.com/itriskltd. Licensed under Creative Commons Attribution-NonCommercial 3.0 Unported License.