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.

Password Protected TCP Reverse Shell (IPv6) | Linux x86_64

Introduction

In this post we will create a custom TCP reverse shell for Linux x86_64 architecture that requires password to spawn a shell. This post is a continuation of Password Protected TCP Bind Shell | Linux x86_64 and since my SLAE32 series include an in-depth analysis of the functions used in reverse shells we won’t spend too much time there.

Shellcode

I decided to create an IPv6 reverse shell this time around for two reasons, the first being I haven’t done any before! and the second is for some reason msfvenom don’t have one for x86_64 so the final shellcode could be of use to somebody, maybe.

Creating an IPv6 reverse shell is not rocket science, all we need is use AF_INET6 as domain when calling socket() function and use IPv6 structure to specify what IP and port we want amongst other things (I used localhost ::1 in this case). Lastly, we need to accommodate for the structure length when calling connect() function using RDX register.

The following is the final null-free shellcode. Please refer to the link of my previous post in the introduction section to learn more about read() function used in the password check routine.

Now its demo time.

Closing Thoughts

I did learn a thing or two about IPv6 addressing while crafting this shellcode and I hope you did too. All of the above code is available on my github or exploit-db. Feel free to contact me for questions using the comment section below or just tweet me @ihack4falafel .

This blog post has been created for completing the requirements of the SecurityTube Linux Assembly Expert certification:

http://www.securitytube-training.com/online-courses/x8664-assembly-and-shellcoding-on-linux/index.html

Student ID: SLAE64 – 1579­

Password Protected TCP Bind Shell | Linux x86_64

Introduction

In this post we will create a custom TCP bind shell for Linux x86_64 architecture that requires password to spawn a shell. We wont be going into too much details on how each function work as this has already been discussed in my previous Creating Custom TCP Reverse Shell | Linux x86 post.

Shellcode

If you’re not familiar with x86_64 assembly its pretty much the same as x86 from shellcoding standpoint. The following are the key add-ons (I should say) that you get when using x86_64 assembly as opposed to x86:

I used read() function to check for input via stdin and then compare it to a predefined password (in this case I used “pwnd”), if the check fails the shellcode will jump to “_nop” section which will effectivly cause the bind shell to crash. Please refer to the link in the introduction section for more in-depth analysis of the functions used by the bind shell. The following is the final null-free shellcode.

Now comes that fun part, let’s test out the shellcode.

Closing Thoughts

I feel passwords are essential when it comes to bind shells and hope this post will benefit folks looking to create one. All of the above code is available on my github. Feel free to contact me for questions using the comment section below or just tweet me @ihack4falafel . This post is one of many to come so stay tuned!

This blog post has been created for completing the requirements of the SecurityTube Linux Assembly Expert certification:

http://www.securitytube-training.com/online-courses/x8664-assembly-and-shellcoding-on-linux/index.html

Student ID: SLAE64 – 1579­

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.

RC2 Shellcode Crypter/Decrypter in Python | Linux x86

Introduction

RC2 is a symmetric-key block cipher which was popular in the first half of the 90s of the last century. RC2 also known as ARC2 was designed by Ron Rivest of RSA Security in 1987. Without going into too much details, RC2 consist of block size and key length amongst others things more on that later. In this blog post, we’ll create RC2 shellcode crypter/decrpter to demonstrate the concept. Please note that I’m no RC2 expert and this blog post is by no means an overview of RC2 algorithm

Crypter

In order to create RC2 crypter there is couple of thing we need to figure out ahead of time. That is, key-length which can range from 8 to 1024 bits, cipher-mode which can be either ECB or CBC, and the secret key. We’ll use key length of 128-bits and CBC as cipher mode which require an Initialization Vector. Here’s code referenced from Chilkat, will use the comments section to explain the process

Note: the above shellcode basically spawn shell for us and can be found here

Let’s test it

Decrypter

Hence RC2 is a symmetric-key algorithm meaning the same key is used for encryption and decryption, there is nothing much to it really other than reversing the process of encryption. All of the code used to execute shellcode at run time was referenced from here

Test it

Its demo time! we’ll use pyinstaller to compile the python script

Closing Thoughts

While researching crypters/decrypters, I found most of the blog posts out there were using C wrappers, so for the sake of not making a redundant one I decided to use python wrapper. This post marks the end of my SLAE journey in which I learned how little did I know and how much I still need to learn. Thank you Vivek Ramachandran and the people who helped make this course available! Feel free to contact me for questions using the comment section below or just tweet me @ihack4falafel .

This blog post has been created for completing the requirements of the SecurityTube Linux
Assembly Expert certification:

http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/

Student ID:    SLAE-1115

Github Repo: https://github.com/ihack4falafel/SLAE32/tree/master/Assignment%207

Polymorphic Shellcode | Linux x86

Introduction

Polymorphism is a technique used to mutate code in a way that will keep the original function intact. For example, 1+1 and 4-2 both achieve the same result while using different values and operations. Polymorphic shellcode can aid in efforts to evade anti-virus and IDS/IPS. This post will look at couple shellcodes and how to produce polymorphic version of them.

Shellcode I

The first shellcode we’re going to work with is execve(), which basically spawn shell for us

Mutate code and use the comments section to explain the process

Compile and test

Shellcode II

The second shellcode we’re going to mangle is exit(), this one execute exit function with status code of 1

Mutate code and use the comments section to explain the process

Compile and test

Shellcode III

The third and last shellcode we’re going to deal with is fork(), this one will enter fork loop until system crashes

Mutate code and use the comments section to explain the process

Compile it

Note: Obviously we’re not going to test this one unless we want to crash the system

Closing Thoughts

I chose very simple shellcode examples so we can focus on the concept of polymorphism, hope you learned something from this post. Feel free to contact me for questions using the comment section below or just tweet me @ihack4falafel .

This blog post has been created for completing the requirements of the SecurityTube Linux
Assembly Expert certification:

http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/

Student ID:    SLAE-1115

Github Repo: https://github.com/ihack4falafel/SLAE32/tree/master/Assignment%206

 

Disecting Msfvenom Shellcode | Linux x86

Introduction

 In this post, we will analyze three samples of Linux x86 based shellcode generated by msfvenom using different tools. Now before going into the next section here’s the list of what is available to us.

Shellcode I

The first shellcode we’ll look at is adduser, the following are the options that needs to be feed into the payload

Generating shellcode

Compile and test

Use Ndisasm to dump assembly code

Analyze code line by line using the comments section

syscall reference setreuid(), open(), write(), exit()

Shellcode II

The second shellcode we’re going to look at is chmod, the following are the options that needs to be feed into the payload

Generating shellcode using default options

Compile and test

Use GDB with peda to dump assembly code

Analyze code line by line using the comments section

syscall reference chmod() and exit()

Shellcode III

The third and last shellcode we’re going to dissect is shell_bind_tcp, let’s check payload options

Generating shellcode

Compile and test

Use libemu to dump assembly code

Analyze code line by line using the comments section

syscall reference socketcall()dup2(), and execute()

Closing Thoughts

Stepping through msfvenom shellcode taught me few behind the scene tricks, also it cleared my doubts as far as how some of the commands work. Hope you learned something too! Feel free to contact me for questions using the comment section below or just tweet me @ihack4falafel .

This blog post has been created for completing the requirements of the SecurityTube Linux
Assembly Expert certification:

http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/

Student ID:    SLAE-1115

Github Repo: https://github.com/ihack4falafel/SLAE32/tree/master/Assignment%2015

 

[ROT-N + Shift-N + XOR-N] Shellcode Encoder | Linux x86

Introduction

According to English dictionary, encode is converting something, such as a body of information from one system of communications to another; especially: to convert a message into code. This blog post will combine three basic encoding operations (more on that later) to encode sample shellcode and then decode/execute it to demonstrate the concept.

Encoder

In this section, we’ll create 3-phase encoder that takes one byte of given shellcode at a time, mangle it and then produce an encoded word (2 bytes). The following will describe what each phase will do. Phase I (ROT-N), in this phase we add number N to shellcode byte. Phase II (Shift-N), in this phase we shift stdout from phase one to left by N. Phase III (XOR-N), here we just XOR stdout from phase two to get the final encoded word. Before we start working on the encoder, let’s write shellcode that spawn shell to test with.

Let’s compile execve() code block and then dump shellcode

We’ll create python script that takes ROT, Shift, and XOR as user input and print original and encoded shellcode, please note you still need to change shellcode inside the script to your liking. For this post, we’ll use the one created earlier.  It’s worth noting that the script shift operation number can only be anything between 1 and 8 bits due to encoded_shellcode size (word) in the decoder. Also, we’ve added XOR input value to the end of the encoded shellcode as terminator, so if XOR operation in the decoder results in zero that means hey stop decoding.

Generate encoded shellcode

Decoder

Now comes the decoding part, let’s write code that basically takes encoded shellcode produced earlier , decode it in reverse order and then execute

Compile and dump shellcode

Add it to final exploit

Demo time

Closing Thoughts

I believe learning shellcode encoding is vital to exploit development, in order to evade modern anti-viruses and/or intrusion detection/prevention systems. Please note all of the code in this post were tested on Ubuntu 12.04.5 LTS. Feel free to contact me for questions using the comment section below or just tweet me @ihack4falafel .

This blog post has been created for completing the requirements of the SecurityTube Linux
Assembly Expert certification:

http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/

Student ID:    SLAE-1115

Github Repo: https://github.com/ihack4falafel/SLAE32/tree/master/Assignment%204

Egg Hunter for The Win | Linux x86

Introduction

What is egg hunter? and why on earth would you need it? This post will answer these questions and discuss access() syscall, which will be a vital part of our shellcode. The post will then conclude by demoing a working egg hunter shellcode. Please note all of the work here is based off of Skape’s paper.

Egg Hunting

Egg hunting is a technique used to search Virtual Address Space (VAS) for pattern referred to by Egg that usually marks the start of our desired payload. Now you would probably be asking what if we hit an unallocated memory while searching for that pattern? Well, the answer is the process will SIGSEGV leading to a crash! To prevent this kind of behavior we will abuse access() syscall to hunt for our egg without crashing (more on that later). A good example of egg hunter use case is buffer overflow exploit with limited buffer size that won’t allow for large payloads such as bind or reverse shell, so we use egg hunter as stager to capture and execute payload of our chosen.

access()

access() syscall is used to check what permissions the calling process has to a file referred to by pathname, and it consist of two arguments as shown below

Two reasons you’d want to use access() syscall, the first being it doesn’t have lots of arguments thus less registers to initialize, which translate to smaller size. The second reason is we’re looking for function that doesn’t write to the pointer, cause that will defeat the purpose. We’ll use pathname pointer to preform address validation by observing the ZF flag, when the pointer hits unallocated memory it will return EFAULT, meaning hey this memory page is bad try the next one. Let’s identify access() ID “EAX”

Also its worth noting that we’ll need to repeat our egg twice (8 bytes) to avoid collision of egg hunter with itself, so the egg hunter will have to have two matches before it jumps to payload.

Final Shellcode

Now that we know what egg hunter and access() does, let’s write egg hunter code and then test it!

Let’s compile and dump shellcode!

Here’s the final egg hunter shellcode coupled with “/bin/dash” from exploit-db

Demo time!

Closing Thoughts

I don’t know about you but I find egg hunter method really fascinating and I’m glad I learned how to write my own! Thank you Skape for your awesome work! Feel free to contact me for questions using the comment section below or just tweet me @ihack4falafel . All of the code is available on on my github as shown in the link below.

This blog post has been created for completing the requirements of the SecurityTube Linux
Assembly Expert certification:

http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/

Student ID:    SLAE-1115

Github Repo: https://github.com/ihack4falafel/SLAE32/tree/master/Assignment%203

Creating Custom TCP Reverse Shell | Linux x86

Introduction

Reverse TCP shell consist of three syscalls, one for setting up socket that includes socket(), connect() functions. The second syscall is dup2() for file descriptors, and the last syscall execve() is used to spawn shell upon successful TCP connection. Please note that most of the functions mentioned here have already been covered in my previous blog post TCP Bind, hence this post will only focus on connect() function, which is the main difference between bind and reverse shell! The post will then conclude by tying all the pieces together to create working shellcode.

socket()

socket() is used to create medium for communication, for more information on this function please refer to TCP Bind blog post. let’s code!

connect()

This is where we’re going to spend most of our time, connect() function basically connect a socket referred to by sockfd file descriptor to an address specified by addr, and it consist of three arguments as shown below

sockfd is used to point to socket() created earlier, hence we will save its address to “ESI”. addr is where we specify our desired IP address and it’s broken down to three parts as shown below

Now sin_family is pretty self-explanatory so will go with “AF_INET”, which according to the first code block in socket() translates to “2”.  Also we’ll go with “1337” for sin_port and “192.168.80.129” for sin_addr both values needs to be pushed in network byte order “big-endian”, and here’s why RFC1700. The last argument would be addrlen which defines the size of addr in bytes, “16” in our case. Let’s identify ID for connect() function “EBX”

Back to the terminal

dup2()

dup2() is used to duplicate file descriptors, for more information on this function please refer to TCP Bind blog post. some more code!

execve()

execve() is used to execute a program, for more information on this function please refer to TCP Bind blog post

Final Shellcode

Now that we have all the pieces of the puzzle, let’s compile and test and then create python script that takes an IP address and port number and add it to our custom shellcode, here’s final code

Here’s graphical version of it

Demo time!

Let’s dump shellcode and then use it to create python script

Here’s the script

Running the script with same ip address and port will output exact same shellcode generated earlier!

Closing Thoughts

This post is continuation of TCP Bind one, hence did not have much information outside what we’ve already learned. Feel free to contact me for questions using the comment section below or just tweet me @ihack4falafel . All of the code is available on on my github as shown in the link below. Hope this post has been a good resource and I’d like to thank you for viewing!

This blog post has been created for completing the requirements of the SecurityTube Linux
Assembly Expert certification:

http://www.securitytube-training.com/online-courses/securitytube-linux-assembly-expert/

Student ID:    SLAE-1115

Github Repo: https://github.com/ihack4falafel/SLAE32/tree/master/Assignment%202