Main navigation | Main content
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.
This will create what we'll call your group directory,
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.
If you would like to reuse a VM image you group used for HW1, you can do that instead by copying your old ha1.qcow2 file to the name ha2.qcow2. You'll also need to configure the VM with a second network adapter by adding the following lines to /etc/network/interfaces inside the VM:
auto ens4 iface ens4 inet dhcpHowever starting with a fresh VM is our recommended configuration, since it should be less error-prone.
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.
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.
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.
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.
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.) Then configure your web browser to use localhost port 8080 as a proxy.
$ 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.
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.
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.
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.
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.