BBP#1 (BugBountyProgram Story) Zolo

Devender Rao

Published in

InfoSec Write-ups

6 min readOct 16, 2023

Story:

I was going to sleep after dinner, and got a Phone call,

Dear Sir, We have received a scheduled visit to our hotel when you are visiting, kindly share the timings.

I was confused, as I hadn’t booked any hotel. Then he shared more details that they received a lead from Zolo, that you are visiting our property today. Then suddenly I remembered the #5 bug which I discovered 2 years back might be related to this.

Note:- For now, All these bugs are fixed and Zolo’s Bug Bounty Program is paused. So Don’t test them, you will get nothing ;(
Time Invested:- Jan 2020 to Dec 2021, they paused it after. Always give time to your program and learn it whenever there is a new feature.
Scope:- Mobile app and the Website.

1. No Rate limit

Description: When the resource can be accessed n times within a short time frame.

This can be while we comment on any post, verify the OTP, or create posts.

There was already a rate limit applied on the endpoint of 5–10 requests for a single Phone number in 1–2 hours.

Bypass :-

There were 2 Parameters, Phone_number, and otp_type. So in OTP_type if we give any value it will accept and OTP will be sent. This rate limit was bypassed, as the otp_type will be different for every request it will treated as a new request.

After the fix, I found that the rate limit on OTP verification was not working and can bypass the OTP with bruteforcing (6-digit OTP), it will take time but the OTP does not expire, and no rate limit on the endpoint.

Turbo intruders can be used here 1k-5k request per second as per server and your ISP throttle limit.

Fixes:- 2nd Parameter removed, OTP will expires after 10mins and 5–10 times check
Note Taking:-
Always check all parameters in the request and what’s their impact on the response and application. Twick with settings, even if you don’t know

2. Infomation Leak

2.1 When Checking User existence

Excessive information was leaked while checking the availability of the phone number. When a user registers, the website checks if the user is already in the database or not and if there it will give back some information regarding the same.

The endpoint was public and without any rate limit. Email was not there, so not much impact but email/mobile verified or not and the employee status was there.

2.2 When the User review some property,

If you booked any room and gave the review, you can check the other user’s review also. But When I was checking the name was displayed on the front-end but while checking the complete response, the user’s Phone number was there.

The phone number is PII, and there is no need to be there.

You need to visit every property(room) and check for the review and you will get the user’s PII right there.

2.3 When User Booked the Property

When the user booked the property, they will be contacted back by the property owner but you can not contact them as per policy. I found an endpoint where I was able to get all the details of the property and it includes the owner details . After checking the burp history I was able to find the endpoint.

Fixes:- Additional information was trimmed from the response.
Note Taking:
Always check Burp history and the sitemap, this might give enrich information regarding the different and hidden endpoints as well as site structure

3. Email Verification was Bypassed which caused ATO (Account Takeover)

After successful user registration, a request is sent to the server which saves the user information (PATCH /api/v4/profile ) in the db .

And you will never see this request again once you register, not when you do any updates to the account. The trick is here, if my email is already verified and if I send this request again with the parameters exactly the same as the profile details, but change in email address so my email will be changed and also verified.

So I was able to verify abcd@gmail.com,

So ATO? , when we log in the OTP is sent to both the Phone number and email address.

The Platform allows multiple accounts on the same email, but it was also a bug.

Now ,

Victim => 9012345678 Email => attacker@gmail.com (chained this bug with CORS and we were able to change the email address as verified)

Attacker => 7012345678 Email => attacker@gmail.com

When the Attacker logs in with the Victim’s phone number, the otp sends both the Victim’s phone number and the attacker’s email address. As we own the email we can log in without the phone number’s requirement.

Note-Taking:
Sometimes it is not a bug, it’s a feature, But you need only the mindset that can make any feature a bug :)

4. Phone Number Changed

When a user does the KYC, the details of the user update again and the system doesn’t check the parameters are changed and update them in the db.

But here is a catch, what happens if the victim already an account on the Phone number? The account is updated with our phone number, which means the previous phone number is deleted :>, I didn’t notice this in the early stage.

The attacker can change the Phone number with the victim, and when the victim will login, we will receive the OTP on our email too,

But After changing the Phone number, when the victim login, it will sign up to the platform which means earlier data of the account was removed.

Attacker => 9012345678 Email => attacker@gmail.com
Victim => 9012345678 Email => victim@gmail.com
(account deleted)

The bug was a bit confusing and they fixed it quickly before I did any other test cases.

5. Scheduling the Visit

This is the bug, due to which I am writing the blog….

Users can schedule a visit to the property before booking, normally, they allow 90 days to book in advance, but due to restrictions on the client side, I could book a property even after 6 months as they are checking the date on the server-side.