Full Account Compromised

No sensitive information will be shared here but it contains the general steps that was taken to gain Full account access of a web application’s users

Main areas

Through the discovery/mapping of the application I made note that there's was a page that listed all the users on the application. This was not unexpected as the role I was testing was an administrator role. Alongside the user page, there was also a page for clients, as the web portal was for supervisions to monitor and manage clients.

Because this in a monitor/managing web application, most roles in the web application has the ability to access and export client data, sensitive client data.

Finding the hash

Visiting the user’s account profile returns limited data in the browser but reviewing the HTTP Response has loads more data. One of the bits of data being returned is the hashed password. Knowing there is hashed passwords being returned I used burp’s intruder to extract all the possible hashes.

First, I got a list of all the user’s ID, I got this by viewing the Users Overview page. I took the returned JSON and with CMD tools, JQ & awk I saved the user IDs to a text file. Once I had the User IDs, I run burp intruder and setup a grep search to extract the hashes.

Reviewing the hashes, it was a bcrypt hash with a unique salt. bcrypt is a tricky has that is not easy to crack but it is possible able with enough resources. Due to the resource limitation, we have I only cracked my admin user’s hash as a PoC.

Now I have a cracked password, but the application has MFA, so it's a good finding but I wanted to escalate the finding.

Path to Escalation

As mentioned above the application has MFA, so I look to see if I can change the password without being authenticated, no joy. I was fuzzing the API looking to see if there is an older endpoint that doesn't require authentication, once again, no joy.

I eventually turned to the login process, maybe I would find a way to authenticated to the web app without the MFA token. Durning this process I notice that after you give the web application username:password it returns 2 tokens, an authToken and a refreshToken. Using these tokens, I tried to access data wit in the application, but all attempts failed as it requires a different token that has been through the MFA process.

Well, I now have a cracked password & two tokens that are pretty useless.

But during the login process there was a request that send out the MFA token that doesn't require any type of authentication. I tested by sending a MFA token to a different mobile number I have access to. Soooo I did what everyone would do. I requested a new MFA token, to the new number and attempted to login with that MFA token. But, no joy.

MFA takeover

I turned back to the web application and notice that there is a function to update the mobile number that is used for the MFA process. My Spidey senses was tingling.

I had a cracked password, 2 tokens, a way to get MFA codes and the function to update the MFA number. Next, I turned to the function to update the number, I relogged to get a new authToken, requested a new MFA token and attempted to update the number, as it goes, I had no joy.

At this point I was running out of options, then I thought let's just try the refreshToken, I didn't expect anything, but Joy!! I just got a 200 HTTP code, so I just updated the MFA number!

Successful login

I now had a cracked password and hopefully a mobile number that would get the much-needed MFA token. I entered the email and cracked password. I held my breath waiting for the MFA token. BOOM! My phone vibrated with a text message containing the MFA token. I entered the token and was greeted with the web app dashboard as the admin user!

At this point I could have extracted sensitive data, delete all other users, invite other users and change the password of the victim user. I was not able to change the victim’s email address so I could not escalate this finding to a full account takeover.

What happened

Well i can only take a guess as this is a custom authentication framework what was built of this series of applications. But I will take my best guess here.

As there is 2 different tokens used in this application the first token is used to verify you are who you say you are and the 2nd token is used if the first token has expired. So the application use the first token in every HTTP request to the web server, once the expiry date has been reached then the 2nd token is used to generate a new set of the 2 tokens. From the application history the 2nd token is only every used to gen the new tokens and for nothing else. So, my best guess is that in the custom framework there was a insecure coding error that allowed the 2nd token to be used in the API calls.