One-click Account Take Over

Hello, my friends!

First of all, about us (dynnyd20, Giongnef, lttn), we are a group of eager learners, aiming to make the Internet safer. We are also colleagues in the same company sharing the same ideals. After a period of hunting security bugs individually, we realized there were still many limitations. We decided to collaborate and form a team to develop together.

With a spirit of sharing to be shared, we would like to share about a very interesting case that we discovered when collaborating.

This isn’t the first valid bug, but it’s a case that combines business logic, which is our strength when working at our current company. A very interesting case our team encountered, and how we elevated its impact from Out Of Scope to high impact.

Let’s get started!

Note: As the server had a WAF that immediately blocked IP addresses upon scanning attempts, We hacked this target entirely manually.

Overview:

• I’ll temporarily refer to this website as ‘redacted.com’. This is the online administration solution for small businesses. Invoicing, payment control, text recognition of purchase invoices & more.
• This website allows users to change their email.

Focusing on our strength in logic, we decided to start with the profile > Change email feature.

First try

We tried to test IDOR on this function by modifying the value of “CurrentUserBE.Email” parameter. After confirming the verification sent to the email, we found that the victim’s email was changed.

For sure, we tried again, but with no success, nothing happened. The question that arises in our minds is: Why? Is it a server error or not? (We will explain later 😉)

We remember that it was 2 AM at that time, and none of us were alert enough after a long working day, so we decided to end that day after several unsuccessful attempts.

Do you think that we will give up? Nah…We continued to try again the next night.

The next night…

My colleague pinged me, saying that this is a bug but with a new direction…

Specifically, upon returning the next night in a more alert state, we discovered that the “CurrentUserBE.Email” parameter was not the affected parameter. So when the confirmation link for changing the email was clicked, whose email would be changed?

It will be changed for the user with the current session. A new attack vector dawned on us:

1. The attacker requests to change the email with the new email is his email
2. The link to confirm changing email will be sent to the attacker’s email
3. The attacker tricks the victim into clicking the verification link
4. Bong! The victim’s email is changed to the attacker’s email
5. The attacker performs the forgot password function on the victim’s account and finally TAKE OVER the victim’s account

Reporting? Nah.. Life is not like a dream.

The same company is out of scope. Ok, we will try to take over another user’s company.

On another try, we created a new company and used the above way to change the email of the user in another company. Do you think it was a success? No, it was a failure. All we got was “The verification is not correct”.

Give up here? Nah.. giving up is not in our dictionary

Deep into the application functions, we found that a user could invite a user from another company to their company and a user could manage many companies.

We started discussing again, realizing that we could only take over another user’s account when they were within our company. But we needed to impact another company to turn this bug into a valid one. We have two ideas to continue exploiting this vulnerability:

• Idea 1: User belongs to the company (Attacker) -> After being inactive by admin > This account is still listed but it cannot access company resources at all > Attack attempts to change admin’s email -> Not working 😢
• Idea 2: Attacker adds victim to his company > Take over the victim’s account > Successfully take over any companies that are managed by the victim > Yeahh! it’s valid.

More details about idea 2:

• When a user switches activity status from one company to another, the application will re-issue cookies to the user (only to interact with the company the user is working for).
• However, the email reset token can always be activated regardless of the company the user is operating in as long as that user is on the attacker company’s user list.

=> So to exploit the highest impact, we invited the victim to our company and used the token of this user in another company to confirm the verification token.

Successfully exploited, and we ended that night at 3 AM with happiness.

“Everyone has to start from somewhere “- @lightangel1412

Happy hacking! Thanks for reading ❤

Feel free to reach me on Linkedin or Twitter