Bypassing WAF, 403, and OTP to Exploit SQL Injection
In this blog post, I’m going to share my experience exploiting a SQL Injection after bypassing WAF, the 403 Status Code, and OTP on a VDP program. I won’t go through my recon process here, as I’ve covered it in a previous XSS writeup, which you can read: 403 Forbidden? No Problem, Here’s a POST XSS.
Bypassing the 403
After opening up subdomains one by one, I stumbled upon a subdomain called legacypanel.redacted.com. However, the first thing I encountered was a “403 — Access denied.” As usual, I entered a dummy path to test whether this was a stubborn 403 on all paths or only on the main domain.
legacypanel.redacted.com/dummypath
After entering the dummy path, the code changed from 403 to 404, indicating that the 403 restriction was only applied on the main domain and not on other paths. The next step involved conducting a directory brute force on the target using my private wordlist. Following the fuzzing process with ffuf, I discovered the existence of a /dashboard path.
Bypassing the OTP
Upon accessing the dashboard, I encountered a registration page. I went ahead and registered, and the web application informed me that they had sent an OTP, but alas, the OTP was never sent to me.
So, I had already bypassed a 403, conducted a fuzz, but should I surrender just because the web application didn’t send me the OTP to my email? You can probably guess the answer :) Well, the answer is YES. I gave up, feeling hungry and tired. After a 30-minute break, I returned to the work.
There are several ways to bypass the OTP, and I tried these things:
- I attempted to brute force the OTP code, but there was a rate limit, so I failed.
- I experimented with magic OTPs, and as you can guess, I failed.
- I tested a Race condition on OTPs, and again, I failed.
But, I finally found a way to bypass the OTP. The OTP was coming back in the response, and I had spent 30–45 minutes attempting various bypasses when the only necessary thing was to look at the responses. So, I entered the OTP and jumped into the web application.
WAF Bypass
The user dashboard of the web application featured a handy search box, allowing users to keep tabs on their orders and tickets. My initial experiment involved inputting a SQL Injection payload, specifically 1234', which triggered a noticeable shift in the web application’s behavior. This alteration raised my suspicion, prompting me to consider the possibility of a SQL injection.
After injecting a single quote, I tried the following payload:
1234' and sleep(5) --
Can you guess the output? WAF BLOCKED me. Now, I needed a way to bypass the WAF.
I changed my payload to the following:
1234'/**/and/**/sleep(5) --
It didn’t work. Then, I started capitalizing the words in the payload:
1234' // AND // slEEp(5) --
I got blocked again. I modified the payload to:
1234' %2F%2A%2A%2FAnd%2F%2A%2A%2Fsleep(5) --
If you’re thinking I got blocked by the WAF, you’re spot on — blocked again. The tricky part wasn’t the space or the comment; it turned out to be the closing parenthesis of the sleep() function. After scouring search engines and reading through some subreddits, an idea sparked in my mind.
The solution? Combining the payload with a URL-encoded newline. I tweaked the payload to incorporate this newfound insight:
1234'%2F%2A%2A%2FAnd%2F%2A%2A%2F%0Asleep(5) --
And? WAF blocked me again :(
Then I changed my payload to:
1234'%2F%2A%2A%2FAnd%2F%2A%2A%2F%0Asleep(5%29--
And after implementing the final payload, success was achieved.
Reporting
I diligently compiled a comprehensive report (although I must confess, the report was bad :))), and promptly submitted it to the program. With a sense of accomplishment, I concluded my day as a contented hunter.
Conclusion
My journey through bypassing OTP, WAF, and the formidable 403 barrier to exploit a SQL Injection was both challenging and rewarding. From the initial hurdles of access denial to the intricate maneuvers required to bypass security measures, each step presented its own set of obstacles and lessons.
Through persistence, experimentation, and a dash of creativity, I uncovered vulnerabilities and devised strategies to overcome them. While some attempts ended in failure, each setback served as a valuable learning experience, pushing me to explore new approaches and refine my techniques.
Ultimately, the successful bypass of the OTP and the execution of the SQL Injection underscored the importance of perseverance and adaptability in the field of cybersecurity. By sharing my experience, I hope to inspire others to approach challenges with a tenacious spirit and a willingness to explore unconventional solutions.
Thank you for joining me on this adventure. Until next time, stay curious, stay vigilant, and happy hacking!