Practice: OSCE

DVD X Player 5.5 Pro (SEH) Buffer Overflow Exploit

Preparing for the Offensive Security Certified Expert (OSCE) exam, I hopped on exploitdb.com to find vulnerable software to exploit buffer overflows.  Now, for the exam, I wanted to pick one, then ignore the exploit file, download the application and find out how to exploit it myself.  I think this would be the best way to simulate finding a 0day (besides finding a 0day), and exploiting it. I found the DVD X Player 5.5 software.  It is a computer media player that can run on Windows.  I am installing the software on Windows XP SP3 and Windows Vista.  Let start with Windows XP.

After the install it looks like it uses a playlist like WinAmp. The file extensions are PLF and SLS.  That goes with the original exploit for the software. Well, let's open up the FileFuzzer script and create a file with the buffer of 1000. Why not start small. We need to first open the DVD X Player app and then, open up OllyDbg. We will then attach the application running so we can catch the application's reaction to the buffer. 






Looks like we have a winner. The EIP and SE Handler was over-written.  Now, I increased the buffer size to 2000 once I saw where in the buffer overwrote the SEH. I figured that out by using the ruby script pattern_create.rb by MetaSploit. That will create a specific pattern of characters so we can find where EIP is.  Once we find what is located in the SEH, we can use another MetaSploit script called pattern_offset to find out how many characters(bytes) are before the SEH.  We put in the value for SEH and put it as a parameter for the script. It gives a value of 612.  So, after 612 "A" characters, you can control EIP and thus, execution flow. Sweet.

Alright, next, we want to start making a exploit file now that we know the necessary buffer length. This will help us ensure that we have the right length of the buffer and how much space we have remaining to inject shellcode. That is easy enough.  We create 612 "A"s and 4 "B"s and the rest "C"s. Hopefully, our buffer gets to one of the registers, (if we are lucky). It looks like this is like most SEH exploits. It looks like our "C"s are after the exception handler so if we can find an address to get to a "POP POP RETN", we can land there. We go to 'View -> Executable Modules'.  Now, we have to avoid any ASLR enabled dll's and executables. We have one at #603022B8 in the "Configurations.dll".

We want to follow the flow by creating a breakpoint(F2) on our "POP POP RETN" at the address just mentioned. Then, by pressing F7, we can step thru execution one step at a time. After the "POP POP RETN", we land exactly 4 bytes behind our SEH.  Now, it looks like we have the option to either to make a jump forward or backwards. We have a space of roughly 608 bytes going back and approxiamately 1300 bytes ahead. I chose to jump ahead since it is a larger space.  If you  want to learn more about jumping, please go to CORELAN (https://www.corelan.be/index.php/2009/07/23/writing-buffer-overflow-exploits-a-quick-and-basic-tutorial-part-2/).

Now, to jump ahead, we want to make sure we jump at least 6 bytes over to avoid overwriting our SEH jump. We want to land in 'NOP' AKA '\x90' commands to slide into the actual shellcode. Let's leave 10 'NOP' commands to slide into so we can go straight into our shellcode. Using MetaSploit, I generate a shellcode that will send a reverse shell to my local IP address on port 4444. We want to make sure that the size of our shellcode does not exceed our buffer. It is only 314 bytes so we are very safe from that. We just need to remember to subtract that from our remaining buffer size. We are looking at 1374 - 314 = 1060 which should be the remaining 'C's for our buffer.

Lastly, before creating our new PLF file, we want to create a listener to catch the new network connection coming from our 'victim'.  Bring on netcat! The command, 'nc -lvvp 4444' should do it. Now, run our new file to create the final PLF file. Run it on our victim, without the debugger and see what we get.






Wonderful.  We can do changes to the file to see how it would work.  We can jump backwards instead of forwards from the SEH. We could add an egghunter which I think I will do later. Hopefully, this helps another student of infosec besides myself.