← All talks

Java Shellcode Execution

BSides Charleston · 201330:03187 viewsPublished 2014-11Watch on YouTube ↗
Speakers
Tags
CategoryTechnical
StyleTalk
About this talk
Second talk of the day at BSides Charleston 2013. Java Shellcode Execution presented by Ryan Wincey
Show transcript [en]

all right so first off this is my first presentation probably can't tell already um let's see uh give you a little bit of my background I've been writing C for about 6 years professionally um mostly doing remote Administration stuff um which is kind of good when you kind of transfer over to the pin testing kind of round um most of the target operating systems that we targeted were mixed so we were doing stuff for Windows and Linux which kind of LED naturally to start using something that was um crossplatform like Java um and now I'm in my current job I don't actually write a lot of code professionally um but we do still use a lot of it to automate a

lot of our our pin test um so yeah so let's go forward same all right so why job all right so a lot of people seem like Java testers for Nos and so you tend catch a lot of [ __ ] you talk about how you want to write a Java I think it's not cool usually like python see all those kinds of things um a few good reasons is uh it's cross platform form so it'll run across everything you can run on Windows you can run on Linux unit all kinds of good stuff um it's got lots of libraries um I'm really really lazy so I hate writing new code and so they give you just about

anything you'd ever need um so that's always really useful um and I guess when you need to find something you can usually go online Google it 50 million people have already done it before um so you just copy paste and good to go another reason why I really like to use it is because it's widely deol I or lik to stout or say that they've got it on like 3 billion devices every time you install they like to brag about that say how many think it's on which is really good for as pin testers when you're trying to find people to run your stuff on you can kind of assume that it's probably on that

box all right so let's talk about what I came here talk about I have a problem here when I'm writing security tools and I'm using Java so one of the things I'm pretty used to in most of your native tools like see is if I want to ex Shell Code um it's pretty trivial um you can actually just kind of put your shell code into a buffer um you kind of just put a function pointer at it and you can call it right away but how do we do this in Java um since Java's interpreted code um you really don't have access to that native code um and so it can become quite a problem

trying to get to those functions to be able to do this um like I said see it's pretty trivial this is our example um you're just going to stick your shell cod in there you point right at it and you just call it really easy um Java does give you some possibilities for doing this uh they have a jni and they also have jna which requires you to actually write C code that exports certain functions that then you can call directly into from java problem with that is you're writing extra code so you have your C code you have your Java code one calls into the other you always have to bring that code with you so if you deliver it you don't

know it's always going to be there unless you put it on that system should be kind of clunky um a lot of times if you were to dely that in like enteras level it could probably get a fire signature or something like that if people kind of more we are um let's see so Sol that problem I went to the internet and I tried to find the different ways that people were doing things uh the first one I found was uh this guy and he was using the jni technique I just described where you go out and uh you write that dll you hope you can push it along and nothing bad goes wrong um and the second one after lots

of searching was this newn project um called jav payLo that I found first in Source Forge and eventually he moved it over to GitHub um there's a lot of code in there that I actually don't know what it does um it seems really cool but I haven't had time to look at it um but I did find one class that was really interesting um was called the jit Shell Code runner in the very top of it found this so I got really interested I want to figure out what I'm was doing so first thing I did was I download source code execute a calculator and uh saw what happened and nothing happened so I was

like all right why does this not think this thing work you know I got really confused I was like this guy says this code works so I started reading these comments I saw last thing I worked on was 701 which was released actually in October of 2011 so I was like well maybe this this has something to do with it probably need to look into this further so start exploring a little bit and uh got that particular JM that he said and this thing popped up which is always really good so if you're like a right any kind of exploits usually I try to test things with the calculator um just because it's real simple to make sure

everything works so put that calculator shell cut in there Let it Fly and if you get this you uh you're really happy but anyways so now that I knew that it worked I wanted to really kind of figure out what was going on so I started actually looking into the code trying to figure out why it worked on this particular jbm but the new ones it didn't um so started reading through the comments again there was very little the guy uh didn't really give much comments um but I emailed him and by the way if I hadn't mentioned this guy's name um Michael Cheryl I that out question but uh yeah he was a really

nice guy actually emailed him to figure out how he was doing these things um he emailed me back told me lots of lots of good information to kind of go further with everything so figured I'd go into a little detail give you some explanation so uh we'll see how this thing goes all right so once again just get a little refresher on Java uh it's an interpreted language um it kind of takes what you write turns it into bite code um and then that bite code is interpreted by the jbm into native instructions um now one thing they added um probably had been too long ago 10 years so kind a little off they added

the the the jit compiler which takes Java instructions that you actually run a whole lot and it will on fly compile those in the native code cach them so if you run them a lot you get your speed performance almost as if you're writing native code um so one good thing about this is this means that our Java jbm has native pointers somewhere and it has native code that we might be able to get to so now that we know we can get to this NE code we got to find out how so that we can put our native code in it place it call it so the good thing is Java actually provides us the way I mean it seems to

provide just about everything might not be that documented like this particular class called the unsafe class so the unsafe class it's a Java Sun proprietary class they use it for doing concurrency classes um they don't really want you to use it it allows you to directly access memory um the reason they don't like it is if you are to use this incorrectly you will crash the entire jbm so whatever application you have is just done for and you can't catch it um cuz it's a netive exception and they don't like catching those um let's see so to tr to figure out what we want to do to get from the point I had showed earlier to try to find that pointer to

that native code from where we're at we actually have to walk the memory structure of the underlying job classes that are native and try to find those pointers so that we can then replace it with our own code so the general algorithm that Mr sheer came up with was first he obtained the address of a static member inside a

class so once you find that static member then you find the pointer to another structure that actually keeps track of all of the methods in that class um and so what we're looking at here is actually um the internals of a class in Java so if you were to actually break it down and look at what it looks like in like your C++ native code this is actually the internal structure of that class so you can see so it's as you tell our integers most of these are addresses um and what he figured out was was that there's always a pattern um so he he pretty much developed indicators so that he could figure out where the particular

poter he was looking for was um you'll see these three arrows point to what he decided were pretty much consistent across the jvms so that he could find that one right there it's called method array pointer um once he found that method array pointer um he would step into that and each one of these pointers actually is a method structure inside this method structure there will also be another structure to the actual native structure so we're getting closer but so that native structure will actually have our pointer to where we want to go so in this one again we have two more indicators that he also found will generally be was it like three steps

above the native meth structure and they will always have a certain pattern or it's close and then once we step into that native method structure then we finally have our n native method structure and inside that is finally the pointer that we're looking for um so once we found that pointer um we get to fun point so once again that unsafe class it has methods in it that you can actually write to memory too so once we get this pointer we actually just call into it start overwriting all the B that are in that pointer that was compiled by the jit compiler with our Shell Code um and then once we do that

we so so the uh the issues that I started figuring out between what he had originally written and the jvm that I downloaded it didn't work um was it turns out these indicators that he was Finding aren't exactly consistent across all these jbms um which makes a lot of sense because this code's ever changing and they're probably adding new methods new fields to these classes so the good thing was the actual sequences that you found were consistent just the place in the class changed so they might move up a few they might move down a few so the offsets were actually different so what I ended up trying to do was get in there and actually try to automate the process

of finding those so pretty much kind of Brute Force things walking those trees until we found those indicators so that we know where we were um another one of the problems was between our 32 bit and 64 jvms Java decided that the pointers that they used um for their address spaces were too big in 64 so they came up with a way of compressing um your pointers which became kind of a problem for us because we have to determine which ones are compressed and which ones are not and then run it through yet another algorithm they provide to decompress it and try to go forward with reinforcing these indicators again um other than that the biggest problem I

found when I was trying to like I said make this work across everything was starting with Java 17 they actually added a realignment issue um at the very beginning so as you could imagine once you start in on the process of trying to um dig down on these these different um pointers and such and these structures um it's okay if you already know where you're starting from but what they introduced was they moved the very first pointer so the the problem once again using unsafe classes if you pick the wrong pointer hold jbm crashes so you're done so I had to figure out a way that if the jvm crashed we could proceed um and that's where I ended up

writing it you had another group forcer at the beginning to try every one of these offsets and if it crashed just pars through that output data say this is pretty much a failure and they go forward until we actually found the right one this is kind of yeah but yeah this is what the picture kind of what I was talking about so we have our original jbm we pass an offset of what we thought might be that very first pointer we try it out if it crashed we go forward if we got the success we go on and that way this one was safe and we can proceed afterwards and this one wouldn't matter so now

is

so I fig the first thing I'm going to show uh just a little bit of the the class structure and how this stuff works just um with the code that he had originally that I modified and then if I have should probably doing fast is uh show one of a practical application that you might be able to use in a pin testing environment

all right

so in this example right here I have some U Shell Code that actually executes a calculator I um generated this through Med and one of the issues that I'll get into later is when you're following the stuff from java you have to fix out the stack correctly or it will crash um that's what this extra code is you'll see you have some extra things right here

set this break point here so you can see as I was mentioning we did all the codes to go figure out where everything was this right here is actually our native pointer that I was talking about which is one we want to replace and then this code goes ahead and puts in all of our Shell Code and then immediately after it We R right here

all right love success okay so so that's kind of like our little Pro Concepts

um all right uh just a few few technical notes before I went on um inside the actual method that we're to be replacing with our own code if yall do ever decide to go look at this code so you can you know expand it on it use it for better things um you see a lot of this really random stuff um I got really confused when I first saw this and so I really needed a good explanation from Mr Cheryl um because it looks like just Randomness uh he but he then informed me that these uh volatile um instructions right here particular um member that were increment and decrementing their volatile ins actually caused the jvm to create a whole lot of

memory um and it will like make a bunch of native instructions to do these very simple things and he actually put them in this order so that when it's being interpreted it doesn't get optimized and rip out a bunch of this code um because every time it writes these it will make that buffer that we want to put stuff into larger um so like I said it looks really crazy and there's a whole bunch of these blocks so as he described to me if you want to make room for bigger Shell Code or whatever you can just copy more of these blocks and if you do side actually debug through you can see how big of a buffer

it's making for these um if you want to verify um that's actually another tid bit so I need to probably throw in there a really cool thing about this technique that breako I just showed y'all um if you do know how to use like immunity debugger or wind debug or anything like that you can take that actual address you can plug it into your wind debug set a break point and you can actually watch the Shell Code running through a native debugger um and verify a lot of these things you can verify what Shell Code you're running how big these buffers are and a lot of that kind of thing um which is actually kind of become a dual

purpose for me when I'm developing exploits I just use this as a super plug it in there and start

do okay uh as I said earlier another caveat that you really have to worry about when you're trying to run shell Cod through this particular technique um when you call in from java into your shell code it has the stack set up a certain way so that when it's done um it will come back into the jbm correct ly so you have to keep note of that and realign your stack when it comes back or once again your JPM will crash um and that really you can't really get around that um which why actually for the second demo I was going to use a medit one but the um Ms payload msf payload um utility that it has produces Shell Code

that really mangles up the stack um so as of right now really know how to recover it um so let's go to our second demo and I'm going to try to do another calculator but we're going to use this time so this is your first talk you thought it would be a good idea two demos yes just go for it I S talking yeah all right unless you know when you have five minutes five

minutes

here that's way too small

all right in this box we have split listener we're listening for a Joba payload um so we actually use a lot of Joba payloads and how work we do because like I said it'll work acoss anything so it's really nice to be able to send out one thing and know with pretty good certainty that you'll get a lot of fallbacks because it'll work on all the operating systems so we're going to assume that we're using a Java payload and we set this here

call so those

box the desktop I have need

normally you'd probably deliver this in you know an evil applet or U maybe through a fishing campaign put it in the macro run this Minecraft

ex go back and see they got us nice inter

all right so that's just that so I put together just a Qui concept for this um WR a little um extension I called it um sh and we have this little function here where we can provide it where sh we want and see if it works and this is that same Shell Code that we just looked at

so yeah right now PRACK together definit make it cleaner some time back over here hopefully calul right

so so that's our little what you could do I mean you could always fill that with uh like I said a interpreter shell or a rat of any sort um you just have to make sure like I said you set everything up right so that it doesn't crash your other shell if you want to keep it all right so uh

that's it um you have any uh questions all have you tested any of the teches against uh I haven't I haven't yeah most of the stuff I use is is Oracle stuff just cuz it's easier to download um yeah I I really don't know I would I would hop that it would work but I yeah I can't say for sure I Haven checked it but yet right now it works against 32 bits 64 um 16 all the way up to 43 and 17 up to about 45 I guess we right down there any um changes to the like Java policy that need to occur in order for you to execute unsafe code no see that's the best part um this actually

isn't an exploit which is a kind of funny thing cuz when I first wanted to talk about this we had to get a lot of approval cuz it scared a lot of people they thought this was a no day um but this is how Java Works um it'll be here as probably as far as I can tell from now on um because it has to talk to native land so these pointers are going to have to be there unless they get rid of that jit compiler so there really no way around it so there's no security policy that needs to be relaxed in order to use that functionality no work out of the box on

any any security policies that you can enable to se as far as I know like I said it's not an

exploit yeah I mean and that's the thing like so if you think about it in terms of like you know the programming language like I was mentioned before like this is possible in any native language so it's more of a feature than a vulnerability have you are you we any research where people tried to get uh this code injected into an application that didn't use unsaved um I think and like I said I'm not positive because I didn't look through much more of Mr Cheryl's code but I think that's actually what most of his project was about was he was just using um Java to do pin test similar to metlo and so I think he' figured out

ways of actually using things like this and other techniques to two hat running Java applications using this using things like their remote Java debugging and that kind of thing so there's probably some stuff there this particular class isn't related to that this is just the way I'm the showell code but it's possible yeah and I guess to to further his question like why this Java let you overr random pointer you know I thought the whole point of java was you couldn't do pointers and it was safe language I mean I'm guessing they could probably restrict that unsafe package um but since it's also just Java code and it's been out there for forever I mean it's already out therea

have just pass around that class they have do something serious I guess else any questions um mind see uh here's my contact information uh thanks for uh let me talk I want to thank the boss for going through the hassle getting this approved for me uh thank Mr Cheryl for all the the hard work um I know he's really busy or he probably lots of more cool stuff this kind of blew my mind kind of figur this out yeah I'm going to try to put it up on GitHub uh soon uh he has his own but mine's Chang kind of significantly from what he was trying to do so I don't know if he's going to be able merged directly

in his stuff so I might just put it up separately um same with the little M PC so check it out