A quick, practical rundown of this research paper by Avinash Sudhodanan and Andrew Paverd on account pre-hijacking attacks, for reference during pentests.

What’s the attack?

Stealing user accounts before they’ve even been registered by the victim. After the victim registers them, the attacker has access.

If, during a web app test, you notice that you can register a new account and are let in without having to click an email confirmation link, these attacks will potentially work.

The paper enumerates 6 main techniques.

Below are summaries of each one, together with preconditions and attack recreation steps. Finally, remediation steps are listed.

1) Classic-Federated Merge Attack

So-called because it exploits a weakness in the interaction between classic (password-based) and federated (Single Sign On) authentication.

The attacker registers an account with the victim’s email address and sets a password. Later, the victim registers using a federated approach (e.g. ‘Sign up with Facebook’).

Preconditions

• the target app supports both classic and federated account creation, using email address as the account identifier
• the target app allows users to connect a federated identity (e.g. a gmail account) with an existing account registered via mail and password.

Steps to reproduce

• the attacker registers an account using the victim’s email address. They set the password. The victim may receive a confirmation email but it is likely ignored or sent to spam.
• the victim later decides to create an account on the service. They use their federated ID, e.g. ‘Register with Gmail’. They use the address anticipated by the attacker.
• through combinations of user complacency and poor implementation, it’s possible that the attacker now has access to the victim’s account with the password they set in step 1.

2) Unexpired Session Attack

An attacker with access to an account can continue to access it, even after the victim resets the password.

Preconditions

• an attacker already has pre-hijack account access, either through attack 1 or weak registration flow (e.g. the attacker registers with email and password and are not forced to click a confirmation link via mail, but have immediate access)
• the target service allows users to reset passwords
• the target service allows concurrent user sessions

Steps to reproduce

• the attacker registers an account using a victim mail and keeps the session alive, for example by means of an automated script that refreshes the page every so often so the JWT doesn’t expire.
• later, the victim registers an account with that same address but registration is blocked. They may assume they already created an account themselves but have lost the password. So they reset it and start using the service with via their new password.
• if the service doesn’t invalidate all active sessions when the password is reset, the attacker can persist their access indefinitely as long as they keep the session alive by refreshing periodically.

3) Trojan Identifier Attack

The attacker attaches their own federated identity to an account. They are able to access a victim account via ‘sign in with Google’, using their own google address.

Preconditions

• the target service must support classic password-based and federated authentication
• users don’t need the ability to create an account with federated identities, but only to associate them
• the target must provide a password reset functionality

Steps to reproduce

• the attacker registers an account with the victim’s email address and a password that they choose.
• they then associate their own, attacker-controlled federated identity
• some time later, the victim creates an account and it fails because the account already exists. They may think they have already created an account and proceed to reset the password
• the victim can log in with the new password, but the attacker can also log in to the same account via their federated identity

4) Unexpired Email Exchange Attack

An attacker gains control of a victim account via an unexpired email change confirmation link.

Preconditions

• the taret service must allow email changes
• it must send a confirmation link to the new address, the validity of which must be relatively long

Steps to reproduce

• the attacker registers an account with the victim email address
• they change the email address associated with the account to their own
• a confirmation link arrives in their own inbox, but they don’t click it
• some time later, the victim registers an account. It fails and they reset their password as in the previous examples.
• then, the attacker clicks the confirmation link in their own inbox, changing the associated account email address to their own, achieving account takeover

5) Non-verifying IdP Attack

IdP = Identity Provider, ie third party federated identity service such as Okta. This is the mirror image of attack 1: Classic-Federated Merge, whereby the attacker registers via federated identity and it isn’t properly verified, then the victim accesses via the password method.

Preconditions

• the target service must support classic and federated registration, including at least one non-verifying IdP
• alternatively, it could allow users to configure their own custom IdPs such as OneLogin or Okta

Steps to reproduce

• the attacker creates an IdP with the victim’s email address at the non-verifying IdP
• they then create an account on the target service using the newly created IdP. If badly implemented, the service will just assume that the ID is already verified.
• some time later, the victim registers via classic registration
• the attacker’s federated identity is still associated, so they can log in to the victim’s account

6) Email Verification Trick

If at any point, the attacker finds that the service is sending confirmation links to the victim’s email address they can try this trick to bypass it. The trick is simply this:

• the attacker registers with their own address
• they then change the associated email address to the victim’s
• if no confirmation link is sent to the new email address, the attacker has control of the account associated to the email address of the victim

Remediation

The root cause is the failure to verify ownership of the claimed identifier. This is often done asynchronously, allowing newly registered users unhindered access to their new accounts, without having to go and click links in their inboxes.

However, all these attacks could be mitigated if services or IdPs blocked users from carrying out any further actions after registration, until they click a confirmation link in the claimed email inbox.

Additionaly, when passwords are reset, all other sessions should be invalidated, along with all pending email exchange links.

Users should be notified of all identities linked with an account, so they have the ability to disassociate any unrecognised or unused IDs.

When classic and federated accounts are merged, the service must check that the user currently controls both accounts.

Any email confirmation links must have a short life span.

Unverified accounts should be pruned from the service after a short amount of time.

Multi-Factor Authentication should be implemented correctly to alert a user when an attacker attempts to access a pre-hijacked account.