Over The Flow The Simple Way

Intro 

This article is dedicated to simple exploitation and exploit fixation. During this article we will reproduce an exploit with disabled Data Execution Prevention (DEP) that concerns Free float FTP Server Buffer Overflow Vulnerability found here, the vulnerable software can be downloaded from here. I will go through the Buffer Overflow Exploitation step by step to show the exploit procedure. The Free Float Ftp Server does not need any installation, it  is  just a simple FTP server.. But before we do anything like that we would have to explain how to disable the DEP from Windows 7 (I am suing windows 7).

Completely Disabling DEP

In order to successfully reproduce the exploit in your Windows 7 SP1 EN you would have to either completely disable DEP or exclude the Free Float FTP server executable from using DEP. To completely disable DEP you:

1. Click Start, and then click Control Panel.
2. Under Pick a category, click Performance and Maintenance.
3. Under or Pick a Control Panel icon, click System.
4. Click the Advanced tab, and in the Startup and Recovery area, click Settings.
5. In the SystemStartup area, click Edit.
6. In Notepad, click Edit and then click Find.
7. In the Find what field, type /noexecute and then click Find Next.
8. In the Find dialog box click Cancel.
9. Replace the policy_level (for example, "OptIn" default) with "AlwaysOff" (without the quotes).

WARNING: Be sure to enter the text carefully. Your boot.ini file switch should now read:

1. /noexecute=AlwaysOff
2. In Notepad, click File and then click Save.
3. Click OK to close Startup and Recovery.
4. Click OK to close System Properties and then restart your computer.

This setting does not provide any DEP coverage for any part of the system, regardless of hardware DEP support.

Verifying DEP is Completely Disabled

1. Click Start, and then click Control Panel.
2. Under Pick a category, click Performance and Maintenance.
3. Under or Pick a Control Panel icon, click System.
4. Click the Advanced tab.
5. In the Performance area, click Settings and then click Data Execution Prevention.
6. Verify that the DEP settings are unavailable and then click OK to close Performance Settings.
7. Click OK to close System Properties then close Performance and Maintenance.
   

Adding DEP exclusions

In order to do that you would have to go:

Computer -> Properties -> Advanced Settings -> (Tab) Advanced -> Performance -> Settings -> (Tab)  Data Execution Prevention -> (Text Box) Turn On DEP for all programs and services except those select: 

Note: This means that all other system dll are still protected from DEP?

Calculating the EIP

First we will have to calculate the EIP address, in order to do that I will use the very well know tool from metasploit named pattern_create.rb.We will start with a size of 1000 characters (generating that way a 1000 unique character sequence pattern). So I will do a cd /opt/metasploit/msf3/tools and then type ./pattern_create.rb 1000. After that I will inject the string into the application (the vulnerable variable USER from float ftp server) using the following simple Python script:

Note: Notice how simple is the script, you practically do not even have to know how to program. See the variable buff assigned the none repeating pattern with 1000 characters. Then we inject to the ftp variable USER the string. The next thing to do would be to use the Olly Debugger v1.0  to see the internals of the program (do not ever but ever, but ever use Olly Debugger v2.0 it is real a crap).

This what we will get back from the Python Shell as an output:

Note: The FTP Server spits back all the pattern, interesting. But is not important for our experiment.

So I run the debugger and attach the vulnerable FTPServer:

Note: Now from the Debugger after I injected the generated string I see this. This means that out pattern as expected overwrote the EIP. And using the pattern_offset we will calculate the exact position of EIP.

Important Note:We do ./pattern_offset.rb 37684136 which will give us the number 230. Now this number is important.So we can do later other calculations. In order to gain access to the offset utility you would have to do a cd to the same directory with the pattern_create.rb tool. The hex number used with the offset tool was copied from Olly debugger by right clicking and coping the address of the EIP register.

Verifying that the EIP address was overwritten

In order to verify that we successfully managed to overwrite the EIP address I will add 230 A's to cover the initial offset and then 4 B's simply to overwrite the EIP address and then I will fill the rest of the stack with C's. So the pattern would be AAAAAAA........ BBBB CCCCCCCCCC..... where the length of  A's is 230, the length of B's is 4  (all addresses in 32 bit architecture are 4 bytes long) and the length of C's is 1000 - (length of 4 B's +  length of 230 A's) so we would fill all the stack with the right amount characters (if you do not do that the server might not crash!!!) the overflow was initially detected by the author of the original exploit (meaning the 1000 characters) so we do not have to do anything myself, plus if we use the shellcode from the author of the original exploit we know that the shellcode fits into the stack (in case we had to write our own shellcode, we would have to recalculate the ESP available space for example). So the following again simple Python script will map and verify that the EIP address was overwritten successfully (this time the 4 B's will overwrite the EIP address):

 Note: See again how simple and elegant is the script that maps the EIP register in this example.

This is what the Python Shell spits back:

 Note: See how the injected string looks like when bounced back from the FTPServer.

 This how the FTPServer look like in Olly Debugger v1.0 after the string injection (the FPU section):

 Note: Notice that looks really bad.
 

  
Note: This is the error message window popped up when we try to continue to execute the FTPServer after injecting the string described before.The EIP address was successfully overwritten with our 4 B's

Finding the JUMP address

In order to inject some type of shellcode to a vulnerable software you would have to now a good jump address to redirect the execution flow. What is a jump address is out of scope of this article. There is a  very easy way to locate jump addresses. in the main panel of the FTPServer by simply doing a Debug ->  Restart and wait, after the program restarts I go to the executable section identified by clicking the E button on top of the Olly Debugger v1.0:

 If we double click into the USER32.dll we see:

Note: This is how USER32.dll looks like in CPU.

Next thing if you do a right click search for all commands you get this (inside the USER32.dll):

This is what you get after the search of jmp esp:

Note: From the above jmp addresses I will choose the 76604E5B.

Injecting the Shellcode

Know we know how to overwrite the address of the EIP, we have a shellcode (copied from the original exploit, written for Windows XP EN), now I am going to add a few nops before the shell and inject the shell. So the final exploit looks like that:

Note: This is how the final exploit looks like cool e?

If we have a look at the Python shell:

Note: See how the injected string with shell looks like.

Now lets have a look at some parts of the exploit to see how it works, the first part is A's part:

Note: Here you can understand how useful the information was from the pattern_offset.rb. This helps us push the shellcode to the right place.

The second interesting part is the nops operator:

Note: The NOP opcode can be used to form a NOP slide, which allows code to execute when the exact value of the instruction pointer is indeterminate (e.g., when a buffer overflow causes a function's return address on the stack to be overwritten). Plus it allows to the shellcode to decode properly.

The third most interesting part of the code is this:

Note:  If you see at the beginning of the exploit we imported from the struct package the function pack which helped us to convert our address to Little Indian. Little Indian" means that the lower-order byte of the number is stored in memory at the lowest address, and the high-order byte at the highest address.  The forth line of the exploit code that is interesting is this one:

 

Note: In this part we see our malicious buffer.The final size of the buffer is again 1000 characters as originally identified.

Testing our Exploit

In order to test my exploit I will run a netstat -ano 1 | findstr 0.0.0.0:21 to monitor that the FTPServer is running and listening at port 21 as planned and also run a netstat -ano 1 | findstr 0.0.0.0:4444 to make sure that the shellcode is running as it would suppose to (listening for a binding shell at port 4444).

The ftp server monitoring window:

Note: See the the netstat is running every 1 second.

And kaboom shellcode monitoring window shows that the exploit was successfully executed:

The telnet window to interact with the FTPServer bind shell:

Note: See that the telnet remote shell has access to the same folder with the FTPServer. The exploit continues to run even after the FTPServer was killed!!!

Epilogue

None DEP exploits are easy to write even when you do not know assembly. Fixing and replicating is mush easier than thought now days. All the knowledge is out there, you just have to look for it.Shellcodes can obviously be generated also from metasploit. This is a very good example on how you can experiment with jump addresses and different shellcodes generated from metasploit or downloaded from other sites (even though I do not recommend that)

References:

http://www.exploit-db.com/exploits/15689/
http://www.zensoftware.co.uk/kb/article.aspx?id=10002
http://en.wikipedia.org/wiki/NOP