We covered a simple demonstration of XML External Entity Injection vulnerability which is part of OWASP Top 10. This was covered as part of HackTheBox baby WAFfles order challenge.
Initial Exploration
I started by interacting with the web application, which appeared to be a to-do list. I could add tasks, mark them as complete, or delete them. I noticed that for every action, there were “complete” and “delete” options.
Source Code Inspection
I viewed the page source to understand how the application worked. I found that when a task was entered, a POST request was made. This request included the task itself and a secret_key. This secret_key seemed to be an important piece of information. I also discovered a JavaScript file (main.js) being called and a comment: “don’t use get status all until we get the verify Integrity patched.” This hinted at a potential vulnerability in the verifyIntegrity function within main.js. The script also used a getTasks function associated with a randomly generated user ID, and it updated tasks every three seconds.
Analyzing main.js
I examined the main.js file. I found that the “complete” and “delete” actions made GET requests to specific API endpoints (/api/complete and /api/delete), and these requests also included the task_id and the secret. The getTasks function made a call to /api/list/endpoint, also including the secret. My hypothesis was that if I could find other accessible endpoints under /api/list/, I might be able to access tasks not intended for my current user, especially if the user had elevated privileges.
Fuzzing for Endpoints with Wfuzz
To discover these hidden endpoints, I decided to use a fuzzing tool called Wfuzz. Before running Wfuzz, I needed to identify all necessary parameters for the request. I used Burp Suite to capture a request when adding a task. I observed a POST request to /api/add which included a session ID in the cookie. This session ID and the previously found secret_key would be crucial for the Wfuzz command.
Constructing and Running Wfuzz Command
I constructed the Wfuzz command to fuzz the endpoint part of the URL /api/list/ENDPOINT_TO_FUZZ?secret=SECRET_VALUE. I initially used a wordlist from seclists/Discovery/Web-Content/API/api_endpoints.txt. I filtered out common non-existent page responses (like 404s with a specific character count) to narrow down the results. When the first wordlist didn’t yield results, I switched to another wordlist: seclists/Discovery/Web-Content/API/objects.txt.
Discovering the Vulnerable Endpoint
After filtering out 404 and 403 responses based on their character counts, Wfuzz revealed a valid endpoint: all.
Accessing the Flag
I then tried to access the /api/list/all endpoint. Initially, it was disallowed. I realized I needed to append the secret to the URL: /api/list/all?secret=SECRET_VALUE. This allowed me to see all tasks for all users, including a task entered by the “admin” which contained the flag.
Technical Commands Used in the Terminal
- To start the Wfuzz scan with the first wordlist:Bash
wfuzz -w /usr/share/seclists/Discovery/Web-Content/API/api_endpoints.txt -b "session=YOUR_SESSION_ID" http://TARGET_IP_OR_DOMAIN/api/list/fuzz?secret=YOUR_SECRET_KEY --hc 22 - To start the Wfuzz scan with the second wordlist and additional filtering:Bash
wfuzz -w /usr/share/seclists/Discovery/Web-Content/API/objects.txt -b "session=YOUR_SESSIO
