As part of our cybersecurity bootcamp, we engaged in various Capture the Flag challenges, including a web security CTF aimed at familiarizing us with Burp Suite. One of the challenges we tackled was called “Admin has the power,” available on the Cyber Talents website.
To overcome the challenge, we utilized Burp Suite, specifically leveraging the proxy and repeater modules, along with the built-in web browser. Although the challenge was short, we found it more efficient to configure Foxy Proxy as our proxy tool to forward the request data to Burp Suite, eliminating the need for manual clicking through each stage of the HTTP requests.
The initial page presented to us appeared in the right-hand pane, featuring a simple login screen with a username and password field, as well as a sign-in button. Burp Suite rendered each HTTP GET request in a separate pane, displaying the raw HTML GET request on the left. By selecting the “pretty” tab, we could view the HTML code of the page instead of the rendered version.
We had to resend the exact HTTP GET request since we had initiated the proxy capture after our initial loading of the web page. To explore potential avenues for gaining admin access, we began by analyzing the HTML code of the login page to understand its structure and identify elements that could be manipulated. Fortunately, the HTML code contained a commented line disclosing the login information for a support account. We decided to attempt logging in as a support user using that information. Line 30 of the right-hand pane displayed the relevant information.
Upon logging into the support account with the credentials found in the HTML code, we encountered a static web page. However, our objective was to become the admin rather than a support user. Despite the promising start, it seemed we had reached a dead end. We returned to Burp Suite to investigate if any valuable information had been generated in the HTML requests exchanged between the web browser and server, specifically focusing on the “cookies” pane associated with the GET request responsible for retrieving the support page.
Sending the login data to the server resulted in the generation of a cookie containing our role as “support.” As indicated, better privileges were necessary to capture the flag in this challenge, requiring admin access rather than support access.
Analyzing the cookie information sent to the server, it was evident that our role was specified as “support” since we logged in as a support user. Our next step involved attempting to manipulate the HTTP request to deceive the server into recognizing us as an admin instead of a support user. We aimed to achieve this by submitting valid login information while altering our role from support to admin.
To carry out this manipulation, we transferred the HTTP GET request to the repeater module in Burp Suite. This allowed us to modify the request and resend it to the server, with the hope of tricking it into granting admin privileges instead of support privileges.
By making the necessary modification within the repeater module and resending the request, we succeeded in fooling the server. Consequently, the server returned the page intended for “admin” users, and we successfully captured the flag. Although a simple exercise, it demonstrated a fundamental workflow for testing web pages using Burp Suite.
Furthermore, while this manipulation method is rudimentary and incapable of breaching a bank or an enterprise website, we should note that numerous websites created by freelancers or business owners themselves—particularly those belonging to local businesses—may be vulnerable to this type of attack. Websites featuring a straightforward customer login interface that neglect proper security practices could be susceptible to breaches similar to the one we accomplished during this exercise.
