This document discusses running shellcode from Java by overwriting the pointer to a Java method with a pointer to shellcode. It explains that Java is cross-platform, has an extensive library, and is widely deployed. It then provides an example of NOP shellcode in C to call the shellcode. It links to resources on injecting shellcode from Java without JNI. The document shows a Java method with volatile variables that is overwritten by the shellcode and demonstrates calling the shellcode from Java.
14. package javapayload.stage;
/*
* Running shellcode from Java
without JNI (i. e. loading a DLL
from disk).
(c) 2011 Michael Schierl <schierlm
at gmx dot de> (Twitter @mihi42)
15. * This version has been tested on:
*
* Oracle 1.4.2_11 Win32 (-client, -server)
* Oracle 1.5.0_06 Win32 (-client, -server)
* Oracle 1.6.0_19 Win32 (-client, -server)
* Oracle 1.7.0_01 Win32 (-client, -server)
*
* Oracle 1.6.0_26 Linux32 (-client, -server)
* Oracle 1.7.0_01 Linux32 (-client, -server)
I’m Ryan Wincey, I’m a developer and pentration tester. This is my first presentation on.. Pretty much Anything. So bare with me. It might be a little dry, and technical.I’m going to give you a little of my background to provide some back story on my talk today. I’ve been writing code professionally for about 6 years, with a primary focus on enterprise level remote system administration. The target operating environment for the software projects I’ve been a part of has been mixed, with mostly Windows systems and a handful of Solaris and Linux systems. Given the diversity in operating systems and architecture, Java was our programming language of choice.So with my current job, I’m not developing full time anymore, but I do write a fair amount of code to aid in pentesting and maintaining persistence on computers that we compromise. So once again I’ve found myself in the situation where I have a mixed target base that my software has to run on. So I decided to go with what I was used to, and write tools using Java.
So why Java.
So why Java. I definetly found the people on the internet that have a distaste for it.
It runs on just about everything. Phones, Tablets, Laptops, Desktops, Servers, u name it.
I’m super lazy and don’t want to have to write anymore code than I have to. Tons of resources online to borrow code snippets…etc.
Sun’s claims “3 billion devices” have Java installed on it. Good chance it will be on a system that you are targeting. It also blends in well because all java programs look the same from the task manager. People see Java running, they probably don’t think much of it.
So let’s fast forward to the topic of this talk, I found myself with a assortment of Java based security tools, some I’ve written, some open-source. Then I came across a pretty serious limitation I was used to be able to do with native languages.
How do I run shellcode directly from a Java application. So just as a quick refresher, shellcode is pretty much compiled native code that can be injected directly into memory and executed. I’d say it’s most common use is for software exploitation … but it can also be used to load code into a program without that code ever being written to disk, Which can be pretty important when you are trying to avade an antivirus.Searching the Internet didn’t provideIn C, this is a pretty trivial exercise
In C, this is a pretty trivial exercise as shown aboveAfter searching the Internet, I can up with a couple options. The first technique involves writing a native library in ( C/C++) and using either JNI (Java Native Interface) or JNA ( Java Native Access ) to pass the shellcode from Java to the DLL to execute it. This technique is rather clunky since a DLL has to be transported alongside the Java code and also adds one more artifact on disk that a virus signature could be made for.https://github.com/schierlm/JavaPayload
After searching the Internet, I came up with a couple options. The first technique involves writing a native library in ( C/C++) and using either JNI (Java Native Interface) or JNA ( Java Native Access ) to pass the shellcode from Java to the DLL to execute it. This technique is rather clunky since the DLL has to be transported alongside the Java code and also adds an additional artifact on disk that a virus signature could be created for.
The other option I came across was buried in a project on SourceForge called JavaPayload written by Michael Schierl. After perusing the source code a little bit I found a class called JITShellCodeRunnerhttp://javapayload.sourceforge.net/, also located on GitHub at https://github.com/schierlm/JavaPayload. I read
Inside the JavaPayload/payload/stage package I found a class named JITShellCodeRunner that had these comments at the top. I downloaded the source and executed the calculator executing shellcode on my machine running the latest JVM from Oracle. Unfortunately all I got JVM crash.
I read through more of the comments and noticed that the most recent JVM the code had been tested on was Java 1.7 update 1. So I downloaded Java 7 update 1 dated (Oct 18, 2011) and upon execution I got this. Success.
Success. A welcome sight for those that have much experience writing exploits. Now I knew that this voodoo was possible, I tried to dive deeper into the inner workings of this class so I could try and get it to work across all JVMs. The comments in the code yielded very little insight into what was actually going on so I emailed Mr. Schierl hoping for an explanation. Mr. Schierl was very helpful and explained in detail what he had done.
Just to give a little refresher, Java is an interpreted language that compiles Java instructions into byte code. Byte code is then interpreted by the JVM into native instructions and executed on a system. To increase performance, the Just-In-Time (JIT) compiler inside the JVM will compile frequently used methods from byte code into native code on the fly, and cache them in memory.
So now we know that the JVM not only executes byte code, but also caches natively compiled shellcode. If only we could find a way to replace the native code compiled by the JIT, with some of our own, and then execute it. Turns out there is, and Java provides it, Kinda.
The Unsafe class. The Unsafe class is a Sun proprietary class that can be used to access memory directly. As the name suggest, it is extremely unsafe to use because any native exceptions that are raised while trying to access memory cannot be caught, and will cause the JVM to crash. The generalprocess for locating the a method’s native pointer consist of walking the memory structure of the Java Class instance using the Unsafe class functions. The original algorithm that was implemented by Mr. Schierl begins by first obtaining the base address of a static field in the Class
That pointer references another structure that contains a pointer to an array of all of the methods in the class. The arrows point at the fields surrounding the method array pointer that act as indicators for locating the correct pointer.
Each pointer in that array, then points to a structure that contains a pointer to a structure representing the native function.
Lastly the native function structure contains the pointer to the entry point for the JIT compiled code. Once this pointer has been located, the shellcode can be inserted into native memory space using the Unsafe class. All that’s left is to call the method.Now for the fun part, I started exploring why this novel technique didn’t seem to work anymore. I found that there are several inconsistencies in the class layout across the various architectures and releases that would make it difficult to make a comprehensive solution. Although the sequence of fields in a class appears to be fairly consistent, the offsets to the fields tended to change across JVM releases. In all likely-hood this because new fields or members are being added or removed to the underling classes. Another compatibility issue was the introduction of compressed pointers in the 64bit JVMs that required an additional call to the Unsafe class to decompress the pointer if it was compressed.The most significant issue I found was the realignment of the base memory object starting in Java 1.7. Since this is the first step in the process, choosing the wrong initial pointer throws off the rest of the memory walk. What makes this significant is an incorrect offset into the class memory can cause the JVM to crash since it will cause a native exception to be thrown.
To mitigate this problem, I added code to brute force the initial offset by spawning a separate JVM for each attempt. This technique protects the original JVM while the correct offset is located.
Just a few technical notes, for those that might look at this code later. The java method who’s native code is replaced, is filled with what appear to be a arbitrary set of operations. However these operations are responsible for the size of memory that is allocated for the native code produced when it is JIT compiled. The operations are sequenced in this manner so that the operations will not be optimized when the Java code is compiled.Another caveat that needs attention when using this technique is to properly align the stack after running the desired shellcode. If this is not done, the JVM will crash. This might not be a concern but it should be noted.
In case I had time I wanted to show what kinds of things can be done with this technique to extend some known penetration tools.
Each pointer in that array, then points to a structure that contains a pointer to a structure for its JIT compiler code.
For those that want to try the code out, I’ve sent my updates to Mr. Schierl to merge into the JavaPayload project, but also plan on putting the updated code on my Github this weekend.Thanks for letting me come talk about everything. I wanted to thank Micheal Schierl for the great research and for being an expert reference on how this stuff works.Also wanted to thank my boss for going through the hassle of getting this talk approved to be presented.
