CSE 484 Lab 3

Courtesy of xkcd ~ http://xkcd.com/149/

General Description

In this lab you'll be rooting a machine, reverse engineering a protocol, cracking a password, and getting away with it.

The Story - Corporate Sabotage

You're a freelance attacker, and you've been hired for a mission by the mysterious Yoshoo corporation. This is a faceless, international syndicate controlled by an unknown group of grad students. Yoshoo has recently learned that its doohicky software business has competition from the rising Anozira corporation. Yoshoo has tried to take Anozira out of business by seeding torrent sites with Anozira software. However, Anozira countered by requiring that each product has a unique product key - each of which costs $100,000. Yoshoo has hired you to infiltrate Anozira, gain access to the license generating software, and pass licenses as required back to Yoshoo.

You've managed to get hired by Anozira as a software engineer. In the past two days you've found out that Anozira is fairly protective of its license generating code; it's stored on some far, remote server (called morris.cs.washington.edu) that you don't have any access to. However, you learn that your boss administers a server in his office (called CSE484-Lab3), which has a license client on it. The client is called client, and seems to be able to connect to the license server. From a social engineering attack (more commonly known as casual conversation), you learn that in order to run the client, you need administrative privileges on CSE484-Lab3; you guess that it's probably located in /root. As expected, your boss doesn't trust you and gives you a meager user account on CSE484-Lab3. From social engineering, you learn the following:

• client can connect to the license server, but can only see a list of currently issued keys and get info about the current username. It cannot request new keys... yet.
• The license server has a built-in functionality to generate new keys. Your coworker thinks that it should be really easy to extend the client to query the server for a new key once you discover the protocol by which they communicate. Being a security expert, you know that security by obscurity rarely works - you get excited.
• One of the software engineers tells you that he thinks that part of the protocol includes a cryptographically transformed version of a password with some pepper from a dictionary of words located in /root
• The boss locks the door to his office when he goes home at 5pm, but the lock looks easy to pick

Your plan of attack: (1) gain root on CSE484-Lab3 (2) Reverse engineer the protocol for client (3) Connect to the server and generate a new key.

What You Get

A virtual machine image of CSE484-Lab3 (server in your boss's office). Your login is student. Your password is cse484lab3. Download if from here: CSE484-Lab3-UbuntuServer8_10.tar.gz (~471M compressed and 1G extracted). You can use VMWare Player installed on the lab machines to load this VM. When you open the image, choose I moved it.

What You Should do

1. (2 points) Use your ninja skillz to gain root on CSE484-Lab3. You can use any method you want (use metasploit, nessus, anything you find on-line). We suggest that you leverage your physical access to the server, make it boot off of a live CD, mount the harddrive, and give yourself elevated privileges. Record what you did in a file called report.txt
2. (70 points) Reverse engineer the protocol for client. We suggest you use Wireshark (conveniently installed on the VM) to capture and analyze the packets. A big part of reverse engineering the protocol is seeing which parts of the packet structure change with each call and which stay the same. A part of the packet includes a cryptographically transformed password from /root/words with some pepper added. Once you figure out which part of the packet structure contains the ciphertext of the password and which cryptographic transformation is used, you should mount a dictionary attack on it to discover the password and pepper. A naive implementation of this takes 3 hours to run on attu. You can make an implementation that runs MUCH faster. Record how long your implementation runs, how long it takes to run if the password is not peppered, the actual password, actual pepper, description of protocol and packet structure in a file called report.txt. Note: you are required to calculate the amount of time it takes to crack an unpeppered (cryptographically transformed) password with your implementation so that you can compare how much additional computation is incurred by adding the pepper. You will not be graded on speed, only on the proportion of your results (peppered vs not peppered) and your explanation for them.
3. (20 points) Extend the skeleton code, available here, to connect to license server and query for a new license. The server your code should connect to is morris.cs.washington.edu. You can either write code to capture the server's reply or just monitor what packets you receive in return via wireshark. Record your newly obtained license(s) in the report.txt file.
4. (8 points) Write a paragraph on why you were able to easily compromise the CSE484-Lab3 server, what weaknesses allowed you to reverse engineer the protocol of client, and what steps you would take to harden the system if Anozira paid you more than Yoshoo.

What you need to give us

1. report.txt containing:
   • What you did to get root
   • Description of protocol, packet structure, how long it took for your implementation to run in order to crack the cryptographically transformed peppered password, how long it took your implementation to run in order to crack an unpeppered password, the actual password you found, the pepper you found.
   • A license you were able to get from the license server
   The file doesn't need to fancy. It can be bulletted.
2. Source code for password cracker and readme on how to use it. The readme can be very brief (just how to build it and execute it)
3. Source code for license-getting software that you wrote and a readme on how to use it. The readme can be very brief (just how to build it and execute it)
4. Feedback on what you thought was easy/hard/confusing. Write a paragraph on your experience with this lab in report.txt

Random Hints

• peppered password - recall that pepper is a couple of bytes included in the input to the cryptographic transformation in order to make dictionary attacks harder. For example, if the cryptographic transformation was a binary called foo, the pepper was aC, the password was bambam, and our peppering scheme was to put 1 byte of the pepper before and 1 byte of the pepper after the password, then we could call:

  echo -n "abambamC" | foo

  to get the corresponding ciphertext. This may or may not be the peppering scheme we used, and we haven't told you what foo is.
  Here is a hint about the peppering scheme used by client. The pepper is composed of a combination of lowercase and uppercase letters. To make your life easier, and your code run A LOT faster, figure out what peppering scheme is used below. The pepper is no longer than 3 characters long, but can be shorter; peppering characters can only be in the begining, end, or both (not in the middle) of the password. Here is a real password and the same cryptographically transformed peppered password using the real scheme that we used. Password:

  bambam

  The corresponding output is:

  52c83d9dfcf9c8c0ed2d28e1e58a7c28

  client uses the exact same peppering scheme! If you figure the above out, then you'll know what peppering scheme is used in the project (of course it'll have a different pepper that you'll need to find). On attu, a dumb, inefficient script takes 2.5 seconds to crack the above string (just for reference -- if yours is taking an hour, you're probably computing things wrong).
  
  
• launch live CD - If you choose to use the live CD approach to gaining root, you can read about how to configure VMWare Player to launch from a live CD ISO here: http://www.virtualization.info/2005/10/how-to-launch-iso-and-use-livecds.html
  
  
• passwd.bf - this file needs to be in the same directory as the client binary in order for client to work.
  
  
• strings - In order to be able to request new keys from the key server, you will have to send it a command (like a RPC) as part of the packet. You'll notices that all of the other packets also send their own commands. The command portion of the request-a-new-key packet will have the following form:

  command_name:peppered_password

  The peppered_password will be the one you recovered earlier. In order to discover what command_name is, you'll have to look for strings in client (the binary you found in the root directory of CSE484-Lab3) that have a similar format to the commands used by the other, already implemented, packets. To do this, you can run:

  strings client

  To narrow the results down, you can run:

  strings client | grep SOMEPATTERN

  Of course you can use any other tool you would like to reverse engineer the packet structure. Just makes sure to record what you did in report.txt

• X - the CSE484-Lab3 virtual machine has fluxbox installed as the default X windows server. It takes up less room and is quite fast. To start it, type

  startx

  . To adjust the the resolution, open a shell in fluxbox and use xrandr like:

  xrandr -s 1024x768

  if you want 1024x768 resolution. Here a link on using xrandr.
  
  
• Scapy (http://www.secdev.org/projects/scapy/) may be useful.
  
  

Extra Credit (potentially hard)

If you've mastered this lab, try do any/all of the following for extra credit:

• Exploits - install outdated software on the VM (you can, since you're root) and use metasploit or nessus to gain root. Here is a link on how to install metasploit. You can get Nessus from here and install it with:

  dpkg -i PACKAGE_NAME

  
  
• Lab 1 - make your exploits for lab 1 work on the VM. You may want to turn stack randomization off. Here is a link that may help.
  
• If we think of anything else, it'll appear here (feel free to suggest potential extra credit ideas)

FAQ and ERRATA

• Why do I have to use the huge VM? - because you need to learn why access to a physical system makes it insecure, how to gain root, and because you need root to do some network things and you don't have root on the lab machines.