Hello everyone! I am a final-year cybersecurity student currently diving deep into penetration testing. In this writeup, I will walk you through a CTF challenge provided by HackerDNA, specifically the ClearDesk lab. Lab Link: https://hackerdna.com/labs/cleardesk.
Reconnaissance — The Foundation of Security Testing
In this lab, I utilized dirsearch, a powerful command-line tool designed to brute-force directories and files on web servers.
Command:
dirsearch -u 18.203.83.186
or you can specify a file extension, exclude error Ticket not found, and make sure to grant permission so that a 401 error doesn't occur—add the user's session cookie by
dirsearch -u http://18.203.83.186/api/ticket/ -e php,txt,json,html,.env --exclude-text "Ticket not found" -H "Cookie: session=eyJXXXX"
Upon accessing the /api/ endpoint, we are greeted with a JSON response that serves as the API's documentation. Although it states that authentication is session-based and requires logging in via /login first, the exposure of these endpoints is critical. It provides a direct map for an attacker to perform targeted enumeration. Specifically, the existence of /api/user/<id> and /api/ticket/<id> strongly suggests that the application might be vulnerable to IDOR, as it relies on predictable numeric identifiers for sensitive resources.
Upon successfully logging in, I was presented with the user dashboard. A closer inspection reveals two primary functional areas that serve as our main attack surfaces:
- View Profile (API): This feature interacts directly with the
/api/user/endpoint to fetch and display user information. - Tickets: A helpdesk module that allows users to view support tickets via the
/api/ticket/endpoint.
If you access the profile view, the app displays the user ID in the URL. This is dangerous because if access controls aren't properly configured, it could lead to an IDOR. Let's try it.
As you can see, when the ID is changed, it displays another user's profile. Search for the admin user, and then write down the ID so you don't forget it.
After successfully confirming an IDOR (Insecure Direct Object Reference) vulnerability within the 'View Profile' feature, I shifted my focus to the 'Tickets' module.
And boom! My hypothesis was correct, the Tickets module is also vulnerable to IDOR. This confirms a systemic failure in the application's authorization logic. The server responded with the full details of a highly sensitive administrative ticket. Nestled within the ticket description was the first Flag, ready for submission.
What comes next? Now that we have proven the existence of a systemic IDOR, our goal shifts from viewing data to obtaining administrative control. The objective: gain the credentials necessary to log in as an Admin.
And boom! My persistence paid off. Through targeted enumeration, I discovered a specific ticket containing not only another flag but also the Administrative Credentials.
Here is a screenshot of the admin panel
The Final Strike: Exploiting Path Traversal for the Root Flag
After gaining access to the administrative dashboard, I identified a "Log Viewer" feature. This feature interacts with the /api/logs endpoint, fetching internal system files like system.log.
In a secure system, this feature should only allow access to a specific "allow-list" of log files. However, based on our earlier analysis of the application's weak authorization, I suspected a Path Traversal (LFI) vulnerability.
Recalling the flag name discovered in the previous administrative ticket, I intercepted the request to the log viewer. I modified the file= parameter, replacing the standard log filename with the path to the root flag we were searching for.
And yes! The lab is complete. The server blindly followed the input path and rendered the contents of the flag file directly in the response. By chaining IDOR, Credential Theft, and Path Traversal, I successfully escalated from a low-privileged intern account to achieving a full system compromise.
To secure ClearDesk, developers must implement strict server-side authorization checks (BOLA) for every API request and enforce robust input validation on the file-reading feature to prevent directory traversal attacks.