Free Privileged Account Discovery Tool: Identify & secure credentials to stop lateral movement. Download Free

BeyondTrust
  • Products
    Privileged Password Management
    Discover, manage, audit, and monitor privileged accounts
    Password Safe DevOps Secrets Safe
    Endpoint Privilege Management
    Manage privileges on Windows, Mac, Linux, and Unix endpoints
    Windows and Mac Unix and Linux Active Directory Bridge
    Secure Remote Access
    Centrally manage and secure remote access for service desks and vendors
    Remote Support Privileged Remote Access
    BeyondInsight Analytics
    See All Solutions
  • Resources

    Universal Privilege Management

    Our innovative Universal Privilege Management approach secures every user, asset, and session across your entire enterprise.

    Watch Video

    Learn

    Case Studies
    Competitor Comparisons
    Datasheets
    Glossary
    Product Demos
    Whitepapers

    Attend

    Events
    Go Beyond
    Training
    Webinars

    Support

    Changelog
    Professional Services
    Technical Documentation
  • Blog
  • Partners
  • Contact
  • Support
  • Services
  • Training
  • Events
  • Company

Java Pwns Everyone...Again.

August 30, 2012

  • Blog
  • Archive
Java has a nasty habit of getting you owned. This latest 0day is no exception to the long-lived trend of reliable Java-based exploitation. Here’s what you need to know: How does it work? The current exploitation method being employed in the wild right now leverages two zero day flaws in Java. The first flaw leverages an implementation issue (logic bug) within ClassFinder.findClass(), which is only present in Java 7. The method findClass() allows Java code to access restricted classes, when it should disallow such access. By using findClass() to gain access to restricted classes, the exploit is then able to use a reference for sun.awt.SunToolkit to access the getField() method. The second flaw, found in getField(), allows Java code to modify private fields (logic bug), which should normally be immutable when accessed externally (from outside the class it was declared in). The exploit uses getField() in order to modify the permissions of java.beans.Statement, which is then used to disable the Java Security Manager. At this point, the exploit is able to run code arbitrarily. No memory corruption occurs in the exploitation of these vulnerabilities. This makes the exploit 100% reliable for Java 7, across multiple platforms and through multiple browser-based attack vectors. What can we do to mitigate this threat?
  1. Install the patch from Oracle for CVE-2012-4681.
  2. Audit your environment for systems that have Java. Determine what systems actually need Java and remove it according to your needs. Once you have reduced your Java footprint, you can further reduce your attack surface by restricting how Java runs; determine if a system needs Java for Internet facing applications or if it needs Java for desktop and internal applications. Configure systems that need Java granularly – more information on how to do this can be found in the links below.a. Controlling Java<Applet> Tags http://blogs.msdn.com/b/ieinternals/archive/wp-content/uploads/15/controlling-java-in-internet-explorer.aspxb. Controlling Java <Object> Tags (ActiveX) http://support.microsoft.com/kb/2751647
It is important to note that some security companies have incorrectly recommended mitigation strategies for Java which would only disable the loading of Java via Applet tags, but not via Object/ActiveX instantiation. To be blunt, if you had followed those recommendations, an attacker would have simply changed Applet tags to Object tags and owned your systems. So keep in mind when reviewing mitigations, even from “Quality” folks in the vulnerability management space, that your mileage may vary. ;-) This constant panic over Java sucks… Yes, yes it does. Java is a big, powerful, and widely used software package that is prone to gnarly vulnerabilities like the ones being exploited right now. As such, it will continue to garner a lot of attention from malicious entities. This exploit has already been folded into Metasploit and is being used actively in the BlackHole exploit kit. By limiting the use of Java within your organization, you’re effectively closing doors that attackers would otherwise stroll through. Following the aforementioned recommendations will help reduce the likelihood of exploitation and let you breathe a little easier. BeyondTrust’s Retina Network Security Scanner (Retina Community is free) can audit for systems that are vulnerable to this issue: 17016 - Oracle Sun Java ClassFinder Vulnerability (CVE-2012-4681) - Windows - JDK 17017 - Oracle Sun Java ClassFinder Vulnerability (CVE-2012-4681) - Windows - JRE 17018 - Oracle Sun Java ClassFinder Vulnerability (CVE-2012-4681) - UNIX/Linux - JDK 17019 - Oracle Sun Java ClassFinder Vulnerability (CVE-2012-4681) - UNIX/Linux - JRE

Scott Lang, Sr. Director, Product Marketing at BeyondTrust

Scott Lang has nearly 20 years of experience in technology product marketing, currently guiding the product marketing strategy for BeyondTrust’s privileged account management solutions and vulnerability management solutions. Prior to joining BeyondTrust, Scott was director of security solution marketing at Dell, formerly Quest Software, where he was responsible for global security campaigns, product marketing for identity and access management and Windows server management.

Stay Up To Date

Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

You May Also Be Interested In:

Whitepapers

A Zero Trust Approach to Secure Access

Webcasts

Rising CISOs: Ransomware, Cyber Extortion, Cloud Compromise, oh my!

Whitepapers

A Zero Trust Approach to Windows & Mac Endpoint Security

BeyondTrust Logo
  • Facebook
  • Twitter
  • LinkedIn

Keep up with BeyondTrust

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

Customer Support
Contact Sales

Products

  • Endpoint Privilege Management
  • Password Management
  • Privileged Remote Access
  • DevOps Secrets Safe
  • Remote Support

Resources

  • Blog
  • Case Studies
  • Competitor Comparisons
  • Datasheets
  • Glossary
  • Videos
  • Webcasts
  • Whitepapers

About

  • Company
  • Careers
  • Contact
  • Events
  • Leadership Team
  • Partner Program
  • Press

Languages

  • English
  • German
  • French
  • Spanish
  • Korean
  • Portuguese
  • Japanese
  • Privacy
  • Security
  • Manage Cookies
  • WEEE Compliance

Copyright © 1999 — 2020 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.