Lucene search

K
huntrThewhiteevil5494E258-5C7B-44B4-B443-85CFF7AE0BA4
HistoryMay 05, 2022 - 11:57 p.m.

Users Account Pre-Takeover or Users Account Takeover.

2022-05-0523:57:25
thewhiteevil
www.huntr.dev
19

8.8 High

CVSS3

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

REQUIRED

Scope

UNCHANGED

Confidentiality Impact

HIGH

Integrity Impact

HIGH

Availability Impact

HIGH

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

6.8 Medium

CVSS2

Access Vector

NETWORK

Access Complexity

MEDIUM

Authentication

NONE

Confidentiality Impact

PARTIAL

Integrity Impact

PARTIAL

Availability Impact

PARTIAL

AV:N/AC:M/Au:N/C:P/I:P/A:P

0.015 Low

EPSS

Percentile

85.5%

Team,

May you all be well on your side of the screen. :)

While Doing some research on the https://microweber.org, I was able to find a Pre-Account Takeover vulnerability.

Kindly check the proof of concept video & reproduction steps for better understanding.

Proof of concept:

I have uploaded the both of the proof of concept video in my drive.

And turned on the link sharing.

Kindly check it out once.

https://drive.google.com/file/d/1qRG-NGPq5jKl5ekeUtzI7SYqwmcI2x3_/view?usp=sharing

Steps to Reproduce:

Go to the https://microweber.org

Try to create new account by using the victim email address.

Example:

My victim: [email protected]

Once done with entering the needful details for signup, we were landed on the dashboard directly by using the victim email.

In attacker end attacker has victim email id and password to login on the https://microweber.org

Victim end, victim receiving email notification for account verification from the https://microweber.org and victim checking it out.

Then, victim can try to login through the Google Oauth SSO, what happens here victim can directly land on the dashboard by using the SSO.

Which shows attacker end attacker can login through the victim email address and password, victim end victim can login through the Google Oauth SSO.

Since, Attacker and victim end same account was used on.

Until victim identifies this is attacker created account, and then until victim change the password and or adding Authenticator OTP, both of their ends the same account was accessed.

That’s the issue and it shows the Account Takeover.

Solution:

Either don’t let the user enter with Oauth when there’s already another account created with the same email or let the user enter but let him know someone else has already created an account and if it was him or not then ask him to change the password.

First, clearly verify the Email OTP or link, then give the access to the dashboard.

The easiest remediation to this issue is to ensure that the email verification is adequately implemented and can not be bypassed.

Further, by ensuring that the social logins are correctly implemented, the email extracted from the social login is verified against the existing user’s database to ensure that the victim asked to reset the password.

By doing so, it is possible to remove the attacker’s persistence.

Cheers!

8.8 High

CVSS3

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

REQUIRED

Scope

UNCHANGED

Confidentiality Impact

HIGH

Integrity Impact

HIGH

Availability Impact

HIGH

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

6.8 Medium

CVSS2

Access Vector

NETWORK

Access Complexity

MEDIUM

Authentication

NONE

Confidentiality Impact

PARTIAL

Integrity Impact

PARTIAL

Availability Impact

PARTIAL

AV:N/AC:M/Au:N/C:P/I:P/A:P

0.015 Low

EPSS

Percentile

85.5%

Related for 5494E258-5C7B-44B4-B443-85CFF7AE0BA4