Due: Friday, February 23rd, 11:59 PM
For clarifications and hints, see the FAQ.
Setting up pp3 on your own machine: Download the pp3 virtual machine image, pp3.ova (warning: 1.6 GB!). Note that this is not the same VM image as the one in previous projects, so you should not use those VMs. The ova file should load into VirtualBox.
The easiest way to access your VM from the host computer is with SSH. VirtualBox’s networking rules do not by default allow incoming connections to the VM, but you can set up a port forwarding rule, as follows. In the settings window for the pp3 VM, choose the “Network” tab, then show the “Advanced” options, and click the “Port Forwarding” button to bring up the port forwarding rules dialog.
In this dialog, you should create a rule binding Host IP 127.0.0.1, port 8024 (or another port of your choice) to Guest port 22 on the VM. Then click OK.
With port forwarding enabled, you can SSH into your VM using a
command like “
ssh bitbar@localhost -p 8024”.
As with any project, you will want to make and keep frequent backups
of your work. If you are developing your code in the
bitbar home directory inside the VM, then an easy
way to back this directory up is with the
Suppose you have set up port forwarding so that port 8024 on the
host forwards to port 22 on the VM. And suppose you’d like to
back up into a directory called
bkp123 in your home
directory. Run the following command on the host:
If you run this command again later it will update the contents of
rsync -av -e "ssh -p 8024" bitbar@localhost:pp3/ ~/bkp123/
bkp123to match the contents of
bitbar’s home directory.
To restore from backup, run the following command, again from the host:
rsync -av -e "ssh -p 8024" ~/bkp123/ bitbar@localhost:pp3/
The fictional “Bitbar” service has set up a simple
Web application at
http://localhost:3000 (inside the pp3
VM), allowing registered users to post profiles and transfer
“bitbars” between each other. Each registered user
starts with 200 bitbars.
You will craft a series of attacks on the Bitbar website that exploit vulnerabilities in the website’s design. Each attack presents a distinct scenario with unique goals and constraints, although in some cases you may be able to reuse parts of your code.
Although many real-world attackers do not have the source code for
the websites they are attacking, you are one of the lucky ones: you
can find the source code under
~/pp3/bitbar/app/ in the
The Bitbar server is actually run locally on your VM. We will run your attacks after resetting our own local database of registered users. Of course this means that any data you have added while working on the assignment will not be present during grading.
~/pp3/bitbar/. This is the root directory of the Bitbar Rails app.
This will make the Bitbar application available in the browser
at the URL
http://localhost:3000. You can close the
server by pressing Ctrl + C in the terminal.
Browser: We will grade your project within the pp3 VM, using the Chromium browser. Therefore, you should test your code in the VM on this browser.
user1before loading your URL.
http://localhost:3000/steal_cookie?cookie=...cookie data here...
http://localhost:3000/profile. No changes to the site appearance or extraneous text should be visible. Avoiding the blue warning text is an important part of this attack.
attacker” account. The browser should be redirected to
https://cseweb.ucsd.edu/classes/sp17/cse127-aas soon as the transfer is complete (so fast the user might not notice).
localhost:3000at any point.
attacker(that’s the actual username) and replaces the profile of the current user with itself.
attackeruser changes their profile to whatever you provide in your solution, the following will happen: if
attacker’s profile, 1 bitbar will be transferred from
user1’s profile will be replaced with your solution profile. Later, if
user1’s profile, then 1 bitbar will be transferred from
user2’s profile will be replaced as well. Thus, your profile worm can very quickly spread to all user profiles.
attackeruser and view that profile using the grader’s account. We will then view the copied profile with more accounts, checking for the transfer and replication.
xis the user whose profile is being viewed. The visitor should not see any extra graphical user interface elements (e.g. frames), and the user whose profile is being viewed should appear to have 127 bitbars.
Do not run the turnin script found in
this script expects you to have solved four problems whereas this quarter we
assigned only three. We will supply you with an updated turnin script to run.
The script will look for the following files, but will pack everything
attacks directory and send them to our server.
GROUPfile, as in pp1 and pp2.
The last attack is substantially harder than the first two. We encourage you to start early!
Beware of Race Conditions: Depending on how you write your code, all four of these attacks could potentially have race conditions that affect the success of your attacks. Attacks that fail on the grader’s browser during grading will receive less than full credit. To ensure that you receive full credit, you should wait after making an outbound network request rather than assuming that the request will be sent immediately.
This is Project 2 from Stanford’s CS 155, Computer and Network Security. Thanks to Dan Boneh, John Mitchell, Collin Jackson, and the 155 TAs.