View RSS Feed

Fb1h2s aka Rahul Sasi's Blog

Sandy: Opensource Exploit Analysis Framework .

Rating: 82 votes, 4.94 average.
Client side exploits are inevitable part of the security Industry. And no matter how much new security is added to these products they would be always exploited. As long as Government and Individuals need to hack into others confidential data there would be a requirement for exploits. So when there's demand, someone will supply.

Name:  download.jpeg
Views: 6260
Size:  3.2 KBName:  images.jpeg
Views: 5377
Size:  4.2 KBName:  Screen Shot 2014-04-07 at 3.19.33 pm.jpg
Views: 5465
Size:  5.8 KB

I started developing Sandy an Exploit Analysis and Automation framework in 2013 for Indian Honeynet project. I was working as a researcher with a Threat Intelligence firm back then and was able to actively work on this project. I recently changed my job and I am now working as a Application Security Engineer. The change in job profile kind of slowed my progress with sandy. Any way to keep things rolling and keeping the project alive SANDY is moved to GIT
GIT: .

There are a lot of automated system to process Msword and PDF exploits but nothing was there for JAVA . So sandy is created specifically for Java exploits.

Read More:

An instance of Sandy is here at . I just ripped the back end code and moved it to GIT. There would be lot of hardcoded paths and configuration. And it would take some time to beautify the code.

More About Sandy and JAVA Analysis Module:

I did two talks on Automated Exploit analysis and the Need for a specialised system at HITB and HITCon introducing SANDY.

The entire talk was for the security industry [Threat, AV, Firewall, IPS/IDS] and putting forward a solution to mass analysis exploits. With the rise in APT attacks and malwares spreading via a document, java, and browser exploits is pretty high.

Two big issues faced by the security industry is,

1) On how to analyze exploits in bulk and extract IP/controller information.

2) On how to attribute to apt groups to exploits collected.

Traditional malware sandboxes are built to analyze binary samples and you can submit binary files blindly to it with out knowing much about them. But that is not the case with exploit samples where a certain criteria’s needed to be satisfied for successful exploitation, like a document exploit might only work on Chinese xp box or a java exploit will only drop files on mac machine etc. And talking about java exploits, there is no sandbox that process java exploit at all. So their needs to be an intelligent specialized system that process these exploit samples. So I was working on a free tool [online and client version] in which I implemented both static and dynamic analysis, where files are not submitted to the dynamic sandbox directly instead it goes through a static analysis engine where it collects information about the samples and this intelligence is used in dynamic analysis phase. So tool is specific for analyzing exploit samples and a beta testing version could be found here.

So in my talk I explained the various things I learned from building this tool, and explained the methods used to automate mass exploit analysis so that individuals could replicate the methods or learn the various techniques involved in APT attacks.

JAVA Exploit Introduction:

Java Applets:

A Java applet is a small application written in Java and delivered to users in the form of bytecode. The user launches the Java applet from a web page and it is then executed within a Java Virtual Machine (JVM) in a process separate from the web browser itself. A Java applet can appear in a frame of the web page, a new application window, Sun's AppletViewer or a stand-alone tool for testing applets.

A browser that has java plugin installed would be able to execute the java class file from a browser.

<applet code="Bubbles.class" width="350" height="350">
Java applet that draws animated bubbles.
Another way of invoking an applet is by using the JNPL protocol. A better idea of JNPL and browser java plugins could be obtained from the following blog of mine.

So technically these are the only two ways I am aware of by which a java plugin could be invoked.

Java applets by default runs in a sandboxed environment and all the exploits seen in the wild uses a sandbox bypass technique .

Java Sandbox :

Before Getting into Java Exploits and Exploit analysis lets review Java security Architecture.
Pic Credits: Ref:

Name:  java_arti.jpg
Views: 1536
Size:  22.9 KB

Java Security is handled by the a Java Sandbox . The role of the sandbox is to provide a very restricted environment in which to run untrusted code obtained from the open network. The java sandbox is only enforced on web applets and not on java codes running on the local machines.

Java Security Arc.

Default Sandbox settings prevents applet from:

1) Reading and Writing files on the client machine.
2) Making Network connections
3)Creating Listening Sockets.
4) Starting other programs.
5) Loading Libraries.

Attachment 644

By default java is designed to be safe having solutions for a lot of common security issues, including but not limited to buffer overflows, memory management , type checking . One type of files that are by default allowed to run outside the Sandboxed environment are the "Signed Applets" (Not anymore).

Previously all the security checks were programmatically implemented.But later a in-order to make things more convenient and to manage java security restrictions easily , java introduced an easy to manage "Java Platform Security Model" .

Java Security Model

The Java security model is based on controlling the operations that a class can perform when it is loaded into a running environment. For this reason, this model is called code-centric or code-based.
The basic concept of security model are as follows.

1) Manage Permissions

Permissions: A permission is a set of permissible operations on some set of resources.

2) Protection Domains and Security Policies

A protection domain associates permissions with codesources. The policy currently in effect is what determines protection domains. A protection domain contains one or more codesources. It may also contain a Principal array describing who is executing the code, a classloader reference, and a permission set ( instance) representing a collection of Permission objects.

In short
Protection domain = Code source + collection of permissions
Code source = Origin of class file (URL| Path) + zero or more signers (certificates)
A class’s protection domain is established by the class loader when the class is loaded (only the class loader knows the class file’s origin) . A class’s protection domain is later used to make security decisions about what code in the
class is or is not allowed to do
In other words, a less "powerful" domain cannot gain additional permissions as a result of calling or being called by a more powerful domain.

3) Security Managers and Access Controllers
The above above permission check and protection domains are managed by security managers and access controllers.

Java Security is handled by the a Java Sandbox . The role of the sandbox is to provide a very restricted environment in which to run untrusted code obtained from the open network. The java sandbox is only enforced on web applets and not on java codes running on the local machines.

Sandboxed :

So the following applet with the compiled class file when run form the browser would be executing on a controlled environment.

<APPLET CODE="Main.class" WIDTH="800" HEIGHT="500">

JAVA Applet Permissions:

All the permission are enforced in a policy file located at []java-dir]/lib/security/java.policy .

The access controls is a stack based implementation.Each api when called is checked for it's permission before getting executed. The above is done by

So the basic pesudocode of would be as follows.

Code: ()


$Java-policy ="java.policy";

$api_caller_framer =$api_calls_stack;

check_permission($Java-policy , $api_calls_stack;);

check_permission($Java-policy , $api_calls_stack;)


if (allowed)

   return Allowed

else (not-allowed)

   return not_allowed


Few java properties to remember:

  • Java Restricted Packages
  • Java Security Manager
  • Reflection
  • Type safety
  • Java Serialization

Java Restricted Packages

There are packages in Java that cannot be accessed by untusted code by default.
These packages have the capability to execute privileged codes, or anything that is possible with java.
Example Restricted Packages: sun.awt.SunToolkit,sun,, com.sun.xml.internal.bind and

Security Manager

“Security manager is an object that defines a security policy for an application” . You can programmatically manage security policies using the SecurityManager class Java.lang.System.setSecurityManager is the method that sets security manager for the application.

Turning off the security manager is simple as adding this to you'r code. [Having right privilege]
Ref:BH_US_12_Oh_Recent_Java_Exploitation_Trends_an d_Malware_WP.pdf

The following Packages Implement the Security Manager[ java.lang.Securitymanager ] .

So normally code execution in java applet is achieved by disabling Security manager code:
Disabling security manager is only possible by a signed java applet or after a privilege escalation, and hence the above code is always seen in all the latest java exploits [obfuscated] majority of times. When a java sandbox bypass in done the code will have privileges to disable the security manager.

Different Types of JAVA Exploits

Here we will detail about the different types of bug found in Java:

  • Java Type Confusion Exploits. [CVE-2012-0507, CVE-2013-0431 ,CVE: 2013-2423 , ]
  • Java Logic error and sandbox bypass. [CVE-2012-4681, CVE-2013-0422]
  • Argument Injection [CVE-2010-0886 ]
  • Memory Corruptions [Stack based, Heap based, Outbound Write, Integer overflows] . [CVE-2013-1493, CVE-2013-2465 CVE-2013-2465 Java storeImageArray ]

A common Signature in Exploits:


Turning off the security manager is simple as adding this to you'r code.


The base class is :

And this is only possible by a signed java applet or after a privilege escalation, and hence this code is always seen in all the latest java exploits [obfuscated] majority of times.

Java Serialization

Java provides a mechanism, called object serialization where an object can be represented as a sequence of bytes that includes the object's data as well as information about the object's type and the types of data stored in the object.


Reflection is commonly used by programs which require the ability to examine or modify the runtime behaviour of applications running in the Java virtual machine.


With reflection : We Can create an instance of a class at runtime and use it while executing. Can access private class members.We can access private methods and variable, hidden class members .These are not possible when security manager is enabled.
Example : Consider we have an object named stack of unknown type and we want to do a push method on it if method exist . Java rules are not really designed to support this unless the object conforms to a known interface, but using reflection, your code can look at the object and find out if it has a method called 'push' and then call it if you want to.

Method method = stack.getClass().getMethod("push", null);
method.invoke(stack, null);
Reflection is is one of the most used features of Java when it comes to exploit building.

Type safety


Java prevents programs from accessing memory inappropriate ways. Type safety means that a program cannot perform an operation on an object unless that operation is valid for that object. has got a very good example and I will quote the entire example here.

Type safety is the most essential element of Java's security. To understand why, consider the following slightly contrived example. A calendar-management applet defines a class called Alarm. This class is represented in memory as shown in Figure 2.10. Alarm defines an operation turnOn, which sets the first field to true. The Java runtime library defines another class called Applet, whose memory layout is also shown in Figure 2.10. Note that the first field of Applet is fileAccessAllowed, which determines whether the applet is allowed access to files on the hard disk.

Suppose a program tried to apply the turnOn operation to an Applet object. If the operation were allowed to go ahead, it would do what turnOn was supposed to do, and set the first field of the object to true. Since the object was really in the Applet class, setting the first field to true allows the applet to access the hard disk. The applet would then be allowed (incorrectly) to delete files.
Type safety is generally done by performing static analysis at the time of compilation.So if a type changes at runtime then it’s impossible to do the safe check. So if we find a type confusion bug then we could confuse java making it think its process one kind of object but in reality its a different one.


Example :

An example on how type confusion is used to bypass security manager in java.

Here an applet has two pointers to the same memory one with type T and one with type U.

class T {
               SecurityManager x;

class U {
           Myobject x;

T t = the pointer tagged T;
U u = the pointer tagged U;
t.x = System.getSecurity();

Myobject m = u.x;

CVE-2012-0507 - Java Atomic Reference Array Exploit

Vulnerable Code:

public AtomicReferenceArray(E[] array) {
    // Visibility guaranteed by final field guarantees
    this.array = array.clone();

POC Explained

AtomicReferenceArray ara = new AtomicReferenceArray(new Integer[1]); 
Integer value = (Integer)ara.get(0); // value set to type integer of atomic ref array
AtomicReferenceArray uses sun.misc.Unsafe to directly access the array
With this we can do “ AtomicReferenceArray.set() “ which allows you to store any reference in the array.
So we can replace integer value with any reference in the array, and type safety check is bypassed.

AtomicReferenceArray ara = new 
AtomicReferenceArray(new Integer[1]);
ara.set(0, "foo");
Integer value = (Integer)ara.get(0);
Now value contains a string while being typed as Integer.With this combined with few other things we can disable security manager , and sanbdox restriction would be bypassed.

CVE-2012-4681 - Accessing restricted class with [ com.sun.beans.finder.ClassFinder ]

Restricted package sun.awt.SunToolkit was able to be accessed by ClassFinder method {java 7 New}. And with this privileged class

Classfinder.findclass was able to access restricted class .
Get accessor to private "acc" field of Statement.class . {Java 7}
Create Access control context with all permission
Create statement that disables security manager.
Set "acc" field accessor with permissions and security manager statement.
Execute and disable security manager
Game over.


class restricted_class = ClassFinder.findclas("sun.awt.SunToolkit");
Expression ex = new Expression(retricted_class, "getField",new Object[] [ Statement.class,"acc"])
Field.acc_field =((Field expr.getValue()};

//Get All permision

Permission all_permission = new Permissions();

all_permission.add( new Allpermission());

AccessControlContext allPermAcc = new AccessControlContext(new ProtectionDomain[] { new ProtectionDomain (new CodeSource ( new URL("file:///")/new Certificate[0], all_permission)


Java Applet Reflection Type Confusion | and memory manipulation .

Change type double to integer.
Use reflection to copy an integer field from one object to another.
Now reflection will copy 8 bytes instead of 4 thinking since the previous type was double.

JAVA Exploit reference:

CVE-2013-0431- jmxmbeanserver Logic Error Sanbox Bypass

Memory Corruptions:

CVE-2013-2465 , CVE-2013-2463, CVE-2013-2462 , CVE-2013-1493

Java Type Confusion Vulnerability

CVE-2013-0431 : RType Confusion Again.

Bypassing Security Warnings:

CVE-2013-1493 Memmory corruption


Tags: None Add / Edit Tags



Total Trackbacks 0
Trackback URL: