Finding Hidden Features
Table of Contents
Fuzzing to Find Hidden Features
Persistence is essential. Especially in our field. Recently, my team and I came up against a COTs application that seemed secure and well configured.
Over the course of two weeks, we meticulously followed the OWASP testing guide, extensively enumerating every feature of the application. Despite our thorough efforts, we initially found no vulnerabilities. It wasn’t until the end of our assignment that I decided to delve deeper by fuzzing directories several levels deep, driven by a determination to find anything that might have been overlooked.
Let There be Fuzz
There are several tools we can use for fuzzing in scenarios like this, but I prefer to stay inside Burpsuite for most of my testing needs. We can simply send our request to Intruder and highlight what we want to fuzz. It’s worth mentioning that you need Burpsuite Pro to avoid rate limiting. Once in Intruder, typically, I select the parameters I want to fuzz, highlight them, and click “Add.” Then, I choose my wordlist, depending on what I am targeting. SecList usually has what I need. It’s important to try several different wordlists when fuzzing. One that I have found particularly useful for APIs and even some directories is the api-res wordlist under SecLists>Discovery>Web-Content>api>api-endpoints-res.txt.
Finally, I’ll configure the speed at which we want to fuzz. Although it’s unlikely, we don’t want to overwhelm the server in any way, so I usually reduce the number of concurrent requests to two or three. Next, we start fuzzing. Another crucial aspect of fuzzing is filtering our results. Fortunately, Burpsuite makes this easy. We can search for specific words, depending on the type of testing we’re conducting, or we can sort by response codes, sizes, etc.
So, utilizing various wordlists, I began probing deeper into the application’s directory structure. Interestingly, I discovered that accessing the endpoint /01 of a certain path redirected to that path’s main page, while /02 led to a secondary page, if it existed. Encouraged by this pattern, I continued with /03, /04, and so on. This approach started revealing some new, unindexed pages, some of which were admin pages that had not been identified in earlier phases of testing.
To exploit this finding systematically, I created a wordlist ranging from 1 to 50 using seq and resumed fuzzing across all known paths. This unearthed several intriguing pages, but one really stood out: it was used by admins to send notifications to various user groups within the application, including other Admins, regular users, and other specific groups.
To assess how the receiving end of these notifications handled the user input of the administrators, I executed a test by sending a notification to our pentester group that included an XSS payload similar to the one below:
<img src=1 onerror=console.log(document.domain);>
Surprisingly, when they received the notification, the page included it without any sort of validation or sanitizarion. The JavaScript executed, confirming stored XSS. This experience underscores the indispensable value of fuzzing in penetration testing and bug bounty hunting. As bug bounty hunters, we don’t have all the time that threat actors do to enumerate our target. And so, we must prioritze our activities. If we don’t fuzz, we truly don’t know what vulnerabilities lie hidden, waiting to be exploited. This single finding alone illustrates why thorough testing, beyond standard enumeration, is crucial for uncovering deeper security flaws. Try harder!