IDOR Infinite Money Glitch? | Bug Bounty Hacktivity Explained transcript

It can be easy to discard doors as a beginner level vulnerability and I myself have frankly kind of stopped looking for them. You know, a found bounties so now I need to start looking for the real vulnerabilities. But many hackers out there from Douglas Day to [music] Zinc who calls himself the Idorminator now have shown that idors are just a way to basically print money in bug bounty by making ridiculous sums of money.

And somehow [music] instead of fixing the problem, it seems like AI is actually making idors more common rather than less common. So in this video, I'm going to cover three bug bounty reports across different programs to show you that even the best frameworks biggest companies out there are still susceptible to really simple idors that have huge impact and large payouts. All right, I'll set up with a very quick explanation of what id doors are for those of you who might be a bit newer into bug bounty.

If you know what an idor is, then just go ahead and skip this part. But basically an IDORM or an insecure direct object reference is when server hosts one of these user input parameters which is a UU ID so you unique identifier for an object and it returns data based on it without validating whether the user actually has access to it. So imagine we have this user's endpoint and whenever we request a user it gives us like details about [music] about the user.

So like the name, email, address, you know, payment method or whatever things that other [music] users probably shouldn't be able to see. If say we had this identifier one, which is our user, then if we want to test for an outdoor, we just change this to two. And if we change this to two, then if it returns the user data, then this is vulnerable to an idor. That's basically it. It's very simple vulnerability. You just basically change one of the unique identifiers and see if the server responds with them.

And obviously it doesn't only exist in the query parameters. For example, this is like a JSON endpoint. And instead of being in the query parameters, the I doors in this case is in this JSON parameter here. And this in this case might be a way to like change a username. So if you wanted to like change this username, we would provide the ID and then the name. In this case, it would verify if this ID is there and then it would change the users.

So that's one of the ways you can hunt for idors. And then this is something that I found on Twitter or X sorry from Idorminator and it's one of something that shows like the bit of a complexity with idors. So for example here we have this massive API request from T-Mobile and you can hear see up here that's a unique identifier. This is how unique identifiers look in T-Mobile and it's in the URL. So maybe we could change this and look for an IDORM.

There's this org user here which probably is some kind of role. Maybe we could change that to admin and see if we get extra permissions. Then there's actual authorization since these APIs have to check for access control. There's usually cookies are being used for authentication. But in this case we have two other headers. We have authorization header which is usually standard for APIs. But then we also have this X O originator header which is a completely custom header.

So the server could literally be using any one of these to check for authorization. So it's worth checking if the server is which one the server is actually using. Maybe it's using literally none of them. That's also a possibility that the server has no access control in this case. So it's worth checking all of those. And then the other points of entry for idors you can see this B2B organization which is another unique identifier.

You can see once again somewhere down here the user ID which is the same one as the user ID above here. Actually it's actually not the same one that's a different one. Oh no the B2B organization is the one from up here. And then the user ID is completely unique. And then you can see the actual request body which not only has the user ID again but also the organization ID as well. So you can see just how many different places there are to test for and you literally have no idea which one the server is actually validating.

So maybe the server is actually validating this header here is actually using this header to determine where the property is coming from. So maybe if we change the header it'll give us like different results. Maybe it's using the thing in the JSON endpoint. Maybe we can put like an S SQL payload somewhere. You know, there's a lot of things to test for in terms of APIs. And this just shows that idors don't necessarily just exist in like here and here.

They can also be in like headers. They can be in query parameters and stuff like that. Especially on these big companies and they're big APIs, they tend to have a lot of infrastructure. And this is why there's just a lot of headers going on. Like you can see that there's even an email address here which is which is like really interesting because you don't usually see that in an API call. So there's a lot of things to test for.

That's what a an outdoor is just when we can modify one of the unique identifiers and then basically change it to access another user data. So now I'm going to hop in to the three reports I'm going to showcase today. The first IDOR vulnerability was found here in Matilla. Matilla is the company that runs Firefox and that's mainly what they do. And they also have accounts in Firefox mainly to sync your data like store your passwords and stuff like that.

That's mainly what they use the accounts API for. And what you could do is you could actually delete any user who uses single sign on. Single sign on is stuff like Google, like Facebook login or Apple. So any user that uses those login methods, you could delete their account, which is pretty crazy if you ask me because Firefox is a huge browser. So that kind of vulnerability is pretty interesting and the fact that it's an idor as well is definitely just shows you that this is very common.

And basically what happened was that in order to delete your account, you had to supply two things. Had to supply the user's email and you had to supply their password hash. If the user was using a normal account, you can see that this vulnerability like is hard to exploit because even if there was an ID door here, you would have to know their password hash and their email. If you knew those two things and you could literally just log in as them anyway, so it wouldn't actually matter.

But you scroll down here, if the user was using single sign on, then you didn't need to change the password hash. I imagine it was the same for all like the single signons. And if they were using single signon, all you needed to do was change their email. So you could know someone's email and delete their account, which is pretty serious. Obviously, if you know someone's email, you can delete their account. That's a pretty high severity vulnerability.

And in this case, that's what it was ranked. It was a high severity vulnerability. And it was also very simple. You just see you just change the victim's account and the Gmail just it works for there. And this is a recently new vulnerability. What might have caused the vulnerability for this if we just think about it? Well, it's likely. I mean, I'm I'm just spectating here. I don't know if this actually happened, but I think what probably happened is that the the first login feature that was implemented, there wasn't any single sign on.

So, the single sign on probably was implemented later. And then they had issues with this delete account endpoint, which is probably added prior to single sign on as well. So when they added single sign on, they were trying to figure out what to do with this password hash because obviously if you have single sign on, there's no password to hash at all. It just doesn't exist, right? And the database probably was like checking for the password hash and they probably just got rid of it.

The developers like, "Oh, let's just fix it by getting rid of the password hash." Well, then they forgot that password hash is the only thing that actually makes it secure because probably beforehand the login feature, the people that made the login feature were like, "Oh, we don't actually need to put access control here because the password hash is just going to prevent idors because if you know the person's password, you can log in." Then the people who made the single sign on were like, "Okay, to make this feature work, we're going to get rid of the password hash because single sign on has no has no has no password hash." And presumably there's also some kind of access control happening in the background, but then that was obviously never implemented because of the password hash feature.

That's kind of what I imagine causes vulnerability. So if you can think like that like a developer, it's going to help you find a lot of these doors cuz stuff like this become basically becomes kind of a headache for developers when it's implemented in post and they just forget things that haven't been implemented. And yeah, that's his vulnerability. So, we're going to hop into the next one now. The next report is from Hacker One.

Probably all know Hacker One. It's the platform where you can submit your bug bounty reports to other companies with. And because they're a bug bounty platform, their security is probably pretty high. So, the fact that an idor exists here should make you think a little bit. And it's an idor where you could access any users private reports. In hacker one, you can have public reports like disclosed ones and then private reports which shouldn't be disclosed because they probably contain like vulnerability details that haven't been released to the public.

So this is a very serious vulnerability for hacker one and probably something that they're looking at in their threat model whether you can access other people's reports to gain access about company's vulnerabilities and in this case because of that it was a critical vulnerability for them and the bulk here or the vulnerability existed in this books.json JSON endpoint. Now, I haven't hacked on hacker once, so I can't say this for certain, but a JSON endpoint having a post sent to it is a bit weird.

It's a bit odd and I I wouldn't have seen that before. And I imagine because of that, it might have caused a bit of issues, which I'm going to talk about later, which is I think the root cause of this vulnerability anyway. But in this case, if you had this endpoint here sent to a JSON one, it would have um you see here this X form encoded data here. And there was this one parameter organization ID or if you changed it, you could access basically all the reports for a given organization.

So organization would be like a company. And the hacker also discovered here that you could add different parameters onto it to increase the amount of reports you could see. And you could basically see all of them just like straight up you could see all of them. That's obviously very serious. Now what is the root cause of this? What do I think is the root cause of this? Anyway, I speculate that because this was ajson endpoint, the code review tools that other companies use kind of like AI tools or like code QL from from uh GitHub for example, they're not really used to seeing this as a like a REST API feature like some kind of like post endpoint.

Usually, this is a static data. So, what I kind of think happened is that the code review tool or whatever like review they were doing saw this.json JSON endpoint and then didn't confirm whether it had access control. And that tends to happen when you have these kind of weird features with likejson. Again, this this might be common for hacker one. I don't know. But I speculate that this might have caused issues with some of the code review tools that they were using or some kind of AI as well.

And that's why this door got left in here just because of that endpoint. That's my take on it anyway. But it's also a very simple vulnerability and it would be weird for someone to have left something like that out on a very core functionality. As well as that, maybe this happened because people hadn't tested the organization part of this. Maybe they were just looking at whether a user could access another user's report and not whether a user could access an organization's report.

That also could be possible. Either way, that's a critical idor from hacker one there, which should definitely make you think that if a company like this can fall for an idor, then definitely a lot more companies would. And the final report is from PayPal. PayPal probably already know as well, is just a way to basically send people money by like a secure service. I think it kind of works like a credit card as well where you can like take in a bit of the debt as well or something like that.

Either way, PayPal also a pretty secure company because they are financial company and also fall victim to a pretty serious idor. So, let's have a look here. What the vulnerability here was was relating to these secondary accounts. So, in PayPal, you could have a primary account and then you can have secondary accounts under that primary account. I think you can also have a secondary account be under multiple primary accounts.

So, keep that in mind here. And there was this endpoint here where you could manage your secondary accounts and you could change the permissions and you could also add [music] your secondary account to a different primary account. And in this case, this was the door. You could just set the ID to a secondary account that you didn't know and add yourself to that account. [music] And that's basically the whole vulnerability because once you added yourself that account, you could just steal all the money basically.

Also, super simple vulnerability. I think the reason this happened was because this weird access control that was here where it was like the secondary account was only the primary account but it was also like you could also have like multiple secondary accounts and primary accounts. This was kind of like intended [music] and then someone just didn't end up checking the access control. And this is a good bit older. This is from actually very old.

It's 2019. Maybe I should have selected [music] something more recent. Either way, I guess you got like the snapshot of Idor's chart history in this video. But yeah, you can see Id doorors are a very consistent vulnerability. I mean, this has been happening from like 2019 to 2025 are still going [music] strong. And there's honestly very little vulnerabilities that have survived for that long and still been so lucrative.

Like the top top like one hacker on Bcraft literally just find doors, [music] which is like insane. That's like really weird for a vulnerability that's been around for so long. I hope this video showed you how hunters out there are making an absolute ridiculous amount of money with idors that are both super simple and highly impactful. Essentially the ideal kind of bug you want to find. It would really be a mistake to look down on idors as a lesser vulnerability [music] when in reality their prevalence is going up and up even though AI is getting better and better as well.

On another note, I'm going to be working more on client side vulnerabilities now in the next coming weeks. So, if you have anything that you want me to cover from client side, then leave [music] it in the comments below. And as always, I'll take a look at it. Be like anything from client side patch reversals, post messages, cross-ite scripting, and that kind of stuff is what I'm going to be working on for the next few weeks.

And yeah, anyways, thanks for watching and happy hunting.