4500$ bounties on a single Web Application (API Hacking)

Intro,

Hi, its me again.

In this write-up I will talk about my four bugs (one critical and three of medium severity) I discovered on a single web application two month ago. All vulnerabilities are API related, So I hope you like it.

I will try my best to write in a way that if you are not a tech guy, would grasp something:) but if you know basic just ignore TLD (Too Long; Didn't Read) part. OK, without wasting you time lets jump right in.

Bugs,

First, the Critical one!

IDOR leads to view all users’ bank details

I really dont know how and where should I start. Lets start from the very beginning, I was invited in a private program on HackerOne. The Scope of program was just two main applications. So, I picked one and started creating an account. After exploring it for two or three days, checking all functionalities I thought it is safe.

But, I found the first bug! the critical one! The functionality of application enables users to connect their bank accounts. When they navigate to their Dashboard an API call was hit to show the details of their bank details.

The API endpoint was like:

GET /api/payment-method/
HOST: domain.company
Authorization: Bearer faketoken1234567890
Content-Type: application/json

The response was in JSON format, actually it was empty for me. because I did not connect my bank account. We have a popular quote which says, “Test IDOR in requests which return sensitive data!“. If you have not heard it, So keep it in your mind and repeat it while hunting :))

So, lets talk what is IDOR? TLD (Too Long; Didn't Read)

IDOR (Insecure Direct Object Reference) is a security flaw where attackers can access data or perform actions they shouldn’t be allowed to, simply by changing a part of the URL or request. For example, if a website uses a URL like:

https://example.com/user/123

where "123" is your user ID, an attacker might change "123" to another number (like "124") and get access to someone else's data.

It’s like walking into a building with open doors, where each door is labeled with a number, and you can open any door just by knowing its number, even if it’s not your room. This is dangerous because it exposes sensitive information that should be protected.

What now? Our API endpoint does not have numeric value? Does it? NO, but we add a random value at the end of API endpoint it will become:

GET /api/payment-method/1 # this 1 is a random number
HOST: domain.company
Authorization: Bearer faketoken1234567890
Content-Type: application/json

After sending the request, the response was 404 Not Found :( no way, it is not vulnerable you may think. But no bro, In the "Hacking APIs: Breaking Web Application Programming Interfaces" book by Corey J. Ball, we read that “familiarize yourself with the API's structure and patterns.“ Therefor, when I saw all endpoints I noticed that, every endpoint has a / at the end. I mean all endpoints were like:

GET /api/payment-method/
GET /api/change-name/
GET /api/dashboard/

So, I told myself Lets add a simple / at the end and send the request and guess what? The response was all bank information of user 1 in the database! NO WAY! by changing the number from 1 to 8k we were able to view all users’ bank details.

HERE is the Screenshot of real request:

After finding this, I wrote a detailed report and sent it to the program. After about 20 minutes I got a replay saying, “We are working for the fix!”

After 40 mins the severity was changed to HIGH, but then it was changed to CRITICAL. Asking me if the 192.168.1.1 IP (this is obviously not mine) belongs to me or not? I confirmed that the IP belongs to me by showing a screenshot. After 10 minutes I was awarded 3000 dollars:) All process took lesser than an hour.

I got confidence and told myself to dig a bit deeper and not change the program because I have a bad habit. After working a week, i change the program which i will urge you and myself to not do it anymore.

Second, IDOR leads to view users address

After finding the first bug, I became even more motivated to uncover additional issues. As the saying goes, 'Programmers often make the same mistakes,' and that proved true here. I found another IDOR vulnerability with similar logic on a different endpoint. Although the value wasn’t numeric, it was still a short, random value that I managed to find it. So, lets moved on to the third bug.

Third, Hidden API endpoint enables attacker to update bank provider, name, phone number

I found the endpoint within JS files, normally I do not look for endpoints in JS files. I just crawl all functionalities of application while Burp Suite is on in the background and then trough GAP (which is a Burp Suite extension) I find all endpoints, parameters and word.

So, I found some endpoints and tried to fuzz all of them trough intruder. One of them was /api/user/info/ endpoint. A note I should add is, I fuzz with all methods e.g. GET, POST, PATCH, PUT and so on.

while fuzzing I got 200 OK for that endpoint with GET request method. the response of my request was my name, phone number, bank provider and some objects. So, i was thinking if I can see the response, I might be able to change them as well. Because there was no functionality to change your details. So, I changed the request method to PATCH and copied all response’s data from previous response and paste it to the request,

When I hit send, I got a 200 OK, indicating the change was successful. To confirm, I updated my name, checked the UI, and found that my name was indeed updated. I was also able to modify my phone number and bank provider with similar success.

At first, I didn’t report this vulnerability, thinking it might not be accepted. But a week later, I decided to submit it, and they awarded me $500 for the finding!"

Forth, Mass assignment leads to Bypass phone verification, updating it and updating Name, Address

While hunting keep in mind that you should click on any functionality, navigate to every part of application. In my case I found an endpoint which was responsible to update users’ address. Investigating the Request, I noticed there are first_name, last_name , phone_number fields. While changing them from null to a random value, I got the 200 OK, response with applied changes. I should say that, there was no functionality to change our names so, it was one impact. but the real impact was that we could enter our number without verifying it (by OTP). I wrote a report and it was accepted as a medium severity vulnerability. Bellow I attach the request.

I have already found an Open Redirect on this app, but i have not reported it yet. because it is out of scope. The good news is, “the application is being updated” (according to its help section). So, I am monitoring it regularly to see if there is a new functionality or not.

Final Words

Do not waste your time finding subdomains. just focus on main applications. So I hope you find it insightful. Be Happy, Be Nice.

See ya :)