Introduction to Computer Security

Hands-on assignment 2 virtual machine instructions

Hands-on assignment 2 is about exploiting network-level and web-software vulnerabilities in a web server. In order to make this realistic but still not have you interfering with each other or taking over CSE Labs networks, you'll test out your attacks using a virtual network with virtual machines that we've set up. These VMs will be spread across a cluster of network-accessible machines run by CSE Labs. This page gives directions and some hints about how to use your VM effectively. The VM you control is similar to the one in HA1, but most of the action occurs on the virtual network.

Getting started instructions

1. We are assuming if you did not contact us already that you will be using the same groups, of size up to 2 students, that you did for HA1, and if that is so, your group number will also be the same as for HA1. Questions about your group registration should be directed to the TA (Aditya Pakki, pakki001 AT umn.edu).
2. The registration information your group got for HA1 assigns your group some unique identifiers. Specifically your group will have two numbers: in the discussion and sample commands below, we'll write these numbers as GG and HH, so whenever you see those you're supposed to fill in your group's numbers. GG is a unique number for your group, ranging from 01 to the number of groups we have (probably no more than 50); you should always write it with two digits. HH is number of the computer your VM will run on (H for "host"); as of this writing we've been assigned computers 01 through 04. HH is not unique to your group, but GG is. (The PP number from HA1 is not used in HA2.)
3. To create a new VM which will be your attacker VM, SSH into the machine csel-x5271-xHH.cselabs.umn.edu where HH is the host number mentioned before. Then run the command:

   /export/scratch/csci5271/ha2/master/setup-vm

   This will create what we'll call your group directory,

   /export/scratch/csci5271/ha2/groupGG

   and put in it a fresh virtual machine disk image file named ha2.qcow2. The disk image is about a 3GB file, so copying it will take 10-60 seconds.

4. For convenience, change directory into your group directory. The remaining special commands will be set up as symlinks in this directory so you can run them with "./".
5. Start your VM for the first time using the command ./run-vm. This command will take over your terminal, and print some reminders, but you won't see any messages directly from the boot process. It will take at least a minute or two, but about 30 seconds after you see the login: prompt printed in the terminal, you'll be ready to go on to the next step.
6. The recommended way to log into your VM is with SSH from a different window. The ports used by your VM are probably blocked by the department firewall, so you can't SSH in directly from anywhere, but you should be able to SSH in from any CS or CSE Labs machine in Keller Hall (including your xHH machine). You should use the command:

   ssh -p 55GG student@csel-x5271-xHH.cselabs.umn.edu

   Where GG and HH are replaced with the group and host numbers mentioned above.

   The VM comes with an account named student which is set up for your use. Initially the password for the account is loans, but you'll need to change the password the first time you log in. Share the password with the other members of your group, but not with anyone outside your group. Specifically on the first time you'll have to type the old password loans twice, then your new password twice, then log in again with the new password.

7. The student account has the ability to run commands as root using the sudo command, so you're generally free to administer the computer as you see fit. For instance if you'd like you can create separate accounts for each group member.
8. When you're done using the VM for a while you should turn it off. The recommended way of doing this is by running the command sudo halt -p inside the VM.

Don't interfere with other groups and users

Please remember that the machines the VMs are running on are a shared resource used by many other students at the same time. Don't use so much memory, CPU, or disk space that other users can't use the machine. You're responsible for keeping your VM secure, such as by keeping passwords secret. But you're also responsible for not interfering with other groups' VMs. Hacking into another group's VM is definitely not part of the assignment. Because VM disk images are large, please don't store them on other CSE Labs machines or run QEMU on machines other than the one you've been assigned (to help you remember this, the CSE Labs staff have conveniently not installed QEMU on most other machines).

To encourage you not to leave your VM running when you aren't using it, we've set it up to shut itself down if it's left running unattended overnight (specifically, at about 4am). If you really are using the machine at that time you can cancel the shutdown with the command sudo shutdown -c.

Command-line networking tools

Several useful command-line programs for accessing the network and web sites are already installed on your attacker VM. tcpdump can be used to sniff network traffic. netcat behaves like a simple TCP client or server taking input and output to standard input and standard output. curl and wget are two different programs for accessing web sites from the command line, both with lots of options. w3m is a text-mode web browser. All of them have manual pages you can read to learn more.

Advanced SSH setup

The simplest way to connect to your VM is to SSH first into your xHH host machine, and then from there into the VM. You can also copy files in two steps this way using the scp command: note that the option to scp for changing the port is a capital -P, as opposed to ssh's lowercase -p. However if you're copying files a lot you may find that you get tired of typing all of these commands. Of course you can write a short script of use shell variables to abbreviate commands. But the best way to save yourself typing, because it also is more secure, is to use extra features of SSH.

A better practice than SSHing first from one machine and then to another is to ask the first machine to just proxy your SSH connection to the second machine. For instance, one benefit is that the machine in the middle never has to see your password for the second machine. You can set this up by putting the following two commands in your .ssh/config file on your client machine:

Host vm-via-xHH
  ProxyCommand ssh USERNAME@csel-x5271-xHH.cselabs.umn.edu netcat localhost 55GG

Here USERNAME is your CSE Labs username, and HH and GG are host and group numbers as usual. Then you can use the command ssh student@vm-via-xHH to connect to the VM's student account.

If you make just the change described above, it will still ask you to type two passwords. But you can combine this with another technique to avoid typing passwords, which is to create an SSH key pair. This approach uses public key cryptography to create a matched pair of a private key and a public key. You put the public key on the machines you want to log into, and load the private key into to memory of the machine you're coming from using a command named ssh-agent; then SSH will automatically use the private key to authenticate you in place of a password. There's a few different steps involved in setting this up, but there are a number of tutorials you can read on the web; one pretty good on is on the Ubuntu wiki.

Proxying the virtual network

Your attacker VM is not very powerful: it works fine for running text-mode programs, but you probably wouldn't want to try to run a large graphical web browser on it. Instead, you can run your favorite graphical browser on another machine, and use an SSH-tunnel proxy to give that browser access to the attack network. SSH has options for forwarding single ports, but the easiest option to use is the -D option in OpenSSH, which sets of a SOCKS-compatible proxy that will forward any port your web browser asks for. Specifically you can add the option -D 8080 (or any other port) to the SSH command you use to connect from the machine you want to run the browser on, to the VM. (If it's not a direct connection, you should use the vm-via-xHH approach described above.) The configure your web browser to use localhost port 8080 as a proxy.

For example,

$ ssh USERNAME@vm-via-xHH -D 8080 -CN (Make sure that your VM is running and you can already do a plain ssh USERNAME@vm-via-xHH)

Then, nothing appears in the terminal except blinking cursor. Go to your browser setting to use the proxy. For firefox, preferences => Network Settings => Settings... => Click manual proxy configuration and type 'localhost' in SOCKS Host and '8080' in its Port. Apply the change, go to url bar and type http://SERVER.

For Chrome, preferences => Advanced => In System, Open proxy setting. Then, follow steps in Firefox as shown above.

Note that setting details might be slightly different depending on OS. We have tested Firefox in both macOS and Ubuntu and Chrome in macOS.

Firefox and extensions

You can potentially complete the assignment using any graphical web browser you want (or it should even be possible using only command-line tools), but we've specifically tested with recent versions of Firefox so that would be a good choice if you don't otherwise have a preference. There are also some Firefox extensions you can install which might make your life easier.

FoxyProxy provides extra support for using different proxies: for instance you can configure it so that your web browser uses the proxy described above only for web sites that start with 192.168, and not for other browsing.

For older versions of Firefox we recommended Firebug as a general web inspection and debugging tool. But in recent versions of Firefox is has been replaced with Firefox's own Web Developer tools.

HackBar is another debugging extension that's convenient for editing the data submitted in forms.

Avoiding and recovering from problems

Your virtual machine should never be the only place where you have a copy of your work. Part of the reason for this is that because of their size, we store the disk images on a "scratch" disk partition that is not backed up: if that disk were to have a hardware failure, all your VM images would be lost. So you should keep copies of your exploit scripts in other places, such as your CSE Labs home directory (which is backed up) or other machines of your own.

If you want to run the VM on your own machine

The attacker VM image and the scripts we use to run it aren't secret, but the client and server victim machines do have secrets on them (that it's your job to steal), so you can't do this assignment entirely on your own hosts: you need to attack the VMs we've set up.

If you have more questions

Please don't hesitate to ask questions if you get stuck while trying to manage your VM, etc. If the question is one that everyone in the class can benefit from hearing the answer to, the best place to ask it is on the discussion on the Canvas page. If you have a question that should be answered privately, please send it to both of the course staff using the email addresses on the syllabus to ensure a prompt response.