BSides Iowa 2018: "Finding & Exploiting Zerodays (Yes, you can do this!)"

well good morning everybody I love this configuration because everybody is gonna be looking at the screen and not at me but when I was growing up in my neighborhood during Easter time we had a neighborhood Easter egg hunt you guys ever do that so around 11 some responsible high school kids would come and get some of the donated eggs from each of the families and then hide them and then in the afternoon after most people got back from church the Easter egg hunt would begin toddlers would go out first there'd be some eggs that all know the lawn for them and my time the elementary school kids went there were only hard ones left to find and what I'm

about to show you is a very surprised buzzing student finding something that felt like one of those Easter eggs still on the lawn that was really surprised it was there and then I did a just a normal stack based buffer overflow with a with an S eh chain addition in that which will be a review for most of you so I'll just step you through it but the really interesting thing to me is that it was still out there I thought by the time I get to the hunt all the easy ones have been found that was just very surprising to me I'm gonna project my voice better okay all right here's my contact information I'm from

Omaha Nebraska and call me JK if you want and the title of my talk is finding and exploiting zero days yes you can do this well here's the about me slide that you have to do to all the conferences step you through this kids are getting bigger for them are adults and one high school freshmen with really large feet and the band is doing well both my band mates our cybersecurity people Dave just got his G wept yesterday said it was a really hard test so congrats to Dave and over on the left took the motorcycle trip in California is pretty cool that is actually south of Monterey on Highway one if any you have a chance to

do that I highly recommend you taking that in and this on the right is the result of a heinous Prive esque for a Linux executable compiled with NX protection that required return-oriented programming to exploit statement of humility of course I'm just like you I am NOT an expert in what I'm about to show you some of you will are the one about to show you is really not kung fu it's just very basic stuff and just glad to be here guys so here's what I'm going to show you two long do not read okay so one time at band camp I was going through the OSCE course that offset puts on and I was taking the

crack the perimeter course I finished the zero day unit finished the lesson about fuzzing fuzzing student using a tool called spike anything you've ever used that it's resident in Kali Linux for free not well documented not a lot of training material through it successfully fuzz the lab machines using spike and I wanted to do an op test to see if this was does this stuff work or is this just latvia s-- so i went here and found this and i liked it because it was a web-based file-sharing available for free with the actual neural application available for download and so I downloaded the app and set up my target VM XP was available it was there

and

set up the app in my Windows XP machine got it working properly and then browse to it in my Cali chose a guest session chose one of those links and then I examined it in Wireshark chose that guess get request and the get request looked like this and this is what I would model in spike and so when I was done it looked like this you can see that there are eight or nine variables there and based on my research for exploit DB those two that are in red brackets were known to be vulnerable so if I was fuzzing correctly what would happen to the server it should go down if I'm fuzzing correctly it should go

down when I fuzz those two variables so so I began to fuzz and I was glad to see that the first variable crashed as I was hoping it would if I was fuzzing correctly so it's like wow this stuff really works I continued fuzzing each variable in succession and the other ones did not fuzz till I got to the eight variable the second to last one and it crashed as success and so my learning objectives were complete for the day and as I was putting things away the last variable so this happened which surprised me and interested me so I did some research and exploit DB to see if anybody had reported this particular parameter the password

parameter as vulnerable I didn't see anything so I began a normal buffer overflow investigation that a lot of you have done and so the next thing I did was I caught the crash in the binary debugger and I noticed that the the top red bracketed box there was the actual string that was sent to cause the crash some punctuation and a lot of a's and ii read bracketed box just confirms the crash notice there is no EIP overwrite at this point but notice that the input that I sent is three positions down in the stack and when you go through the OS cracked a perimeter of course that is one of the classic presentations for a

structured exception handler buffer overflow so what I did was I checked the SH chain and saw to my delight that I had overwritten the structured exception handling with my A's which when you pass that exception to the binary debugger oh here's I have cheesy builds in this thing so just bear with me on this thing over out the EIP and that's good news because you now can get at least a denial of service attack from a remote and so what's the next question okay I got a denial of service is it exploitable right so I did the standard work up for that I noticed that the top of the stack was the input that I control

so the next thing I did was try to replicate the crash with a script and you can see from here this is your classic Python remote script you'll notice the environment you'll notice the the host variable set setting the crash variable to punctuation and a lot of a's and then below that is just how a get request looks in python and then below i put some tcp connection type things with some messages to me that it sent and connected properly and so that i tested that and i got the same results and so alright now we're in business now we're in business because now we have the means to experiment we now have something that works and we can tweak

and experimental and do it repeatedly so going through the pattern analysis that a lot of you have been taught I determined that the override happened at 57 and so I crafted my string with 57 A's four B's and then some other things sent it again and saw that I had over overwritten the structured exception handler and therefore the EIP with four B's meaning I own the EIP the next thing I did although this was not required for a Windows XP machine I wanted to find out which of the DLL is associated with the app and the libraries associated with it had safe seh protection and the ones in red associated with the app itself do not so

I would choose one of those dll's for my next pop code so I chose the image load DLL and began to search it for a pop pop ret sequence which is what you do for a structured exception handler and found one that I thought would work because it did not have any no bytes in it and that is the one that I chose for my return address in effect modified my string with the return address where the bees used to be and directed execution in my binary debugger set up a breakpoint sent it in execution stopped at that beginning of that pop pop bread and cheesy but that means I now control the execution of this

program so now it's getting exciting

so I stepped through the pop pop and the red remember when that input I control was in the third position of the stack so whenever you do a pop it releases the top address of the stack and the second pop releases the second address on the stack and there at the return when a processes of the return it's going to direct execution to whatever's at the top of the stack and so what is at the top of the stack I examined it and notice that it was last four of my A's the last four of my ace and the to the next to that is the return address that I did previously for the beginning of

the pop pop ret sequence and the rest is input that I control so it's presenting itself as a classic stack based buffer overflow at this point check to see I had at least about 400 bytes for shellcode most shellcodes about that and I did it was clean so in the last four positions of the of the 57 A's I chose opcode that would execute a forward relative jump of 16 bytes and that's just what I started with modified my exploit with it and sent it and saw this is where that is where it would DirectX and choose so that blue line there is the notional position of my shellcode so I created shellcode the usual way that a

lot of us use i used ms Venom windows reverse shell localhost tacking kali linux machine random port that I use chose the Python format for easy cutting paste into my exploit and I also ruled out null bytes as part of my string and it looked like this and I pasted it into my exploit and when I was done it looked like this you can see I have a buffer variable notice it's very much the same crash variable in the get request part and so now what do you do is you test it right maybe it'll work so I tested it and everything worked fine that directed at execution it executed the 412 forward relative jump and jumped to my spot in

shellcode where I inspected in memory to make sure that it injected cleanly and then stepped it through each set watching the decoding process making sure that it decoded properly and that it would execute and it was very clean so the next thing I did is I tested it so I set up a listener in my Kali Linux machine port 235 and then in another terminal I executed the exploit got the normal connecting sending indications which was good and was rewarded with a nice shiny shell let's see that again shall we Breaking Bad Hank and this was an administrator level shell which was system and so okay success so the next thing I did is I

made my exploit pretty for off sec and email this to them very excited heard nothing so after about a week I emailed offset evens disclose this thing and they never answer but then the next day was on the board and there it was interesting enough a week and a half later someone else submitted an exploit for the exact same parameter defeating Windows 7 and defeating DEP with a return-oriented programming exploit and it was pretty sweet so the moral of the story is that there is always always somebody better so so that's what happened and this is what we talked about and this completes my portion of the brief I'm subject to your questions well you guys slept through this sir I

did the exam requires a stack-based buffer overflow proficiency without the need to know structured exception handling so one level below that is what's required for the osep would you agree Michael yeah okay okay thank you everybody [Applause]