Challenge 9:Database Exploitation (Part 2)
This is a detailed writeup created for challenges associated with the Certified Web AppSecurity Expert (CWAE) certification.
Challenge/Task
- Database Exploitation (Part 2)
Proof-of-Concept (POC):
Do you remember the XSS Hunter we used recently?
If we quickly review the report, we receive a cookie from the victim. We can use this cookie to login into the victim account. As for your information, cookie is something that is unique and was assigned by the server to the user for authentication activity.
Let’s see how we can use the cookie to login to the victim. I try to login to the system while intercepting the request using burp suite. Please notice the cookie value there.
I then copy the cookie value inside the XSS hunter and paste it into the cookie of the previous request.
With those cookies, I land to a Dev account without any credential needed.
Looking at the profile, I noticed that there is a new endpoint which is Dashboard. When I clicked it, it redirects me to https://the-abstractors.com/management where we can see all the logs of user activity.
Upon checking in the Burp suite, there is a new endpoint which is GraphQL.
The GraphQL is an endpoint that is used to display anything based on what we are requesting. There are two parameters which are query and variables.
For example, this query is to query id number of all posts with their title.
For parameter variables, it is used to show the start and end date for the query. As per previous assessment, we can try to inject the SQL payload inside this param using the same practice.
So now I want to know inside the two values inside the variables which are start and end, which one is vulnerable to SQL injection. We will be using single quote to test it.
From the server response below, I guess we have the answer which is the end value is vulnerable to SQL injection. Referring to the error, psycopg2 is normally refer to Postgres DB.
Now, we try to send the same payload as previous assessment which is 1 or 1=1, however the servers did not return anything. Just return me an error.
Maybe we can use another trick to proof if the DB is responding to my SQL query. We can use sleep () method. I try to send this payload to see if server will return me the response after 10 seconds
Finally, the server proves if it is responding to my SQL query. It responds to me after 10 seconds
So, with the same tactics, I want to know what the length of the DB. is My command here will make the server responds after 10 seconds if the length of the DB is 5 or 6 or 7 or 8 or 9 or even 10. First, I will set the length as 5 and we will monitor the response “select case when (length(current_database ()) = 5) THEN pg_sleep(10) else NULL end”
Seems 5 is not the answer as the server responds quickly to my request. We try another value which is 8. It is finally sleeping 10 seconds. That’s mean, the length of the DB is 8