Akwaaba! to you all. I'm going to describe a simple IDOR scenario I came across in a bug hunt. As always, I'd recommend you read about my $1,500 Recon Tips but if you're a Mobile app testing enthusiast, check out Coding Exploit App to exploit LFI in Android.
‼️ Disclaimer: I've changed specific details about the application in this write-up for confidentiality. Even the screenshots shown are from a different, similar application that doesn't have a bug bounty program — they're only used for illustration. Also, all API endpoints mentioned have been altered to avoid revealing the actual program.
The Program
This company provides an application that can best be described as a modern-day password manager. A key feature of the app is the ability to add a trusted device, which allows users to bypass OTP verification during the login process on that specific device.
The vulnerability
There is an API endpoint to retrieve information about our own Trusted device. This endpoint takes our account's UUID and returns the device's information. There was an IDOR vulnerability in this API that allowed an attacker to retrieve device info belonging to other users in the same tenant.
IDOR (Insecure Direct Object Reference) is a type of access control vulnerability that occurs when an application provides direct access to objects based on user-supplied input. Any form of info is stored as an object. For instance, User information is stored as objects that are referenced via specific identifiers, such as predictable integers or randomized strings.
An IDOR vulnerability occurs when these identifiers can be manipulated to reveal another user's object without proper authorization.
#Return our Trusted device info by passing our UUID to the endpoint
/api/v3/trusted-devices/<UUID>I know what you're thinking, create two accounts, substitute account B's UUID into the endpoint to retrieve their Trusted device information. I did that, IT DIDN'T WORK. I got a 403-permission error.
If you fancy core Android app attacks (not the Burpsuite kind), check out how I exploited a Content Provider
JS Recon to Discover More
I have to admit; I had initially given up on finding an IDOR. However, while attempting to execute a separate attack, I began reviewing the JavaScript to identify all admin-related requests (those directed to /api/v3/admin/*). During this process, I stumbled upon an endpoint that got me thinking. This specific endpoint is triggered when clicking on a user with whom you have shared a password, and it returns limited information such as their name and role.
#different endpoint to return limited member info
/api/v3/members/<UUID>/account/info
So, I thought: if ../account/info returns only limited account details, what happens when I change things up a bit?
I'm fond of reviewing JS files even though I can't code JS. Read how I made $1,500 from simply reviewing JavaScript files.
The Exploit
Nothing too complex, I simply recooked the API endpoint into one that pulls another member's Trusted device information, and it worked.
#reworked endpoint to return another member's device info
/api/v3/members/<UUID>/trusted-devices/infoBy substituting another user's UUID into that endpoint, I was able to retrieve their device information. The disclosure included their User-Agent, IP address, and several cryptographic keys.
As for the UUIDs themselves, they were leaked throughout the application. For example, when a registered user shares a credential set with you, their unique UUID is exposed within the share link.
Impact and Payment
The major impact here was the leakage of other member's external IPs and cryptographic keys. I reported this as a High but was bullied into settling for a Medium gang.
You can also check out an easy to miss SSO vuln to led to a 2FA bypass that gave me a quick $150.
Hey …bye
Thanks for reading this, if you have any questions, you can DM me on X @tinopreter. Connect with me on LinkedIn Clement Osei-Somuah.