IDOR in session cookie leading to Mass Account Takeover

If you are familiar with what IDOR is, you will know that it can be anywhere from url, request body, GET or POST requests and yes, in cookies too..

After spending quite a lot of time in a private program i was invited, i started to learn how everything works, and that usually means (not every time) that you are more likely to find more bugs, and that’s what happened to me… i ended up in top 1 in the leader-board next to a few well-known Hackers :)

Ok back to the write-up.

When testing/analyzing the workflow of a web application i am usually looking for any type of token/ID that can be used to gain information or perform sensitive actions that can lead to IDOR.

In was trying to reproduce a CSRF issue when i noticed that in the cookies there was one called shoppingID that resulted to be the Session Cookie.

After taking a closer look at the cookie’s value i realized something that quickly got my attention:

shoppingID=88ea39539e74fa67c09a4fc0bc8ebe6d00978392PEr9ySESSIONID3552522PXGLkC;

Have you noticed? If not, please don’t continue and look at it again.

If you noticed it then congratulations, you might have a quick eye for possible IDORs.

At the end of the cookie there is SESSIONID and 7 numbers:SESSIONID3552522 . I quickly created a new account and looked at the session cookie and it was really similar but with some differences.

shoppingID=88ea39539e74fa67c09a4fc0bc8ebe6d00978392HAB6FSESSIONID3552538KMDALK;

Most of the cookie’s value was the same in both session cookies, and that usually means a problem. The first part was completely the same, the only difference was in the 5 random characters before and after SESSIONID{numbers} . It took me some time to analyze the cookie’s value but then i realized that those random characters *weren’t validated by the server* so changing only the numeric ID (the 7 digits after the ‘SESSIONID’) would give me complete access to the any account.

This is how the cookie looked like separated in A, B and C.

After the creation of a few accounts i found out the following:

[A] = This was repeated in my test accounts, a pattern validated in the server (there are also other different patterns).
[B] = This is the number assigned incrementally in account creation, this is exploitable.
[C] = This is a combination of random numbers and letters that isn’t validated in the server.

So because [B] was numeric only, [C] wasn’t validated and [A] was a pattern repeated on other accounts, it was possible to just brute-force the ID to gain complete access to other accounts.

This access token was permanent and didn’t change over time, so this would give me complete access to other account’s including credit cards if stored in their accounts.

It took some time for the H1 team to understand that a session cookie IDOR was actually possible. At the end it was resolved and awarded $2.000 as the max payout for a Critical Vulnerability.

That was all, i hope you like it :D

If you feel like buying me a coffee because you liked what you just read, feel free to do it here https://www.buymeacoffee.com/zonduu