(Reloading Java Exploits)

(ReVuln Ltd.)

HITB AMS 2014

New JRE is Dead!

Long Live Old JRE!

(About)

Donato Ferrante

@dntbug

Luigi Auriemma

@luigi_auriemma

Consulting

Penetration Testing

SCADA Security

Vulnerability Research

…

revuln.com

info@revuln.com

twitter.com/revuln

(This Talk)

•At the end of this talk you will know about:

–New techniques to harden Java exploit to bypass detection

–Limitations of current defensive solutions

–To fear the Enterprise world as a Java user

•Overview:

Introduction

Hardening

Sharing / Serialization Hardening

Multi-JVM / X-origin / Emu

Final consideration

Tricks

Java Update

(Why Java?

From http://www.java.com/en/about/:

•97% of Enterprise Desktops run Java

•89% of Desktops (or Computers) in the U.S. run Java

•9 Million Java Developers Worldwide

•#1 Choice for Developers

•#1 Development Platform

•3 Billion Mobile Phones Run Java

•100% of Blu-ray Disc Players Ship with Java

•5 Billion Java Cards in Use

•125 million TV devices run Java

•5 of the Top 5 Original Equipment Manufacturers Ship Java ME

(What’s the current status of Java?)*

Block Self-Signed and Unsigned applets on High Security Setting

Exception Site List

The Exception Site List feature allows end users to run Java applets and Java Web Start applications

(also known as Rich Internet Applications) that do not meet the latest security requirements.

* https://www.java.com/en/download/faq/release_changes.xml

(Is Java finally safe and sound?)

•Java (as JRE) is obviously getting better

•Java users are still not ready for a safer JRE..

–Not updating

–Downgrading

–Changing security settings

True Stories..

(Enterprise - 1)

With the recent Java-Update there was a security enhancement.

Websites without a valid certificate are blocked by Default. In the

Java Control Panel you have to manually switch from “High” to “Medium” Security.

Is there any registry key which I can distribute via GPO?

I don’t want to set this manually on all our 400 Users…

(Enterprise - 2)

(JRE Status)

57.44%

from Kaspersky [1]

94.83%

from Websense [2]

This pie chart was compiled using data from

26.82 million Individual users of Kaspersky

Security Network reporting the use of any

version of Java on their personal computers.

~ 15 million users are running an

outdated version of the JRE

(Java Exploit Status)

To recap the Java exploits status, we just need 1 example.

In August 2013, the most exploited vulnerability according to Kaspersky [1] is

CVE-2012-1723. Which was at that time more than 1 year old.

(CISCO 2014 Security Report)[3]

91%!!1!

(JRE World)

•JRE world is a mess..

1) People still using old and out-dated

versions of the JRE

2) Exploits for old JRE vulnerabilities

are still used heavily by attackers

NOTE: Surveys from different Vendors reflect only part

of all Java users, as they have feedback from their Customers only

•Sometimes they don’t even know about Java

•They don’t keep the JRE up to date

•They are forced to use an old release of the JRE

•Their systems are affected by old JRE issues

•They need some defensive solution

–Antivirus / IDS / IPS

(What about Java users?)

(Our Goal)

•Assess the status of the current defensive solutions

•Try to bypass detection of these defenses on exploits

for old vulnerabilities..

(Defenders)

•We randomly selected a number of different defensive solutions,

including but not limited to:

–AVG

–Microsoft Defender

–F-Secure

–Symantec

–…

•An old vulnerability (CVE-2012-4681) and an old exploit to harden (original

exploit [4] by @jduck)

•Via Applet

–Embedded on a web page

–Executed within a JVM

(Attackers)

(Applet Security)

The security manager is a class that allows applications to implement

a security policy. It allows an application to determine, … , what the

operation is and whether it is being attempted in a security context

that allows the operation to be performed.

(Exploit Workflow)

•Something like:

–Get access to sun.awt.SunToolkit

•Supposed to be a restricted package

–Call methods indirectly trick the JVM Verifier

–Get access to a private field of Statement

•Via SunToolkit.GetField()

–Define a new access control context

•All Permissions

–Create a Statement to disable the Security Manager

–Use Field to change the permission of the Statement

–Disable the Security Manager

(Detection Rate)

•For the basic version (the one available on the internet) of the exploit

Microsoft AVG Kaspersky

F-Secure Symantec

Exploit:Java/

CVE-2012-

4681.AIN

Java/

Exploit.

BBJ

HEUR:Exploit

.Java.CVE-

2012-

4681.gen

Exploit:Java/

CVE-2012-

4681.F

Trojan.Maljav

a!gen24

(Java Bytecode)

•Problem: it’s too verbose - Too much information is disclosed to defenders

Information From

Source file name Gondvv.java

Requesting permissions java/security/AllPermission

Spawning a process java/lang/Process

Referencing an EXE calc.exe

An Applet! java/applet/Applet

1 + 1 = Malware..

(Hardening)

Hardening(base)

•There are a number of different basic techniques to harden Java exploits,

including:

–Obfuscation

•Flooding based

•De-numberation

–Reflection

•Proxy call

•These techniques aim to reduce the amount of information available from

the bytecode

•Well known techniques, we won’t talk about these..

Hardening(advanced)

Serialziation

Sharing

Multiple JVM

X-Origin

Emulators

Sharing

Sharing(idea)

•KEY-POINT:

–Applets on the same page share the same Java Virtual Machine

•IDEA:

–Using multiple Applets to exploit a vulnerability

–Applets will cooperate to update the status of the shared JVM

–We are writing a distributed version of an exploit

–The “malicious” status is not given by a single Applet but is given as

the result of the execution of a set of different Applets

•An important step of the Sharing approach consists in splitting the original

exploit Applet into multiple Applets

Sharing(exploit split)

Original Exploit

Applet

Exploit[0]

Applet

Exploit[1]

Applet

Exploit[..]

Applet

Exploit[k]

Applet

1:K

•An exploit is a sequence of steps

•We are writing a distributed version of the exploit!

•By splitting the exploit across different Applets we need to be sure that

the steps will be executed in the right order

Sharing(exploit steps)

Exploit[0]

Applet

Step 1

Step 2

Exploit[1]

Applet

Step 3

Exploit[..]

Applet

Step i

Step i+1

Exploit[k]

Applet

Step n

2 m

Sharing(recap)

Applet_1.class

Applet_2.class

Applet_N.class

JVM

•Applets:

–In this approach an attacker will use

multiple Applets

–Possible to even mix legit and

malicious code

•JVM:

–The status is updated by all of the

Applets hosted on the page

•Detection:

–Detectors now have to understand

the communication pattern to

determine the JVM’s status

Simple Sharing

Timers(example)

Attacker.htm

Uno.java

Due.java

Easy way to handle synchronization

•PROS:

–Easy way to bypass detectors..

•CONS:

–Not very suitable with complex communication patterns

–Timers can be affected by external delays, which randomly

affects the timing of each step. This might impact on the success

of the exploit.

Timers(recap)

AppletContext

AppletContext(intro)

•AppletContext is an interface, which allows Applets to query their

environment (the web page they are hosted on)

•We are mainly interested in two methods:

–Applet getApplet(String name)

•To get a reference to another Applet on the same web page

–Enumeration getApplets()

•To find all the Applets on a given web page

•There are multiple ways to use this feature to harden Java exploits, let’s

see an example..

AppletContext(plan)

•We split the original exploit into several different Applets (5)

•We use an additional Applet as a Communication channel

Master.class

Zero.class

One.class

Two.class

Three.class

Channel.class

OriginalExploit.class

AFTER

BEFORE

AppletContext(comm. pattern)

•Here we can see one of the possible communication patterns which we

choose to use to harden the original exploit

•Please keep in mind that each of the Applets below will execute 1 or more

steps of the original exploit

–We need somehow to handle step synchronization

Master.class

Zero.class

One.class

Two.class

Three.class

Step A

Step B

Step C

Step D

Step E

Step F

AppletContext(channel.java)

•It represents the “structure” that will

handle the Applet communication

•We define this “structure” in a

blocking way, so that even if the

exploit steps are distributed, we can

still execute them in the right order

–Receive() are blocking in our

implementation

•The channel exposes a number of

send/recv functions that allows other

Applets to share Java types

Blocking function

AppletContext(comm. pattern)

Master.class

Zero.class

One.class

Two.class

Three.class

AppletContext(comm. pattern)

Master.class

Zero.class

One.class

Two.class

Three.class

Start Applets

Communication

AppletContext(initial step)

Blocking function

Wait for the remaining Applets to finish their tasks,

then execute the payload

AppletContext(comm. pattern)

Master.class

Zero.class

One.class

Two.class

Three.class

Execute

intermediate

exploit steps

Class<?>

AppletContext(comm. pattern)

Master.class

Zero.class

One.class

Two.class

Three.class

Disable

SecurityManager

Statement

AppletContext(last step)

Wait for a previous Applet to send a

Statement object..

AppletContext(comm. pattern)

Master.class

Zero.class

One.class

Two.class

Three.class

SecurityManager

has been disabled

SecurityManager

AppletContext(comm. pattern)

Master.class

Zero.class

One.class

Two.class

Three.class

SecurityManager

has been disabled

Execute

payload

AppletContext(execute!)

Master.class

Zero.class

One.class

Two.class

Three.class

Execute

payload

AppletContext(recap)

•PROS:

–Very effective way to bypass detectors!

–Each Applet can host a few steps of the original exploits

and some legit code

•CONS:

–It’s based on Java (only)

•Which means that all the communication is handled in Java

•A Java emulator can help detectors to infer the communication

pattern

LiveConnect

LiveConnect(intro)

•Java + JavaScript = LiveConnect

•LiveConnect is a feature of Web browsers that allows Java and JavaScript

to interact within a web page

•Which means, we can call Java code from JS, and vice-versa

•To use LiveConnect, our code needs to use:

–netscape.javascript.*

•At Runtime, the Java plugin will do all the magic we need to run our

mixed Java/JS application

LiveConnect(possible approach)

•Remove all the strings, constants, etc from the Java code and move these

information into the JS part. Less info in the bytecode means harder to detect.

HTML/JS

LiveConnect(html+ js)

•The exploit now consists of:

–A web page

–1+ Applet(s)

–A number of different JavaScript

functions defining part of the

original exploit

•Strings

•Numbers

•Maths

•Etc..

debug

value

Applet

LiveConnect(java side)

•From the Java Applet(s) we request part of the original exploit from the

hosting web page, by calling several JavaScript functions (via LiveConnect)

Applet JavaScript

js_getDisableSecurityAccOne()

“file://”

LiveConnect(recap)

•PROS:

–By using LiveConnect, we are actually shifting the detection from Java only to

{ Java AND JavaScript }, which means that:

•now detectors will have to evaluate the Applets in function of the

JavaScript code in order to understand the behaviour of the Applets

–LiveConnect can be used as a strategy to replace AppletContext to handle

Applets communications

•CONS:

–It requires JS to be enabled on the victim browser

Let’s see another interesting way to minimize the amount of information in the

bytecode..

Serialization

Serialization(intro)

•LONG DEFINITION: Serialization is the process of translating data

structures or object state into a format that can be stored (for example,

in a file or memory buffer, or transmitted across a network connection

link) and reconstructed later in the same or another computer

environment

•SHORT DEFINITION: Serialization allows us to translate the status of an

object into a format that can be stored and resurrected later in the same

or another JVM

•Java serialized object => Sequence of bytes { AC ED .. .. ..}

•By using Serialization an attacker can hide a lot of information to the

detectors, including but not limited to part of the exploit algorithm itself

Serialization(idea)

Klass k = new Klass();

k.val1 = “Hello”;

k.val2 = “ReVuln”;

k.update()

Serialize(k)

k.print()

1st time

“Hello ReVuln”

Serialized object

.print()

2nd time (even on a different JVM..)

“Hello ReVuln”

NOTE: The blue “circle” hides the algorithm used to generate its status!

Serialization(pre-created object)

•Since serialization can be used to recreate objects in memory, we can use

this concept to define an interesting idea..

– IDEA:

build an exploit by reusing pre-created (serialized) Java objects

Obj[1] Obj[2] Obj[3]

Obj[j] NO CA FE

BUT AC ED

Serialization(high-level)

•An object can be serialized or deserialized via:

–public final void writeObject(Object x) throws IOException

–public final Object readObject() throws IOException, ClassNotFoundEx.

•The deserialization algorithm is interesting, as it might disclose information that

will be then used by detectors to block possible exploits

–we call this “information disclosure”, a Weak Link

•NOTE: To perform a deserialization the JVM needs to know the Class (type) of the

serialized object

Applet

Serialized

Obj

JVM

Class(Obj)

ClassNotFoundException

Definition for Obj found

Definition for Obj NOT found

(Back to the Original Version)

Serialization(serialized version)

Some numbers:

•Original version #LoC = ~ 74

•Serialized version #LoC = ~ 3

Rule of Thumb:

•Less code => More difficult to detect

(for a number of reasons, including but not limited to: False Positives)

Serialization(details)

GET / HTTP/1.1

Disable Security Manager 5

Serialized object

Let’s play the JVM role here..

len class name

SerialPay.class

(GET /SerialPay.class HTTP/1.1)

•If we serialize a non-standard JRE class, detectors will be able to obtain the

class definition by following the same way the JVM did

•In our example a detector would just analyze the first byte of a serialized

stream, to get the length and the name of the serialized class and

download it to detect our exploit:

–wget http://remote_host/SerialPay.class

•The class SerialPay is a Weak Link

•Let’s try to define a strategy to remove these weak links and obtain a

serialized version of a given exploit

–Welcome Exploit Pruning algorithm

Exploit Pruning(definition)

It produces a mutation M(E) of an input exploit E, reducing the bytecode

information, without introducing weak links.

1. Select* a Serializable and Standard Class C in E

2. Collect all the code that updates the status of an object O (type C)

3. Check for dependencies*

4. Prune this code (P)

5. Use the pruned code P to produce a serialized object S, which represents

the updated status of the object O in the exploit context

6. Replace P in E, with an assignment like: O = deserialize(S)

7. Repeat* steps from 1 to 7

(Step 1 – Pick a Class)

Permissions localPermissions = new Permissions();

(Step 2 – Check class definition)

We are looking for a

Serializable and Standard

Class C in E

(Step 3 – Collect all the code that

updates the status of an object O)

Permissions localPermissions = new Permissions();

localPermissions.add(new AllPermission());

(Step 4 – Use the pruned code P to

produce a serialized object S)

Permissions localPermissions = new Permissions();

localPermissions.add(new AllPermission());

(Step 5 – Replace P in E, with an

assignment like: O = deserialize(S))

Replace P in E

O = deserialize(S)

(Step 6 – Reduced Exploit)

BEFORE

AFTER

(Step 7 – Repeat)

Use the current reduced exploit as input of the next pruning pass

Repeat Step 1-7

You can keep pruning as long as the prerequisite is satisfied:

There is at least a Standard and Serializable class in E not yet pruned

Exploit Pruning(recap)

•Serialization helps to reduce the amount of information available from

the Java bytecode to the defenders

•Using serialization in exploits forces defenders to implement and use some

sort of parsers to be able to read serialized data into their engines

•By performing exploit pruning an attacker can reduce the class-disclosure

during the deserialization process to a minimum

•Serialized data can be obfuscated (as we are dealing with an array of

bytes). Obfuscation can be performed either in the Java code or outside

i.e. JavaScript, HTML tags, media stuff, etc :]

•NOTE: The exploit pruning process can be easily automated

Multiple JVM

•Applets can run in different JVMs

–Even if they are on the same document

•To spawn a different JVM, we use the separate_jvm param

test.htm

Multiple JVM(separate_jvm)

Applet 1

Applet 2

JVM 1

JVM 2

•JVMs are independent and separate

•We need a way to handle the X-JVM communication

–A possible way is to rely on some JavaScript on the hosting page

test.htm

Multiple JVM(communication)

Applet 1

Applet 2

JVM 1

JVM 2

evil.htm

Multiple JVM(impact)

•By deploying an exploit in a way that will use 2 or more JVMs to trigger the

vulnerability, we are breaking most or all of the possible defensive

strategies based on JVM inspection..

Applet 1

Applet 2

JVM 1

JVM 2

Applet 3

Applet 4

JVM 3

JVM 4

X-Origin

X-Origin(intro)

•Sandbox Applets have a number of limitations (for security reasons)

They cannot connect to or retrieve resources from any third party

server (any server other than the server it originated from).

X-Origin(idea)

•The idea here is to use some JavaScript to break out of this limitation, so

that we will be able to harden Java exploits by retrieving

information/exploit-parts residing on different domains

•There are some caveats to keep in mind while working with this approach

–We can’t leave the domains where the Applets are hosted

–But we can share information/resources across different remote

domains hosting different Applets

•Let’s see a practical example..

X-Origin(schema)

Applet Local

Applet Remote

Points to

Applet Remote

Javascript and

HTML

Remote

Resource

http://domain-L/al.htm

http://domain-R/ar.htm

X-Origin(code)

Local Applet

Remote Applet ptr*

Quick way to implement

HTML/JS based communication

X-Origin(recap)

•Domain-L

–Contains the main exploit Applet

–Contains a pointer to an Applet residing on a different remote domain

•Domain-R

–Hosts the Applet, which will provide local (to R) exploit-parts to the

other Applet (on L)

•By doing so we will be able to do X-domain Applet communication

•Which means that now, it’s possible to harden an exploit by retrieving

exploit parts from different remote domains, and then combine all these

parts together to get the actual exploit to work

Emulators

Emulators(intro)

•Some defensive solutions (i.e. some AVs) available on the market offer an

embedded (in the engine) Java emulator

•The emulator kicks in (usually) only for a subset of .class files

•Emulators allow these products to resolve obfuscation problems or even

to obtain information about the execution flow of an exploit

•Emulators can be annoying for Java exploits

•Luckily there are a number of tricks to defeat emulation..

Emulators(detect/break/exploit)

•These tricks aim mainly to the following 3 things:

–Detecting the emulator

–Breaking the emulator

–Exploiting the emulator

Emulators(detecting/breaking)

•Abusing the Java Garbage Collector (thanks to Adam Boulton)

–The main idea is to reuse JVM callbacks when the garbage collector

kicks in to execute part of the code, by implementing the finalize()

method for each class used

–The workflow is the following:

•Define 1 or more class implementing the finalize method

•Deploy the exploit code as code of the finalize methods

•Define a strategy to trigger the Java garbage collector (1+ times)

•Profit

Emulators(exception/native)

•Abusing Java Exception handling subsystem

–Call chain of functions executing the exploit

code into the Exception handlers

–Building this chain by reusing exceptions

thrown by mis-called standard JRE functions

•Abusing JRE native methods

–Using obscure native methods like

Math.hypot (thanks to @mihi42)

•NOTE: if the emulator is not able to run the

code, the AV will not be able to see the exploit,

as the exploit flow will be revealed only when

the code is actually executed

Emulators(exploiting)

•Emulators are usually part of AV engines

•Written in C/C++ for performance reasons

–Buffer and Heap overflows

•The Java class format is interesting to parse

–Table++

–Index++

–Len++

–2 * Free()

–More..

•Potentially a LOT to have fun with :]

The Java Update

The Java Update(intro)

•So…

–You were running an OLD version of the

Java Runtime on your system

•But..

–You did an update

•So..

–You are safe!

•So..

–You are NOT safe!

The Java Update(java_version)

Updating Java = Installing a new version

Updating Java != Uninstalling the old version

Using java_version to select an old

JRE version for a given Applet.

“The JRE version selection capabilities of the new

Java Plug-In are intended to solve longstanding

problems in enterprise deployments of applet content.”

Wait!

What about the detection rate?

(Detection Rate)

By applying Sharing/Serialization hardening

on the original exploit with very minimal obfuscation…

UNDETECTED

Conclusion

(Conclusion - 1)

•Java is a huge attack vector and its exploits were and are the main web threat

•Current defensive solutions are NOT effective against hardened Java exploits =

you are vulnerable even if you use a $1000 Antivirus, IPS, IDS, or even a

magicbox to defend your systems

•I am safe because my browser asks for confirmation before running Java!

Really? Good luck with that :]

•PROTIP#1: Be sure to not mess with the Java security settings, if they are set

to High by default it means that there is a good reason for it :]

•PROTIP#2: The only way to be safe against old vulnerabilities is either to

remove Java, OR to delete any previous version from your system and use

ONLY the latest one

(Conclusion - 2)

•From the CISCO Annual Report 2014 [3]: “Cisco TRAC/SIO research also

shows that 76 percent of enterprises using Cisco solutions are also using

the Java 6 Runtime Environment, in addition to Java 7. Java 6 is a

previous version that has reached its end of life and is no longer

supported. Enterprises often use both versions of the Java Runtime

Environment because different applications may rely on different

versions to execute Java code.”

(Want to know more?)

•If you want to know more about Java Exploit Hardening please check one of our

previous talks on this subject:

–http://revuln.com/files/Ferrante_Smashing_Exploit_Detectors.pdf

(References)

1) Kaspersky Lab Report: Java under attack – the evolution of exploits in 2012-2013:

http://media.kaspersky.com/pdf/Report_Java_under_attack_2012-2013.pdf

2) Websense on Java attacks:

http://community.websense.com/blogs/securitylabs/archive/2013/03/25/how-

are-java-attacks-getting-through.aspx

3) Cisco 2014 Annual Security Report:

https://www.cisco.com/web/offer/gist_ty2_asset/Cisco_2014_ASR.pdf

4) @jduck original exploit for CVE-2012-4681:

http://pastie.org/4594319

Before we end.. :[

•PROTIP:

–Even if your AV tells you: “Detected”, look closer because…

Before we end.. :]

•PROTIP:

– Detected doesn’t mean it didn’t run on your pc..

(Thanks!)

100

“Invincibility lies in the defense,

the possibility of victory in the attack.”

ReVuln Ltd. – revuln.com

Yarrrrr.. Questions?