Thursday, August 30, 2012

Java patched at least 4 bugs

The last couple of days there has been a big convulsion on the social networks about the Java zero days found in a Chinese attack campaign on the Internet.

After some deep analysis of the Jar used in the exploit, we found out that there were actually two bugs exploited in order to jump outside the Java security sandbox.

Oracle has just released a new update, Java JDK/JRE 7 update 7 is now
available at

The release notes say that this contains fixes for CVE-2012-4681. This seems to be a new move in the recent history of Java updates, since generally it takes months to QA a Java security bug fix - which may be how long this took, considering some researchers claim they sent these vulnerabilities to Oracle months ago.

While doing some fast analysis (keep in mind we only spent an hour and half on it), we find out that they patched at least 4 vulnerabilities in the Java code base: The two used by the Gondvv worm and two more on difference pieces of code. Just by simply running the Immunity CANVAS exploit that exploits this vulnerability we can see that this update is preventing it.
When we run the exploit we get the following exception: access denied
("java.lang.RuntimePermission" "accessClassInPackage.sun.awt")
 at java.lang.SecurityManager.checkPermission(
 at sun.applet.AppletSecurity.checkPackageAccess(
 at sun.reflect.misc.ReflectUtil.checkPackageAccess(
 at com.sun.beans.finder.ClassFinder.findClass(
 at com.sun.beans.finder.ClassFinder.resolveClass(
 at java.beans.Statement.invokeInternal(
 at java.beans.Statement.access$000(
 at java.beans.Statement$
 at Method)
 at java.beans.Statement.invoke(
 at java.beans.Expression.execute(
 at Gondvv.GetClass(
 at Gondvv.SetField(
 at Gondvv.disableSecurity(
 at Gondvv.init(

There isn't much information in the traceback about the exact changes that this update includes so taking a better look we can see that not only these 2 vulnerabilities used in the Gondvv exploit have been patched, but also some others.
The two vulnerabilities used in the exploit were located in com.sun.beans.finder.ClassFinder and com.sun.beans.finder.MethodFinder
The update also patched at least another 2 other vulnerabilities that were basically the same but related to Constructors and Fields and allowed an attacker to get any public constructor or any public field via reflection bypassing security checks. 

These 2 vulnerabilities were located in com.sun.beans.finder.ConstructorFinder and com.sun.beans.finder.FieldFinder and the underlying issue was the same "a trusted immedate caller".
These two "new" vulnerabilities patched combined with the MethodFinder weakness could allow you to bypass the Sandbox and obtain full execution on Linux, Windows and MacOSX.  Now Oracle has added proper checks by adding calls to methods of sun.reflect.misc.ReflectUtil class.
Another interesting change this update includes is that public static methods getField and getMethod in sun.awt.SunToolkit were removed which means that the technique used in the exploit to get a private field no longer works.

- Esteban Guillardoy

Tuesday, August 28, 2012

Java 0day analysis (CVE-2012-4681)

(This post brought to you by Esteban, Immunity's in-house Java friend)


A couple of days ago, a Java 0day was found running like crazy in the wild. While a lot of defense bunnies where asking "WWMAD" (What will my Antivirus do?), we decide to dive into Java for the details of the vulnerability and as we expected, the unpatched vulnerabilities used in the Gondvv exploit were more than one (When we said, "dive deep into Java", we actually meant open our new Infiltrate 2013 Master Class slide deck which will include a full day of Java auditing).

The first bug was used to get a reference to sun.awt.SunToolkit class that is restricted to applets while the second bug invokes the getField public static method on SunToolkit using reflection with a trusted immediate caller bypassing a security check.

The beauty of this bug class is that it provides 100% reliability and is multiplatform. Hence this will shortly become the penetration test Swiss knife for the next couple of years (as did its older brother CVE-2008-5353). 

As a final note, the bug was introduced in Java 7.0 released in July 28, 2011. While you are feeling the rush of blood going through your veins while by getting all those shell being pop, think that somewhere not far way (Probably a 10hs flight from some of the major airports in Norte Americana) was enjoying it non-stop for quite some time now.


As the “Secure Coding Guidelines” document [1] states, it is important to understand how the permissions are checked in the Java security model. (Please readguideline 9-1).

Many operations in the JDK perform permission checks before executing. Whenever a call to method is performed, the complete call stack that exists at that moment is analyzed.

If any of the callers in the stack do not have the required privileged an exception is raised.
When we are running code in an Applet in our browser, there is a context that has very restricted permissions.

This means that if there is any caller in the stack that is part of our applet, the permission checks will fail (unless there is a doPrivileged code block, but let's leave that out for now).
Section “9 – Access Control” in the “Secure Coding Guidelines” document [1] together with the “Java Security Architecture” document [2] will give you a complete insight on how all this works.

The Gondvv exploit

A PoC for this 0 day exploit quickly began to spread when Joshua J. Drake posted it on Twitter

By analyzing this implementation we can clearly see how the exploitation is done and where the vulnerabilities are really located.

The first thing we notice, is that most of the online analysis talks about one vulnerability where we saw two 2 vulnerabilities being exploited to achieve full execution on a target.

Basically the exploit is creating an instance with a that has full permissions and then replace the actual AccessControlContext of a java.beans.Statement instance to be able to execute code with full privileges.
So let's take a better look at each part to understand what is happening under the hood.
In the java.beans.Statement implementation we can see that the AccessControlContext instance is a private final field and it gets its value by calling AccessController.getContext().

public class Statement {

private static Object[] emptyArray = new Object[]{};

static ExceptionListener defaultExceptionListener = new ExceptionListener() {
public void exceptionThrown(Exception e) {
System.err.println("Continuing ...");

private final AccessControlContext acc = AccessController.getContext();
private final Object target;
private final String methodName;
private final Object[] arguments;
ClassLoader loader;



That call to the getContext method will set the AccessControlContext to an applet context that has restrictions with a limited ProtectionDomain which of course is not privileged at all.

Back in 2010 Sami Koivu published information about a Java vulnerability (CVE-2010-0840) that built a “trusted method chain” [4].

You can see in the article that the exploitation of that vulnerability also made use of the java.beans.Statement class.

The article also explains that the fix was to add an AccessControlContext field to the Statement class setting its value to the applet context when creating an instance thus avoiding the full trusted chain.

This AccessControllContext field added in that fix is exactly what this new 0 day exploit is replacing in order to be able to execute code with full permissions.

But how can a private field be changed?
The trick here is to use the sun.awt.SunToolkit class which contains a very interesting public static method:
public static Field getField(final Class klass, final String fieldName) {
return AccessController.doPrivileged(new PrivilegedAction<Field>() {
public Field run() {
try {
Field field = klass.getDeclaredField(fieldName);
assert (field != null);
return field;
} catch (SecurityException e) {
assert false;
} catch (NoSuchFieldException e) {
assert false;
return null;

We can see that it is using reflection to get fields and the complete implementation is inside a doPrivileged block. This getField method can be used to get any field on a class and the good thing is that it can even retrieve private ones.

Well this is of course very useful, it's important to notice that the classes that are part of certain packages are restricted for applets and cannot be accessed or used. Such packages are:
  • com.sun.deploy.*
  • com.sun.imageio.*
  • com.sun.javaws.*
  • com.sun.jnlp.*
  • com.sun.xml.internal.bind.*
  • sun.*
Trying to instantiate or use classes in these packages will result in an AccessControlException.
This means that we are not able to get a reference to the sun.awt.SunToolkit class from our applet.
But the basic thing we need to know is that calls to certain methods can potentially bypass the SecurityManager checks depending on the immediate caller's class loader.

This is explained in detail in the “Secure Coding Guidelines” document by Sun [1] in guidelines 9-8 and 9-9.

This exploit is abusing this situation taking advantage of the immediate caller to bypass security checks.


There are 2 different zero-day vulnerabilities used in this exploit: one is used to obtain a reference to the sun.awt.SunToolkit class and the other is used to invoke the public getField method on that class.
The exploit is making use of the java.beans.Expression which is a java.beans.Statement subclass.
There are 2 Expression instances that are used to trigger these 2 different bugs.

When the Expression.execute method is called it ends up calling Statement.invokeInternal method, so let's check the implementation:

private Object invokeInternal() throws Exception {
Object target = getTarget();
String methodName = getMethodName();

if (target == null || methodName == null) {
throw new NullPointerException((target == null ? "target" :
"methodName") + " should not be null");

Object[] arguments = getArguments();
if (arguments == null) {
arguments = emptyArray;
// Class.forName() won't load classes outside
// of core from a class inside core. Special
// case this method.
if (target == Class.class && methodName.equals("forName")) {
return ClassFinder.resolveClass((String)arguments[0], this.loader);
Class[] argClasses = new Class[arguments.length];
for(int i = 0; i < arguments.length; i++) {
argClasses[i] = (arguments[i] == null) ? null : arguments[i].getClass();

AccessibleObject m = null;
if (target instanceof Class) {
For class methods, simluate the effect of a meta class
by taking the union of the static methods of the
actual class, with the instance methods of "Class.class"
and the overloaded "newInstance" methods defined by the
This way "System.class", for example, will perform both
the static method getProperties() and the instance method
getSuperclass() defined in "Class.class".
if (methodName.equals("new")) {
methodName = "newInstance";
// Provide a short form for array instantiation by faking an nary-constructor.
if (methodName.equals("newInstance") && ((Class)target).isArray()) {
Object result = Array.newInstance(((Class)target).getComponentType(), arguments.length);
for(int i = 0; i < arguments.length; i++) {
Array.set(result, i, arguments[i]);
return result;
if (methodName.equals("newInstance") && arguments.length != 0) {
// The Character class, as of 1.4, does not have a constructor
// which takes a String. All of the other "wrapper" classes
// for Java's primitive types have a String constructor so we
// fake such a constructor here so that this special case can be
// ignored elsewhere.
if (target == Character.class && arguments.length == 1 &&
argClasses[0] == String.class) {
return new Character(((String)arguments[0]).charAt(0));
try {
m = ConstructorFinder.findConstructor((Class)target, argClasses);
catch (NoSuchMethodException exception) {
m = null;
if (m == null && target != Class.class) {
m = getMethod((Class)target, methodName, argClasses);
if (m == null) {
m = getMethod(Class.class, methodName, argClasses);
else {
This special casing of arrays is not necessary, but makes files
involving arrays much shorter and simplifies the archiving infrastrcure.
The Array.set() method introduces an unusual idea - that of a static method
changing the state of an instance. Normally statements with side
effects on objects are instance methods of the objects themselves
and we reinstate this rule (perhaps temporarily) by special-casing arrays.
if (target.getClass().isArray() &&
(methodName.equals("set") || methodName.equals("get"))) {
int index = ((Integer)arguments[0]).intValue();
if (methodName.equals("get")) {
return Array.get(target, index);
else {
Array.set(target, index, arguments[1]);
return null;
m = getMethod(target.getClass(), methodName, argClasses);
if (m != null) {
try {
if (m instanceof Method) {
return MethodUtil.invoke((Method)m, target, arguments);
else {
return ((Constructor)m).newInstance(arguments);
catch (IllegalAccessException iae) {
throw new Exception("Statement cannot invoke: " +
methodName + " on " + target.getClass(),
catch (InvocationTargetException ite) {
Throwable te = ite.getTargetException();
if (te instanceof Exception) {
throw (Exception)te;
else {
throw ite;
throw new NoSuchMethodException(toString());

And the Statement.getMethod implementation is:
static Method getMethod(Class<?> type, String name, Class<?>... args) {
try {
return MethodFinder.findMethod(type, name, args);
catch (NoSuchMethodException exception) {
return null;

Highlighted in the code you'll see the calls to com.sun.beans.finder.ClassFinder.resolveClass and com.sun.beans.finder.MethodFinder.findMethod methods.

com.sun.beans.finder.ClassFinder.findClass vulnerability

The Statement.invokeInternal method is calling com.sun.beans.finder.ClassFinder.resolveClass and if we take a look a its implementation we'll see that it ends up calling the com.sun.beans.finder.ClassFinder.findClass method:
public static Class<?> resolveClass(String name, ClassLoader loader) throws ClassNotFoundException {
Class<?> type = PrimitiveTypeMap.getType(name);
return (type == null) ? findClass(name, loader): type;

public static Class<?> findClass(String name) throws ClassNotFoundException {
try {
ClassLoader loader = Thread.currentThread().getContextClassLoader();
if (loader == null) {
loader = ClassLoader.getSystemClassLoader();
if (loader != null) {
return Class.forName(name, false, loader);
} catch (ClassNotFoundException exception) {
// use current class loader instead
} catch (SecurityException exception) {
// use current class loader instead
return Class.forName(name);

This code shows that if an exception is captured, then the default is to simply call Class.forName and this is exaclty what happens here.

As it is explained in the Guideline 9-9: “Safely invoke standard APIs that perform tasks using the immediate caller's class loader instance” on the “Secure Code Guidelines” documentation [1], a call to Class.forName will use the immediate caller ClassLoader and in this case the caller is part of the JDK which is trusted thus allowing us to get any class on any package.

The caller's stack can be seen by simply debugging the applet:

MethodFinder.findMethod vulnerability

According to the “Secure Code Guidelines” document in guideline 9.8 the java.lang.Class.getMethod and java.lang.Class.getMethods only take the immediate caller into account when performing security checks.
These methods can be used to get a Method reference via reflection but only “public” ones.

Even though we have a reference to the sun.awt.SunToolkit class we cannot call any of its methods directly because is part of a restricted package and a security exception will be raised.

What is needed here is a way of getting a method reference via reflection but having a “trusted” immediate caller in the stack in order to bypass security checks.

The implementation of com.sun.beans.finder.MethodFinder.findMethod is this:

public static Method findMethod(Class<?> type, String name, Class<?>...args) throws NoSuchMethodException {
if (name == null) {
throw new IllegalArgumentException("Method name is not set
Signature signature = new Signature(type, name, args);

Method method = CACHE.get(signature);
if (method != null) {
return method;
method = findAccessibleMethod(new MethodFinder(name, args).find(type.getMethods()));
CACHE.put(signature, method);
return method;

The call to findAccessibleMethod ends up calling java.lang.Class.getMethods and the immediate caller in the stack is com.sun.beans.finder.MethodFinder which is trusted since is part of the JDK thus bypassing the security checks.

Once again we can see the callers stack by debugging the applet:

Affected Versions

The com.sun.beans.finder.MethodFinder and com.sun.beans.finder.ClassFinder classes are available only since JDK 7.

Putting all together

So this exploit is performing the following steps:
  • Creates a Statement instance that will call System.setSecurityManager(null) method using reflection.
  • Creates a custom AccessControlContext with full permissions.
  • With one bug it gets a reference to the sun.awt.SunToolkit class that is restricted to applets.
  • With the other bug it invokes the getField public static method on sun.awt.SunToolkit using reflection with a trusted immediate caller that bypasses the security checks.
  • With the getField method it is getting a reference to Statement.acc private field and setting its value to the custom AccessControlContext instance previously created.
  • Finally it executes the Statement that will disable the Security Manager bypassing all security checks because it has full permissions set in its AccessControlContext.


Esteban Guillardoy
twitter: @sagar38


[1] - Secure Coding Guidelines for the Java Programming Language, Version 4.0 -

[2] - Java SE 7 Security Architecture -

[3] - Java SE 7 Security Documents -

[4] - Sami Koivu Blog - Java Trusted Method Chaining (CVE-2010-0840/ZDI-10-056) -

Wednesday, August 8, 2012

STALKER - Analyzing [Your] Wireless Data

At INFILTRATE 2012 I gave a presentation entitled Secrets In Your Pocket: Analysis of [Your] Wireless Data[1].  I discussed many ways that you or your target can be stalked, profiled and forced to disclose personal information.

Most people tend to store information disclosures away in the cerebral junk drawer where other useless knowledge is archived.  "So what?" is the typical response I get when I discuss personal data disclosures, "What can you do with it?"

That's a great question.

STALKER is a tool that I wrote to reconstruct all captured traffic (wired or wireless alike) and parse out all of the "interesting" information disclosures.  It goes beyond just grabbing passwords and emails out of the air as it attempts to build a complete profile of your target(s).  You would be amazed at how much data you can collect in 15 minutes.

Here is a list of the most obvious and interesting data that can be collected with STALKER.

  • Name(s)
  • Email addresses
  • Phone numbers
  • Billing/Home address
  • Passwords
  • Emails
  • User names/Screen names
  • User-Agent strings
  • Wireless networking probes (Beacons/SSIDs)
  • DNS requests
  • Host names
  • Weblinks
  • Search queries
  • and so much more!

But what I want to focus on are the not-so-obvious information disclosures and how they can be used against you or your target.

ARP Disclosures and GPS Coordinates

At INFILTRATE I released details of a feature of Apple products (iPhones, iPads, Macbooks, etc) that leaks the MAC addresses of the last 3 wireless access points that the device has connected to (lots of Apple fans yelled at me after this.  Feel free to continue yelling at @MarkWuergler).  What does this mean?  It means that your target's device is disclosing where the target lives, works and plays to everywhere within wireless range.  STALKER keeps track of all of this for you and even plots the target's preferred access points on a map.

The blue marker on the above map represents the location of the wireless access point that a target device has connected to and the red marker represents where the actual device was seen by STALKER.  Over the course of a few days this map is populated with all the frequented locations of the target.  

Reconstructed Files

If you target is downloading/uploading files then STALKER will put them back together and lovingly save them on the hard drive for you.  It doesn't matter what the file type is - as long as STALKER can see it - you'll have it.  View web pages as the target viewed them, view their documents, listen to their music and to their VoIP phone calls.  

I will warn you though - there are just some things that can't be unseen (I will leave this to your own imaginations).

Emails and Chats

“Integrity is doing the right thing, even when no one is watching.” - C.S. Lewis

Most people are always on their best behavior ... until they start to share private messages.  Criminal behavior is evident, true personalities and intentions surface and the completely unimaginable take place in digital conversations.  All of which you can browse easily in the STALKER inbox.

Piece by Piece - Building a Profile One Disclosure at a Time

One thing that I look for on penetration tests that I conduct is how to turn a small, seemingly unimportant bit of data into more meaningful data.  For example, a userid from a website could be used to turn into a person's name -> name into email address -> email address into phone number -> phone number into home address -> etc, etc, etc.  STALKER is capable of automating this for you so you don't have to worry about making the connections yourself.  You're welcome.    

Forced Information Disclosures

SILICA can be used to actually force a target user to interact with the applications and services that will disclose the most information about them in the fastest time possible using its Custom Injection module.  This mode will inject custom content into the browser of the target (this can be hidden or obvious depending on your needs).  Typically this is used to actually compromise the wireless device (which is a topic for an entirely new blog post) but it can also be used to aggressively collect the kind of data that you want to feed to STALKER.

Practical Uses

There are many potential audiences for STALKER.  Here are a few that come to mind: 
  1. Those that immediately understand the risks associated with information disclosures.  This is usually the category that victims fall into.
  2. Those who have something to protect.  This is the category that governments and corporations fall into.
  3. Those that are tracking and investigating individuals.  This is the category that law enforcement falls into.
  4. Those that are proactive about security.  If your personal or corporate wireless device's traffic is run through STALKER and anything of interest shows up then you have a leak that needs to be plugged (before it can be abused).
  5. Social engineering.  If employees are profiled by STALKER the likelihood of a successful social engineering attack increase dramatically (as STALKER may contain information that can help answer security questions to validate identity).


Anybody with a wireless card has the ability to collect highly sensitive data on you and those that are associated with your organizations.  Let STALKER show you what you are giving away to your attackers before your credit score, lawyers or CNN have a chance.


Don't talk about this program to girls you just met.  And under no circumstances make the same mistake as I did and tell them that you wrote the program ...

[1] Secrets in Your Pocket: Analysis of [Your] Wireless Data (Prezi or watch the Video)


Mark Wuergler
Twitter: @MarkWuergler

SILICA, Wireless Cards, Licensing

There's really two reasons SILICA is licensed by the wireless card. One is to keep honest people honest, and the other is because we find that the particular card we ship to you, our amazing SILICA customer, is absolutely the best for the job.

When picking the Ubiquity SR-71 card we looked for something that had external antenna jacks (we're not going to solder your cards) but which could also handle the multitude of wireless modes SILICA uses for extended periods of time.

As Mark put it in a recent customer support email:
The Ubiquity SR-71 is the only card we can support because it's actually the only card that passed all our tests in search for the perfect wifi adapter for SILICA. All other cards (including the Alfa) have stability issues when put into the different modes that SILICA relies on (monitor mode + injection, AP mode mode with multiple virtual interfaces, AP mode with injection and an interface in monitor mode, etc). 

On the bright side I can tell you that the SR-71 won't let you down.  After all the tests we ran on all the other cards I personally only use the SR-71 for everything I do.  Even when using the standard antennas that ship with it the card has an impressive range and you can always swap those out for another antenna plus amplifier if needed.

As a side note, we're really excited about the next release, which will include STALKER support!