ISA 564, Laboratory I: Buffer Overflows

Transcription

1 ISA 564, Laboratory I: Buffer Overflows Lab Submission Instructions To complete the lab, you need to submit the compressed files (either tar or zip) using the GMU Blackboard system. Please make sure that you upload, before the due date, as a single compressed file containing all the individual task files and descriptions. Lab Description Shellcode is a set of foreign/injected bytes which is, in the original meaning of the word, native machine code that spawns an interactive shell. The term is now broadly applied to any process control flow redirection to enable the attacker s intentions, and not necessarily machine code. This lab is designed to familiarize the student with shellcode and its design. Initial Lab Setup We will conduct the lab with one VMware-based virtual machine (VM): VM1 (Kali Linux). You will need to download the following software on your local machine: VMware workstation or Player: VM1: o Select the 32 bit PAE for VMware image Getting Started We will conduct the lab on the VM. Turn on VM1, and sync with the course repository. cd Desktop If you have not cloned the repo, do so: git clone Else, update the repo: o cd course-material o git pull Ensure that you can compile code. cd ~/Desktop/course-material/shellcode make testsc If you have errors, run this and try again: o sudo apt-get install gdb build-essential gcc-multilib Directories will be referred by their path under ~/Desktop/course-material. For instance, alephone is ~/Desktop/course-material/alephone and bof is ~/Desktop/course-material/bof. Unless otherwise specified, assume alephone. 1

2 There are many protections in current compilers and operating systems to stop stack attacks like the one we want to do. We have to disable some security options to allow the exploit to work. Most of this setup is done, but when you compile manually, you'll need to set the compiler flags. Disable ASLR: sudo sysctl -w kernel.randomize_va_space=0 Setting this doesn't survive a reboot, so I created the file: /etc/sysctl.d/01-disable-aslr with the line: kernel.randomize_va_space = 0 Set the following compiler flags when you compile: -z execstack // Make the stack executable by turning off NX protection -fno-stack-protector // Remove stack smashing detection StackGuard -g // Enable debugging output 2

3 Task I: Understanding the Stack and Function Call Conventions Subtask I In the alephone directory, type the following command to generate the corresponding assembly file from the C source file: gcc -S -o example1.s example1.c Please try to understand how the original C file is converted to the assembly (.s) file. Note that the Aleph One s paper also contains the generated assembly code. Are your results different from Aleph One s? Why? (Task I.1) Draw the stack frame changes at the time that the function() is called (Task I.2). Subtask II Compile our second example example2.c with the following command: gcc m32 O0 -o example2 example2.c Execute the generated binary by typing:./example2. What are your results? And why? (Task I.3). You may consider drawing related stack frame changes to explain the result. Subtask III In our third example (example3.c) we aim to understand how the function return address can be inferred from a local variable and then manipulated. In this particular example, we first identify the stack return address of function(), then modify the value to skip the x=1 line (in example3.c), so that the example prints 0. Compile and run example3.c with the following commands: gcc -g m32 O0 -o example3 example3.c gdb example3 You can disassembly the main function within gdb: disassemble main. From the gdb output, you need 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. Note the location of the return address pointer in memory cannot be calculated explicitly, 3

4 because it is dependent on your memory stack. You may have to use trial and error to determine the offset between buffer1 and the return pointer. 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. Record the necessary code changes (Task I.4), execute:./example3, and capture the screenshot of the result (Task I.5). Task II: Shellcode Basics While Task I contains the basic concepts behind modifying the return address (and consequently the execution flow), Task II introduces how to prepare shellcode that will be executed after hijacking the execution flow. Note that shellcode is essentially machine code that will be recognized and executed by the CPU. Shellcode is a bit of a misnomer, due to historical reasons it used to be primarily for launching interactive shells. In our experiments, we will be using the following C program (shell_test.c) to test the shellcode, you can find it under the alephone directory: #include <stdio.h> char shellcode[] = ""; /* global array */ int main (int argc, char **argv) { int (*ret)(); /* ret is a function pointer */ ret = (int(*)())shellcode; /* ret points to our shellcode */ /* cast shellcode to function */ (int)(*ret)(); /* execute it as a function */ exit(0); /* exit() */ } A typical way to write the shellcode is to prepare a C program with the same features. Then we can compile the C program and the generated assembly instructions can be used for our shellcode purposes. As an example, consider the example program (shellcode.c): #include <stdio.h> int main(void) { char *name[2]; name[0] = "/bin/sh"; name[1] = NULL; execve(name[0], name, NULL); } You can compile the program and obtain its assembly instructions. Make sure you have a clear understanding of the assembly code, using the AlephOne paper as a guide. gcc m32 O0 -o shellcode -ggdb -static shellcode.c 4

5 gdb shellcode disassemble main disassemble execve We are going to use this code to execute a shell from a victim program. However, we want to make sure our process will quit normally after our shellcode is executed; for instance, in case execve fails. Otherwise, the computer could continue to execute data in memory, likely causing a core dump or segmentation fault. View the assembly translation of the exit command so that we can use this to stop the execution of our shellcode after the execve call. Do this by obtaining the corresponding assembly code of exit.c. gcc m32 O0 -o exit -ggdb -static exit.c gdb exit disassemble _exit Now, we must prepare the hex representation of the binary code to use when we eventually inject it into the vulnerable program s memory. When complete, we will be able to use testsc.c to execute our binary code. 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. Compare these until you notice and understand how that the essential components of shellcode and exit have been placed into shellcodeasm.c. gcc m32 O0 -o shellcodeasm -g -ggdb -static shellcodeasm.c gdb shellcodeasm disassemble main Our intention is now to copy these assembly commands into a string that we can use to inject into vulnerable processes. To do this, you must use gdb to show the binary machine code representations of the assembly code in shellcodeasm.c. In gdb use 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). Use x/48bx main to get the first 40 bytes in main. We can now test our shellcode by using a wrapper program to place it in memory and execute it. Conveniently, the machine code values determined from above have been placed in a character array in testsc.c. gcc -m32 -O0 -fno-stack-protector -z execstack -o testsc testsc.c./testsc 5

6 After running this, you should have access to a shell prompt (on Kali the sh prompt is #). While this exploit works, because we are storing it as an array of characters and the NULL character in our string could potentially cause problems. To solve this problem, we rewrite the assembly code to remove all NULL bytes (testsc2.c). Type the following commands and you should have a shell. gcc -m32 -O0 -fno-stack-protector -z execstack -o testsc2 testsc2.c./testsc2 Please explain why it is important to eliminate NULL characters (Task II.1) and how we can modify the assembly code to remove null characters (Task II.2). Note that the current testsc2.c file does not contain any explanation. Please add the corresponding explanation via comments for testsc2.c (Task II.3). The needed documentation should be consistent include what assembly mnemonics are executed and a short comment about what an instruction or groups of instructions are doing (Hint: objdump -D). What would be the result of directly executing./shellcodeasm? And why? (Task II.4) Task III: Advanced Shellcode As mentioned earlier, shellcode can contain functionalities other than spawning a simple shell. In the alephone directory, there is a file testsc3.c, which, unfortunately, is not documented. Please document this file, a la Task II.3, and explain what additional features are contained in the shellcode (Task III.1). There is also a file testsc4.c, which contains packed, or obfuscated shellcode, document how this encoding works, what the shellcode output is, and why an attacker would pack shellcode (Task III.2). For each of these, execute them and capture a screenshot to demonstrate how the shellcode can be used (Task III.3). For instance, show me a dialogue of interaction with the shellcode or pre/post shots that demonstrate your shellcode was successful. The Metasploit framework can also be used to generate the shellcode. We will use the msfconsole interface. For example, the following commands creates a port-binding shellcode in Linux. root@kali:/desktop/course-material/alephone# msfconsole msf > use linux/x86/shell_bind_tcp msf payload(shell_bind_tcp)> generate h msf payload(shell_bind_tcp)> generate t c Put this output into the file testsc5.c. Test that it works, when running connect to it with nc Please analyze and document the shellcode, a la Task II.3 (Task III.4). 6

7 Submission Checklist Task I (25 points): Answer those questions in Task I.1, I.2 I.3, I.4, and I.5. Task II (30 points): Answer those questions in Task II.1, II.2, II.3, and II.4. Task III (40 points): Answer those questions in Task III.1, III.2, III.3, and III.4. Lab survey (5 points) References [1] Aleph One, Smashing the Stack for Fun and Profit. Phrack Magazine, Volume 0x07, Issue 49, File 14of 16, November, 1996 [2] Avicoder, Smashing the Stack for Fun & Profit : Revived, February,