Attacking Social Logins: Pre-Authentication Account Takeover

3 years ago 148

BOOK THIS SPACE FOR AD

ARTICLE AD

Authentication is one of the most crucial aspects when it comes to the security of an application. However, suppose an attacker can bypass the implemented authentication by any means. In that case, it is possible to perform privileged actions, enumerate sensitive information and cause chaos resulting in technical, business and reputational impact.

Often, it is observed that most modern applications allow their users to register/enrol using multiple methods such as registration via email, registration via Social Logins and other methods. However, log in via OAuth2.0, SAML, etc., based authentication is usually considered to be secure. However, if an application doesn’t correctly implement a few basic checks, it may become a severe security vulnerability.

This article will discuss a simple security flaw that occurs due to improper implementation of social logins and lack of [or bypassable] email verification in an application that allows an attacker to maintain persistence access into the victim user’s account, i.e. Pre-Authentication Account Takeover Vulnerability.

As the name suggests, an attacker is required to have authenticated access to the victim user’s account before the victim registers himself for the application. The common question that arises here is how an attacker would gain access to the victim’s account before the victim creates an account? This is where the Pre-Authentication account takeover comes into the picture. Let’s break down this attack into small pieces and understand how one can perform successful exploitation.

This attack is not possible and applicable everywhere. However, there are specific requirements to attempt exploiting this issue as mentioned below:

Lack of Email Verification: The target application should not have an email verification mechanism, or it should be bypassable. Often, it is observed that whenever a new user creates an account on some application, it requires first verifying the email and then only the access is granted. In a nutshell, this is an essential thing that is necessary to perform this attack. Due to this misconfiguration, an attacker would register an account in the application using the victim user’s account, i.e. Pre-Authentication.Social Logins: The target application should also support at least one social logins, such as log in with Google, Facebook, Twitter and other services. Also, the victim’s email that the attacker is using for Pre-Authentication should be the one used in its social media account.Victim User’s Email: The last item required is the victim user’s email; however, that’s not a big task, and it is possible to enumerate emails easily.

While performing penetration testing on a confidential target, I observed that the application allowed me to automatically login to the application as soon as I created a new account. This implies that there is no email verification at all. Similarly, the application also supported multiple social login methods such as Login with Google. Following the below steps, I was able to perform pre-authentication account takeover successfully:

[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.Observe that the application successfully logs in a user upon registration process completion, and all the features of the applications are accessible.Now, log out and navigate back to the target application’s login functionality.[Victim Step] This time, use Google Authentication and login to the application using the same Email address that is used in Step-1Observe that the login is successful and the victim user can access the application. Then, perform any changes in the application, such as profile update.[Attacker Step] Now, In a separate browser window, attempt to log in using the Email:Password used for registration in Step-1 .Observe that the attacker is successfully logged in to the victim user’s account and can see all the changes that the victim performed.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.

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.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.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.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.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.

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.

Always look for possible ways to bypass the email verification, especially when the social login options are present.Always attempt to chain the vulnerabilities together to increase the impact.Be observant and approach an application after understanding its logic.

Read Entire Article