Main navigation | Main content
This hands-on assignment 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. You'll have control of a single Linux VM, but most of the action occurs on the virtual network.
csel-xsme-f21-csci5271-GG.cselabs.umn.edu
In case you are curious about the parts of that somewhat long name, the csel- prefix and the cselabs.umn.edu both place the VMs under CSE Labs' control; CSE Labs now uses the prefix as well because Active Directory does not support DNS domains, though these VMs don't actually use Active Directory. xsme stands for ``X-cluster Self-Managed Environment"; the ``X cluster'' is historically the set of VMs used for specific class purposes, and ``self-managed environment'' refers to the way the systems administration of these VMs is under the control of the course staff and students, rather than directly with the CSE-IT staff. f21-csci5271 is of course a reference to the semester and course.
The cluster that the VMs are running on is a shared resource used by many other students at the same time, so use the VMs for purposes of the assignment only. No part of the assignment should require large amounts of computing power; if you find yourself writing code that runs for a very long time or makes an enormous number of network requests, it's a sign you don't have the right idea of an attack. 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 not part of the assignment.
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.
In order to keep closer watch on what's happening on these VMs with our untrusted systems administrators, CSE-IT has put them behind a more restrictive firewall than typical lab workstations. One particular restriction is that the VMs do not have unfiltered access to the general Internet. You can still so things like browse the web with them, but only via a web proxy. Specifically this is configured by an environment variable http_proxy that is set by default to the URL http://proxy.cselabs.umn.edu:8888/, along with a variable https_proxy with the https version of the same URL.
You should leave the proxy configuration in place if you want to browse the general web from the VM, such as using w3m to download software from a web page.
On the other hand, you may need to disable the proxy configuration if you want to use command-line web tools to access the VPN such as to carry out an attack, because the proxy isn't connected to the VPN. You can do this by removing the environment variables for the execution of a single program by prefixing the command line with the program env and it's -u option. For instance:
env -u http_proxy -u https_proxy wget http://192.168.G.1/
Which should download the front page of the web server into a file named index.html, assuming you replace G with your group number.
The simplest way to connect to your VM from off campus is to SSH first into a CSE Labs machine, and then from there into the VM. You can also copy files in two steps this way using the scp command. 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 xGG-via-kh4250 ProxyCommand ssh USERNAME@csel-kh4250-GG.cselabs.umn.edu netcat csel-xsme-f21-csci5271-GG.cselabs.umn.edu 22
Here USERNAME is your CSE Labs username, and GG is your two-digit group number and group numbers as usual. The suggestion of a similarly-numbered lab machine in 4-250 as the intermediate CSE Labs machine is arbitrary. Then you can use the command ssh student@xGG-via-kh4250 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 and a Duo authentication. 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, though it works fine for running text-mode programs and scripts. However there are a few reasons why it's not the best place for running a large graphical web browser: it doesn't have much RAM, and viewing the GUI using SSH's X forwarding feature won't perform well unless your network connection is very close. 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 5555 (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 5555 as a proxy.
For example,
$ ssh student@xGG-via-kh4250 -D 5555 -CN (Make sure that your VM is running and you can already do a plain ssh student@xGG-via-kh4250)
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 '5555' 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 also use an SSH feature called local port forwarding to forward just the http (port 80) and https (port 443) ports from the victim server to your local machine; then you'd connect not by using the browser's proxy configuration but just localhost with the appropriate port number.
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. Because the VMs are self-administered, they don't run backups, and poorly chosen command might make them unresponsive or destroy data.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 publicly on Piazza.