(Reloading Java Exploits)
(ReVuln Ltd.)
HITB AMS 2014
New JRE is Dead!
Long Live Old JRE!
(About)
2
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:
3
Introduction
Hardening
Sharing / Serialization Hardening
Multi-JVM / X-origin / Emu
Final consideration
Tricks
Java Update
(Why Java?
4
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
(Whats the current status of Java?)*
5
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
6
True Stories..
7
(Enterprise - 1)
8
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)
9
(JRE Status)
10
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)
11
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]
12
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
13
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?)
14
(Our Goal)
Assess the status of the current defensive solutions
Try to bypass detection of these defenses on exploits
for old vulnerabilities..
15
(Defenders)
We randomly selected a number of different defensive solutions,
including but not limited to:
AVG
Microsoft Defender
F-Secure
Symantec
16
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)
17
(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.
18
(Exploit Workflow)
19
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)
20
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)
21
Problem: its 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)
22
Hardening(base)
23
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)
24
Serialziation
Sharing
Multiple JVM
X-Origin
Emulators
Sharing
25
Sharing(idea)
26
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)
27
Original Exploit
Applet
Exploit[0]
Applet
Exploit[1]
Applet
Exploit[..]
Applet
Exploit[k]
Applet
K
1
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)
28
Exploit[0]
Applet
Step 1
Step 2
Exploit[1]
Applet
Step 3
Exploit[..]
Applet
Step i
Step i+1
Exploit[k]
Applet
Step n
1
2 m
Sharing(recap)
29
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
O
r
i
g
i
n
a
l
E
x
p
l
o
i
t
Simple Sharing
30
Timers(example)
31
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)
32
AppletContext
33
AppletContext(intro)
34
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, lets
see an example..
AppletContext(plan)
35
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)
36
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)
37
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)
38
Master.class
Zero.class
One.class
Two.class
Three.class
AppletContext(comm. pattern)
39
Master.class
Zero.class
One.class
Two.class
Three.class
Start Applets
Communication
AppletContext(initial step)
40
Blocking function
Wait for the remaining Applets to finish their tasks,
then execute the payload
AppletContext(comm. pattern)
41
Master.class
Zero.class
One.class
Two.class
Three.class
Execute
intermediate
exploit steps
Class<?>
AppletContext(comm. pattern)
42
Master.class
Zero.class
One.class
Two.class
Three.class
Disable
SecurityManager
Statement
AppletContext(last step)
43
Wait for a previous Applet to send a
Statement object..
AppletContext(comm. pattern)
44
Master.class
Zero.class
One.class
Two.class
Three.class
SecurityManager
has been disabled
SecurityManager
AppletContext(comm. pattern)
45
Master.class
Zero.class
One.class
Two.class
Three.class
SecurityManager
has been disabled
Execute
payload
AppletContext(execute!)
46
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:
Its 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
47
LiveConnect
48
LiveConnect(intro)
49
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)
50
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)
51
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
JS
Applet
LiveConnect(java side)
52
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)
53
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
Lets see another interesting way to minimize the amount of information in the
bytecode..
Serialization
54
Serialization(intro)
55
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)
56
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
57
Obj[1] Obj[2] Obj[3]
Obj[j] NO CA FE
BUT AC ED
Serialization(high-level)
58
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)
59
Serialization(serialized version)
60
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)
61
1
2
GET / HTTP/1.1
4
Disable Security Manager 5
Serialized object
6
Lets play the JVM role here..
3
len class name
SerialPay.class
(GET /SerialPay.class HTTP/1.1)
62
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
Lets 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)
63
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
64
(Step 1 Pick a Class)
Permissions localPermissions = new Permissions();
65
(Step 2 Check class definition)
We are looking for a
Serializable and Standard
Class C in E
66
(Step 3 Collect all the code that
updates the status of an object O)
Permissions localPermissions = new Permissions();
localPermissions.add(new AllPermission());
67
(Step 4 Use the pruned code P to
produce a serialized object S)
Permissions localPermissions = new Permissions();
localPermissions.add(new AllPermission());
68
(Step 5 Replace P in E, with an
assignment like: O = deserialize(S))
Replace P in E
O = deserialize(S)
69
(Step 6 Reduced Exploit)
BEFORE
AFTER
70
(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)
71
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
72
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)
73
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)
74
Applet 1
Applet 2
JVM 1
JVM 2
evil.htm
Multiple JVM(impact)
75
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
76
X-Origin(intro)
77
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)
78
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
Lets see a practical example..
X-Origin(schema)
79
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)
80
Local Applet
Remote Applet ptr*
Quick way to implement
HTML/JS based communication
X-Origin(recap)
81
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, its 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
82
Emulators(intro)
83
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)
84
These tricks aim mainly to the following 3 things:
Detecting the emulator
Breaking the emulator
Exploiting the emulator
Emulators(detecting/breaking)
85
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)
86
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)
87
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
88
The Java Update(intro)
89
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)
90
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?
91
(Detection Rate)
92
By applying Sharing/Serialization hardening
on the original exploit with very minimal obfuscation…
0
UNDETECTED
Conclusion
93
(Conclusion - 1)
94
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)
95
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?)
96
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)
97
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.. :[
98
PROTIP:
Even if your AV tells you: “Detected, look closer because…
Before we end.. :]
99
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?