This lab has been tested on our pre-built Ubuntu 20.04 VM, which can be downloaded from the SEED website. Since we use containers to set up the lab environment, this lab does not depend much on the SEED VM. You can do this lab using other VMs, physical machines, or VMs on the cloud.
To get started, we first go to the seed labs website, https://seedsecuritylabs.org/Labs_20.04/Web/Web_CSRF_Elgg/ and we download the labset up files and unzip them. Then we open up the command line or terminal and switch to the Labsetup directory and run a few commands. We run Docker-compose build, which creates all of the containers in order for us to use the websites and do this lab. Then we run docker-compose up which starts all of the containers and gets everything up and running. We can test to see if these containers are running using the command, docker ps. This command shows the container id, image, ports, status, name, and other information. Before testing the URLs on the web browser, we need to edit the /etc/hosts files to add the URLs next to their IP addresses. We can do this by running sudo gedit /etc/hosts, or sudo nano /etc/hosts, depending whether your OS has gedit installed or not. Then we can test the url by putting any of the following URLs we use for this lab into the web browser. If we see the login page for www.seed-server.com, then we know the containers are running. We log in and continue the next steps for the lab using the admins created for us already.
3.1 Task 1: Observing HTTP Request. In Cross-Site Request Forget attacks, we need to forge HTTP requests. Therefore, we need to know what a legitimate HTTP request looks like and what parameters it uses, etc. We can use a Firefox add-on called "HTTP Header Live" for this purpose. The goal of this task is to get familiar with this tool. Instructions on how to use this tool is given in the Guideline section (§ 5.1). Please use this tool to capture an HTTP GET request and an HTTP POST request in Elgg. In your report, please identify the parameters used in this these requests, if any.
For this task, we need to observe HTTP Requests that our browser sends out everytime we click something on the UI. Each functioning feature or button, will always send out HTTP requests with information that we can access. We can access this using the FireFox extension or add-on called "HTTP Header Live”. Once you are able to set that up, you can have that open on the side view and click on any button or any click that would capture a HTTP request and view the response on the tool. For example, figure below, I clicked on the add button to add Alice as a friend using Samy’s account. And the requests below are what were captured. The parameters used in the request are ?friend=56&__elgg_ts=1665973772&__elgg_token=PCtIngK2Qc8A-5sch3zpRQ&__elgg_ts=1665973772&__elgg_token=PCtIngK2Qc8A-5sch3zpRQ
3.2 Task 2: CSRF Attack using GET Request In this task, we need two people in the Elgg social network: Alice and Samy. Samy wants to become a friend to Alice, but Alice refuses to add him to her Elgg friend list. Samy decides to use the CSRF attack to achieve his goal. He sends Alice an URL (via an email or a posting in Elgg); Alice, curious about it, clicks on the URL, which leads her to Samy’s web site: www.attacker32.com. Pretend that you are Samy, describe how you can construct the content of the web page, so as soon as Alice visits the web page, Samy is added to the friend list of Alice (assuming Alice has an active session with Elgg). To add a friend to the victim, we need to identify what the legitimate Add-Friend HTTP request (a GET request) looks like. We can use the "HTTP Header Live" Tool to do the investigation. In this task, you are not allowed to write JavaScript code to launch the CSRF attack. Your job is to make the attack successful as soon as Alice visits the web page, without even making any click on the page (hint: you can use the img tag, which automatically triggers an HTTP GET request). Elgg has implemented a countermeasure to defend against CSRF attacks. In Add-Friend HTTP requests, you may notice that each request includes two weird-looking parameters, elgg ts and elgg token. These parameters are used by the countermeasure, so if they do not contain correct values, the request will not be accepted by Elgg. We have disabled the countermeasure for this lab, so there is no need to include these two parameters in the forged requests.
For the second task, we want the hacker(samy) to have the victim(alice) added as a friend by a posting on Elgg. This link should lead Alice to the attacker website which would trigger an HTTP response and would make Samy Alice’s friend against her own will. First, we open the HTTP Header Live tool and click on the Add Friend button on Alice’s profile from Samy’s account. This would then trigger a POST response and would list the information for the HTTP request. You would be able to see the attributes and parameters for the request. We would be able to access the get request and parameters of Alice’s Guid using the parameters provided in the URL. We take the link and place it somewhere safe, where we would be able to access it again. We then go to Samy’s profile and view the source code. Using the source code, we find the GUID for Samy which is 59.
Task 3: CSRF Attack using POST Request After adding himself to Alice’s friend list, Samy wants to do something more. He wants Alice to say “Samy is my Hero” in her profile, so everybody knows about that. Alice does not like Samy, let alone putting that statement in her profile. Samy plans to use a CSRF attack to achieve that goal. That is the purpose of this task. One way to do the attack is to post a message to Alice’s Elgg account, hoping that Alice will click the URL inside the message. This URL will lead Alice to your (i.e., Samy’s) malicious web site www. attacker32.com, where you can launch the CSRF attack. The objective of your attack is to modify the victim’s profile. In particular, the attacker needs to forge a request to modify the profile information of the victim user of Elgg. Allowing users to modify their profiles is a feature of Elgg. If users want to modify their profiles, they go to the profile page of Elgg, fill out a form, and then submit the form—sending a POST request—to the server-side script /profile/edit.php, which processes the request and does the profile modification. The server-side script edit.php accepts both GET and POST requests, so you can use the same trick as that in Task 1 to achieve the attack. However, in this task, you are required to use the POST request. Namely, attackers (you) need to forge an HTTP POST request from the victim’s browser, when the victim is visiting their malicious site. Attackers need to know the structure of such a request. You can observe the structure of the request, i.e., the parameters of the request, by making some modifications to the profile and monitoring the request using the "HTTP Header Live" tool. You may see something similar to the following. Unlike HTTP GET requests, which append parameters to the URL strings, the parameters of HTTP POST requests are included in the HTTP message body (see the contents between the two * symbols):
For this task, we want to attack the victim again but this time using the POST method to post a statement on the victims page without their consent. We want to edit the editprofile.html file so we are able to forge a POST request to trigger the attack. We open up the file using a text editor and view the contents of it to see what we can change. We head over to Samy’s profile and click edit profile. Then in the About me section, we type “Samy is my hero.” and do the same for the brief description. Before saving this updated profile, we open the HTTP Header Live tool to record the HTTP requests that are being captured. We intend to utilize a CSRF attack.
Task 4: Enabling Elgg’s Countermeasure To defend against CSRF attacks, web applications can embed a secret token in their pages. All the requests coming from these pages must carry this token, or they will be considered as a cross-site request, and will not have the same privilege as the same-site requests. Attackers will not be able to get this secret token, so their requests are easily identified as cross-site requests. Elgg uses this secret-token approach as its built-in countermeasures to defend against CSRF attacks. We have disabled the countermeasures to make the attack work. Elgg embeds two parameters elgg ts and elgg token in the request. The two parameters are added to the HTTP message body for the POST requests and to the URL string for the HTTP GET requests. The server will validate them before processing a request.
Task 5: Experimenting with the SameSite Cookie Method Most browsers have now implemented a mechanism called SameSite cookie, which is a property associated with cookies. When sending out requests, browsers will check this property, and decide whether to attach the cookie in a cross-site request.