Hello Hackers, After a long time… I am back again 😀. In this write-up, I am going to share a recent bug I discovered during a freelance penetration testing engagement. The bug chain I discovered was:

IDOR → Admin Panel Takeover → SQL Injection → Database Dump.

Due to NDA restrictions, I cannot disclose anything related to the target website. However, for practice purposes, I have created a similar website that contains two flags:
1. user.txt
2. root.txt

Give it a try 🎇 and let me know in the comments how your experience was. So, let’s get started!

Here is the CTF challenge 👩‍💻:
https://ctf-lab-production.up.railway.app/

Give your best shot, and if you get stuck, don’t forget to check the hints 💡.

I was given a wildcard domain, something like *.abc.com. As part of reconnaissance, I did a little bit of Google dorking and ran well-known tools such as subfinder and dnsdumpster. Eventually, I discovered a subdomain that looked something like xyz.target.com.

When you visit the site, it redirects you to the /login page. Nothing special there. So I ran multiple fuzzing tools like ffuf, dirb, and gobuster. I also searched for parameters captured by the Wayback Machine and ran katana to crawl the website.

Luckily, I found a crawled path that looked like this:

https://xyz.target.com/abc/authenticate:[email protected]:cryptoshant

From the URL, we can clearly see that it is leaking user credentials. So I visited the /login page and tried the credentials, and to my surprise, they worked! 👀

Now I started exploring the user dashboard and other features in the account. But the real thing began when I visited the endpoint /profile.

I made a small change and clicked the save button, then captured the request. I noticed that the request contained a user_id parameter that appeared to be easily guessable. At that point, I thought: why not test for an IDOR?

And it worked 🎆.

Next, I tried enumerating user IDs. Eventually, I found the admin user_id and was able to obtain the admin email address.

Real Request:
GET /user/profile/1 HTTP/1.1
Host: xyz.target.com
Cookie: cookie
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Origin: null
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=0, i
Te: trailers
Connection: keep-alive

The next interesting part was that they had a password change functionality under the /profile endpoint. The surprising part was that it did not require the old password 😁.

So I simply set a new password and confirmed it — and that’s it!

Real Request:
POST /user/update_password/2 HTTP/1.1
Host: xyz.target.com
Cookie: cookie
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 96
Origin: null
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=0, i
Te: trailers
Connection: keep-alive
_token=token&password=admin123&password_confirmation=admin123

Now I had changed the admin password and already knew the admin email address. I logged out from the user account and logged back in using the new admin credentials I had set.

As expected, the admin panel contained around 16,000 users’ PII data, which was exposed. Here is a glimpse.

Out of curiosity, I also discovered an SQL Injection vulnerability after accessing the admin panel. I found an internal API request made to the backend that was not properly protected. This allowed me to explore more details related to the backend system.

In the end, I compiled all the findings and reported them to the relevant team. They are currently working on upgrading their system.

The SQL Injection part will be disclosed later in the CTF challenge write-up. So give it your best shot! I am pretty sure you will be able to find both flags easily 🤗.

Again, here is the CTF link:
https://ctf-lab-production.up.railway.app/

I know that this type of bug is becoming harder to find nowadays since systems are becoming more secure. However, don’t forget that these types of issues still exist on many websites. Once you find a lead, don’t stop there — try to explore deeper and deeper.

In my case, I had no fear of duplicate reports since I was the only person testing their product so I explored more and more. I hope you learn something new from this write-up.

Thank you for reading! I hope you try the CTF and learn something new from it.

See you in the next one. Bye 👋