Pre-Authentication Account Take-Over

Hello Hunters, Today I’m going to tell about one of my interesting and rare finding which is Pre-Authentication Account Take-Over.

For who doesn’t know about the what is the attack is all about, I would like suggest to first go through this Awesome Write Up by Mr. Harsh Bothra Link, you will find very verbose details about this attack, as I also get the idea of this attack from this write up.

So let’s begin with the attack.

This is an private program so I’m not going to disclose program name, let’s called xyz.com.

Now the xyz.com allows user to register himself using the registration form or Social Login which is google.

1. I’ve just choose to register through the FORM, so I put my email address as victim@gmail.com (which in real case victim’s email) and register my self, but one interesting thing happen which is there no email verification done by the application. Now I’ve access to all the functionality of the application without any restriction.

2. Now I just logout from the application, navigate to the registration page.

3. Then after I’ve try to register through Google Authentication using mail victim@gmail.com and guess what I’m successfully login access all the previous details which is submit through the form registration without any warning or message that the user is already register.

4. Now I’ve just change something in data and just logout from the account.

5. Then after I’ve to login with email and password and I’m successfully login in application with got access the account with changed data done by the victim user.

I’ve just make an Report and submit to the program, But didn’t get any response yet and this happens many times and I’m not going to bother them with more than one remainder mail as this is an private program.

So for more clarification of attack please read below steps (Cr. Mr. Harsh Bothra).

1. [Attacker Step] Navigate to the target application and register a new account using the victim user’s email. Since the application also has a Google Authentication option, I used a Gmail account for registration as a victim account.
2. Observe that the application successfully logs in a user upon registration process completion, and all the features of the applications are accessible.
3. Now, log out and navigate back to the target application’s login functionality.
4. [Victim Step] This time, use Google Authentication and login to the application using the same Email address that is used in Step-1
5. Observe that the login is successful and the victim user can access the application. Then, perform any changes in the application, such as profile update.
6. [Attacker Step] Now, In a separate browser window, attempt to log in using the Email: Password used for registration in Step-1 .
7. Observe that the attacker is successfully logged in to the victim user’s account and can see all the changes that the victim performed.
8. This allows an attacker to keep persistence access in the victim user’s account as long as the victim manually changes the account’s password.

Impact

1. Since there is no email confirmation, an attacker can easily create an account in the application using the Victim’s Email. This allows an attacker to gain pre-authentication to the victim’s account.
2. Further, due to the lack of proper validation of email coming from Social Login and failing to check if an account already exists, the victim will not identify if an account is already existing. Hence, the attacker’s persistence will remain.
3. An attacker would be able to see all the activities performed by the victim user impacting the confidentiality and attempt to modify/corrupt the data impacting the integrity and availability factor.
4. This attack becomes more interesting when an attacker can register an account from an employee’s email address. Assuming the organization uses G-Suite, it is much more impactful to hijack into an employee’s account.
5. The overall severity usually lies from High to Critical depending upon the data that is being stored.

Note: If the victim already has an account using social login on the application, this attack will most likely not work.

Remediation

1. The easiest remediation to this issue is to ensure that the email verification is adequately implemented and can not be bypassed.
2. 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.

To my fellow hunter, if you find any interesting finding then do share your ideas with community as it will help others to grow in this field.

A Big Thank to Mr. Harsh Bothra for the Awesome write ups and other Hunters who continuously share their knowledge by writeups and different sources as well.

Thank your for reading guys. Stay Safe.