 Damn, I love backtrack. I really do. Where's our queue? Alrighty, so we've got a pretty intense 50 minutes. We'll be going through the development life cycle of an exploit. The exploit is in an NNM open view system. Are you familiar with that? Like that big machine that owns the whole network sort of thing. So if there's one box in the whole network that you want to own, it's probably that one. The whole exploit development cycle was quite interesting and a bit painful. And that's basically what I wanted to share, the pain, you know, sort of not have to deal with it all by myself. So basically what we'll be doing today is we'll be going from bug to zero day. We'll just retrace all the steps that we took in order to own NNM from fuzzing until the whole, you know, developing through Oli and getting our shellcode in there and we'll see that we had to face all these nasty, nasty difficulties which took a sleep and lack of sleep and lots of trouble with the wives sort of thing. I love you. Okay, so I think we'll just drop straight into the demo. I think we might be a little tight on time. This is basically our open view NNM system which we were encountering. We were actually fighting with this in a pentest. And what we decided to do at some stage when we noticed that there weren't any plausible attack vectors is to start, you know, prodding the zero day angle seeing if we could find something, some low hanging fruit that would eventually give us or compromise the system. So a quick port scan revealed that there's all sorts of funky services running on NNM from, you know, SNMP services to HTTP services and everything. So we went for the lowest hanging fruit and we started bashing away at the HTTP service and oddly enough in less than 60 seconds the thing blew up. So I'd like to show you the whole process, the development of the spike file that we used which was ridiculously simple and while I'm in the intros I'd like to say no thanks to HP which didn't even bother returning a mail after two calls and three mails telling them that they've got an unauthenticated overflow which could lead to system compromise and they never even bothered returning a mail. This exploit was actually published six months ago and it never even received the CVE so I've been having fun pawning HP machines while everyone's been ignoring this so, you know, hopefully this will sort of raise some attention to the topic and people will actually patch their machines or at least disable the service because this is actually quite popular. Alrighty, so the service that we'll be debugging today or observing is the OVAS service. This is their main web server and what we did is we started using a very simple sort of template. Is the mic on? Can you hear me at the back? Too far. Alrighty, so basically we took a very, very overly simplistic spike template which we started throwing out the application and I'd like to show you the results. Obviously the wonderful thing about this is that we're all doing this on the back track so the whole process was self-contained into one sort of debugging session. So if you look at the spike file then you'll see that we're a pretty basic sort of template here. We're fuzzing just like a few headers, the host header. We're not even going to be doing the actual get request. I've sort of dumped it down a bit so the fuzzing won't take too long during the demo. Hopefully we'll be finding that our overflow is in the host header field so let's just give that a quick run and see what happens to our NNM machine. So we'll use the audit SPK file, HTTP SPK file and just by running this, what am I missing? Port. Just by running this we can actually see that HP NNM is reacting its opening threads for each session being battered away and in exactly 20 seconds the thing broke. So we were very happy because we thought that this is going to be a stroll in the park. We'll develop this exploit, get a root shell, get home back in time for dinner. Little did we know. Little did we know. So looking at this crash we started poking around and very soon we realized that this was a structured exception handler crash. I can actually replicate this with a standalone Python script. It took us a couple of tries playing around with the buffer lengths just to see that everything was as anticipated. So looking at the proof of concept or standalone skeleton exploit as I call them, basically what we've got here is a get request with a very, very long and ugly host header and this is where our crash comes out and apart from that everything is pretty much as usual. There's nothing fancy or interesting about this get request apart from again this host header which is taking around 4,000 bytes of buffer. So we slammed this against our NNM machine. Yeah we probably should have the debugger there and we'll take the OVAS process and let it live. And hitting the open view service with our script, this is actually a bit freaky because it takes it a few seconds to crash. What we'll see is that we own all these wonderful registers. We own a bit of the stack and possibly the best part of this whole thing is that we own the structured exception handler. Now usually what we'd want to do in a situation like this is allow the exception to occur. So I'll just simulate that by pressing shift F9. And here we have EIP which is all ours. So we're all happy and giddy about this and yes we're going to own this thing in 30 seconds because all we need to do now as you usually do in structured exception handler overwrites is you need to find a nice place that contains a pop-pop ret instruction and that will basically bring us right here. So the rest of our buffer which is usually where we'd shove our shell code in would be right here. Now notice that we're pointed to 4 bytes before our value that overwrites EIP. And usually what you do in a standard structured exception handler exploit is use these four bytes to jump over this address so we don't actually execute these bytes. And then here you'd be putting your bind or reverse shell. If we look at this a bit further we'll see that we've got around 400 or 500 bytes for shell code which is usually enough. I mean you could probably get away with a reverse shell of 350, 400 bytes unless you need to start encoding it. So the first thing we did all happy and joyous is look for a pop-up ret command to get us back to our buffer. And this is where things started to get really, really ugly. We found an address in one of the HP DLLs which obviously isn't compiled with safe SEH or GS or anything that's just out there. So looking for the first address I think I might still have it here in Oli. Yes. So we found this address which indeed contains a pop-pop ret command. Now just take note of these values here because this is going to play an interesting part in the next few minutes. So essentially what we'd like to do is go to our proof of concept exploit and change these 42 bytes into our address that will lead us to our pop-up ret. So we did this and we just took that wonderful address, shoved it here and it's padding just at the right place. I skipped a few steps of finding the right place in the buffer, etc. That's not what we want to deal with today. We're going to look at the harder aspects of developing this exploit. So we send this and let's see what happens. Okay now apparently the actual overflow is in the HP mechanism of filtering URLs and logging them which is actually quite common. So once again we've got our structured exception handler which catches the error but something is wrong here. Take a look at this. I'll show you what the original value should have been and what it ended up as. So the original value should have been 5a02ef74 and what we got here, well I see a 02 and I see a 74 but something else, something has gone wrong here. So we tried this a few times thinking that we did something wrong but essentially at the end what we realized is when we looked at the actual placement of our buffer on the exception handler we saw something funky here. So if you can see it over there at the back but it looks like something expanded. Do you see that 5a right here? That 5a should have been the first thing to overwrite our address and we can see our 5a here. Let me just show you the original address. We can see our 5a. We can see our 02 and it looks like our EF has been mangled because 74 is here so EF is basically transformed to what is it, AFC something. And that is when we understood that we're screwed because what's going on here is some sort of translation or expansion of bytes which are not alphanumeric. So suddenly we had this alphanumeric cloud over our head and we realized that we'll need to do some encoding on our shellcode. Now Metasploit actually contains a couple of really, really good alphanumeric encoders so we thought that, okay so this isn't such a big deal, we'll just simply encode it with Metasploit and everything will be done with. So the next step was to find a nice alphanumeric return address that wouldn't be mangled after sent or after accepted by NNM. So we dug in a bit deeper and this is what we found. All right so this is the address again somewhere in NNM, one of the DLLs, lots of them to look for and we'll once again slam our NNM server and wait patiently for the crash. This actually freaked me out yesterday because I was sending the buffer and waiting for a couple of minutes until the crash occurred. I thought everything had gone to hell but thankfully it stayed. So once again we've got our structured exception handler, this address is good, this address does not get mangled in any way and this will directly lead us to a pop-pop-ret instruction set. So I'll allow the exception to occur, I'll press Shift F9, I'm taken to a pop-pop-ret. Now notice what happens here on our stack. We pop one, we pop one and then we would return back to our buffer so if we follow this and dump, these are the exact bytes that we're jumping to and these are the exact bytes that constitute our return address. So we take the jump and usually what we do here is we take a short jump over the return address and put our shellcode here. Now a short jump would be an EB something, EB10 for example and that would just very very conveniently take us there. But then we realize that EB is not in our allowed instruction set, in fact we're only allowed a very limited instruction set, a limited range of bytes that we can use. I think I've got it somewhere here just to give you a bit of reference. So you can see that this thing isn't pure alpha numeric, I mean you've got some of these bytes here but it is a very limited instruction set and we can't just do, we can't even have our short jump, we can't even use EB. So this is where things got really really hairy and we had to think sort of very very hard on how to do this. So after bashing our heads a bit we realize that we might try to use a conditional jump, something like a jump zero, jump not zero, we just need to make sure that our zero flags are set and that jump would always be taken, otherwise these instructions will actually kill our exploit. So in the end what we ended up doing here is giving a conditional jump and we have to make sure that each and every time that this exploit is sent that condition will always happen, otherwise we screw our exploit. So we've got our zero flag here, the jump not zero is taken and that should take us across our return address and into the safe zone of our buffer. So we'll take that jump and here we are. And from here onwards we're free to write around 400 bytes of shell code. So the first thing we do is go to the metasploit framework, generate some alphanumeric shell code and something looks wrong because you'll notice that the actual encoder, doesn't matter which one you use, either the alpha two or the pex alpha num will actually contain some characters which are not alphanumeric. And this is a problem because looking at this you say, well, okay, it doesn't matter that this is the decoder, it still contains a byte which will screw up our shell code, we cannot have this. And then the very, very sad realization that metasploit will no longer help us and we need to do something custom. And that is when things really, really got ugly. Because at some stage you just get so used to using metasploit you forget how to do the basics and this is the first time we actually got slapped around and forced to do some ugly stuff. Luckily for me, I saw this article about Venetian shell code and I got this interesting idea there that came up to me and I said, maybe we can use that technique in order to write our own alphanumeric shell code here. Now the other problem that we have is that we only have around 400 bytes of space. Now if we want to have a reverse shell or a bind shell, that's around, I don't know, 250, 300 bytes and if we want to encode that, you're at least doubling that. So there's no way that our original space for our shell code could cover all of that. And then we think, okay, so maybe we need a smaller payload, something like an egg hunter that could look for a second larger payload in memory and we'd have to figure out a way of getting the second payload into memory and then the first payload, the egg hunter, would actually search safely through the address space and find our final payload and give us a bind or a reverse shell, whatever it is. Yes, it did get hairy because now what that means is that we need to encode, manually encode 32 bytes of egg hunter code. The egg hunter that we used was one of Matt Miller's creations, amazing stuff, really, really, 32 bytes of magic if you ask me. So let's just take some reference, take a while to look at the egg hunter shell code itself. The egg or that signature that the egg hunter will be looking for is Woot, W-00-T, all in capitals and you can actually see the egg right here inside the assembly code. If anyone's interested in seeing the actual code then come to me later, I'll show you the article by Matt Miller and give you some code examples. But essentially these are the bytes that we'll need to write and encode manually. So the technique that was mentioned in the Venetian shell code article basically said that the easiest way to get past the alphanumeric situation is to actually carve our own shell code in memory in real time and very elegantly place it onto the stack in a place where we anticipate that execution will reach. This sounds much more complex than it actually is. I think it's much easier to see this in action. So what I'll be doing now is I'll be writing the shell code in Oli and explaining each line what it does. 25 minutes left. So that's the first part of the shell code and it's actually not too complex. Notice that the shell code is composed of really, really basic instructions and all the characters, all the op codes are allowed. So basically we're limited to things like add, sub, push, pop and a few others but that's pretty much it and that is the instruction set that we have to start carving our shell code in memory. We'll be using EAX for several calculations so the first part of the shell code basically says whatever you have in EAX, zero it out. So EAX is zero already but let me just shove some values here so you can actually see the process happening and we'll step that and step that. So EAX is now zero and I know that all my calculations are beginning from a clean slate. The next thing I do is I want to locate my position in the stack because if I will be carving out shell code on the stack I need to know where it's carved and I need to carve it in a place where execution will reach after my first state shell code. So looking at the actual memory dump we would probably want to write our 32 bytes of egg hunter around here. So in order to do that we need to find our current location in the stack and we can do this by using a really cool trick by pushing ESP, the stack pointer to the top of our stack and then popping it to EAX so now EAX actually holds the value of ESP and we can start doing calculations on EAX. The next three lines basically align the stack to exactly the place that we want to write our shell code. This is actually an interesting calculation because if we do, if we take this, that and the other command then EAX should now be pointing to exactly this area. So our stack is aligned to the place that we want to write our shell code. Now that we've got that in place we actually write the egg hunter shell code once again using the sub and add commands. So just take a look at the rest of the shell code and see what that looks like. All right, so these were the first instructions that we gave. Did our desktop just die? These were the first instructions that we gave and now once again we zero out EAX in order to start writing and carving our shell code in memory and just again, just to make sure that you've seen that notice these last four bytes of our egg hunter. These will be the first four bytes that we write in memory. So E7FFE775. We'll do some calculations. We'll work on EAX, subtract these two values and look at the value that we have in EAX right now. Let me just get it to the right place. Do you see that? That's my 75, that's my E7, that's my FF and that's my E7. So I've got that value on the stack now and what I'm about to do it is I'm going to push it to the exact place where I had it aligned to before. So we'll push that and you should see the last four bytes of the egg hunter written to the stack. Oh, that ran a bit too fast. Okay, I've already written two lines. Let's do that again just so you can see it happening in real time. Feel the love. All right, we'll crash it once again. We'll take the jump, we'll pop, pop, ret it, we'll gently jump over our return address and we'll paste the beginning of our shell code. Great. So once again, we zero out EAX, we find the location of where we are on the stack, we align our stack to where we want to carve our shell code and now we start writing the shell code. All right, so again, the first two lines zero out EAX, these are the last four bytes of our shell code, of our egg hunter shell code, we push these onto the stack and there you have them and then we continue and then we zero out EAX once again and we write the next four bytes and we push them onto the stack and again, zero out EAX and we keep on doing this with all the 32 bytes of our egg hunter and slowly our egg hunter materializes just at the end of our buffer. Once again, zero out EAX, do the calculations for the next route, push it onto the stack and so on. Now, where exactly are we pushing this stuff because once this loop finishes and I've pushed all my 32 bytes onto the stack, well, it was aligned in such a way that as I continue the code execution, I will actually meet my egg hunter and from here on, basically what happens is that the egg hunter kicks in and starts looking for the final payload which is a bind or reverse shell. So let's do that, let's take all these modifications, let's put them in a script, run it and see how the exploit works and also look at the egg hunter in action because this is probably one of the nicest pieces of assembly that you could ever use in an exploit like this. We also had another problem, which I didn't mention. Where do we put this large payload, this large, I don't know, 600, 700 byte payload of a bind or reverse shell? So mucking around with the NNM service, we actually saw that if we append an unlimited amount of data at the end of our HTTP request, that wouldn't actually be affected by the OV filter and we wouldn't be getting any bad characters and nothing would be mangled. So this is an ideal place to put even 1,500 bytes of shell code. So that is where our second state shell code will reach and don't forget, as always with an egg hunter we always need to have that signature, that egg that the egg hunter will know to identify and act upon once it sees it. So let me run this final working exploit and show you how we actually got to execute code on NNM. How are we doing with time? Alrighty. So we hit NNM once again, same sort of idea, the structured exception handler. Yeah, it has to kick in. We've got our wonderful, friendly return address. We take the jump, we pop, pop, ret. We do the funky jump over the return address. Ugg, I wanted to do something with that. Hold on, sorry. Once again crashing it, structured exception handler kicks in. We take the jump, take the pop, pop, ret. Jump over our return address and right here I'd like to make a tiny change just so any future changes are actually seen in Olly better. We'll get this red highlight than just normal highlighting. So let's start walking through and see what happens. Once again, EAX gets zeroed out. We push our stack location into EAX. We do some calculations on it. We align our stack to where we want to write our egg hunter payload. And then we start writing the egg hunter. So ESP starts decoding our egg hunter shell code and we end up meeting it. Now, our egg hunter will look for instances of root, capital W, zero, zero, capital T. And once it finds two of these in a row, it will assume that our shell code is right after that. So what we'll do is let's put a couple of break points in these instructions. This is basically the command that looks for the first instance of root. If that is found, then we look for another instance of root and if that is found, we jump to the location that comes immediately after that, i.e. our shell code. So let's give that a run and we hit our first break points. It's currently looking at this memory address, looking for these bytes, W, zero, zero, T, or the other way around. Not here, go back, search again. Not here, go back, search again. And you can actually see EDX is the main counter used to search through memory. This could take a really, really long time because we might be looking through four gigs of RAM, which is a lot. So let's skip this break point and ask the egg hunter to stop and show us what's going on after the first root has been identified. So we'll let that run. This could take some time. Nice seeing you all. You want to entertain them, Chris? No. Pup goes that way. Pup goes that way. Olly actually does add a lot of overhead to these type of things. You'll notice that when we run this without Olly, it shouldn't take more than 10 seconds, but those are probably the most beautiful 10 seconds that computer has ever seen because basically it's pointing itself. So we've hit our second break point. Let's just take a look at what EDI holds and look at that, it's holding our first root. See, follow this memory space. Look at that, that's our second root. That was our first root and this is your standard bind shell code if I remember correctly. So let's see what happens now. The jump to continue running the egg hunter is not taken and the next instruction that we're going to hit is jump EDI. Now, what do we have in EDI once again? We have a nice unadulterated bind shell. So let's take the jump and this bind shell, just in case, was encoded using the alphanumeric Metasploit encoder. Even though we didn't really have to, we just thought it might be safer. If everything is sort of alphanumeric-ish, then what the hell, why don't we have the shell code that way as well? So basically what we see now is the bind shell decoding and this is actually very pretty to watch. If you look from here onwards, you'll actually see the bind shell decode in real time. So we'll press, we'll single step and just look at that CLD in below and you see that that's like raw bind shell decoded. And this happens really, really quickly. So let's allow our bind shell to completely decode. I'll put a break point at the beginning and in theory, we have nothing listening on port 4444 right now. If we now let this bind shell run, we've got a shell. So just to have like, you know, the meat and everything will do that and that's actually interesting. We won't go into that right now. What I'd like to show you though is what I'd like to show you is the actual exploit running in real time so you can get an estimate of how long the egg hunter does search through endless amounts of memory space and obviously also look at the process shooting up to 100%, which again is probably, you know, the nicest part of this whole thing is that the machine is literally hacking itself and the last one is, you said, well, I've got a buffer somewhere. It's got a bind shell. Look for it and when you find it, execute it and make me some coffee while you're at it sort of thing. All righty, so what do we want? How do you get to the task manager thing? Backtrack! Ah yes, that's the one. It's okay. All right, so what's this little box right here? As the machine gets hacked. All righty. So we'll send our final payload. Look at that. Oh come on, you can do it. I think I can, I think I can. It's probably taking some time to crash. There you go, egg hunter working. The machine is in pain screaming. We'll probably be done a bit earlier. And you know exactly when to look for the shell, right? The machine is so slow, it's actually delaying the output of net stat. It's like, just give me a second, I'll have it there, just a sec. Isn't that beautiful? All right, so the shell code, the egg hunter looks like it's calmed down, which would probably indicate that we've got our shell. So just to kill some time last night, this wasn't working. I had the whole offset of the shell code wrong and Chris takes me to drink. Thank you, Chris. Thank you. He planned an off-sec party last night. Yeah, I saw it to God, brother. All right, guys, thank you very, very much for coming. Thanks for this support.