Discovering private chats between users and the support team

Greetings, Bug Bounty community! I'm Krishna Jaishwal, also known as jarvis0p, a Computer Science student and bug bounty hunter. Today, I'm excited to share my recent $2000 bounty journey with you, where I discovered a significant Insecure Direct Object Reference (IDOR) vulnerability in a video content streaming platform.

The Application

While testing the application I was thoroughly checking for access controls on every functionality. But for hacking over a day I couldn't find anything. Despite robust authorization checks and ever-changing session cookies and CSRF tokens, I persisted in my hunt. My breakthrough came when exploring the Need Support? feature.

Need Support?

The way that it works is that users have to create a support ticket where they will describe the issue details and the team will look into it to assist them. You can continue chatting with the team on this ticket to explain the issue or get assistance from the team. Users can also add images and attachments to show details of the issue. So I immediately created a support ticket to see how all of this was working on the programming level. There was nothing I could do with the creation of tickets as it was protected by CSRF tokens and session cookies. But my eyes got caught up when I saw how they were fetching data on these tickets. The request had two IDs in it. First was the user ID and second was the ticket ID.

POST /account/support/discussion/load-topic/<user-id>/<ticket-id>

I immediately thought that this did not look right because the application can find/authorize the user from the session cookie. Then why user-id?

Getting to an IDOR

First I wanted to try whether changing the user-id and ticket-id to another user IDs, will give me his chats. I had another testing account, so I tried to fetch other's account chats but the server gave me 403 Forbidden.

At this point, I thought this endpoint again had authorization checks. But I still was not sure why user-id is in the request if you have session cookie. So I tried putting random cookie to fetch chats and again 403. Finally, I tried removing the cookie header completely from the request, and to my surprise, it worked !!

So basically if you know user-id of a person and the ticket-id then you can see the chats between any users and the support team in an unauthenticated session. The user ID was a 9-digit number and the ticket ID was a 7-digit number. These are most probably assigned in sequencing order because when I tried creating consecutive tickets, the ticket IDs were very close.

Exploitation

I needed the user ID of other users to show the exploit of this bug. I scrolled through the burpsuite proxy and found an endpoint where I was able to get the user ID of another user on the basis of the username/channel name.

You can see in the response HTML, I found my user-id to be 730723625

Now to get ticket-id, there was no other option other than fuzzing, and that I wanted to avoid because the application was very serious about rate limitation. On almost every endpoint, it immediately throws 429  too many requests, if I use burp intruder. But to my luck, this endpoint did not have any rate limitation checks. So I fuzzed the ticket-id for other users using ffuf and got some hits.

On opening those tickets I was able to see chats between that user and the support team.

Fetching Attachments

As I told this feature also allows users to add attachments i.e. screenshots. This was the endpoint that was fetching the attachment URL.

GET /account/support/<attachment-id>/<ticket-id>/<user-id>/attachment/1

Guess what? This endpoint was again vulnerable to the same improper authorization. So on removing the cookie header, I was able to get attachments. The attachment ID was again 7-digit numbers, so this can be easily fuzzed.

Hence this vulnerability can allow any attacker to get complete chats between any user and support team.

Conclusion

• The application had improper authorization on two endpoints allowing to get complete chats of any users including attachments with the support team in an unauthorized session.
• Those endpoints have no rate limitation checks to prevent attackers from fuzzing the API endpoints.
• The application uses weak IDs to identify its resources, making it vulnerable to IDOR. Instead strong IDs like UUIDv4 can be used which are not prone to fuzzing attacks

Timeline

• 31 October 2023: I made a detailed report explaining the issue and submitted it with High(7.5) severity according to CVSS.
• 01 November 2023: The report was triaged and fixed immediately.
• 01 November 2023: They gave me a bounty of $1500 and a $500 bonus
• 03 November 2023: Awarded $50 for restest.

Tips

1. Go for manual hacking. It is more effective, more fun, and avoids duplicates.
2. Test access controls on each and every feature. Maybe all features have good security checks but there could be some features where developers forgot to put the checks properly.
3. The way APIs are made is such that every resource has a unique ID assigned to it which they use to perform CRUD operations. So wherever you find IDs, try IDOR. IDOR is present everywhere.
4. Try changing/removing session-maintaining tokens or cookies, if resources are still accessible then it could be a bug. You can also do this with Burpsuite's Autorize extension.

Thank you for reading. if you have any questions, DM me and I will get back to you!

Happy Hacking!!

Author: Krishna Jaishwal

Twitter: twitter.com/jarvis0p1
Linkedin: linkedin.com/in/krishna-jaishwal-3bb368237/