Techniques For Finding Higher Level IDORs | Bug Bounty Explained transcript

IDORs, or insecure direct object reference, is a relatively old vulnerability class that is actually still quite relevant today as well. But, the techniques for finding it have started to become a lot more nuanced, and it has become a lot harder to find those simple IDORs. What I call like level zero IDORs, just arbitrarily changing some [music] ID value from your value to another user's value, those type of IDORs are starting to become a lot harder to find.

And they have been for the past couple of years. The reason for that is because of automated scanning, the framework is getting better, this REST API framework is getting better actually doing the authentication. Then, you know, AI, artificial intelligence with better understanding of context, [music] and you know, developers just becoming more aware of the issue as well. But, there have been types of IDORs that have consistently still been quite popular despite the rise of these toolings.

And these are what I call like higher-level IDORs. They're IDORs that actually require you to understand the application, understand the threat model, and understand what certain users should be able to do. And these IDORs are quite hard to automate against just because it requires a good understanding, a good human understanding, of what the application is intentionally supposed to do. And it can come from stuff like reading documentation, or just having an awareness of it.

And today, I wanted to to just walk you through an example of some IDOR that I found in a real application, a real public bug bounty program, that is said. And I want [music] to just talk about other IDORs that I found that are similar to this, and why I try and focus on these IDORs as opposed to IDORs that are just about changing an identifier. And you'll also be able to follow along with this lab. So, I'm going to host it on my server, and the link will be in the description, so you can hop in with me as well.

This is a website that Cloud CloudMade just to put it out there. This guy just made this in about 5 minutes. I've got code, so Cloud Code spun this up for me. It's on localhost at the moment, but I will have a link in the description for this lab. Uh you can visit it, and I actually recommend you try and find the vulnerability for this first yourself, and then come back. This may be a little bit challenging. However, I do think that you should try yourself first, and then come back to the video.

So, do that, and then you can start watching from here. Okay, I assume all of you have gone off and done the actual lab or whatever, and now you can watch me do it. So, we're in this um project store. So, first of all, let's understand what we're actually looking at. This seems to be an application where you can create some projects, and there's just some tasks for each of the projects, and each of these has an ID. That's pretty cool.

It's um some kind of cool cool app like that. And we have um these two different kind of tabs here as well. So, there's public projects, and there's my projects. I imagine there's like private projects that other people can't read. Have this marked public here. So, we have the tasks here, and we have the actual name of this task, and we have the description. Okay, cool everything here. Let's just try and go make a new task.

So, we'll call it classic, we'll just call it like test 1 2 3. Come in here. You can see it's like has a different icon, so supposedly it means it's like a different object or whatever. And we have tasks, and then we have secrets for each tasks. Sorry, no, we have tasks and we secrets. Sorry, they're two separate things. You can go in here, we can now add a task. Let's see. Add that kind of thing here. You can go to secrets.

I'll add secret 1 2 3 as well. Okay, just test all the features, just have a have a look at how this works. You can reveal it ourselves. You can edit, delete. This is pretty standard application. It's like a pretty standard SaaS application. Just a bit of, you know, >> [snorts] >> REST API stuff going on. Um the sep- separation between, you know, public, private projects, and then some kind of menu that we probably can't see in the public one, and then some tasks that we can edit.

Okay, cool. We can come in here, and I think I had my uh proxy on for most of this, {question mark} um yeah, supposedly. So, we have some of the requests coming in here. We can see things like get project. Maybe we'll just store this. I'm going to just clear all the previous requests I made. These are from the previous video. So, we can come in here, we can see some of them. So, this is using uh GraphQL. GraphQL is a pretty common interface for these kind of applications.

And what it basically does is it turns like database data into this kind of format here, where a user can request exactly what information they want to. So, they can filter information, and they only get what they want to. It's pretty good for for for performance, and it also makes it a lot easier to write these kind of statements, because instead of a developer writing SQL, which is kind of annoying nowadays, you can write like GraphQL statements instead.

So, this is pretty cool um pretty cool GraphQL, but it has a lot of decent bit of quirks to this. So, now it's important to understand what kind of the back end is. It seems like it's GraphQL, and it's we have this header X-Powered-By. That suggests that we're dealing with a Node.js application. So, good to understand what the back end is running. We have a Node.js application um running with Express. So, Express is like this, you know, JavaScript framework.

And we probably have a React application as well, just because these Node.js applications tend to come with React applications. Um I'm not going to check it for now, but I assume it is a React application. So, come in here, we have our session cookie being set. It's cool. We'll send it in, and we have the data coming back as um now kind of interesting of an ETag header here, which is super interesting. Maybe this is getting cached in some way.

Maybe some kind of cache deception is possible then. But, I'm not sure about that. We're testing for IDORs for now, so maybe we'll leave it. This is a completely AI-based application. I haven't coded a single thing in this application. So, maybe there's a load of vulnerabilities here, but I have absolutely no idea. So, we're going to have a look in this, and we have for our project, so this is our project ID, and we have some kind of um secret being stored here as well.

So, we have our secrets, of course, and these are tasks. So, what is probably happening, if we just understand the logic of this application, is when a user clicks on this project, then the client-side JavaScript makes a request to the GraphQL endpoint. It fetches the following data that we just saw. So, it fetches the the ID of the project, the description, uh name, and then whether it's public or not, uh basically to check if it should be stored here or here.

And then the client side takes all that information and turns it into actual UI elements. This is very common in React applications. There's nothing new here. So, this kind of uh data gets put here, here, and here, and this is all done through React. Okay, super cool. Now, we know that we're looking at a GraphQL application powered by Node.js that's running client-side framework like React, and it'll be kind of not the feature model as well.

So, in terms of the kind of understanding of how the application works, we have a good understanding of the technology. Now, what about the kind of access control and how the functionality actually works? So, for each of these projects, we can see that inside of the database is projects, and each of the project is linked to tasks. So, tasks themselves are another object sort of database. So, there's project sorry, there's projects, which are like the top-level thing.

Each of the projects can have tasks, and then, you know, the project also has secrets, which are stored themselves, and each of these are stored by an ID. So, there's the classic way to do, you know, any kind of IDOR testing is, you know, take this ID for a project, you know, get a second user, put in their ID, and then see if we can fetch their project, and ideally their secrets, right? Now, these kinds of IDORs, as I mentioned before, they're getting a lot less popular nowadays just because of testing, automated testing.

It's kind of like a level zero IDOR, I would say. It's kind of not really any thinking. You don't even need to have any application knowledge for that. You just switch out one ID for another. So, we hopefully want to look for a more complicated type of IDOR. Now, let's have a look at some of the more requests. So, we'll come in. We'll see create secret. Okay, we'll store that one as well. Uh get project is the same one.

Okay, cool. So, we have this create tasks endpoint as well. So, we'll log that one as well. Get project, get my projects. Uh these are actually usually very boring in GraphQL just because they take your session cookie, and they don't really give you anything back. So, I'm just going to leave that one because it's probably not interesting. Create project could be interesting, and get public project also very interesting because this is like the same, but we're going to go in here and check it.

And get public projects, I don't think that's going to be very interesting either, so we'll just leave it. And we have a few interesting endpoints. Um another classic IDOR, you know, create secret for another task, create a task for a project you don't own. But, again, those are kind of those level zero IDORs that we don't really want to test for. Maybe more complicated things. For example, we saw that inside um creating a a project, we didn't see this is public value get set at all.

And, you know, since we're using a mutation with GraphQL, perhaps we can actually set this is public value to something that we for to true so that we can create a public project. I didn't see that in the settings. So, perhaps if we went back and read the documentation would have said that users cannot create public projects or whatever. That could be a pretty easy medium vulnerability. So, why not test for that? We'll go create a project and then we'll say something like, you know, here we'll come in here.

Obviously, this requires a bit of understanding of GraphQL. Basically, we can just type in the parameters in here. So, we'll come in here and say is public. We'll say is public and we'll set it to true. We'll see if this works. Uh unknown argument is public. Maybe we'll just say like public public is true instead like this. Okay, it doesn't appear like we have any kind of control over whether or not the project is public or not.

It just seems like that's decided by the server. So, we don't really seem to have control over these public projects. Now, there is this endpoint get public project. Let me just send it in. Which gets a project that is public. And this only returns the tasks and we can see the secrets for these public projects. Now, one of the cool things we could try is grabbing this ID. Since this is also a project and both the endpoints are different, maybe we could for example come here and instead of adding this ID to this project, we'll add in this public project instead.

And you can see it did actually return it. Which is very interesting, but it also returned these secret value instead. So, this is exactly the type of IDOR I'm talking about. We have access to both of these identifiers. So, we have access to both of these projects. However, because uh because we have access to this, then in GraphQL, like by default, you can always read all the endpoints from the file unless the developer turns it off or modifies it somehow.

That's why we were able to read the secret file because of the way the filtering works in GraphQL. Many developers actually do this where they by default give you access to some kind of public feature and then you can read off data that you weren't supposed to read. I think this is very common. So, that's kind of what I mean with these kind of higher-level IDORs. It's when the developer actually consciously makes a decision like the user should be able to read public projects.

They should have access to this. But, because of the kind of, you know, because of your knowledge of how the application works, you can sometimes read off information that could allow you to basically um do things that you weren't supposed to like these kind of secret files, things that you weren't supposed to read. And this is often missed and it doesn't have to be GraphQL. Some of these REST API endpoints, I see it as a query parameter like filter or like expand something.

If you have something that you can read but the read is supposed to be limited. If you can filter it to that thing that you're not supposed to read, then sometimes the backend will just return it to you. Which is a great way to get a very easy, pretty easy high severity vulnerability even sometimes. Honestly, this this actually could be a critical vulnerability if you were able to read these API keys. I managed to find this in a real application.

So, it just goes to show that it's absolutely possible. And I got a high for this. So, that was pretty cool. Now, one of some of the other things that can happen with IDORs, some of these other higher-level IDORs. One of the things that I like to look for is webhooks. So, webhooks often have some kind of their own endpoints. And a lot of the times these view-only users might not be able to read these these webhooks, but sometimes they are able to use this with this technique that I showed you.

And if you are able to get one of those webhook endpoints, then you could send messages to the webhook endpoint and kind of spoof them in some way if their authorization system isn't that good. Something else is automation. Some of these endpoints have automation where they actually use a HTTP URL to trigger some kind of automation inside of it. So, just to give you an example of that, let's say we were here and, you know, I wanted to set up a rule.

So, a rule inside of this, you know, project that every single time I add a task, the task gets assigned to some person, right? Let's just imagine that for example. And there's an HTTP URL that triggers this rule from, you know, some kind of third-party website that I've integrated. If a user can read that URL, a view-only user can read that URL, then they can actually execute this automation. So, most websites don't want people to be able to do that.

Most people don't want people to be able to trigger these automation rules unless they actually, you know, have have right access to the project. That's another way to get a very easy vulnerability on a lot of just these kind of SaaS platforms. That's what I like as well. And then understanding these objects and how they interact as well. So, in these things we have these projects and different features can lead to different things.

So, instead of just testing the basic IDORs, maybe test something like, you know, I can copy over a project from one place let's say let's say there's like a copy project function or something. Let's say like what what if I copy the project like this public project and then it leaks the secrets inside of it. Could be something like that. What if what if I can copy a like um let me maybe think what if I can copy a task from a project I don't own.

That's kind of more basic IDOR. But, kind of these kind of things just exploring, you know, how these features work, how the access control is supposed to be implemented. And yeah, do be sure to try out this lab if you haven't already and it'll be on my website. And yeah, I hope you enjoyed this video on some of my new techniques for finding IDORs. It's the understanding the object model of the website, how stuff is structured and just a deeper understanding, you know, through the documentation, through the interaction, understanding how the deeper IDORs will work and IDORs that are not necessarily just replacing one ID with another.

That's the important thing. It's not just about replacing one ID with another, it's about accessing things that you shouldn't supposed [music] to access and that can be done in a variety of ways, not just by changing identifiers, but also, you know, adding different things and changing different filters. You know, checking what's actually getting returned to you, checking web sockets, which is something that most people don't do, filtering inside of web sockets for sensitive information.

You know, stuff could be encrypted as well like, you know, these web sockets or, you know, some of these requests, they could come back, you know, ZSTD compressed or something like that. It could be a pain, but I mean there could be some good stuff in there as well. Sometimes it's worth checking that. And yeah, that's those are some of my techniques that have been working for me in the, you know, past few weeks or months.

So, I just wanted to share with them with you so hopefully you can go out, find some kind of vulnerability and, you know, if you do leave a comment. Like please tell me if you found a vulnerability with some of these things. I'll know what actually will help some of you guys. And yeah, if you haven't already, then please consider leaving a like and subscribe to the channel so that you get more bug bounty content recommended to you by the algorithm which will hopefully give you just that edge over the competition that you need to squeeze out those vulnerabilities this year.

And yeah, that's it for me. Thanks for watching and happy hunting.