UW Computer Security Research and Course Blog

Since many people are probably busy working on or wrapping up lab 2, I thought it would be a good time to post a security review based on some interesting findings that I discovered in the course of completing the lab. My search began with version 5. When I began attempting version 5, I became increasingly frustrated to the point where I believed that version 5 was completely secure from cross site scripting and the only way to break it for extra credit was to break the server itself. So that’s what I attempted.

One of the basic things that I found out about lab 2 while working through the different versions was the structure of the cookie. The cookie itself, seemingly a random combination of letters, turned out to be a base 64 encoded string. The basic form of this string was “d|cse net id|version number|large hexadecimal number|random decimal number”. After questioning Alexei about this in section, I learned that the large hexadecimal number was actually a salted hash using a private key. Due to the salted nature of the hash, it seems very secure to attack. I learned more about the workings of the lab and the cookie itself in my explorations of the server. Another interesting but unsuccessful discovery was that script could be injected into the version field for all versions. This field was not filtered, even for 5, but was not correctly recognized so that I only got a cookie with a blank version field for my efforts.

To start, I went to the yummy login page to try and take advantage of any SQL injection bugs that lurked within. Unfortunately, I found this part of the page to be locked down and my attempts were to no avail. Another attempt I made was using what are called rainbow tables (precomputed hash values to take advantage of a time space tradeoff—you use a lot of space but it takes much less time) to try to crack the hex hash in the cookie so that I could create my own fake cookies for whichever version I desired. I found out that the salted hashes prevented this attack. I decided that I had to find something else outside of what the web server presented and break the server itself. I needed to hack the Gibson. To attempt breaking the server, I began at the logical starting point by seeing what network-accessible processes were running on the Yoshoo server. In order to figure this out, I took advantage of the nmap port scanner. For those unfamiliar with it, nmap is a useful tool that is able to take advantage of multiple techniques to coerce a server into revealing important details like what services are running on what ports (and the service version numbers), operating system details, and other interesting information.

What nmap revealed was not encouraging. The server was running a few services (MySQL, Apache, SSH, and a few others), but all the services were up to date and therefore had no existing exploits. I tried to connect to MySQL via default accounts and passwords, but was unsuccessful. Similar attempts with SSH also proved futile. I decided my last resort was to probe further into Apache to find some leverage.

Besides weak passwords, default configurations are another prime cause of security problems. That was the case here. One of my first explorations, exploring the availability of default folders, provided supremely fruitful. Some of the folders that Apache makes available by default are home, icons, images, tmp and (most importantly to me) logs. After testing the home directory and finding it was available, I became excited and hoped for perhaps a stored key that would allow me to create my own cookies. No such key was found. After making my way through the different directories and finding only useless files that didn’t help me in the least, I tried to open the tmp directory. To my surprise, this directory was available and full of a large number of regular and error logs. Looking through the error logs, I didn’t find much information that seemed to be of any benefit. Looking into the execution logs from the beginning, I began to find some interesting clues.

One of the first things I found (irrelevant to the lab itself) was a large number of vulnerability scans. These scans, from two primary user agents, tested for a myriad of different pages that could be available by default and could be used to exploit the server itself. Prominent among these pages that the scanners looked for were “phpmyadmin” and administration pages. Although irrelevant to my search, I found it interesting how dangerous default settings could be.

As I moved through the logs by date, I started to see TAs performing XSS vulnerabilities. The server was logging all GET and POST requests, so I could see all the URLs that were being used. A little further on, I realized that these logs were the Holy Grail that I was looking for. The setup of the lab was done in such a way that all query strings to Yoshoo were logged along with the IP address of the user. To give the cookies out, there was a specific script called “girlscout.php” that took a cookie and a successful XSS URL and executed it so that the user could get a cookie for their successful attack. Because only successful URLs were listed, I was easily able to see all the correct answers for the different versions as well as the cookies that were given out for these answers. Luckily, I signed my ethics form so I didn’t carry out any malicious actions and instead alerted the staff so that these issues could be fixed. Everything is fixed now, so this vulnerability has been closed.

Assets:

• Grade access: This would allow anyone to access and change a security student’s grade for this project.

• IP addresses: IP addresses, possibly of home computers, could allow tracking or some other invasion of privacy in addition to directed attacks.

• Script URLs: The URL for each script that a person uses is available so that the scripts could be manipulated and taken advantage of.

• Answers: The answers for each part of the assignment are available so that the students would not need to actually complete the lab.

Adversaries:

• The Cheater: With grades on the line, answers to all the solutions could be available and a student would be able to easily copy answers and cheat to complete this lab.

• The Malicious Attacker: With the IP address and script URLs available for each student, a malicious attacker could attack individual users in ways that goes beyond just the lab to real damage of other systems.

• The Grade Resetter: With the authentication cookies available for every answer (and specified in a way that is easily obvious and scriptable because of the girlscout script), a malicious student could blow the curve by resetting everyone’s grades to 0 for each part of the lab (unfortunately negative values are not allowed, I tried).

Threats:

• Because the logs match up IP address to student ids (through the scripts that each student must run from their abstract account), one can identify personal computers (if they aren’t using lab computers) in order to attempt to further exploit these computers or do further malicious things directed at specific users (DOS, tracking or privacy invasion, etc.).

• The logs contain the addresses of scripts that everyone must use to store the cookies. These will most likely either write a file or email the user. It is possible on some scripts to read them and obtain information like the user’s email. It is also possible to DOS the user by email bombing them (sending a large number of requests to the script) or fill up their hard drive with tons of files. The really malicious thing to do would be to send the emails every few minutes randomly. Then the user wouldn’t be able to just select all and delete and would have to go through them manually. It would also make things difficult if the user intended to still use the script for the project because they would then need to go through the emails looking for the right email. Especially malicious: make the email contents look like legitimate cookies with base 64 info so the user isn’t sure if they are real. The user would have to either decode each cookie or try multiple, if not all, cookies.

• For anyone looking at the logs, they now know all the correct answer to each version because of the girlscout script. The correct answers can be modified and reused so the attacker can get their own project done without any actual work.

• The POST number in the logs for a submission to yummy can also be found as the last seemingly random number in the cookie. This gives more information for a malicious user to create fake cookies that are accepted for the lab.

• Along with the correct answers are cookies for all the right answers. All grades can now be changed. This could easily be scripted so that nobody could get a grade above 0 for any part of the project. This is one thing I was particularly excited about finding. The project can effectively be invalidated so that results would need to be evaluated by hand by the TAs or discarded entirely (after everyone puts in a lot of hard work).

Weaknesses:

• One weakness of this lab is the lack of filtering in the version numbers. This could be used for getting a user to click what they think is a safe query (for an assumed safe version like 5). Also, this allows exploitation of any type of XSS vulnerability across all versions. Finally, this weakness doesn’t allow a user to get credit for a legitimate XSS attack against the server.

• The primary weakness for lab 2 was default settings. The default permissions allowed me to view the logs directory so that I could gain access to all assets.

Defense:

• In order to defend against XSS attacks in the version number, user input filtering similar to the filtering done in version five could be done for all version input.

• In order to defend against the primary settings weakness, the primary defense is being assertive about how your server is set up. Talking with Alexei, I was informed that the CS staff set up the server in a way that left these default settings in place and made the system vulnerable. Always changing default settings and allowing minimal permissions would help eliminate this issue.

• In order to avoid this particular situation, less information could be logged so that the GET requests are not stored. This would pretty much eliminate this vulnerability because the answers and cookies would not be available from the logs.

• In general, running the latest version of all software helps prevent exploitation of any vulnerabilities that may exist. This was the case for lab 2—no software vulnerabilities were available for exploitation.

Although the system may still have holes, I did not investigate any others. Even in a security class, human error can creep in and lead to vulnerabilities. Although this issue was fixed, this security class will surely be given again and there are always students looking to find some other bug to break the system. Throughout this exercise, I found the lab to be mostly secure, but one hole can give everything away to an attacker. The system is only as strong as the weakest element.