Broken Access Control
Hi everyone. Welcome to this new post from ENCIPHERS. So recently, our team at ENCIPHERS conducted a penetration test for a certain company. The company is a very reputed one in the field of Money Investment and Real State business and it has a lot of day to day users. The client asked us for a penetration test on a limited scope of http://www.xyz.com only i.e the main application of the client without interfering with any other subdomains we started to find some broken access control issues.
As it stood, the application was more or less quite secured to find vulnerabilities like XSS and CSRF. The next thing, that will come to any penetration tester at that time is to check for any broken access control related issues, and the same happened to us. So it was then that we started testing rigorously to find any critical bugs and yes we did find some of them.
Here are the different steps. Let’s see them one by one.
As we have already told you in lots of our posts earlier, you always need to make 2 accounts to test for cross-testing. So we started with that and logged into both the accounts in 2 different browsers.
Next, we started looking in the application URL and also in the Requests tab in Burpsuite, for anything where there will be something like a Identifier or a random number that could be used to differentiate between 2 different profiles.
We told you before that it was a Real estate business company. So in there, was an option to see the different profiles created by the user. These profiles contained different confidential information about the user like the Contact Information, the Ownership Type, and Legal Title. The Request looked like this:
POST /web-api/pfc-api HTTP/1.1
Host: www.xyz.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://www.xyz.com/settings/investor-profiles/3312999599807157
X-RS-CSRF-Orchard-Token:
Content-Type: application/json
Cookie:....[REDACTED]
{"url":"/amd/investor-profile?profile_id=3312999599807157&full=true","method":"get"}
And the Response to this particular request showed various details of the user.
Now what we simply did was to change the profile id with that of the other user account, to see if it shows Access Denied. But no, it doesn’t. Instead, it gave us the full details of that profile of the other user.
The JSON request part looked something like this:
{"url":"/amd/investor-profile?profile_id=3342499135144669&full=true","method":"get"}
As you can see, the profile_id was changed.
Not only Read but we also got Write Access to change the profile name of the other user’s account.
Actually, the link to edit the details of a profile, looked like this:
https://www.xyz.com/settings/investor-profiles/3342499135144669
So we just changed the id with the second one and the link became this:
https://www.xyz.com/settings/investor-profiles/3312999599807157
And to our utter surprise, the option to Edit the Info was still working and we successfully changed the profile name of the other user and saved it.
Not only this, a user can also see the various Investment details of any other user plus the Earnings of that user also. Here is how.
The Request to see the Investment details of a certain profile of a user looked something like this:
POST /web-api/pfc-api HTTP/1.1
Host: www.xyz.com
Referer: https://www.xyz.com/dashboard/myinvestments
X-RS-CSRF-Orchard-Token: ...[REDACTED].
Content-Type: application/json
Content-Length: 161
{"url":"/cqs/query/investor_dashboard_investments?sort=!close_date&rs_profile_ids=[3312999599807157]&i=0&n=8&cms_investment_share_states=[%22ComputedActive%22]"}
As you can see, the profile_id is in the JSON request and as a penetration tester, you won’t be missing to check what happens if you put any valid id of any other user there.
So we simply replaced the id with our other account’s id. And yes, it was ‘200 OK’ with the other account details there.
The Earnings tab was similarly vulnerable to Access Control issues where it was possible to get the whole details of any other user by giving that id.
The Request, in this case, looked like this:
POST /web-api/ocd-api HTTP/1.1
Host: www.xyz.com
Referer: https://www.xyz.com/dashboard/earnings
..[REDACTED]..
{"url":"/investor/earnings?offset=0&count=10&investor_profile_ids=3312999599807157","method":"get"}
As you can guess, what happens after this. We simply replaced the id and yes, that was it.
Now for certain curious readers, who must be thinking that how will someone guess the profile id of any other user because it seems to be a long random number. So for you, the sole purpose of a penetration test is to look for vulnerabilities present in any condition. The companies should always take the first step to make their site secure by taking the proper measures against access control issues instead of thinking that a hacker will not be able to guess such a long random number. If there was proper access control, then when we sent the request by replacing the id, it would have directly shown me Forbidden or Access Denied. Not only this, the profile id’s are also getting saved in the browser’s history and what if someone gets their hands on it. So proper access control measures should be applied in the first place so that even if someone finds a way or an algorithm to guess the number, it won’t help them with accessing the other user’s account.
So this was all for this post. See it is very simple and easy to find such kinds of bugs. The issue in the last post was also easy. You just have to be on the lookout for an identifier and then cross-test among them to find these issues. Hope you must have learned some new things from this post too. See you guys in the next post. So go apply these techniques now and Happy Hacking.!!!!
check out :- https://enciphers.com/finding-and-exploiting-blind-xss/
