New Research Paper: Pre-hijacking Attacks on Web User Accounts

In 2020, MSRC awarded two Identity Project Research Grants to support external researchers working to further strengthen the security of identity protocols and systems. Today we are pleased to release the results of the first of these projects. This research, led by independent security researcher Avinash Sudhodanan, investigated account pre-hijacking – a new class of attacks affecting websites and other online services.

Similarly to classic account hijacking attacks, the attacker’s goal is to gain access to the victim’s account. However, if the attacker can create an account at a target service using the victim’s email address before the victim creates an account, the attacker could then use various techniques to put the account into a pre-hijacked state. After the victim has recovered access and started using the account, the attacker could regain access and takeover the account.

The full details of this work are available in our research paper, which will be presented at the 31st USENIX Security Symposium in August. In this paper, we describe five types of account pre-hijacking attacks, and we show that a significant number of websites and online services may be vulnerable to these attacks. Our primary motivation for publishing this research is therefore to raise awareness of these attacks and to help organizations defend against them.

Challenges in User Account Creation Challenges in User Account Creation

User accounts are a ubiquitous feature of websites and other online services, and have therefore become a valuable target for attackers. Account hijacking is a well-known threat in which the attacker attempts to gain unauthorized access to the victim’s user account.

Organizations rightly invest significant resources to defend against account hijacking. However, one aspect that has received less attention is the process of user account creation, and the corresponding security implications. With the move towards federated identity and Single Sign-On (SSO), many services now support (at least) two different routes for users to create accounts: the classic route of providing a username and password and the federated route using an Identity Provider (IdP) e.g. Sign in with Microsoft. Once the account has been created, some services also offer the possibility to link an IdP account, so that the user can either sign in directly or authenticate via the IdP.

Previous academic research has discussed a “preemptive account hijacking attack”, where an attacker gains control of a victim’s IdP account and uses it to create user accounts at services for which the victim has not yet signed up. Inspired by this attack, we demonstrate that there exists an entire class of such attacks, which we call account pre-hijacking attacks. In contrast to prior work, none of our attacks require the attacker to compromise the victim’s IdP account.

Account Pre-Hijacking Attacks Account Pre-Hijacking Attacks

The distinguishing feature of an account pre-hijacking attack is that the attacker performs some action before the victim creates an account at the target service. The unsuspecting victim might subsequently regain access to this account and start using it, potentially adding personal information, payment details, or any other type of private information. After some time, the attacker completes the attack by gaining access to the victim’s account – essentially achieving the same objective as an account hijacking attack.

In the research paper, we describe five types of pre-hijacking attacks:

1. Classic-Federated Merge Attack: This exploits a potential weakness in the interaction between the classic and federated routes for account creation. The attacker uses the victim’s email address to create an account via the classic route, and the victim subsequently creates an account via the federated route, using the same email address. If the service merges these two accounts insecurely, this could result in both the victim and the attacker having access to the same account.

2. Unexpired Session Identifier Attack: This exploits a vulnerability in which authenticated users are not signed out of an account when the user resets the password. The attacker creates an account using the victim’s email address and then maintains a long-running active session. When the victim recovers the account, the attacker might still have access if the password reset did not invalidate the attacker’s session.

3. Trojan Identifier Attack: This exploits the possibility for the attacker to link an additional identifier to an account created using the classic username and password route. The attacker creates an account using the victim’s email address and then adds a trojan identifier (e.g. the attacker’s federated identity or another attacker-controlled email address or phone number) to the account. When the victim resets the password, the attacker can use the trojan identifier to gain access the account (e.g. by resetting the password or requesting a one-time sign in link).

4. Unexpired Email Change Attack: This exploits a potential vulnerability where the service fails to invalidate email-change capability URLs when the user resets their password. The attacker creates an account using the victim’s email address and begins the process of changing the account’s email address to be the attacker’s own email address. As part of this process, the service will typically send a verification URL to the attacker’s email address, but the attacker does not yet confirm the change. After the victim has recovered the account and started using it, the attacker completes the change-of-email process to take control of the account.

5. Non-Verifying IdP Attack: This attack is the mirror image of the Classic-Federated Merge Attack. The attacker leverages an IdP that does not verify ownership of an email address when creating a federated identity. Using this non-verifying IdP, the attacker creates an account with the target service and waits for the victim to create an account using the classic route. If the service incorrectly combines these two accounts based on the email address, the attacker will be able to access the victim’s account.

For all these attacks, the attacker needs to identify services at which the victim does not yet have an account but is likely to create one in future. Although success is not guaranteed, there are several ways an attacker might go about this. For example, at an individual level, the attacker might already know which services a specific victim uses, and opportunistically pre-hijack accounts at other similar or related services. More broadly, the attacker might learn that a whole organization (e.g., a university department) plans to use a particular service and could pre-hijack accounts for any publicly known email addresses from that organization. Alternatively, the attacker might observe a general increase in popularity of a service (e.g., a video conferencing service when people are required to work from home) and pre-hijack accounts for that service using email addresses found through website scraping or credential dumps. There is usually no risk to the attacker if the victim has already created an account at the service.

Empirical Evaluation Empirical Evaluation

To ascertain the prevalence of vulnerable services, we analyzed 75 of the most popular websites and online services, and found that at least 35 of these were vulnerable to one or more pre-hijacking attacks, including widely-used cloud storage, social and professional networking, blogging, and video conferencing services. Following the principle of Coordinated Vulnerability Disclosure (CVD), we reported these vulnerabilities to the affected organizations between March and September 2021. However, it is highly likely that other websites and online services, beyond the 75 we analyzed, will also be vulnerable to these attacks. We are therefore publishing this research to shed light on this class of vulnerabilities, so that any organization operating a website or other service can take action to protect their user accounts.

Concurrently with our work, other researchers have demonstrated similar attacks (sometimes called “Pre-Account Takeover” attacks). Some examples include: reverse-engineering insecure email confirmation URL parameters [e.g. craighayes] or finding services that insecurely merge accounts created via the classic and federated routes, if they use the same (potentially unverified) email address [e.g. hackerone, hbothra22]. These examples illustrate how widespread these vulnerabilities are likely to be.

Root Cause and Mitigation Root Cause and Mitigation

Fundamentally, the root cause of account pre-hijacking vulnerabilities is that the service fails to verify that the user actually owns the supplied identifier (e.g. email address or phone number) before allowing use of the account. Although many services require identifier verification, they often do so asynchronously, allowing the user (or attacker) to use certain features of the account before the identifier has been verified. Whilst this might improve usability, it creates a window of vulnerability for pre-hijacking attacks.

All the attacks described above could be mitigated if the service sent a verification email to the user-provided email address and required the verification to be completed before allowing any further actions on the account. A similar approach could be used to verify ownership of other types of identifiers, such as using text messages or automated voice calls to confirm ownership of phone numbers. If the service uses an IdP, it should check whether the IdP performs this verification or perform its own additional verification.

Defense in Depth Defense in Depth

Recognizing that it might take time to implement strict identifier verification in all services, we also identified a set of defense-in-depth security measures for account creation, which would also have mitigated the above attacks.

Password resets: When the account password is reset, the service must perform the following actions:

1. Sign out all other sessions and invalidate all other authentication tokens for that account to mitigate the Unexpired Session attack.
2. Cancel all pending email change actions for that account to mitigate the Unexpired Email Change attack.
3. Notify the user of which federated identities, email addresses, and phone numbers are linked to the account, and ask the user to select any identifiers they do not recognize (i.e., retain by default), or more preferably, to select which ones to retain (i.e., unlink by default).

Merging accounts: When a service merges an account created via the classic route with one created via the federated route (or vice-versa), the service must ensure that the user currently controls both accounts. For example, when the user attempts to create an account via the federated route but a classic account already exists for the same email address, the user should be required to provide or reset the password for the classic account. This would mitigate the Classic-Federated Merge and Non-verifying IdP attacks.

Email change confirmations: When the service sends a capability to confirm a change of email address (e.g., a code or a URL with an embedded authentication token), the validity period of this capability should be as low as possible, within the constraints of usability, to minimize the window of vulnerability for the Unexpired Email Change attack. However, this will not prevent the attacker from continuously requesting new capabilities, so the service should limit the number of times a new capability can be requested for an unverified identifier.

Unverified account pruning: Regularly deleting unverified accounts would reduce the window of vulnerability for most pre-hijacking attacks (except the Non-verifying IdP Attack). However, this will not prevent an attacker from creating new accounts with the same identifiers. The service should therefore monitor and potentially limit the number of times a new account can be created for the same unverified identifier. However, this could be used to mount a Denial-of-Service (DoS) attack by exhausting the account creation quota of legitimate users’ identifiers. Therefore, the service could instead reduce the pruning threshold for unverified accounts and leverage bot-detection frameworks to limit the rate at which the attacker can automatically create new accounts.

Multi-factor authentication (MFA): Users can protect themselves from pre-hijacking attacks by activating MFA on their accounts as soon as possible. Correctly implemented MFA will prevent the attacker from authenticating to a pre-hijacked account after the victim starts using this account. The service must also invalidate any sessions created prior to the activation of MFA to prevent the Unexpired Session attack.

Conclusion Conclusion

In conclusion, we hope that this research will help to shed light on this potentially widespread class of vulnerabilities and assist organizations in implementing effective mitigation strategies.

- Avinash Sudhodanan (Independent Researcher) & Andrew Paverd (MSRC)