Unformatted Attachment Preview
۲۰۱٥/
۳/
۲۹
Exploits: Buffer Overflows, Pathname Attacks, and SQL Injections
Introduction
You are the security administrator for FrobozzCo, a large corporation with a great many secrets.
You have just come back from a muchneeded 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 "IdleSwap" 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
inhouse software is more secure than thirdparty software since FrobozzCo alone has access
to the sourcecode. To that end, when the Great Web Revolution hit and statistics relating to
https://www.isi.deterlab.net/file.php?file=/groups/CSCI443/CSCI443/61/index.html#tasks
14/20
۲۰۱٥/
۳/
۲۹
Exploits: Buffer Overflows, Pathname Attacks, and SQL Injections
frobnick production were needed by remote facilities, the higherups 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 boundchecked.
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.
https://www.isi.deterlab.net/file.php?file=/groups/CSCI443/CSCI443/61/index.html#tasks
15/20
۲۰۱٥/
۳/
۲۹
Exploits: Buffer Overflows, Pathname Attacks, and SQL Injections
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.
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 worldreadable). 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 inhouse
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 builtin 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 memoreading 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
https://www.isi.deterlab.net/file.php?file=/groups/CSCI443/CSCI443/61/index.html#tasks
16/20
۲۰۱٥/
۳/
۲۹
Exploits: Buffer Overflows, Pathname Attacks, and SQL Injections
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/cgibin/memo.cgi
If you have set up ssh tunneling to port 80 via local port 8118 (a good idea), the
memo application can be accessed at http://localhost:8118/cgibin/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 SUIDroot.
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
https://www.isi.deterlab.net/file.php?file=/groups/CSCI443/CSCI443/61/index.html#tasks
17/20
۲۰۱٥/
۳/
۲۹
Exploits: Buffer Overflows, Pathname Attacks, and SQL Injections
FrobozzCo has its own internal company credit union, FrobozzCo Community Credit Union
(FCCU). FCCU has an Internetaccessible webbased 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 malicious
user 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/cgibin/FCCU.php
If you have set up ssh tunnelling to port 80 via local port 8118 (a good idea), the
memo application can be accessed at http://localhost:8118/cgibin/FCCU.php
2. Exercise a remote SQLInjection 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
https://www.isi.deterlab.net/file.php?file=/groups/CSCI443/CSCI443/61/index.html#tasks
18/20
۲۰۱٥/
۳/
۲۹
3.
4.
5.
6.
7.
8.
Exploits: Buffer Overflows, Pathname Attacks, and SQL Injections
4. Explain why you can't create a new account or arbitrarily update account balances
(or show that you can).
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 stepbystep "walkthrough" of the
attack that a colleague could follow without assistance.
Fix the vulnerability in the FCCU application by adding input validation and either
character escaping or prepared statements.
Create a patch against the original source.
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.
Store the following files in /root/part3:
1. your memo
2. your exploit walkthrough
3. your patch
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.
https://www.isi.deterlab.net/file.php?file=/groups/CSCI443/CSCI443/61/index.html#tasks
19/20
۲۰۱٥/
۳/
۲۹
Exploits: Buffer Overflows, Pathname Attacks, and SQL Injections
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[13].sh and restore[13].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.
https://www.isi.deterlab.net/file.php?file=/groups/CSCI443/CSCI443/61/index.html#tasks
20/20