Pre-Account Takeover is a type of attack that we very often carry out during our audits. Although it is only possible in very specific situations, the possibilities for malicious exploitation are becoming increasingly common, with potentially serious consequences for data security.
In this article, we present how a Pre-Account Takeover attack works. We will also look at the specifics of the attack, using a concrete example, as well as security best practices for countering the risk.
What is Pre-Account Takeover?
Prerequisites for carrying out a Pre-Account Takeover attack
A Pre-Account Takeover attack specifically targets an account or a user. To do this, the following conditions must be met:
- The platform must allow accounts to be created, and this creation must be effective in the database before any email validation, or no email validation must be required.
- The platform must allow SSO authentication (Google, Microsoft, customer IDP, etc.), without imposing it.
- Users must be able to choose between traditional authentication (login and password) and SSO authentication.
Although this may seem a rare requirement, more and more applications allow accounts to be created and SSO authentication to be used in addition to the traditional login and password scheme.
How Pre-Account Takeover works?
An attacker exploits a Pre-Account Takeover by targeting a user whose email address is known and who will shortly be registering on the platform using SSO authentication; often using social engineering techniques.
The attacker begins by creating an account using the target’s email address via the standard account creation procedure, defining the email address and a password. As the attacker does not have access to the user’s email account, he will not be able to validate the account if verification is required, but this is not essential to the attack.
The aim is to pre-create an account that will be associated with a future legitimate user. When the account is created, an email can be sent to the legitimate user to confirm that the account has been created, which reduces the discretion of the attack.
The attacker then waits for the legitimate user to connect via SSO. As the user’s email corresponds to an existing account created by the attacker, SSO authentication works and the user is redirected to this account. The user does not realise anything, simply thinking he has created his own account.
The attacker, on the other hand, can connect to the account at any time, using standard authentication (email and password). In this way, he can view, modify or delete the data of the legitimate user.
This attack is based on a number of conditions, which limits its probability of success. However, if it is successful, the impact can be serious, depending on the data managed by the platform, like a classic account takeover.
Example of a Pre-Account Takeover Attack on a Web Application
Let’s take the example of a web application for managing personal documents. Users can create an account and take out a subscription to access all the features, such as storage, document sharing and annotations.
This application allows users to authenticate with their Gmail account using Google SSO. It also allows users to create an account directly with a username and password.
Here’s an example of what the authentication page looks like:
Using social engineering techniques, the attacker knows that the user John Brown is planning to use this application. He also knows John Brown’s Gmail address: [email protected].
The attacker therefore created an account with this email address using the classic account creation method (link visible at the bottom of the screenshot above), without using Google or Apple SSO. After filling in the creation form, the following request is sent to the server:
POST /register HTTP/2
Host: test.vaadata.com
User-Agent: Custom user agent
Content-Type: application/json
Content-Length: 104
{"email":"[email protected]", "firstname":"john", "lastname":"Brown", "password":"verystrongpassword"}As we can see, he sets a password for the account. However, he cannot access the email address, as he does not own it.
The account therefore awaits validation. All the attacker has to do is wait for the legitimate user to connect.
This is what the attacker sees once authenticated:
A few days later, John Brown opens the web application. He goes to the main page and sees that he can use his Gmail account.
He authenticated using Google SSO. However, instead of creating a new account, he is redirected to the one created by the attacker, with his Gmail address already associated. John does not realise that this is not a new account.
As the authentication took place via Gmail, the email is considered validated and the tooltip visible in the previous capture is no longer visible:
He therefore uses the platform and uploads a confidential document. Below is the http upload request:
POST /documents HTTP/2
Host: test.vaadata.com
Cookie: session=***
User-Agent: Custom user agent
Accept: */*
Accept-Encoding: gzip, deflate, br
Content-Type: multipart/form-data; boundary=---------------------------41902792651389033399194766463
Content-Length: 1188
-----------------------------41902792651389033399194766463
Content-Disposition: form-data; name="doc"; filename="internal_network_doc.pdf"
Content-Type: application/pdf
[…TRUNCATED DATA…]
All the attacker has to do is use standard authentication to access the account and steal the document.
POST /login HTTP/2
Host: test.vaadata.com
User-Agent: Custom user agent
Accept: */*
Content-Type: application/json
Content-Length: 64
{"email":"[email protected]", "password":"verystrongpassword"}How to Prevent Pre-Account Takeover?
To prevent this type of attack, a number of actions can be taken:
- Check the email address before creating the account: The account should only be created on the platform once the email used has been verified. To do this, a verification link containing a unique, non-reusable, time-limited token must be sent to the user’s email address. This token is linked to the email address provided at registration. When the user clicks on the link, he is redirected to a page where he can define his password, and the token is then verified on the server side. If the token matches the email provided, the account is created, ensuring that the user has access to that email address. The same principle should be applied when changing email addresses to ensure secure account management.
- Inform the user if an account already exists: When the user logs in for the first time via SSO, if an account already exists with the same email address, a message should warn the user that an account already exists. The message could read: ‘An account associated with this email address already exists on the platform. Would you like to link your account to the existing one? If you did not create this account, please contact support’. If the user accepts, login/password authentication must be deactivated and only SSO must be authorised. All existing sessions (or JWT) must also be invalidated on the server side to disconnect any attacker still connected.
Author: Yoan MONTOYA – Pentester @Vaadata