Time for tutorial 6 (yeah I skipped #5, as I got the gist of it). After 6 days, I really got the hang of buffer overflows…too bad they aren’t much in use anymore, but everyone has to start somewhere. So below is EIP and SEH being overflowed with 0x0041, indicating that our “A” where translated to Unicode characters.
Mona locates the Metasploit pattern overwriting SEH at 536. So our payload will be something like
This is where it gets tricky. When following the tutorial, I was never able to see that EIP contained 0x00440044. It actually contained 0x00440045 after moving after the Access Violation exception. I can clearly see that SEH has been overwritten with 0x00420042 and 0x00430043. Fortunately according to one comment, I’m not the only one. When I tried to put 534 bytes of junk rather than 536, I end up with 0x0042004D in EIP (difference of 8). I don’t get why it does that.
At least I’m confident I understand the concepts, but that’s pretty much useless if I cannot put it into practice. For this example, mona can find POP-POP-RET addresses that will work when translated to Unicode. From my understanding, [nSEH] will be useless in Unicode-based exploit, simply because there’s no easy way to have a jump matching Unicode encoding. As such, we’ll need to jump to a register which contains a address close to our shell code and either 1) make sure no instruction between the address and shell code will break the exploit or 2) modify the register (add/sub) to have it jump into a NOP slide to our shell code…and then we have to figure out the shell code, but from what I read, talented people have already took care of this for us.
Today we’ll be studying “egg hunters” as of part 4 of the FuzzySecurity tutorials. Basically this technique is useful when the buffer remaining for your shell code is too small to do anything useful. So far we’ve been lucky and we had huge buffers to inject the shell code, but some time, you may be left with a couple of bytes only. With a “egg hunter”, instead of storing your shell code, you store a small function that will look for “magic bytes” in memory. Your shell code somewhere else in executable memory and tagged with these “magic bytes” so that your egg hunter finds it and executes it. Pretty straight forward.
Exploiting Kolibri Web Server
So my goal today was to test out the egg hunter example from the tutorial. However I got cocky and try to exploit the web server by smashing SEH rather than a normal buffer overflow. Everything went fine until I had to call the address containing the POP-POP-RET.
The problem I’m running into is when looking for a “POP POP RET”, all the results are within Kolibri.exe, and all addresses starts with a null byte, i.e. “\x08\x89\x51\x00”. That means our payload will terminate at the null byte. I thought this wouldn’t be much of a problem, since [SEH] is an address anyway, the only difficulty would be that I may have to put the payload in the buffer prior to the [nSEH], and have a short jmp into the buffer placed into the [nSEH]. Now for some reason, it seems that SEH catches the exception, but never jumps to my POP-POP-RET address; it just terminates the program.
So I got stuck here for today. More to follow tomorrow
"HEAD /"+smash+" HTTP/1.1\r\n"
"User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; he; rv:184.108.40.206) Gecko/20101026 Firefox/3.6.12\r\n"
Today, instead of following the FuzzySecurity tutorial, I’ve decided to solidify what I have learned so far by exploiting another FTP Server, this way we won’t yet stray far from the tutorial. We’ll exploit the PCMAN FTP 2.07 server.
The exploit is a buffer overflow in about any command send to the FTP server. We’ll attempt to exploit the STOR command. To do so, we basically reconstruct the Python script we’ve used in day 1:
And voila! I sometimes runs into issue when running the shell code on the target machine and it seems due to bad bytes in the shell, so this is something I’ll need to check out, i.e. how to determine which bytes should be avoided in the shell code. I usually fix it by regenerating a new payload in Metasploit. In any case, we have out shell:
All right, so now, we should be able to exploit basic buffer overflows from any simple program. Let’s move on…
Today I’ve followed part 3 of the FuzzySecurity tutorial, which went pretty smoothly now that all the VMs and software have been setup and fixed. In the end, I was successful in binding a shell to a port. Yet, I had the feeling that I often have when learning by tutorial: it works now, but would I actually be able to replicate this while exploiting another application? And what really happened? I mean I have loaded my shell code, but yet, I don’t have a clear understanding of what SEH really is. So after completing the tutorial, I actually took time to try to figure out what exactly happened.
The Structure Exception Handler (SEH)
The SEH is a Windows native mechanism to handle both hardware and software exceptions in Windows at both kernel and user spaces. So when the normal flow of an application is interrupted, the SEH comes in to handle the management of the interruption. Basically, this is the native component of Windows which triggers the try…catch… statement you use in your programs. So how does SEH works?
As depicted above, the SEH is a linked list in memory, in which each nodes contains 2 pointers; one pointer to the next node in the list and one pointer to the function who handles this specific exception. There is a node for each exception handled by the current function. These nodes are basically all your “catch (FileNotFoundException)…catch(NullPointerException)” etc…. Each node of the linked list stores the pointer to the Structure Exception Handler and a pointer to the next Structure Exception Handle. The root node, the default exception handler is actually stored in the stack. So in this tutorial, when we smash the stack, we gain control of those 2 pointers, which we will use to jump to our shell code.
So in this case, what is happening is that we smash the stack with “A”s, overwriting EIP with an invalid pointer (0x41414141). Since this is not a valid value, an “Illegal Instruction”/”Access Violation” exception is thrown and thus triggers the SEH handler code. This means the code pointed by the “SEH Handler” [SEH] part of the stack will be called, which is actually a call to the next node in the SEH linked list.
By writing an address pointing to “POP POP RET” instructions at [SEH] and having it executed them, we will load the stack address of [nSEH] into EIP and as such, execute the op code at [nSEH]. So if we insert a short JMP to the address of our shell code (0xEB06 [shellcode]) at the address pointed by [nSEH], we’re done.
This technique won’t work with SafeSEH and SEHOP.
Moving on with Exploiting DVDX Player
You should have no issue generating the Playlist file to overflow the EIP register and trigger a exception.
Then by replacing the long string of “A” by a Metasploit pattern and !mona findmsp, we can find the offsets, as in past tutorials;
Since we’re interested in exploiting SEH in this tutorial, we’re interested at which offset the SEH is being overwritten by the Metasploit pattern. In this case, it’s overwritten at 608 bytes and we have 1384 bytes of buffer for our shell code. That means that the nSEH is at 608 bytes and SEH at 612: “A”*608 + [nSEH] + [SEH] + [Shellcode].
To link with what we’ve read in the first section, here is what happens: Our string of 608 “A” will crash the EIP and cause an exception, jumping directly to the contents of [SEH]. [SEH] must contain an address. [SEH] is located at [ESP]+8 at execution. Remember that the ESP is an indirect pointer to the top of the stack, and the stack grows downwards. By POPping two times and returning, we will load the stack address of [nSEH] into the EIP and execute whatever instruction at this address. To be perfectly honest, I’ll need to further understand this part….
Accordingly, we will look in memory for a “POP POP RET” combination using “!mona seh“. Mona will return quite a few results. We will prefer results located in DLLs owned by DVDX Player, since they are OS-independent.
We’ve picked up 0x640345e7 (“\xe7\x45\x03\x64”) since it’s located within DVDX Player and contains no invalid bytes. We now got the [SEH] part of our payload:
Now for [nSEH], we’ll need to put a “jmp [offset]” instruction in it. Our shell code begins right after the [SEH] (4 bytes) and our jmp instruction is 2 bytes. The short jump op code is 0xEB, followed by the number of bytes to jump from EIP, i.e. 6 bytes. So the instruction to insert at [nSEH] is “\xeb6\x90\x90”:
All that is left is the shellcode, which is a quick NOP slide and a shell bind. Done! Excited, I plug the payload into DVDX Player and fail miserably to have have the shell code executed. I used the same shell code as the previous tutorial in an attempt to minimize the number of things that can go wrong. By doing so, everything went wrong. Well not exactly everything, but the previous shell code had byte “0x1A” in it, which created additional READ exception in the code once the shell code loaded. So I regenerated the code without bytes 0x00, 0x0A, 0x0D and 0x1A and everything went perfect. Or almost. When running the shell code, Windows asked me to unblock port 4444 to listen to inbound connection. I guess using a reverse shell or a “download and execute” is quieter…
I wonder if anything I wrote made any sense since I’ve been so focus into this exploit today. The ascii diagram from FuzzySecurity summarize the principle well enough:
Well enough for today, my frontal lobe is overheating. More tomorrow…
Hopeful that I’ll waste a lot less time than yesterday, I’ve setup a Kali virtual machine. I had one problem while installing: as soon as the actual installation started, I had a “The failing step is ‘Install the System'” error message. This was solved when I created a 15GB Virtual Hard Drive (VHD) rather than a 10GB Virtual Box Drive. I also had to setup Kali so it works with VirtualBox Guest Additions. You’ll first need to update the sources in /etc/apt/sources.list by including the second repositorty(http://http.kali.org);
http://http.kali.org/kali kali main non-free contrib
http://security.kali.org/kali-security kali/updates main contrib non-free
Once done, update the package lists by running apt-get update and then install the the linux-headers for Kali:
Finally, install the guest additions as described in the Kali FAQ ….and realize it doesn’t work. According to the log file, 2 errors occured:
This can be solved by using the latest version of VirtualBox. Once I’ve upgraded to 4.3.8, I was able to compile the Guest additions with no trouble.
The Fun Finally Begins…Exploitin’
Continuing Part 2 of Fuzzy Security exploit tutorial. So now, I can finally use the pattern_create.rb script to find out at which position in the payload I need to put the return address in EIP. In the latest version of Metasploit, pattern_create.rb is in the following directory:
After creating the pattern and putting it in the python script, the EIP registers overflows with value 0x69413269, which correspond to offset 247 of the payload. So far so good.
Once confirmed, then we need to redirect the program’s execution flow to the ESP, the stack pointer, according to tutorial of Fuzzy Security. Good enough, but why ? Well the ESP always points to the top of the stack, which contains an address. If you look at the screenshot above, you’ll notice that the address contained in ESP, 0x00C7FC2C contains our “C”s, i.e. a value we control as well.
So if we replace those “C”s with our shellcode, our objective will be to find a way to jump to the address contained in ESP. To do so, we will find an “jmp esp” instruction in memory, and put the address of the instruction in EIP – the register that contains the address of the next instruction to execute.Use “mona jmp -r esp” to locate the JMP instruction. Once Mona is finished, select View -> Log to see the result.
The results I have differs from the one of the tutorials. Shouldn’t be an issue, so I’ll take the one in “ntdll.dll” (0x7C91FCD8) as it seems to be a stable DLL. In little endian form, it becomes “\xD8\xFC\x91\x7C”. To test if it works, you’ll need a breakpoint at whatever address you are pointing, otherwise the execution flow will just land somewhere in memory. To add a breakpoint, right click in the CPU view, select “Go to” -> “Expression” and in the window, type your address (big endian). After you clicked OK, you should land on your address. Then press F2 to toggle the breakpoint at this location.
So we have verified it worked, we can now move on. I won’t fray to far from the tutorial and just generate a local shell bind payload on port 13373. To do, we’ll need the following Metasploit tool:
Basically what this command does is generate the shellcode for binding a shell on port 13373. It then encodes it in bytes without using bytes 00, 0A and 0C. “\x00” is a terminator value for strings. If included in the shellcode, it will break the code. The same goes with 0A and 0D, which are the “New Line” and “Carriage Return” values (i.e. chr(10), chr(13)). The “-t py” option specifies that the output will be formatted in Python. I thought I could almost conclude this session, but of course, I had to hit one more hiccup. After running the exploit, the debugger throw an “Illegal Instruction” exception at 0x00C7FC28, where the first byte of the shell code is.
I’ve wonder many minutes about this issue. I’ve decided to just plain follow the tutorial and choose the same port, 9988 and regenerate the shell code. To my astonishment, the new shell code worked! The first byte is different, but I’m still not sure why the new code works while the other don’t. More to follow…
I’ve always seen exploit research and development has the pinnacle of computer security, the ultimate black art of hacking, probably because writing exploit requires full understanding of low-level memory and CPU operations. And given the complexity required nowadays to not only find a vulnerability, but actually exploit it, given protection such as DEP, ASLR and EMET, keeps amazing me. Just tonight, a Chinese team successfully pwned Safari and Flash at the annual Pwn2Own. They could have make serious money on the black market with these two exploits. So I asked myself recently: why don’t I start learning exploit development? There’s certainly a future in it.
As such, I’ll be starting at the bottom and follow the Fuzzy Security tutorials, which seems quite detailed. Today, I’ll be following part 1 and part 2, using a virtualized Windows XP 32-bit box. I’ve downloaded Immunity Debugger and Mona.py and Metasploit, filling out those pesky registration form. Of course if you are not aware yet, use FakeNameGenerator and 10 Minute Mail, which work for all these sites. I’ve skipped pvefindaddr.py since it wasn’t available for download anymore. You’ll also need Python 2.7+ for Immunity Debugger.
Basically, I have a quick setup of 2 virtual machines; one runs Windows 7 64-bit with Metasploit 4.8.2-1 and Python 2.7.6, the one is a Windows XP SP3 32-bit machine with Immunity Debugger, the Mona.py script and the vulnerable FreeFloat FTP. With VirtualBox, I’ve set a Host-Only Adapter on both machines on the same virtual network. Copy the mona.py into the C:\Program Files\Immunity Inc\Immunity Debugger\PyCommands folder. If you’re using something else than Backtrack or Kali, you’ll need to download and install a Ruby interpreter and the Development Kit to use the pattern_create.rb of Metasploit. When installing Ruby, make sure you select “Add Ruby executables to the environment path”. Finally, once you have, you need the “bundler” package for Metasploit. Within the Development Toolkit, run the “devkitvars.bat” file. This will add the DevKit to your PATH. Simply type “gem install bundler” and you should be on your way. Or so I thought…
Metasploit then complains it cannot find the rake-10.1.0 sources….What a pain. That’s because the version or Ruby I’ve install contains Rack version 10.1.1 instead of version 10.1.0. To install the correct version use the following;
C:\Ruby>gem install rake--version10.1.0
This will install the correct version. Unfortunately, the same problems happens with additional packages. After trying to install each of them manually, I got tired of it, so I try the “bundle install” command, which needs to be execute from “C:\metasploit\ruby\bin” folder;
At this point, I just give up and install every damn packages I need manually. After 10 minutes of this I just rage quit when the network_interface-1.0.0 package kept failing to install. I’ve downloaded an ISO of Kali. The only success I had tonight was overflowing the EIP register…guess I have a long way to go…