Friday, December 9, 2016

Bug Bounty : Account Takeover due to a Misconfiguration

First of all, I would like to thanks Bugcrowd's analyst especially beemo_bugcrowd for patiently updating the issue during the validation process.

Fiat Chrysler Automobiles announced their public bug bounty program through Bugcrowd in July 2016. More details can see it here: https://bugcrowd.com/fca
As always, I will try to poke around to see how many of the reports are currently being handled by the Bugcrowd for this program as if there are too many crowd, usually I will opt out from it. And the result, yes, there are lot of them especially XSS and CSRF issues. That was the reason these two issues immediately excluded to allow analyst team to filter out them.

I'm targeting Mopowerconnect.
Mopowerconnect


Due to that, I try to look on the other angle and I noticed something which is weird in my view which is the way account was created in Mopowerconnect (was in scope but now excluded). Why? Please refer the figure below:

Authentication process


*this is just based on my observation and own hypothesis during the testing.

To detail the figure above:
  1. When a user creates an account at Mopowerconnect, the request will be sent to Chrysler to generate the authorisation and then at the same time will create another independent account which only be used by Sharepoint.
  2. Means, if you create User1 at Mopowerconnect, Chrysler will processing it and provide you with the authorisation for Mopowerconnect as User1, and at the same time it will create another account for you which is to be used in Sharepoint, assume as UserS1.
How do I know there's a Sharepoint at the backend? This is because there's a misconfiguration which allow an attacker to directly access that framework through URL such as /_catalogs/masterpage/etc/etc . I first submit the misconfiguration issue, it was a dupe. Then I went to look around this Sharepoint pages to understand why it exist. There I noticed that, I'm browsing the Sharepoint pages using UserS1 account, not User1. 

Sharepoint UI

I went back to check on my Burp HTTP history to look on all of the responses. Then I found the request and the parameter that supply my another account, UserS1. It was weird to see there are two types of ID on the request.

Request made at Chrysler


 Then I created another testing account to double verify my hypothesis. And it is proven. At this point, I still can't think what's the best scenario I can do. Then, the idea came in. What if I try to reverse the process? Reset the password :)

The request when resetting the password looks similar. Thru Mopowerconnect UI you request to reset the password, then Chrysler will process it and send the information to the Sharepoint to be updated. Interesting.

Again, I reset the password but this time I've modified one of the value before Chrysler send it to the Sharepoint which is PRF_UID. I changed it into my second account and voila! The account was compromised :)

Combining with the issues due to the misconfigured access to the Sharepoint, I'm able to enumerate list of PRF_UID belongs to another users including the admin. And yes, I can takeover the admin's account as well.

Submitted to Bugcrowd, and it is not smooth as I assume because the request was actually being made at Chrysler domain which is out of scope. I knew that but since the issue is considered as Critical, I kept on insist them to forward the report to the client and let FCA themselves decide on this. Two different analysts reviewed the report and marked as Out of Scope. I was at the point to give up until I made a decision to email the issue to the FCA team myself. I used the Bugcrowd's support medium to deliver the message to the FCA team and also did ping another technical team from Bugcrowd to re-review it.

A week later, 

FCA team replied

 At a month later, the issue was fixed!
Fixed!
Thanks!