Hi
This is my first write-up on Steem and also a Info-Sec writeup after a long time. The story starts when My 6th semester ended and I got some time to hunt. In summer break you have HELL of a time. So I was looking to hunt some website, tied of Duplicates on Hackerone. I came across a Crypto Exchange while surfing google.I won’t be taking the Exchange name here let's say it as xyz.exchange.

So I signed up for the exchange and started testing it. The exchange was highly vulnerable, I was surprised to see that an exchange having volume in thousand of BTC is vulnerable to these type of Vulnerabilities.

The bug which helped me to hack the whole exchange was IDOR.

Description:

Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example, database records or files.
Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user-supplied input and uses it to retrieve an object without performing sufficient authorization checks.

Reference: https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References

Testing + Exploitation :

IDOR!! I love IDORs , especially when they are in Password Reset functionality.

This attack basically consists of two vulnerabilities.

IDOR in Password Reset + 2fa bypass

IDOR in Password Reset Functionality:

When I Requested a password reset link I got something like below

http://xyz.exchange/#/reset_password/cet6YhGBFVD89jnuOiVMwfdr4mcsaeEwk2OimSc0LtVg

I thought that the exchange is using some kind of token implementation here. But I was wrong when I intercepted my Request in Burp. It was a simple POST request being made at /api/reset_password

This request had an id parameter. Every user is assigned an id in the system. The id was incrementing id. From a Hacker perspective, I first thing that came into my mind was what happens if I change this id. And to my surprise, it was vulnerable to IDOR.
I made two accounts and tested it and it WORKED!!!

I was like…

Now comes the second part. Taking over the full account is not possible without correct 2fa token as its required upon login.

For confirming the 2fa token the following request was being made.

Code as the 2fa token. I set the burp to show its response. The response was as follows.

So the trick was to just set the response to true as you will get access to the account even token as “123456”.

Later I found the Admin’s Email and his corresponding account Id via using IDOR in their Ticket System. But I didn’t exploited it as COO didn’t give me the permission.

Take Aways:

~ Burp is your Ultimate Friend Always keep it on and Look at every Request being Made.
~ Never Forget to Play With Request Responses.

Time-line:

Getting this bug to Authorities was another story Which I will share some other time.

June. 16, 2018 → Initial Report Sent
NO RESPONSE
June. 30, 2018  → Mail for Update
NO RESPONSE
July. 6, 2018  → Reported Via Telegram group of Exchange
July. 6, 2018  → Triaged
July. 7, 2018  → Fixed
July. 7, 2018  → Bounty awarded