Cross-Site Request Forgery (CSRF) Attack using SEED Lab

Cross-Site Request Forgery (CSRF) is a type of attack that allows an attacker to execute malicious actions on behalf of a victim without the victim’s knowledge. It works by tricking the victim into making a request to a website using the victim’s own credentials.

For example, if a victim is logged into their bank account and visits a malicious website, the attacker can use CSRF to make the victim’s browser send a request to the bank’s website to transfer money to the attacker’s account without the victim realizing it.

The SEED Lab used for this illustration can be found at:

Cross-Site Request Forgery Attack Lab

Prerequisites

1. Find the description of the SEED Lab used at:

2. Download the SEEDUbuntu-16.04–32bit VM used

SEED Project

3. Check the manual on importing the SEEDUbuntu VM into VirtualBox. Follow the 7 steps in “How to Use Virtualbox to Run SEEDUbuntu VM”

Task 1: Observing HTTP Requests

Observing HTTP requests is an important task when studying and understanding the inner workings of websites, particularly when it comes to security. By observing HTTP requests, you can see exactly what information is being sent between the browser and the server, which can help you identify potential vulnerabilities or areas of concern.

To observe HTTP requests using the Firefox Web Console, follow these steps:

1. Start up Firefox and open the Web Console by pressing Ctrl + Shift + K (or by going to Tools > Web Developer > Web Console).
2. Click on the Network tab to view the network activity of the current page.
3. Access the website http://www.csrflabelgg.com/ without logging in. You should see a HTTP GET request appear in the Web Console.
4. If you opened the Web Console after accessing the website, you may need to reload the page in order to see the HTTP GET request.

To observe a HTTP POST request, login to the website http://www.csrflabelgg.com/ as Charlie (username: charlie, password: seedcharlie) while keeping the Web Console open. You should see a HTTP POST request appear in the Web Console.

By looking at the parameters of the HTTP GET and POST requests in the Web Console, you can see exactly what information is being sent between the browser and the server.

The following parameters were used:

__elgg_token

__elgg_ts

password

username

The __elgg_token and __elgg_ts parameters are likely used for security purposes, such as to prevent cross-site request forgery (CSRF) attacks. The password and username parameters are used to pass the user’s login credentials to the server.

Task 2: CSRF Attack with GET Request

In this task, we consider two people in the Elgg social network: Alice and Boby.

Boby wants to become a friend to Alice, but Alice refuses to add him to her Elgg friend list. Boby 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 Boby’s website:(www.csrflabattacker.com).

As Boby, you will construct the content of this website, so that as soon as Alice visits the web page, Boby is added to the friend list of Alice (assuming that Alice has an active session with Elgg).

To add a friend to the victim, we need to identify what the legitimate HTTP request (a GET request) for adding friends looks like. We will use the Web Console (as in the previous task) to do the investigation.

First, let us investigate the legitimate HTTP requests by adding friends when working as user Charlie, and comparing the results.

Making sure you are logged in as Charlie(username: charlie, password: seedcharlie):

1. Click on “More” > “Members”.
2. Click on Alice’s name. Make sure that the Web Console Network tab is open so that you can see the request you are about to make.
3. Click on “Add Friend” (the button on the left).

The following parameters are used in the GET request:

__elgg_token

__elgg_ts

friend

It can also be observed that the request is issued to the URL:
http://www.csrflabelgg.com/action/friends/add?friend=42&__elgg_ts=1669802924&__elgg_token=7IVmGiAT2pV_mK9kANmBGA

Now:

1. Go back to the “Members” list.
2. Click on “Boby”. Make sure that the Web Console Network tab is open so that you can see the request you are about to make.
3. Click on “Add Friend” (the button on the left).

The same parameters and url are used with only one difference in the value for friend parameter which is 43 in Boby’s case but 42 in Alice’s case.
With this knowledge, we (Boby) can create a page that can be used to phish Alice.

Boby’s website which is www.csrflabattacker.com would host the following page:

<!DOCTYPE html>
<html>
    <head>
    </head>
    <body>
        <img src="http://www.csrflabelgg.com/action/friends/add?friend=43" />
    </body>
</html>

This page would be hosted at /var/www/CSRF/attacker_folder where attacker_folder is arbitrarily named.

The img tag automatically triggers an HTTP GET request whether the image exists or not.

In this webpage will issue a request on behalf of any user visiting to add Boby as a friend.

The remaining parameters, __elgg_token and __elgg_ts are excluded in this lab.

They are used as a countermeasure against CSRF attacks. Specifically, if these parameters do not contain correct values, the request will not be accepted by Elgg
Create a backup of this file as it will also be used later in this exercise.

Next, login as Boby (username: boby, password: seedboby) and send a phishing message to Alice with the link attached.

NB: Ensure the message subject is non-empty, otherwise the website will throw an error. (This is an unintentional bug in the website implementation.)

Ensure that Alice is not friends with Boby before proceeding by checking Alice’s profile at:

http://www.csrflabelgg.com/profile/alice

Next, log in as Alice (username: alice password: seedalice) and click on the envelope to view messages

Click on the link and observe how the webpage appears.

Go back to www.csrflabelgg.com in your browser and you will see the attack was successful and Boby has been added as a friend to Alice.

Task 3: CSRF Attack Using POST Request

In this part of the lab, Bob will run another CSRF attack with a goal to deface Alice’s profile so that it reads “Boby and ${anything} are MY HEROES!!” (you can replace ${anything} with your your name or number or any value you’d like)

Capture a legitimate POST request using the following steps:

1. Log in as Alice (username: alice, password: seedalice)
2. Click on “Edit profile”
3. Open the Web Console Network tab so that you can see the request you are about to make. Fill out the form with some information (this information can be arbitrary) and click “Save”

Observe the HTTP POST request.

There are several parameters used but we are only interested in specific parameters in order for our attack to be successful.

name

accesslevel

description

guid

This parameters would need to be passed as a form submitted to the website as a POST request.

We can do this by editting the index.html file inside the attacker’s website (www.csrflabattacker.com; /var/www/CSRF/attacker folder) so that the page will launch a CSRF attack to deface Alice’s profile.

A sample code has been provided in the original SEED lab.

We will use Javascript to succeed in this attack and ensure Boby’s website which is www.csrflabattacker.com would host the following page:

<!DOCTYPE html>
<html>
  <head>
  </head>
  <body>
    <script type=” text/javascript”>
        function forge_post()
        {
                var inputs;

                inputs += "<input type='hidden' name='name' value='Alice'>";
                inputs += "<input type='hidden' name='description' value 'Boby and Js2169 are MY HEROES!!'>";
                inputs += "<input type='hidden' name='accesslevel[briefdescription]' value='2'>";
                inputs += "<input type='hidden' name='guid' value='42'>";

                var q = document.createElement("form");

                q.action = "http://www.csrflabelgg.com/action/profile/edit";
                q.innerHTML = inputs;
                q.method = "post";

                document.body.appendChild(q)

                q.submit();

        }
        window.onload = function() { forge_post();}
     </script>
  </body>
</html>

This script creates and submits a HTML form. The form contains several hidden input fields, which are used to pass data to the server when the form is submitted.

The function forge_post() is defined at the beginning of the script. This function creates the HTML form and sets the action attribute to "http://www.csrflabelgg.com/action/profile/edit", which specifies the URL that the form will be submitted to.

Inside the function, several input fields are created and added to the form using the += operator and the innerHTML property. These input fields contain various data, such as the name "Alice" and a description containing the text "Boby and Js2169 are MY HEROES!!".

Once the form has been created and the input fields have been added, the form is appended to the body of the HTML document using the appendChild() method. Finally, the submit() method is called on the form to submit it to the server.

The window.onload event is used to specify that the forge_post() function should be called when the page has finished loading. This means that the form will be automatically submitted as soon as the page is loaded.

Check Alice’s webpage and ensure everything is standard with the way you had edited it before doing anything.

Next, log in as Boby and send another message to Alice with the link to the attacker’s webpage that you created above.

Finally, log in as Alice and click on the link contained in the messages.

Ensure you open the Web Console Network tab so that you can see the request, which you are about to make

The website is defaced and only the parameters modified are passed to the HTTP POST request indicating the attack was successful.

This is because malicious page that Alice visited hosted Javascript code that sends a form with filled inputs to the edit page of the profile of the user currently logged in, i.e., Alice.

This would be the same as Alice editing and hitting the submit button by herself.

This attack depends on Boby knowing Alice’s userID. Consider how this can be achieved.

Solution: Bob would proceed to add Alice as a friend and capture the parameters used in the GET request. The friend parameter would be able to provide Alice’s user ID.

Additionally consider a scenario where Boby wants to modify the CSRF attack so that he can deface the Elgg profiles of any Elgg user that goes to Boby’s site.

Is it possible? If so, how? If not, why not?

Solution: Yes. Boby would use a brute force attack for the guid variable and provide a link to the malicious page on his own webpage. Provided one of the guid variables is correct for the user logging on, then it would work. Guid variables would have to be in a small range as the number of users is low.

Task 4: Implementing a Countermeasure for Elgg

Enable the Countermeasure

Go to the /var/www/CSRF/Elgg/vendor/elgg/elgg/engine/classes/Elgg directory.

In the “ActionsService.php” file, find the “gatekeeper” function.

Comment out the “return true;” at the top of this function.

Now when you try to run the previous attacks in Task 2 and Task 3 they will fail.

This is because the HTTP requests issued by the site lacks the __elgg_ts and __elgg_token values, which even if they were included would also have to be the correct ones.