Exploits: Buffer Overflows, Pathname Attacks, and SQL Injections Solution

You are the security administrator for FrobozzCo, a large corporation with a great many secrets. You have just come back from a much-needed four week vacation in West Shanbar, only to find that FrobozzCo has been having some serious security issues with 3 of its most important servers! In order to do everything you need, you've prepared a test environment on DETER with the software installed.

Assignment Instructions
Setup

This exercise consists of three separate exercises, with three separate submissions. However, everything you need is in one DETER experiment.

    1. If you don't have an account, follow the instructions in the introduction to DETER document.

    2. Log into DETER.

    3. Create an instance of this exercise by following the instructions here, using

/share/education/SoftwareExploits_UCLA/exploits.ns as your NS File.

In the "Idle-Swap" field, enter "1". This tells DETER to swap your experiment out if it is idle for more than one hour.

In the "Max. Duration" field, enter "6". This tells DETER to swap the experiment out after six hours.

    4. Swap in your new lab.

    5. After the experiment has finished swapping in, log in to the node via ssh.

Make sure that you save your work as you go. See the instructions in the submission section of this exercise for information about save and restore scripts. Save any changes you make to the sourcecode, your patches, memos, etc. in your home directory.






You will probably want to set up port forwarding for tunelling HTTP over ssh so you can test the web applications with a browser on your own desktop.


Tasks

Part 1: Buffer Overflows -- The Webserver

FrobozzCo has a longstanding tradition of reinventing the wheel whenever possible. As the old saying goes, "Why use something great that someone else made when you can use a mediocre thing you made yourself?" Additionally, the prevailing belief in management is that in-house software is more secure than third-party software since FrobozzCo alone has access to the sourcecode. To that end, when the Great Web Revolution hit and statistics relating to frobnick production were needed by remote facilities, the higher-ups at FrobozzCo insisted that their engineers write a webserver daemon, and it has been dutifully (if unspectacularly) serving web pages for many years.

Unfortunately, it is clear that someone has "rooted" (i.e., gained unauthorized superuser access to) the server; a number of root access files were copied out over the Internet and then the server started sending tons of spam. Fortunately, no data was lost, but the intruder had full control of the server and it is still unknown how they got in. You are convinced there is an exploitable buffer overflow bug in the web server software, but your boss, William H. Flathead III laughed off your suspicions saying, "I wrote the web server software -- and I'd never have made that mistake!"

Nevertheless, he suggests you investigate the possibility of a buffer overflow, "just to be sure."
He asks you to produce a one page memo with an attached working demo that targets a specific buffer overflow (should one exist) causing the server to crash. This should be an intentionally exploitable hole in the code and not simply a robustness issue. If you find a vulnerability, your boss wants a patch to fix it. Finally, he wants to know how to clean up this mess -- how severe is this specific compromise? How can we restore the system to a safe state?

Buffer Overflow Tasks

    1. Load your Exploits experiment in DETER.

    2. Find the buffer overflow in the fhttpd webserver code.

 The sourcecode is in the directory /usr/src/fhttpd.

    3. Exploit the overflow, causing the software to crash.

Please note: you may be able to crash the software in other ways -- we are only specifically interested in a buffer overflow caused by input that is not properly bound-checked.

See RFC 1945, which covers the HTTP protocol. In this document, you can learn about what the HTTP API looks like and how to send commands to web servers manually.

    4. Create an executable program (script or binary with sourcecode), demonstrating your exploit. We've created a skeleton exploit in /root/exploit1.sh and /root/payload1. Edit these with a text editor.

    5. Fix the buffer overflow bug in the fhttpd sourcecode and create a patch against the original.

To compile the code:


cd /usr/src/fhttpd


sudo make


To install and run the code:


sudo make install (this copies in your new binary and restarts the default server on port 8080)

See the tools section of this document for instructions on diff,patch, and other utilities.

See also the section on restarting servers.


    6. Write a ~1 page memo:

        1. Describe the security flaw you found, how you fixed it, and how your demo exploit works. (The memo itself should quote as little sourcecode as possible; for longer sections, refer to filenames and line numbers in the original or your attached patch.)
        2. Considering fhttpd alone, include in your memo:

            1. An evaluation of the seriousness of the breach

            2. A recovery plan for the server. (Is it enough to fix the flaw? Why or why not?)

            3. Any other observations or thoughts you might have.

    7. Put the following files into in /root/part1:

        1. your memo

        2. your working demo with instructions

        3. your patch

    8. Use the scripts described in the section for creating a submission tarball.
    9. Part 2: Common Filesystem Exploits -- The Memo Software

Something else is rotten in the state of FrobozzCo, and this time it is an inside job. FrobozzCo has an internal server that it uses for disseminating official company memoranda. All employees have access to this server via a web interface, but it is not reachable from the Internet without going through a firewall, and the only accesses in the logs have come from internal addresses. Somehow, for the last several weeks, user accounts on the server have been getting hijacked one by one. It seems clear: someone obtained and is "brute forcing" the password file and is using the newfound access to read private data. How could this be happening?

Traditional UNIX systems kept their hashed passwords in /etc/passwd where they were encrypted (but world-readable). This made it trivial for an unprivileged user to feed the password file into a password cracker (sometimes on the same machine!) and obtain other authentication -- sometimes root or other privileged accounts. Modern unices combat this vulnerability by keeping the password portion in a file called /etc/shadow, where only root has access to it. Your system uses an /etc/shadow file, so you know that regular user accounts do not have access to password information. Furthermore, there is only one piece of in-house software on this computer, and it is not written in a language like C that is susceptible to buffer overflows; it is written in a scripting language with built-in memory management that is not vulnerable to that kind of attack. Yet, somehow someone has been able to read private data files like /etc/shadow using the memorandum software. This is bad.

You are sure it must be somehow related to the memo viewing application, because all third-party software is up to date. The memo system works like this: users can log into the system via ssh or access the system via NFS and can publish memos by writing files into the memo directory in their home directories. Then, the memo-reading CGI (which is setuid root ostensibly so it can read multiple users' memo directories) searches the memo directories and publishes a list of memos available for reading. A user can then use a web interface to select one of the memos from a list and read it.

Your boss, William H. Flathead III is skeptical that the memo reader is the problem, because he wrote the memo reading program when he was a summer intern 15 years ago. Still, just in case, he asks you to produce a 1 page memo, working demo of the exploit, and a patch for the memo reading software, should a vulnerability exist. Either way, he also wants to know how to clean up this mess -- how severe is the compromise? How can we restore the system to a safe state?

Pathname Attack Tasks

    1. Load your Exploits image in DETER. (You don't need to reload it if it is already active.). Note: this attack needs to be launched against Apache webserver since fhttpd cannot serve binary content.

    2. Find the directory traversal vulnerability in the memo.cgi code.

The sourcecode is located at /usr/lib/cgi-bin/memo.cgi


If you have set up ssh tunneling via port 80 (a good idea), the memo application can be accessed at http://localhost/cgi-bin/memo.cgi

    3. Exercise a remote vulnerability in memo.cgi to read the private file /etc/shadow

    4. Create an executable program demonstrating your exploit. Your program should display or save /etc/shadow. We've created a skeleton exploit script in /root/exploit2.sh. Edit it with your favorite text editor.
    5. Fix the flaw and create a patch of your new code against the original. Your fix should add input validation and make memo.cgi non SUID-root.

This will force you to redesign the application's back end, such as moving directories, changing permissions, creating groups, possibly changing how or where users create/edit memos, etc., but should not change the appearance or general function of the application.

Users should not be able to delete each others' memos, but the memos themselves are not private.

    6. Write a ~1 page memo:

        1. describe the security flaw you found, how you fixed it, and how your demo exploit works. The memo itself should quote as little sourcecode as possible; for longer sections, refer to filenames and line numbers in the original or your attached source.
        2. Considering memo.cgi alone, include in your memo:

            1. A recovery plan for the server, answering: How serious was this breach? What should be done with the server in order to secure it?
            2. An explanation of why it is not sufficient to simply make sure that the pathnames

start with /home/username/memo/ or /root/memo/

            3. Any other observations or thoughts you might have.

    7. Store the following files in /root/part2:

        1. your memo

        2. your working demo with instructions

        3. your patch

    8. Use the scripts described in the section for creating a submission tarball.

Part 3: SQL Injection -- FrobozzCo Credit Union

FrobozzCo has its own internal company credit union, FrobozzCo Community Credit Union (FCCU). FCCU has an Internet-accessible web-based application that allows employees to access their paychecks and pay bills via a money wiring system. There are very few bank employees, and they use a a special administrative interface that runs on a different system that is not network accessible. In true FrobozzCo fashion, the public banking software was written in house by the CTO's nephew (who is a nice kid but not the brightest candle on the cake).

As it turns out, a lot of money has been disappearing from the credit union while you've been gone. It looks like someone has figured out how to force other accounts to wire money... to an anonymous bank account in the Cayman Islands! Worse yet, several employees have had serious identity theft problems of late -- clearly someone has access to personal information and you have a hunch it's all coming from this server. To top it all off, the company itself is showing a deficit of $32,767 and it looks like it was somehow drawn through FCCU.

In a surprising display of foresight, your predecessor installed a network monitor watching the FCCU server. However, you are shocked to find out (from the network monitor and server logs) that nobody has logged into the server directly -- in fact, the only interaction that anyone has had with the server has come through the Internet facing web interface. It looks like insecure software is to blame, again.

You assume that there must be one or more vulnerabilities in the code that interfaces with the SQL database -- in the FCCU software, the directory, or both -- and that somehow a malicioususer is able to make the system do something it's not supposed to, like write checks. Worse yet, it seems like the attacker has managed to view private information like social security numbers, birthdates, and so on. You've heard about a class of attacks called "SQL Injection," and it seems likely that this is the kind of exploit being used.

Surprisingly, your boss agrees with you and instructs you to produce a one page memo, a detailed transcript demonstrating the exploit, and a patch for the software. Additionally, he also wants to know how to clean up this mess -- how severe is the compromise? How can we restore the system to a safe state?

SQL Injection Tasks

    1. Load your Exploits image in DETER. (You don't need to reload it if it is already active.) Note: this attack needs to be launched against Apache webserver since fhttpd cannot serve binary content.

The sourcecode is located at /usr/lib/cgi-bin/FCCU.php


If you have set up ssh tunnelling via port 80 (a good idea), the memo application can be accessed at http://localhost/cgi-bin/FCCU.php

    2. Exercise a remote SQL-Injection vulnerability to perform these unauthorized tasks on the SQL server:

        1. Show how you can log into a single account without knowing any id numbers ahead of time.
        2. Show how you can log into any account you like (without knowing any id numbers ahead of time).

        3. Make some account (your choice) wire its total balance to the bank with routing number: 314159265 and account number: 271828182845
        4. Explain why you can't create a new account or arbitrarily update account balances (or show that you can).
    3. Create an exploit transcript in the file /root/exploit3.txt, including your answers and how you completed the above attacks.

 document all SQL Injection strings you used, including which pages and in what order.

This is not an executable script, but should be a step-by-step "walkthrough" of the attack that a colleague could follow without assistance.

    4. Fix the vulnerability in the FCCU application by adding input validation and either character escaping or prepared statements.

    5. Create a patch against the original source.

    6. Quoting as little sourcecode as possible, write a ~1 page memo, including:

        1. A description of the security flaw in the FCCU application

        2. A description of how you fixed the flaw. How does your fix solve the problem?

        3. Considering the FCCU application alone, describe a recovery plan for the server, answering:

            1. How serious was this breach? Could attackers gain root access through this vulnerability?

            2. What should be done with the server in order to secure it?

            3. Include any other observations or thoughts you might have.

    7. Store the following files in /root/part3:
    8. your memo

        1. your exploit walkthrough

        2. your patch

    8. Use the scripts described in the section for creating a submission tarball.

What can go wrong

Some helpful advice:

For Part 1, make sure you are attacking fhttpd on port 8080 (or whatever port you are manually running it on) and not Apache, which is running on port 80. (Apache's vulnerabilities are much harder to find.)

For Part 2 and Part 3 make sure you are launching attacks against Apache webserver. The vulnerabilities we target are not in the Apache code.


Extra Credit

Remote Execution

For Part 1, the assigned task is to simply crash fhttpd with an attack payload. However, it is possible to inject code via the payload and not crash fhttpd but take over the application. Since fhttpd runs with root privileges, you can execute anything on the system if you manage to take over the program. For extra credit, do #1 and/or #2 below, and then #3:

    1. Create and successfully execute a remote execution exploit using the vulnerability in fhttpd. This could be as simple as writing a file to the system.

    2. 0wn the box: Create a remote shell you can send commands to, add a login user with root access, or some other reliable remote access facility.

    3. Draft a short writeup describing the steps you took to create the exploit and what you learned in the process.

Submission Instructions

For this exercise, you will submit 3 tarballs; one for the buffer overflow, another for the pathname attack, and the third for the SQL injection. Separating the work into three tarballs makes it easier to deal with the swapin/out nature of DETER.

Accordingly, there are 6 scripts, submit[1-3].sh and restore[1-3].sh in /root/ on the exploits host for creating and restoring those tarballs. In contrast to the permissions exercise, the restore scripts do not have any options -- they will automatically overwrite the particular files they are meant to restore. So make sure that you really want to restore your files before you do it!

submit1.sh and restore1.sh

submit1.sh will back up:

the sourcecode directory /usr/src/fhttpd/
/root/exploit1.sh


/root/payload1


the /root/part1 directory (where you should put your memo for part 1)


restore1.sh will restore those files to their original locations, automatically overwriting whatever is there.

The scripts for parts 2 and 3 work like submit1.sh and restore1.sh, with the following exceptions:

They back up/restore /usr/lib/cgi-bin/memo.cgi or /usr/lib/cgi-bin/fccu.php instead of the

fhttpd sourcecode directory.

They back up/restore the appropriate partN directory part 2 does not require a payload

for part 3, instead of exploit3.sh and payload3 there is a transcript exploit3.txt for you to fill in.


Submit all three files to your instructor.