Bad Characters Sortilege

Introduction

In exploit development world there will be times where you find yourself working with an executable that enforces a very limited character set in which you can use to craft your shellcode. This rather short blog post will talk about how you can use bad characters to your advantage and ultimately produce otherwise prohibited instructions in your shellcode.

Synopsis

While prepping to take the OSCE course earlier this year, I discovered 0day in the register function across Flexense products, see the link EDB-ID: 44455. At the time Structured Exception Handler (SEH) subject was fairly new to me, let alone manual shellcoding. I struggled for days trying to figure out a way to beat this thing before deciding to craft proof of concept shellcode for WinExec() function for reasons that are irrelevant to this blog post. Typically the register function will only accept alphanumeric characters for obvious reasons and as such anything beyond \x7f character is considered bad, this includes pointers and instructions.

During the process of crafting the shellcode, I made sure to stay within the range of allowed characters but then reached a point where I needed JMP ESP instruction but couldn’t find a clean pointer that I can use. To overcome this issue I decided to pass previously identified bad characters to the program to see if any gets converted to an opcode that I could use (in this case was looking for RET instruction) and ultimately found that \xff end up as \xc3, bingo! So I manually encoded  JMP ESP pointer by preforming arithmetic operations on EAX register and pushing it onto the stack.

At this point all we need really is place \xff at the end of the shellcode which will effectively pop previously pushed onto the stack JMP ESP pointer to EIP and execute it! The following is a demo of the exploit, please check the above exploit link for more details.

Final Thoughts

The main takeaway here is always look for ways to circumvent restrictions and don’t take bad characters for granted.. Hopefully this blog post will aid folks who run into similar situations or rather help them come up with more creative ways to solve the problem at hand. Lastly, feel free to correct any inaccurate information I may have provided using the comment section below or tweet me @ihack4falafel.

ROPing the Stack

Introduction

In efforts to learn as much as I can before starting OSCE later this month, I decided to write a blog post about Return Oriented Programming (ROP). ROP in its entirety is fairly new to me and as such this will be learning experience to me as much as it would be to you. Now If you would like a more in-depth overview of the subject I highly recommend reading Corelan Team tutorial, in fact most (if not all!) of what you will see in this blog post is based on information obtained while reading their exploit development series. Lastly, you need to be somewhat familiar with Buffer Overflows and have solid understanding of x86 Assembly before we continue.

ROP

At this point you might be asking yourself what is Return Oriented Programming and why on earth would I need it. Well, from a high-level point of view ROP is set of instruction(s) followed by return (also referred to as gadgets), meaning a given gadget executes and then the return instruction kicks in redirecting the flow of execution to the next gadget inline thus giving us the opportunity to chain multiple commands together to achieve a meaningful function also known as ROP chain (see the figure below).

The reason you would need to construct a ROP chain is something called Data Execution Prevention (DEP), without going into too much details DEP is a system-level memory protection feature that is built into the operating system starting with Windows XP and Windows Server 2003. DEP enables the system to mark one or more pages of memory as non-executable. Marking memory regions as non-executable means that code cannot be run from that region of memory, which makes it harder for the exploitation of Buffer Overflows, for more information on DEP do check this wiki.

In nutshell if DEP is enabled placing your shellcode on the stack via saved return pointer (EIP) or Structured Exception Handling (SEH) record overwrite won’t do the trick and as such you would need to somehow find memory addresses that point to command snippets followed by return instruction in the target program and then place them strategically on the stack to call/execute a function. Now keep in mind your limited by the functions (APIs) used in the program you’re trying to exploit, also you need to account for things like bad characters, SEHOP, and ASLR.

Depending on the situation at hand you can use ROP chains to either call functions like WinExec() to say add user or execute bind shell or use functions that disable DEP by marking region of stack, heap, or the entire process executable. See the table below (used MSDN as reference):

Based on my little experience with ROP gadgets, I’ve noticed that you would run into VritualProtect() and/or VirtualAlloc() calls more often than the other APIs and as such the following section will focus on abusing VritualProtect() to bypass Data Execution Prevention. Below is what you need in order to follow along:

VirtualProtect()

In essence, VirtualProtect() changes the protection options i. e. the way application is allowed to access some memory region already allocated by VirtualAlloc() or other memory functions. I’ve made table of required arguemnts based on information from MSDN.

First things first we need to fire up Immunity Debugger and setup working folder for logging.

Obviously I’ve done this prior to taking the above screenshot hence the old value. At this point I’m going to assume you know how DVD X Player exploit found in EDB-ID: 17745 work and for that reason will skip this part. The next step is to see what ROP functions are available to us in order to bypass DEP.

As you can see the search was limited to application DLLs that don’t have memory protections such as ASLR and SafeSEH turned on and excluded addresses that contain bad characters. Again, I assume you know how to identify  bad characters otherwise I suggest this excellent read here. The screenshot shows mona.py found a total of 48 pointers (3 of which are VirtualProtect()) and the results were written to ropfunc.txt. Let’s overrun the saved return pointer and examine the stack at that point using the following skeleton exploit.

Attach DVD X Player to Immunity Debugger and load OpenMe.plf.

Looking at the stack, ESP points to (0x0012F428) that’s 16 bytes from EIP which makes it fairly easy to pivot from EIP back to the stack (we want to place our ROP chain pointers on the stack, remember?). Now we need to find an instruction that will tell EIP to jump to where ESP is pointing and to do that we need to first generate list of universal ROP gadgets with no bad characters.

The above command will output number of files for various purposes but we’re only interested in two, rop_chains.txt which takes care of pairing registers with arguments for VirtualProtect() and VirtualAlloc() along with their corresponding ROP gadgets, now how cool is that?! The second file is rop.txt which contain every possible ROP gadget we can use. See VirtualProtect() register setup snippet taken from rop_chains.txt.

Notice how the ROP gadgets were placed in prefect order to make sure registers have the intended values by the time PUSHAD gets executed. Although there are two ways you could go about setting up your ROP chain we’ll go with the first option.

NEG instruction was also used to allow the placement of negative values for NewProtect and dwSize onto the stack in order to avoid null bytes. For instance NewProtect needs value of (0x00000040) to mark the memory region where our shellcode lives as executable (PAGE_EXECUTE_READWRITE), right? so to overcome the issue (0xffffffc0) was put instead and then NEG was used to convert it back to 0x40.

Now remember we still need to compensate for the 16 bytes gab between EIP and where ESP is pointing to, will use filler for that. I also did change dwSize value to (0x00000501) to allow for more space and swapped some of the pointers with ASCII print friendly ones as you can see in the final exploit.

The rest of the assembly code is pretty self-explanatory. Let’s take it for test drive.

The DEP policy which was set to OptOut mode in the above demo has been successfully bypassed! To be complete I also did create an exploit for VirtuallAlloc() which can be found on my Github here.

Conclusion

I hope you’ve learned a thing or two going thru this blog post, keep in mind we’ve only scratched the surface on ROP and I’m sure there are handful of tricks and techniques that I’m not aware of yet. Finally, feel free to correct any inaccurate information I may have provided using the comment section below and wish me luck on my OSCE journey in the near future :D.