Burpsuite is an open application that is commonly used by penetration testers to test processes -- mapping and analyzing an application’s attack surface -- and finding/exploiting vulnerabilities within web applications.
Burpsuite is especially useful for fuzzing. Fuzzing is an automated process to test element(s) on web applications for information or vulnerabilties. Some examples are when we fuzz passwords for brute-forcing or subdomains for web-page enumeration. Though there definitely are other tools (i.e. hydra, gobuster, ffuf) to accomplish this, Burpsuite combines many of these tools into a single application.
For this demonstration, we will go over some basic tools and familiarize ourselves with Burpsuite. We will then examine the results and find ways to exploit it against a web vulnerability.
We’ll get started with a simple password fuzzing.
**Big thank you to TryHackMe, as all the questions/samples have been pulled from there. If you’d like to follow along, I’ve attached the Task title for the corresponding demonstrations.**
SAMPLE I (pulled from Advent of Cyber 3 Task 9 Day 4)
On the web page we are given some user inputs to login. We’ll start off by tuning our Burp Proxy on. For Burpsuite and FoxyProxy set up, refer to this link
--> https://blog.nvisium.com/setting-up-burpsuite-with-firefox-and
From our challenge we are given the username “santa”, but we do not know the password. Since we don’t have the proper credentials, we can start off by inputting the Username: “santa” and makeup a random password. While the login will obviously give us an error, we can intercept the request using burpsuite and examine the http request being sent to the server.
Go to proxy and intercept the request; we’ll notice the data username and password (and submit) are being sent over to the server as a POST request.
By right clicking the request and sending it to the “Intruder” tab, we can now select the values we want to fuzz.
Go to “positions” and clear $. Next, select only the random password value we inputted from earlier and add “position”. Keep in mind, we are attempting to brute-force santa’s login information so all other data values, except password, should stay the same.
Go to Payloads tab; we are using “1” payload and we will stick with a “Simple List” for the payload type. Since the challenge gives us a list of possible passwords to fuzz, we will simply copy the list and paste it into the Payload Options.
The results spits out a list of all the passwords that have been fuzzed. From here, the Status code or the Length of the results might be useful indicators for finding useful information. Try filtering Status and Length.
For this particular attack, we’ll see that only the result “cookie” has a status 302, and a length of “2548” bytes; the rest is 200 and 2573 respectively. The status 302 is a redirect code, possibly indicating that the password works by redirecting us to santa’s dashboard.
Let’s check -- go back to the site and enter credentials: username “santa” and password “cookie”.
And great!! We’ve managed to successfully login as “santa”
Let’s use Burp to fuzz something else. This time, we’ll try fuzzing the url of a webpage, which is particularly helpful for enumerating subdirectories and hidden pages. This can be especially useful for exploiting an Insecure Direct Object Reference (IDOR), a type of access control vulnerability. IDOR occurs when a web page’s user input data is not properly validated. In other words since a web server receives a user-supplied input to retrieve files, documents, data, and malicious actor might fuzz a request and spoof themselves as another user. This will make more sense in the exercise! Let’s take a look.
SAMPLE 2 (pulled from Tryhackme IDOR task 7)
In this new example we have a customer login page; interestingly enough we also have a page to “signup” for a new account.
Make an account
Username: “hello”
Email address: [email protected]
Password: “password”
Login with the credentials from the user we just created.
When we head over to “Your Account” we’ll notice something interesting in the url. Here is the full url (as since it is cut off in the screen shot below)
à https://10-10-109-180.p.thmlabs.com/customer?id=15
The query parameter with id=15 suggests that the value is for our new user, “hello”, but since the information is open in the url we should be able to change the data and potentially view the site as another user. This is where Burp comes in; send the request to the Intruder tab like the exercise before.
Clear Positions again, but this time add Position for our “15”, since id=“15” is the query value we are fuzzing,
Change the Payload type from “Simple List” to “Numbers” ** note that we can manually add a different list to fuzz in the Payload options – like we did in for the brute force example; in this example, the id values are all numbers, so we are opting for the Numbers Payload type.
In the results, we can check ID=15 and verify again that we’ve created the username “hello”. I also notice that the results greater than 15 all give me a 404 status error, so there are only 15 IDs present.
If this was a larger list, we might want to target specific results, like the “admin” account . In the Results window, go to Options and add the term “admin” to Grep-Match.
Back in our results we’ll find both ID=6,13 produces the admin ID and email. We can also enumerate other users and their emails by looking through all other ID values that returned with a 200 status code.
Let’s leverage the information we’ve learned to exploit another vulnerability on this site. Can we steal the admin’s password by using a logic flaw within the “reset email” button in the login page? Let’s find out.
When we signed in from the new user (“hello” that we created earlier, we might’ve noticed that the Support Tickets page had a message:
We might’ve also noticed a password reset button during the login page. Perhaps we can tweak the password email request for admin over to the “hello” account’s email, and receive the reset as a Support Ticket? Let’s try it.
Enter the admin’s email and username that we found from Burpsuite into the Password reset page.
Check the network tab and the email reset request. Notice that this is a POST request, and within the url, we see that the email is being sent to [email protected].
Though we can use Burp to resend this request, this time let’s try using the inspector tab from Mozilla Firefox. The results should still be the same when we are editing andresending the post request.
Edit and add “&[email protected]” to Request Body. Then “Resend”.
**remember, the [email protected] email was generated from the previous exercise. we are redirecting the admin password reset to this emai instead of admin’s.
When we login as the user hello and check “Support Tickets” we see the message “Tickets can be created using the below button or by sending an email to your custom address [email protected]”. If we properly manipulated the POST request, we should be receiving a Support Ticket for a Password Reset from our hello account
Awesome! We are given the direct link to login, and then reset admin’s password. In case you can’t see the link from the screen shot here it is
--> http://10-10-109-180.p.thmlabs.com/customers/reset/0108bd8d8992415854e7d394ef3470fa
Upon visiting the link, we have successfully logged in as admin! From here we can reset the admin password and claim it for ourselves.