Admin Panel Disclosure

Hi, guys. I am David, a software developer and a security researcher. I recently made a new year resolution to be documenting each bug i find in any known application / bug bounty program. So, this is my first security findings write-up. Let’s go !!!!!!!!

I wasn’t permitted to disclose the target, so let’s call the target - redacted.com

I found this target via google dorking. Before my recon process, i just randomly navigated round the application. It’s not an application with much scope, which made me worried a bit, but then i still continued. After navigating around, i started my recon with subfinder and amass for subdomain enumeration. Unfortunately, there were no subdomains found.

In addition to the small scope, there were still no sub-domains. But you know what, giving up was never an option. I left the application at that point and came back after 3 days fired up and ready to devour. Hahaha !

So, i now decided to access the waybackmachine for urls and endpoints. I use waybackurls and gau.

cat <(waybackurls redacted.com) <(gau redacted.com) | sort -u > combined-urls.txt

To my surprise, i got a total of 16857 rows

What next ? I filtered for live urls using httpx-toolkit. Now got 12568 rows. Now, when accessing the urls individually, it returned a 404 error. This has to be frustrating, almost all the urls were returning a 404 error. I had run the httpx-toolkit again and filtered based on content length, and still didn’t get what i wanted. I also FUZZED through for endpoints, still wasn’t getting any valuable result. It’s now time for manual recon. I fired up my burp, proxied all my requests and started navigating round the entire application to get something interesting.

After a while, i stumbled across a backend API service that the application was using to render data.

This was the format of how the API delivers data to be rendered by the application. Now, lets target the API directly. Normally, for me I start API testing by FUZZING, using Assetnote’s wordlist. A valuable wordlist. I fuzzed all through and got nothing valuable. Mind you the application was built in NextJs. I was able to figure this out with the help of Wappylyzer. So, there are defined routes on the server.

I continued navigating manually through the website and got across their authentication pages. ( Register, signup and forgot-password). I started with testing the forgot-password page. and inputted random userID just to know the response and how the application treated the input. It returned 400 error, instead of a 404. Now then, i tried testing with NULL values to see the response. And surprisingly, it returned a 200 Ok Response.

We finally found something Interesting to hold on to !!!!!

Now, that phone number in the response, was actually the phone number in the contact us page. Are you thinking what we are thinking ? We just sent a reset password OTP to reset the Admin’s account. But the issue now was how can we get the OTP code. what came to my mind was prototype pollution. I immediately remembered playing a CTF on hackthebox about prototype pollution on still the same NextJS server, but a different version. I tried to craft the request body like this

{
   "userID" : null,
   "phone" : "+1xxxxxxxxx"
}

It still didn’t work out as expected. I could have created another account and done some tests with it. Because for stuffs like this, it is a very good technique to test with two accounts, but then i couldn’t create account on the application, due to some reasons. But why not i give it a try ?

I then navigated to the /register endpoint and then used the same technique i used for the forgot-password functionality. By setting the input fields to null. And then, it returned a 400 Error code, with message “User already exists “. This is strange. The application is performing validations on the front-end but not performing proper validations on the backend. That’s one issue among developers, they usually think the client side is the only way a user can communicate with the server. Most don’t know the request can be intercepted and modified with the help of an interceptor like Burpsuite or ZAP or any other known ones.

Deductions

The register endpoint with Null value => 200 ok (“user already exists”)
The forgot-password with Null value => 200 ok (“Password reset code, sent to phone number”)

Hehe ! Something good was coming, what came to mind was now to test the /login endpoint and hopefully, it returned a 200 OK login successful message and redirect us to the admin dashboard.

We tried it and BOOM !!! we got access to the admin dashboard, with the bearer token.

I was able to see every damn functionality. From here, i can deface the application and do alot of things. But the application was a live and active one, so i just reported the bug.

FIXES

The main issue here was how the application failed to validate input before processing it. I think this can be fixed if there was proper validation at the backend.

THANKS FOR READING !!!!!! don’t forget to share your comments.