This homework refers to the “fake bank” web application that we have used in class for examples. Information on how to access the application is not included on this public web page – see the Canvas announcement for access information. The announcement also tells you how you can see the code that’s running on the server. Each student has an account set up at the bank with an initial balance of $100. Info on these accounts is in the Canvas announcement.
Each of the following questions asks you to figure out how to exploit a different type of vulnerability in the “fake bank” code. For each one, report on how you performed the attack, including any specific strings or inputs you used (all the information needed to recreate the exploit). In the first three questions, if you have a successful attack you will discover a “secret” value – report that value in your assignment write-up as well. It is perfectly fine to use external resources in solving these problems, but make sure you cite any sources or web sites that you referred to in your write-up.
The login code has a bad SQL injection vulnerability that allows an attacker to log in as any user on the system, without knowing the password. Exploit this vulnerability to log in to the server with username “secure”. The secret value to report for this question is the balance in the “secure” account.
There is a user named “hidden” on the system that is protected using measures beyond the basic bank code that you can see. Because of these extra protections, you will not be able to log in to this account using the SQL injection trick described in the previous question. However, you should be able to find and read a message from “hidden” to “manager” that contains a secret message. Figure out how to find and read the message and discover the secret. Note that you will not be able to see any messages sent to the “hidden” account, so you can’t see the XSS attempts of other students (see the next question).
When the real “hidden” user logs in, they get a special cookie that is not part of a normal login session. Since you can’t log in as the “hidden” user you should have no way to access this cookie. While logged in to your own bank account, send a message to “hidden” that performs a cross-site scripting attack to discover this cookie. I will log in to the hidden account every day around 6:00 PM and read through all new messages received since the previous day, which will trigger a successful XSS attack. Important: I will use the Firefox browser for this, since Chrome has some extra protections that “upgrade” a non-SSL connection to SSL automatically. If you are testing your attacks, use Firefox! Note that while this assignment isn’t due until midnight on the due date, I will not read these messages after 6:00 – that means you cannot put this off until the last minute!
More info on XSS exploit: A successful cross site scripting attack will send sensitive information to a listening server. Here’s how that works for our class: On the class Linux login machine (that you all have accounts on), I have a server running on port 8000 that accepts connections and logs the first line received on any connection to a “monitoring” file. All of this – code and data – is in directory /home/srtate/xss on the class machine, and from your login account you can access this directory and view the source code for the programs that are running (you don’t need to do this – it’s just there in case you’re curious). However, you do not have permissions to read the monitor log (so you can’t see other student strings). To see the results of your XSS attack, you can use the program /home/srtate/xss/code/bin/showmonitor which will display every log line that includes your user name. So putting together all this information:
Your XSS attack must include your user name in the triggered request, or you will not be able to see your results. The “file” part of the URL is arbitrary (it’s not used in any way), so just make sure your user name is embedded in there.
Your XSS attack must include information from cookies in its request, since you’ll need to get the secret cookie value.
If you are testing your attack, and see a blank line in the monitor log when you don’t think it should be blank, it might be the case that your XSS request is being “upgraded” by the browser as mentioned above. Use Firefox to trigger the XSS attack instead.
Feel free to practice your XSS attack by sending messages to yourself and then opening them to see if that triggers a request to the monitoring server. That way you can develop the attack into one that you have high confidence will work, since you only get one actual attempt per day.
You must use this server to get the results of your XSS attack (do not use your own server). I will check this log for your username when grading.
Your account should have a balance of $100. Log in to your account and use one of the penetration testing tools from the last assignment (ZAP or Burp Suite) to bypass the client-side sufficient-funds check to transfer $200 to alice. Yes, this will leave you with a negative balance, but you’re conspiring with alice in this situation so you’ll make off with all the extra money.
Set up a cross-site request forgery (CSRF) attack that will transfer $50 from a logged-in account to “alice”. We actually did this in class, although you’ll need to recreate the web pages that perform the attack. My in-class example made the attack very stealthy by putting it in a hidden iframe - you do not need to do this in your attack. Redirecting the victim’s browser to the bank “send money” page is fine, as long as the transfer is made.
To create this attack, put your attack files in directory csrf of your public_html directory. The initial page should be named index.html. When grading your assignment, I will visit this page in a new tab of a browser, while a different tab is logged in to the bank, and that should trigger the transfer.
Note: When I did this example in class, we discovered that the basic CSRF attack worked in Firefox but not in Chrome. I have since discovered what was protecting the Chrome session and disabled that protection so that the attack succeeds in either browser. We will discuss the details of this in class.