Pre-hijacked accounts: An Empirical Study of Security Failures

in User Account Creation on the Web

Avinash Sudhodanan∗ Andrew Paverd

Independent Researcher Microsoft Security Response Center
arXiv:2205.10174v1 [cs.CR] 20 May 2022

Abstract invest significant resources to prevent account hijacking at-

tacks, in which an attacker gains unauthorized access to the
The ubiquity of user accounts in websites and online ser- victim’s account. Previous work on this topic has studied
vices makes account hijacking a serious security concern. various techniques that could be used for account hijacking,
Although previous research has studied various techniques for example, the use of Cross-Site Request Forgery (CSRF)
through which an attacker can gain access to a victim’s ac- to trick victims into changing their account passwords to an
count, relatively little attention has been directed towards the attacker-controlled value [13, 34, 39].
process of account creation. The current trend towards feder-
In an effort to improve user experience, there is currently a
ated authentication (e.g., Single Sign-On) adds an additional
trend towards federated identity and authentication. One of the
layer of complexity because many services now support both
most visible aspects of this is Single Sign-On (SSO) in which
the classic approach in which the user directly sets a password,
the user creates an account with an Identity Provider (IdP),
and the federated approach in which the user authenticates
and can then use this to create accounts with any relying
via an identity provider.
party (RP) service that supports SSO and trusts the user’s
Inspired by previous work on preemptive account hijack- IdP. There is a strong incentive for services to support SSO
ing [17], we show that there exists a whole class of account because it improves the experience for users by allowing them
pre-hijacking attacks. The distinctive feature of these attacks to reuse the same IdP account across multiple services. Many
is that the attacker performs some action before the victim large companies, including Google, Facebook, and Microsoft,
creates an account, which makes it trivial for the attacker to provide IdP services that are widely supported and trusted by
gain access after the victim has created/recovered the account. websites and other online services. Previous work has also
Assuming a realistic attacker who knows only the victim’s explored the security implications of SSO, showing that IdPs
email address, we identify and discuss five different types of can become single points of failure [6, 7, 17, 22, 40, 41].
account pre-hijacking attacks.
However, one aspect that has not received much attention is
To ascertain the prevalence of such vulnerabilities in the the process of account creation, along with its corresponding
wild, we analyzed 75 popular services and found that at least security assumptions and requirements. This process is further
35 of these were vulnerable to one or more account pre- complicated by the move towards SSO because many services
hijacking attacks. Whilst some of these may be noticed by now support two different mechanisms through which users
attentive users, others were completely undetectable from the can create an account: the classic approach in which the user
victim’s perspective. Finally, we investigated the root cause of sets a password directly with the service, and the federated
these vulnerabilities and present a set of security requirements approach where the user already has an account with an IdP
to prevent such vulnerabilities arising in future. and uses this to create an account with the service. Once
an account has been created, some services also offer the
possibility to link an IdP account, so that the user can either
1 Introduction sign in directly to the service or authenticate via the IdP.
User accounts have become a ubiquitous feature of websites Ghasemisharif et al. [17] presented the first example of
and other online services. Correspondingly, such accounts a preemptive account hijacking attack, in which an attacker
have become valuable targets for attackers, and companies gains control of a victim’s federated identity (e.g., the victim’s
IdP account) and uses this to create accounts at services for
∗ Supported
by a research grant from the Microsoft Security Response which the victim has not yet signed up. The attacker then waits
Center (MSRC). for the victim to join that service and start using their “new”
account. At a later time, the attacker can sign into the service many services do perform this verification (e.g., sending a
using the compromised IdP account and view or manipulate confirmation code or URL to the provided email address), the
any information stored by the victim in that account. vast majority allow the user to begin using the account before
Inspired by that attack, we demonstrate that there exists this verification has been completed, thus opening a window
an entire class of such attacks, which we call account pre- of vulnerability for account pre-hijacking attacks. We hope
hijacking attacks. The distinguishing feature of these attacks that our work will serve to underline the importance of such
is that the attacker performs some action before the victim verification by highlighting the consequences of its omission.
creates an account at the target service. The unsuspecting vic- However, recognizing that this may not be immediately prac-
tim might subsequently create/restore their account and start ticable for all services, we also present a set of defense in
using it. Finally, the attacker completes the attack by gaining depth security requirements for account creation that would
access to the victim’s account. In this work, we identify and have mitigated all the vulnerabilities we identified.
describe five types of pre-hijacking attacks1 . In contrast to In summary, we make the following contributions:
the attack by Ghasemisharif et al. [17], none of our attacks
require the attacker to compromise the victim’s IdP account. • We investigate security failures in user account creation
and identify a novel class of account pre-hijacking at-
All of our attacks make some assumptions about the vic-
tacks in which the attacker takes steps to compromise a
tim’s actions or lack thereof. These include (common) actions,
user account before the user has created the account. We
such as creating an account (using the classic or federated
describe five specific types of account pre-hijacking that
route) or recovering the password for an existing account,
are applicable to current websites and online services.
as well as inactions, such as ignoring emails from services
where the user does not have an account, or failing to no- • We analyzed 75 popular services to ascertain the preva-
tice unexpected identifiers after recovering an account. One lence of vulnerabilities that could be exploited in account
variant requires a successful CSRF attack. We set out the pre-hijacking attacks. We found that at least 35 services
assumptions for each type of attack in Table 1. were vulnerable to one or more attacks. We disclosed
An interesting aspect of account pre-hijacking attacks is these vulnerabilities to the respective organizations and
that they require the attacker to anticipate which services the our reports have already been acknowledged as being of
victim is likely to sign up for and take action before the victim high severity by a major video conferencing service.
creates an account. This could be achieved in various different
ways. For example, the attacker may already know which ser- • We found that the root cause of these attacks is failure
vices a specific victim uses, and opportunistically pre-hijack to verify ownership of the identifier before allowing the
accounts at other services the victim is likely to use. More account to be used. We also present an additional set
broadly, the attacker might learn that a whole organization of defense in depth security requirements for account
(e.g., a university department) plans to use a particular ser- creation and management that would have mitigated all
vice, and pre-hijack accounts for any publicly-known email the vulnerabilities we identified.
addresses from that organization. Alternatively, the attacker
may observe a general increase in popularity of a service (e.g.,
2 Background
a video conferencing service when people are forced to work
from home) and pre-hijack accounts for any email addresses
2.1 Single Sign-On (SSO)
found through e.g., website scraping. There is no risk to the
attacker if the victim has already created an account. SSO is one of the most prevalent examples of federated iden-
To ascertain the prevalence of services that are vulnerable tity management. In SSO, the user maintains a single account
to account pre-hijacking attacks, we analyzed 75 of the most with an Identity Provider (IdP) and uses this to create accounts
popular websites, based on the Alexa global website rank- and authenticate to one or more Relying Party (RP) services.
ings [3]. We found that at least 35 of these were vulnerable When the user visits the RP and initiates the authentication
to one or more pre-hijacking attacks, including widely-used flow, the RP redirects the user to the IdP’s SSO-authentication
cloud storage, social and professional networking, blogging, end-point. The user then authenticates to the IdP, using their
and video conferencing services. We responsibly disclosed IdP account, and gives consent for the IdP to send specific
these vulnerabilities to the affected organizations and our details to the RP. If the authentication is successful, the IdP
reports have already been acknowledged as being of high sends a proof-of-authentication to the RP, such as the authen-
severity by a major video conferencing service. tication assertion in SAML 2.0 [36], or the authorization code
Fundamentally, the root cause of these attacks is that the ser- (authentication token) in OAuth 2.0 [28]. The RP can use this
vice or IdP fails to verify that the user actually owns the sup- proof to fetch additional attributes about the user from the IdP,
plied identifier before allowing use of the account. Although such as the user’s email address. If the user does not already
have an account with the RP service (i.e., a new user), the RP
1 However, we do not claim that this is an exhaustive list of attacks. service uses the attributes provided by the IdP to create an
account. The service may optionally request additional infor- FooApp State: S
mation from the user during account creation. Importantly, Username [email protected]
the RP records which IdP is associated with the account, and
Email [email protected]
will expect a proof-of-authentication from the same IdP when
the user attempts to authenticate in the future. Password $ecret_pass619
Federated identity is becoming increasingly popular as it re- IdPId FB-Id-User42h3
duces the burden on users of having to create, remember, and SessionId A2jkh2k2h55h2kn
manage separate authentication credentials for each service. It PhNum 9886625631
also offers security benefits as IdPs tend to invest in securing
users’ accounts, e.g., using multi-factor authentication.
Figure 1: Example state of the authentication attributes for an
account at the FooApp service.
2.2 Authentication Attributes
User accounts necessarily include various pieces of informa- 3 Threat Model
tion for authenticating the user – we refer to these as authen-
tication attributes. Some of these attributes may be persistent, The attacker’s goal is to gain control (i.e., hijack) the victim’s
such as the user’s username and password, whilst others may user account at the target service. Depending on the nature of
be transient, such as the list of currently valid authentication the service, this could allow the attacker to access the victim’s
cookies. For a given account, we refer to the set of authenti- confidential information (e.g., messages, documents, billing
cation attributes and their corresponding values as the state statements, etc.) or to impersonate the victim (e.g., sending
of the account at that specific point in time. Figure 1 shows messages, subscribing to services, etc.).
an example of such a state. We assume the same web attacker threat model used in
In this example, the Username attribute of this account is prior work e.g., [1, 24, 38], in which the attacker can access
the user’s email address. This need not always be the case, the target service as well as third-party IdP services such as
but a large number of online services use email addresses as those provided by Google, Facebook, and Microsoft. The at-
usernames as these are guaranteed to be unique, and are easy tacker can create both free and paid user accounts at the target
for users to remember. In this paper, we assume that the user’s service, but does not have administrative rights at this service.
email address is always used as the account username. The attacker can also create accounts at one or more IdPs and
The Email and PhNum (phone number) attributes can also use these with the target service. If the target service supports
be used to recover access to the account if the user forgets the custom IdP integration, the adversary can select any publicly
password. Although implementations may differ, the general available identity management service (e.g., OneLogin [30])
pattern for a password reset is for the service to send a secret and use this with the target service.
capability (e.g., a code or a URL with an embedded authenti- Additionally, we assume that the attacker knows the email
cation token) to the registered email address or phone number. address and other basic details of the victim (e.g., first and last
Using this capability, the legitimate user can authenticate to name). These details would already be known to the attacker
the service and reset the password. in the case of a targeted attack, or might be e.g., scraped from
As expected, the Password attribute represents the user- social media or found in password database dumps in the case
chosen secret used to authenticate the user to the service. Al- of an untargeted attack. The attacker can use these details to
though Figure 1 shows a representative example, real services create accounts both at the target service and IdP.
should store the password securely (e.g., storing only a salted For some attacks, we assume the attacker can make the
hash of the password). Although not shown, this attribute also victim visit an attacker-controlled URL (e.g., through click-
encompasses any other authentication secrets, such as secret baiting [12]). The resulting HTTP request from the victim’s
keys used in multi-factor authentication (MFA). web browser may include HTTP Cookies [8] within the con-
The IdPId attribute records the identity of the user as pro- straints of the SameSite policy [26] of the web browser and
vided by a federated identity provider. Depending on the the destination endpoint.
service, it may be possible to add one or more federated iden- Finally, we assume the victim to have at least a basic level
tities to an existing account, after the account has been created of security awareness. This means the attacker cannot per-
(e.g., the option to “Connect with Facebook” or an equiva- form successful phishing attacks on the victim. However, we
lent IdP). In our representation, this would be recorded as a assume that the victim ignores notifications sent by services
change to the value of the IdP attribute. where they do not have an account. This is realistic as prior
The SessionId attribute encompasses all currently-active work (e.g., [2]) has shown the ineffectiveness of notifications.
sessions’ identifiers (e.g., valid authentication cookies) for We assume that the victims and services regularly update their
the account. This is a transient attribute as sessions usually software, and implement mitigations against software attacks
end when the user signs out, or after a period of inactivity. such as code injection [32] and memory corruption [37].
4 Account Pre-Hijacking Attacks was used in the first phase. Some techniques used in this
phase cause the victim to lose access to their account (i.e.,
As with account hijacking, the attacker’s goal in account pre- low stealthiness), whereas others allow the victim and attacker
hijacking is to gain access to the victim’s account. The at- to access the account concurrently (i.e., high stealthiness).
tacker may also care about the stealthiness of the attack, if In the following subsections, we describe five concrete
the goal is to remain undetected by the victim. account pre-hijacking attacks. We do not claim that this is
The impact of account pre-hijacking attacks is the same an exhaustive list of such attacks, but rather that these are
as that of account hijacking. Depending on the nature of the the types of attacks we found to be possible in real services
target service, a successful attack could allow the attacker to (as described in Section 5). The attack trees in Figures 2
read/modify sensitive information associated with the account and 3 summarize these concrete attacks, showing both the
(e.g., messages, billing statements, usage history, etc.) or per- actions of the attacker and victim, as well as the state of the
form actions using the victim’s identity (e.g., send spoofed authentication attributes for the account (S2 - S14 ) after each
messages, make purchases using saved payment methods, action. In all cases, the starting state (S1 ) is empty, since the
etc.). We provide specific examples of the attack impact for account has not yet been created.
the five case studies we describe in Section 5.3. Abstractly, an In the descriptions of the concrete attacks below, for clar-
account pre-hijacking attack consists of three phases: 1) Pre- ity of explanation, we use the victim’s email address as the
hijack, 2) Victim action, and 3) Attack. identifier since this is the most widely-used identifier in real
1. Pre-hijack. In the first phase, the attacker performs some services. However, the same attacks may also be possible
preparatory action, such as creating an account at the tar- using other identifiers, such as the victim’s mobile number.
get service using an identifier belonging to the victim (e.g., Table 1 summarizes the assumptions we make for each attack.
the victim’s email address, mobile phone number, etc.). This
requires the attacker to know the victim’s identifier, but is
4.1 Classic-Federated Merge Attack
not unrealistic since these identifiers are typically not secret.
As explained in Section 3, victims’ email addresses can be This attack exploits a potential weakness in the interaction be-
scraped in bulk for untargeted attacks, or would already be tween the classic (i.e., setting a password) and federated (i.e.,
known by the attacker in the case of a targeted attack. The SSO) approaches for account creation. Specifically, the at-
main requirement in this phase is that the victim must not have tacker uses the victim’s email address to create an account via
created an account with the target service using that identi- the classic approach, and the victim subsequently creates an
fier. By definition, this would prevent account pre-hijacking. account via the federated approach. If not carefully handled,
It is easy for the attacker to detect if this is the case (e.g., the this could result in both the victim and the attacker having
service will respond saying the account already exists), and access to the same account.
this typically poses no risk to the attacker. As discussed in Preconditions. The target service must support both clas-
Section 1, the success of this attack depends on the attacker’s sic and federated account creation, and should use email ad-
ability to anticipate the services at which the victims will dresses as the unique account identifiers (i.e., in place of
create accounts. At the end of this phase, the attacker waits usernames). Furthermore, the service must allow users to as-
for the victim to complete the second phase. sociate a federated identity (e.g., SSO) with an existing (email
2. Victim action. In the second phase, the victim either and password) account – a property we refer to as IdP account
creates or recovers their account at the target service using connect. Services typically achieve this by checking that the
the same identifier used by the attacker in the pre-hijacking email address provided in the assertion from the IdP matches
phase. Ideally, this would be the point at which the victim the email address used during classic account creation.
realizes that pre-hijacking has taken place, based on some 1. Pre-hijack. The attacker creates an account at the target
type of notification from the service. However, as discussed service via the classic route, but provides the email address of
with the concrete attacks later in this section, the type of notifi- the victim and a password of the attacker’s choosing. Specifi-
cation that can be shown to the victim depends on the specific cally, the attacker provides the email address they anticipate
type of pre-hijacking attack. Furthermore, as discussed in Sec- the victim will use for federated authentication. At this point,
tion 5, we observed that vulnerable services vary significantly the target service might send a confirmation email to the vic-
in terms of the notifications they provide, ranging from pro- tim’s email address, asking the recipient to confirm their email
viding warnings that might tip off security-conscious users, to address (e.g., either by clicking on a link or entering the code
providing no notifications at all. Assuming the victim is not provided). However, the victim might ignore emails from
notified or does not heed the notification, they would continue services at which they don’t have an account, and may thus
using their account as normal. ignore the confirmation email.
3. Attack. In the third phase, the attacker gains access to 2. Victim action. If the victim later decides to create an
the victim’s pre-hijacked account. The specific techniques account with the target service, they might choose to use the
used by the attacker in this phase depend on which technique federated route to create this account. Since there is already
 Entity Assumptions CFM US TID UE NV
- does not allow multiple accounts with the same identifier to exist concurrently J J J J J
- supports password reset functionality – J J J –
- supports both classic and federated sign in J – J – C
- uses email address as an identifier J – – – J
- merges classic and federated accounts with the same identifier J – – – J
- supports both classic and federated sign in and sign up J – – – J
Target Service
- supports concurrent sessions – J – – –
- does not expire past sessions by default upon password reset – J – – –
- allows associating a federated account to a classic account – – J – –
- supports email-change functionality – – – J –
- sends email-change capability URLs and does not expire them upon password reset – – – J –
- supports federated sign in through at least one non-verifying IdP – – – – J
- ignores the emails sent by the services where they do not have an account J J J J J
- will attempt to create an account at the target service through the classic route – J J J C
- will recover the account that already exists at the target service with victim’s identifier – J J J –
- will not check whether an unknown identifier is associated to the recovered account – – J – J
Victim
- will attempt to create an account at the target service through the federated route J – – – C
- will not invalidate all the active sessions of the recovered account – J – – –
- will not check whether an email-change verification is pending at the recovered account – – – J –
- is susceptible to CSRF attacks while logged in at the target service – – – C –
- can create an account before the victim creates their account at the target service J J J J J
- knows the identifier used by the victim for creating accounts J J J J J
Attacker
- knows the email address of the victim’s federated account J – – – –
- can create an account with any email address at a non-verifying IdP – – – – J

Table 1: Assumptions on the target service, victim, and attacker for the various Account Pre-Hijacking Attacks. J indicates
that the assumption applies to the attack, C indicates that it applies only to some variants of the attack, and – indicates that the
assumption is not necessary for the attack. The attacks are Classic-Federated Merge (CFM), Unexpired Session (US), Trojan
Identifier (TID), Unexpired Email Change (UE), and Non-verifying IdP (NV).

an account associated with the victim’s email address, one is reset. This allows the attacker to retain access to a pre-
plausible design decision could be for the service to merge hijacked account even after the victim resets the password.
the two accounts, either intentionally or unintentionally. At Preconditions. The target service must allow a user to
this point the service might notify the victim that there was reset the account’s password (e.g., by sending a password
already an account associated with that email address. reset email to the email address associated with the account).
If the victim notices something is amiss, they might thwart The service must also allow multiple concurrent sessions.
the attack by resetting the password, which will succeed be- 1. Pre-hijack. The attacker creates an account at the target
cause only the victim will receive the password reset email. service using the victim’s email address. The attacker then
However, if the notification is ignored, or worse, not shown, signs in to the created account and keeps the session active
the victim might start using this “newly-created” account indefinitely. Depending on the service, the attacker might be
without resetting the password. If the service again asks the able to automate the task of keeping the session active (e.g.,
victim to verify their email address, they might proceed as running a script that periodically performs an action).
they would be expecting this. 2. Victim action. Unaware of the attacker’s actions, the
3. Attack. As shown in state S8 of Figure 2, the victim’s victim tries to create an account at the target service using
IdP is correctly associated with the account, but the password their email address. However, since there is already an account
is still that chosen by the attacker. The attacker can thus di- associated with the email address, the service should block
rectly sign in to the victim’s account using this password, the account creation. The victim may assume that they had
whilst the victim continues to sign in via SSO. In terms of previously created an account, but will be unable to sign in
stealthiness, the victim may not notice the attack unless the given the attacker-chosen password. The victim will then
service notifies users about sign-in events (e.g., sends a notifi- proceed to reset the password and begin using the account.
cation, or displays the last sign-in time, etc.). 3. Attack. If the service does not invalidate all active ses-
sions when the password is reset, it could reach state S9 of
Figure 2. Although the password is only known to the victim,
4.2 Unexpired Session Attack
the attacker still has an active session, and can thus continue to
This attack exploits a vulnerability in which authenticated access the account as long as that session is maintained. The
users are not signed out of an account when the password victim may not notice the attack unless the service provides
some indication of current active sessions. (e.g., [email protected] and [email protected]), or an
Another variant of this attack is where the victim instead address that looks like it is part of the service (e.g., target-
attempts to create an account via the federated route (as in the [email protected]). In the attack phase, the attacker re-
Classic-Federated Merge Attack), but the service prevents the gains access to the account by requesting a password reset or
account creation on the basis that there is already an account one-time sign-in link via this alternative identifier. Resetting
associated with that email address. The victim may decide to the password would be noticeable, as the victim would lose
reset the password, and the attack would proceed as above. access to the account, but accessing the account via a one-time
sign-in link may allow the attacker to remain undetected.
4.3 Trojan Identifier Attack
4.4 Unexpired Email Change Attack
This attack combines actions from the Classic-Federated
Merge and Unexpired Session attacks. The attacker creates This attack exploits a potential vulnerability arising from
a pre-hijacked account using the victim’s email address, but the failure to invalidate email-change capability URLs upon
then associates the account with the attacker’s IdP account for password reset. The attacker creates an account using the
federated authentication. When the victim resets the password victim’s email address and begins the process to change the
(as in the Unexpired Session Attack), the attacker can still email address associated with the account to the attacker’s
access the account via the federated authentication route. own email address, but does not complete this process. After
Preconditions. The target service must support both clas- the victim has recovered the account, the attacker completes
sic and federated authentication. However, unlike in the the change-of-email process to take control of the account.
Classic-Federated Merge Attack, users need not be able to Preconditions. The target service must allow users to
create accounts via the federated route – it is sufficient that change the email address associated with an account. In par-
one or more federated identities can be added to an existing ticular, the service must attempt to verify that the user owns
account. The attacker must have an account with an IdP that is the new email address by sending some type of capability to
supported by the service, and from which federated identities the new email address (e.g., a link to click or a code to enter).
can be added to existing accounts at the service. As before, Furthermore, this sent capability must have a reasonably long
the target service must provide password reset functionality. validity period (e.g., days).
1. Pre-hijack. The attacker creates an account at the target 1. Pre-hijack. The attacker creates an account at the target
service using the victim’s email address and a password of the service using the victim’s email address. The attacker then
attacker’s choosing. The attacker then associates their own starts the process to change the email address to the attacker’s
federated identity to the account, such that the attacker can own email address. The service will send a verification email
sign in via either SSO or the chosen password. to the attacker’s email address, but the attacker does not yet
2. Victim action. When the victim attempts to create an ac- confirm the change. Without confirmation, the email change
count with the target service, the account creation will fail as will not proceed, and the account will still be associated with
there is already an account associated with that email address. the victim’s email, as shown in state S6 of Figure 2.
Although unable to sign in (due to the attacker-chosen pass- 2. Victim action. Unaware of the attacker’s actions, the
word), the victim might think they had previously created the victim tries to create an account at the target service using
account and proceed to reset the password. This will succeed, their email address. As before, the account creation will fail
and the victim may start using the account as normal. because of the existing account associated with the victim’s
3. Attack. As shown in state S10 of Figure 2, the attacker’s email address. Similarly, the victim will proceed to reset the
federated identity (denoted as attackerIdPId), is still associ- password, which is possible since the account is still primarily
ated with the account, allowing the attacker to sign in to the associated with the victim’s email address. The victim would
victim’s account via the federated authentication route. In then proceed to use the account as normal.
terms of stealthiness, the victim does not lose access to the 3. Attack. At a later point in time, the attacker confirms
account, so may not suspect that there has been an attack. the pending change-of-email using the capability sent in the
Alternative identifier variant. A variant of this attack ex- verification email from the pre-hijack phase. If this succeeds,
ists where the service 1) allows users to add an alternative it will change the email address associated with the account,
identifier, such as a phone number or second email address, as shown in state S11 of Figure 2. The attacker can then use
and 2) allows users to reset the account password or request the email-based password reset feature to reset the password
a one-time sign-in link via this alternative identifier. Specifi- to an attacker-controlled value.
cally, during the pre-hijack phase, the attacker associates an After the password reset, the victim will lose access to the
attacker-controlled alternative identifier with the account. The account, thus lowering the stealthiness of this attack. How-
attacker can leverage simple deception techniques to reduce ever, similarly to the Trojan Identifier Attack, if users can
the likelihood of the victim noticing this identifier, such as request one-time sign-in links sent to their email addresses,
choosing an email address that is similar to that of the victim the attacker could use this functionality instead of resetting
 Attacker creates an account with the
victim’s email address

S2
Email [email protected]

Passwd attacker123
Phase 1: Pre-hijack

SessionId attackerSId

Attacker connects attacker’s Attacker changes email to

email address or phone attacker’s email address but
number or federated identity does not confirm the change

S5 S6
Emails [email protected], Emails [email protected],
[email protected] [email protected]
Passwd attacker123
IdPId attackerIdPId Passwd attacker123

PhNum attackerPhNum

Victim creates an account

(or signs in) with victim’s Victim resets the Victim resets the Victim resets the
federated identity password and signs in password and signs in password and signs in
Phase 2: Victim action

S8 S9 S10 S11
Email [email protected] Email [email protected] Emails [email protected], Emails [email protected],
[email protected] [email protected]
Passwd attacker123 Passwd victim123 Passwd victim123
IdP attackerIdP Passwd victim123
IdP victimIdP SessionId attackerSid, PhNum attackerPhNum
victimSid
Classic-Federated Merge Attack Unexpired Session ID Attack Trojan Identifier Attack Unexpired Email Change Attack

Figure 2: Attack tree showing the first two phases of the Classic-Federated Merge (Section 4.1), Unexpired Session (Section 4.2),
Trojan Identifier (Section 4.3), and Unexpired Email Change (Section 4.4) attacks.

the password. This allows the victim to continue using the refer to this as a non-verifying IdP. Using this non-verifying
account and thus improves the attack’s stealthiness. IdP, the attacker creates an account with the target service
CSRF variant. In some services, the attacker might be and waits for the victim to create an account using the classic
signed out of the account at the end of the victim action phase route. If the service incorrectly combines these two accounts
(i.e., after the victim resets the password). Furthermore, these based on the email address, the attacker will be able to access
services may require users to be signed in when visiting the the victim’s account.
email-change capability URL, which would prevent the above
Preconditions. The target service must support both clas-
attack. However, in a variant of this attack, the attacker could
sic and federated account creation and sign in. It must also
forge an HTTP request to the email-change capability URL
support at least one non-verifying IdP, thus allowing the at-
by tricking the victim into visiting this URL while the victim
tacker to create a federated identity based on the victim’s
is logged in at the recovered account (e.g., through a CSRF
email address. Alternatively, the service must allow users to
attack or Click-bait). However, if the victim needs to perform
integrate their own custom IdPs. This feature is more common
an action upon visiting the capability URL (e.g., entering a
for business accounts as it allows users of a particular organi-
confirmation code), this will not be possible.
zation to sign in through their organization’s IdP. The avail-
ability of cloud-based IdP services such as OneLogin [30] and
4.5 Non-verifying IdP Attack Okta [29] makes this step easy for the attacker. We found that
these IdPs did not perform email verification for test accounts,
This attack is the mirror image of the Classic-Federated Merge
yet these accounts could still be used as federated identities
Attack, where the attacker created the account using the clas-
at other services.
sic route and the victim used the federated route. In this attack,
the attacker leverages an IdP that does not verify ownership 1. Pre-hijack. The attacker creates a federated identity (i.e.,
of an email address when creating a federated identity. We an IdP account) using the victim’s email address at the non-
 Attacker creates account with the victim’s Attacker creates an account with the attacker’s email
email address using a non-verifying IdP address and verifies the email address

S3 S4
Email [email protected] Email [email protected]
Phase 1: Pre-hijack

IdP attackerIdP Passwd attacker123

Attacker changes
email to the victim’s
email address

S7
Email [email protected]

Passwd attacker123

Victim creates an Victim creates an Victim creates an account

account with the victim’s account with the victim’s (or signs in) with victim’s
Phase 2: Victim action

email address federated identity federated identity

S12 S13 S14

Email [email protected] Email [email protected] Email [email protected]

Passwd victim123 Passwd attacker123

IdP attackerIdP,
IdP attackerIdP victimIdP IdP victimIdP

Non-Verifying IdP Attack (Federated-Federated variant) Email Verification Trick

Figure 3: Attack tree showing the first two phases of the Non-verifying IdP attack (Section 4.4) and the Email Verification trick
(Section 4.6) applied to the Classic-Federated Merge Attack.

verifying IdP. The attacker then uses this federated identity sion) or unintentional. For example, a previously-discovered
and the custom IdP authentication feature to create an account vulnerability [33] in widely-used IdPs, which has now been
with the victim’s email address at the target service. If the fixed, allowed an attacker to create accounts with the victims’
service performed its own verification for email addresses email addresses, which could then be used to create accounts
associated with federated identities, it would block this attack. with various target services. Similar techniques could be re-
However, some services simply assume that IdPs have per- purposed to perform account pre-hijacking attacks.
formed email verification, possibly to minimize user friction
Although we described this attack using a non-verifying
during account creation.
IdP, it would also work equally well with a malicious IdP.
2. Victim action. The victim subsequently creates an ac-
Mainka et al. [24] investigated the dangers of malicious IdPs,
count at the target service via the classic route using their
but did not consider using a malicious IdP for account pre-
email address and victim-chosen password. Since an ac-
hijacking attacks.
count already exists for that email address, the target ser-
vice might just combine this with the account created in the Federated-Federated variant. A variant of this attack is
pre-hijack phase (similarly to the Classic-Federated Merge that, in the victim action phase, the victim creates their account
Attack). Thinking that this was a newly-created account, the at the target service using the federated route instead of the
victim might proceed to use it as normal. classic route. This only works if the target service allows
3. Attack. As shown in state S12 of Figure 3, the attacker’s more than one IdP to be associated with a single account. As
federated identity is still associated with the victim’s account, shown in state S13 of Figure 3, this results in both the victim’s
allowing the attacker to sign in via the non-verifying IdP. and attacker’s federated identities being associated with the
In this attack, the services incorrectly trust the IdP to per- account. In the attack phase, the attacker can therefore sign
form email-verification. The fact that the IdP does not verify in via the federated route, and the victim will continue to sign
email addresses could be intentional (e.g., a business deci- in via their own IdP account.
4.6 Email Verification Trick Reason Occurrences
When mounting some of the above attacks, the target service Similar website already tested 21
may require verification of the supplied email address. For ex- High-requirements 17
ample, the service could send an email to the supplied address No authentication functionality 13
No email functionality 12
containing a unique URL for the user to visit, or a confirma-
Language barrier 10
tion code which the user must provide to the service. Since the
Service not reachable 1
attacker does not have access to the victim’s email account, Other service errors 1
this could help to mitigate attacks in which the attacker needs
to create an account using the victim’s email address (i.e., all Total 75
except the Non-verifying IdP Attack).
However, the attacker may be able to circumvent this check Table 2: Reasons for which services could not be tested.
by abusing the change-of-email functionality provided by
many services. Specifically, the attacker starts by creating an
ings [3]. Of these, 136 supported account creation, and out
account at the target service using an identifier they control.
of these, we were able to test 75 for at least one attack. We
For instance, the email address of the attacker (state S4 of
could not test the remaining 75 websites due to language bar-
Figure 3). During account creation, the service requests veri-
riers, specific requirements for account creation (e.g., needing
fication of the identifier, which the attacker can perform since
to provide a phone number in a specific country), and other
they control the identifier. After the account has been created,
errors. We also omitted websites where a very similar web-
the attacker proceeds to change the primary email address to
site had already been tested (e.g., we tested amazon.com but
that of the victim (state S7 of Figure 3). If the service does
skipped amazon.in as the latter is a localized version of the
not perform another email verification at this point (or if it
former). The summary of reasons for which websites could
associates the victim’s email address to the account before the
not be tested is shown in Table 2. Although this is by no
verification), the attacker is once again in a position to mount
means a representative sample of all websites, it is reasonable
any of the attacks described above (e.g., the Classic-Federated
to assume that the most popular websites expend significant
Merge Attack, resulting in state S14 of Figure 3).
effort in preventing user account hijacking, and thus our re-
sults are likely a lower bound (i.e., conservative estimate) of
5 Experiments & Results the prevalence of such vulnerabilities across all websites.

To measure the prevalence of vulnerabilities that could lead 5.1.2 Analysis actions
to the account pre-hijacking attacks described in the previ-
ous section, we analyzed some of the most popular websites, We specifically focused on email addresses as this is the most
based on the Alexa global website rankings [3]. In Section 5.1, common type of unique user identifier. As per the precondi-
we discuss our experimental methodology, including the crite- tions, at the beginning of the attack, the victim’s email address
ria we used to identify specific services of interest, the set of should not be associated with any account at the target web-
actions we undertook for each service, and the ethical consid- site. This made it necessary to create multiple fresh accounts
erations which guided our analysis. In Section 5.2 we present on each website for each test. In order to identify whether a
a summary of our results and in Section 5.3 we discuss five website met the preconditions of each attack, we created an
case studies of prominent services that are illustrative of the account and explored and documented the features provided
types of attacks we observed during our analysis. by the service. Specifically, we looked for the following types
of functionality:

5.1 Methodology • Create an account via the federated route;

Due to the varied nature of the websites, we relied on man- • Use a custom IdP for federated account creation;
ual (human) analysis. Although this limited the number of
services we could analyze, it provided the most accurate re- • Associate a federated identity with an account;
sults because it is similar to how a potential attacker would • Change the email address associated with an account;
analyze each service. We discuss the potential for automating
the detection of such vulnerabilities in Section 6.3. During our experiments on the Alexa top 150 websites, we en-
countered 22 unique IdPs. Out of them, Google was the most
5.1.1 Selection criteria popular (integrated in 40 websites), followed by Facebook
(32 websites) and Apple (18 websites). For our experiments,
Given the manual effort required, we limited our analysis to we preferred the IdPs with the most frequency (i.e., whenever
the top 150 websites from the Alexa global website rank- we found websites supporting multiple IdPs, we ran our tests
using the most-popular IdP). For the attacks involving email Attack Potentially Vulnerable
addresses, we preferred Google’s mail service, as we could vulnerable
also use the same account for federated authentication. Classic-Federated Merge 54 13
Whenever a website appeared to be vulnerable, we repeated Unexpired Session 74 19
the test with another fresh set of accounts to avoid false posi- Trojan Identifier 49 12
tives and collect additional information for reporting purposes Unexpired Email Change 72 11
(e.g., creating video-recordings of the procedure). Addition- Non-verifying IdP 3 1
ally, we found that websites use several different channels Total 252 56
and templates for reporting security vulnerabilities. Some
websites used third-party vulnerability disclosure services, Table 3: Summary of vulnerabilities identified during our
such as HackerOne [18] and Bugcrowd [11], whilst others testing (January – June 2021). The Potentially vulnerable
provided dedicated vulnerability reporting forms and security column shows how many services we were able to test that
email addresses. We identified these channels and are in the could potentially have been vulnerable to each attack (e.g.,
process of reporting our findings to the affected vendors. providing all the necessary functionality), whilst the Vulner-
able column shows how many were vulnerable to each attack.
5.1.3 Ethical considerations Some services were vulnerable to multiple attacks and the
detailed results are presented in Table 4.
We took multiple precautions to ensure that our experiments
were conducted ethically and the results disclosed responsibly.
Firstly, we ensured that the impact of our experiments did each attack. As shown in Table 3, we identified at least 56
not go beyond the users accounts we had created for this individual vulnerabilities across all attack types and services.
purpose. We limited our experiments to targeted attacks, and Note that this does not mean that the remaining services from
thus did not inadvertently disclose sensitive data belonging to the top 150 list were invulnerable, as we were not able to
other users of the website. test all services due to language barriers or country-specific
Secondly, we did not leverage any automatic tools that requirements, as explained in Section 5.1.1.
could have sent large numbers of requests, as this might have The Unexpired Session Attack had the highest number of
adversely affected the performance of the website for other potentially vulnerable services. This is to be expected since
users. The manual nature of our experiments was equivalent this attack has minimal requirements (e.g., does not require
to a single legitimate user interacting with the website. This the service to support federated authentication) and is theo-
also meant that we did not trigger any bot detection alerts retically applicable to any service that uses the concept of a
(e.g., [4]), which improved the accuracy of our results. session. We also observed that some services that were not
Finally, for each vulnerable website, we submitted a de- vulnerable to the Classic-Federated Merge Attack might still
tailed report to the affected vendor (as shown in Table 4). In be vulnerable to a variant of the Unexpired Session Attack af-
some cases, we have already received acknowledgments and ter the former has been blocked. However, we did not include
bug bounties for these reports. these in Table 3 to avoid potential double-counting.
In all cases, we ensured that the affected vendors have had We found that a similar number of services were vulnerable
at least 90 days to remediate the reported vulnerabilities prior to the Classic-Federated Merge, Trojan Identifier, and Unex-
to the publication of this paper. Additionally, for the case pired Email Change Attacks, when including those for which
studies presented in Section 5.3, we obtained permission to the Email Verification trick (Section 4.6) was used. However,
publish the details of the vulnerabilities from the affected as shown in Table 4, it is not usually the case that the same
vendors. service is vulnerable to all three of these attacks.
The Non-verifying IdP Attack was far less prevalent as it
5.2 Results & Observations requires the service to support user-specified IdPs for fed-
erated authentication. However, we expect that our results
The summarized results of our analysis are shown in Table 3 are an under-approximation as some services might provide
and the detailed list of vulnerable services in Table 4. this functionality as part of a premium plan, which was not
In Table 3, the second column shows how many services always tested. Nevertheless, out of the three services that we
we were able to identify as potentially vulnerable to each type identified as being potentially vulnerable, at least one was
of attack (e.g., they supported account creation, federated vulnerable to this attack.
identities, etc. as required for each attack). The sum of this It is important to note that, at the time of testing, these re-
column (i.e., 252) corresponds to the total number of pre- sults were conservative lower bounds, as it is possible that we
hijacking attacks we performed. might have missed some attacks. On the other hand, we hope
The third column shows how many services, out of those that the number of vulnerable services will have significantly
that were potentially vulnerable, were actually vulnerable to decreased due to our responsible disclosures.
 Type of Service Classic- Unexpired Trojan Unexpired Non- Disclosure Date &
Federated Session Identifier Email verifying Channel
Merge Change IdP
video conferencing • ◦ ◦ ◦ • Mar ’21, H1P
photo sharing social network ◦ ◦ • ◦ – Jul ‘21, SF
news and entertainment • ◦ ◦ ◦ – Sept ‘21, GE
e-commerce ◦ ◦ • ◦ – Sept ‘21, SF
software company ◦ • • ◦ – Sept ‘21, H1
professional social network ◦ • • • – Jun ‘21, SE
cloud file storage ◦ ◦ ◦ •† – Jun ‘21, H1
job search ◦ ◦ ◦ • – Sept ‘21, BC
blog hosting platform ◦ • • •† – Jun ‘21, H1
online learning ◦ ◦ ◦ •† – Sept ‘21, SE
e-commerce • ◦ • ◦ – Jul ‘21, BC
graphics sharing • ◦ ◦ • – Jul ‘21, SE
freelancing platform ◦ • ◦ ◦ – Sept ‘21, BC
e-commerce – • – ◦ – Sept ‘21, SE
music streaming ◦ • • ◦ – Jun ‘21, H1
cryptocurrency – • – – – Sept ‘21, SF
sports news – • – – – Sept ‘21, SF
adult entertainment – • – • – Sept ‘21, H1
real estate • ◦ ◦ ◦ – Jun ‘21, H1
collaboration/productivity • • ◦ ◦ – Jul ‘21, Fe
image sharing • • – ◦ – Jul ‘21, H1
online learning/teaching • ◦ ◦ ◦ – Sept ‘21, H1
productivity tool • ◦ ◦ • – Sept ‘21, H1
news • • • ◦ – Jul ‘21, H1P
news and entertainment – • – ◦ – Sept ‘21, SE
document management ◦ • • ◦ – Sept ‘21, SF
microblogging social network – •∗ – ◦ – Sept ‘21, H1
video hosting ◦ ◦ • ◦ – Sept ‘21, H1
music sharing • ◦ • • – Jun ‘21, BC
Internet tools ◦ •∗ ◦ ◦ – Sept ‘21, GE
travel reservation ◦ •∗ ◦ • – Sept ‘21, H1P
adult entertainment • ◦ ◦ ◦ – Sept ‘21, GF
Internet tools – •∗ – • – Sept ‘21, Tw
financial services • ◦ ◦ ◦ – Sept ‘21, SF
online learning ◦ •∗ • ◦ – Sept ‘21, GF
Total vulnerable 13 19 12 11 1

Table 4: Vulnerabilities identified during our testing (January – June 2021). For each service, – means the vulnerability is not
applicable, ◦ means the service was tested and found not to be vulnerable, and • means the service was found to be vulnerable.
Additionally, •† means a CSRF attack is necessary in the Attack phase and •∗ means that the attack could be carried out
without resetting the victim’s password (e.g., via a one-time sign-in link). We disclosed these vulnerabilities to the services
via their respective disclosure channels, including HackerOne (H1), Security Form (SF), Security Email (SE), Bugcrowd (BC),
HackerOne Private Program (H1P), General-Support Email (GE), General-Support Form (GF), Federacy (Fe), and Twitter (Tw).
5.3 Case Studies been concurrently reported by another researcher. Details of
the concurrent report are not yet publicly available.
In this section we present five case studies that illustrate how
pre-hijacking attacks could be carried out against well-known
services. All the vulnerabilities described in this section have 5.3.2 Instagram
been responsibly disclosed to the respective vendors.
We found that Instagram was vulnerable to the Trojan Identi-
fier Attack.
5.3.1 Dropbox Trojan Identifier Attack (Alternative identifier vari-
We found that the Dropbox website was vulnerable to a variant ant). In Instagram, identifier verification is mandatory when
of the Unexpired Email Change Attack. creating an account. Nevertheless, an attacker could create
Unexpired Email Change Attack. As described in Sec- an account using the attacker’s phone number, and associate
tion 4.4, the attacker could create an account using the vic- the victim’s email address to the created account. This would
tim’s email address. Dropbox would then send an email to the cause a verification email to be sent to the victim’s email
victim, asking them to confirm their email address. However, address. However, based on our assumptions in Table 1, some
having not signed up for a Dropbox account, the victim might victims might ignore this email. When the victim subse-
ignore this email because it did not give any instructions as to quently tried to create an account using their email address,
what they should do if they did not create the account. The at- they would find that an account already exists (and might
tacker would then start the change-of-email process changing misinterpret this as e.g., being related to the acquisition of
to the attacker’s email address, and Dropbox would send a Instagram by Facebook, if they already have a Facebook ac-
confirmation email to the attacker’s email address (transition count with the same email address). The victim might recover
S2 to S6 in Figure 2). This email contained a URL to confirm the account and start using it. The attacker would then be
the change-of-email, but the attacker would not yet use it. able to sign into the account by requesting a one-time sign-in
When the victim tried to create an account using their own link to be sent to the attacker’s phone number. However, the
email address, this would fail because the email is already attack can be thwarted if the victim notices and removes the
associated with an account, and Dropbox would instead ask attacker’s phone number from the account.
the victim to sign in to that account. The victim might then As Instagram is a social network and an IdP, a successful
use email-based account recovery and set a new password, attacker would be able to access photos and videos shared
causing the attacker to lose access to the account. As shown by the victim and members of their network, and sign in to
in Figure 4a, alert victims might notice the pending email other services where the victim uses Instagram as an IdP. The
change notification in the user interface (UI) and cancel this. attacker would also be able to read the chats of the victim
However, some victims might not notice this. and impersonate the victim. When we responsibly disclosed
Some time later, the attacker could make the victim visit the our findings to Instagram in July 2021, they noted that their
change-of-email confirmation URL (e.g., through a CSRF at- identifier verification emails include a link to report suspicious
tack [13]), which would associate the attacker’s email address sign ups. However, it is unclear how many victims would
with the account. The victim would then see the UI shown take action in this situation, as previous studies (e.g., [2])
in Figure 4b. The attacker could then use the email-based have shown user-initiated security decisions to be ineffective.
password reset feature to gain access to the account. Additionally, Instagram also noted that it is the responsibility
As Dropbox is a cloud-based file storage service and an of the users to look for Trojan identifiers in their profile.
IdP, a successful attack could allow the attacker to access the
victim’s private files and sign in to other services where the 5.3.3 LinkedIn
victim uses Dropbox as an IdP. However, observant victims
might notice that the attacker’s email address is also shown in We found that LinkedIn was potentially vulnerable to the
their account (pending confirmation), and might take action Unexpired Session Attack and a variant of the Trojan Identifier
to remove this, which would block the attack. Furthermore, Attack.
we were not able to test the validity period of the confirma- Unexpired Session Attack. This was potentially feasible
tion URL (and the confirmation email did not state a validity because LinkedIn did not by default invalidate the active
period). The validity period of this URL would also limit sessions of an account after a password change. An option
the possible window of attack. We responsibly disclosed our for doing this was displayed during the password change
findings to Dropbox via HackerOne in June 2021. procedure, but was not selected by default. If the victim did
Session fixation attack. During our experiments, we also not select this option, the account remained vulnerable to
discovered a session fixation attack against Dropbox, which this type of attack. We also noticed that this attack could be
allows an attacker to directly sign in to an existing Dropbox performed using the email verification trick (Section 4.6).
account by fixing the session ID [31]. When we reported this Trojan Identifier Attack. This was potentially feasible
issue via HackerOne, it was marked as a duplicate as it had because LinkedIn provides the option to associate multiple
 (a) Dropbox UI at the end of Pre-hijack phase (Phase 1) (b) Dropbox UI at the end of Attack phase (Phase 3)

Figure 4: Dropbox UI of the victim’s account during the Unexpired Email Change Attack.

email addresses with an account. As described in Section 4.3, Unexpired Session Attack. In the Victim action phase,
the attacker creates an account with the victim’s email address when the victim tried to create an account with their email
and then adds their own email address to the account. This address, Wordpress.com notified the victim that an account
sends an email-change verification URL to the attacker’s already exists and provided the option to sign in to the account
email address. via a one-time link sent to the victim’s email address. As long
After the victim recovers the account and confirms their as the victim makes use of this option (i.e., does not reset
own email address, any attempt to confirm another email their password), the attacker can maintain their access to the
address must be made from an authenticated session. The account. However, even once the victim sets a new password,
attacker thus needs the victim to visit the confirmation URL the attacker’s earlier session will not be invalidated, allowing
on the attacker’s behalf (e.g., through a CSRF attack). If the attacker to retain access potentially indefinitely if the
successful, the attacker could request a one-time sign in link session is kept active.
for this account to be sent to their email address, allowing Unexpired Email Change Attack. Similarly to the first
them to access the account without the victim’s password. case study, in order to successfully execute this attack, the
As LinkedIn is a professional social network and an IdP, a attacker would need to perform a CSRF-like attack in the
successful attack could allow the attacker to read the victim’s Attack phase.
sensitive conversations, impersonate the victim, or sign in as A successful attack on Wordpress.com would allow the
the victim at other services where the victim uses LinkedIn attacker to maliciously modify the websites managed by the
as an IdP. We reported our findings to LinkedIn in June 2021. victim and sign in to other services where the victim uses
As a result, LinkedIn changed the default behavior to invali- Wordpress.com as an IdP. When we reported our findings to
date active sessions after a password change, thus mitigating Wordpress.com via HackerOne in June 2021, the reports were
the Unexpired Session Attack. They also noted that they use marked as “Not Applicable”. These vulnerabilities were not
multiple defense in depth techniques to minimize the win- present in the self-hosted version of the Wordpress software
dow of vulnerability for Trojan Identifier Attacks. Firstly, the because it required all self-registered users to verify their
email-change verification URLs are only valid for a limited email addresses before allowing them to perform any actions.
period of time, forcing the attacker to refresh these regularly.
Secondly, there is only a short time window after the victim’s 5.3.5 Zoom
last authentication in which email-change confirmations will
be accepted without requiring re-authentication. After this We found that Zoom was vulnerable to the Classic-Federated
window, the victim will be asked to re-authenticate, which Merge and Non-verifying IdP Attacks.
would likely raise suspicion. Finally, LinkedIn uses various Classic-Federated Merge Attack. Although free Zoom
anti-abuse controls to prevent the creation of multiple ac- accounts require email verification before the account is cre-
counts with unconfirmed email addresses. We discuss these ated, this restriction was not present for paid accounts. This
defenses further in Section 6.2.2. enables an attacker to abuse the paid account creation pro-
cess to create an account using the victim’s email address
and perform the Classic-Federated Merge Attack. The UI of
5.3.4 Wordpress.com
Zoom when the victim tried to create their account in the
We found that Wordpress.com was vulnerable to the Unex- Victim action phase of this attack is shown in Figure 5. As
pired Session and Unexpired Email Change Attacks. evident from the figure, the victim would believe they were
 scale-up the attack to a larger number of users and services.
For example, the attacker could obtain lists of potential iden-
tifiers (e.g., email addresses and phone numbers) by scraping
social/professional networking services, accessing data from
data breach incidents, or by leveraging contact information
aggregation services. The attacker can then try to create ac-
counts for these identifiers at a large number of services, using
automated scripts. Although the account creation may fail on
some services, as the victim may already have an account, it is
likely to succeed on several other services. New services that
are increasing in popularity are a particularly attractive target
for pre-hijacking attacks as victims are less likely to have
Figure 5: Zoom’s UI in the Victim action phase of the Classic- already created accounts, but are likely to do so in future. For
Federated Merge Attack. This may lead the victim to believe instance, in 2020, the Zoom video-communications software
they are creating a new account instead of being signed in to saw a huge growth in their user base due to the Coronavirus
an attacker-created account. pandemic [10]. After creating the accounts, the attacker can
leverage automated scripts to periodically check whether the
victims have recovered (or started using) the pre-hijacked
creating a fresh account, instead of being signed in to the accounts. For example, in the Unexpired Session attack, the
attacker-created account. attacker can detect account recovery by checking whether the
Non-verifying IdP Attack. Since Zoom supports custom credentials chosen during the pre-hijacking phase can still be
IdPs, the attacker could use a non-verifying IdP to create used to sign-in to the account. After the victims start using the
a Zoom account with the victim’s email address. For our pre-hijacked account, the attacker can wait for a suitable pe-
experiments, we used OneLogin’s IdP service [30]. When riod of time (e.g., to allow the victim time to provide sensitive
the victim subsequently came to create a Zoom account with information) before completing the attack.
the same email address, Zoom did not notify the victim of
the existence of an account with the same email address and
instead signed the victim in to the attacker-created account. 6.2 Root Cause & Mitigation
Being able to login to the victim’s Zoom account would
enable the attacker to record the meetings attended by the 6.2.1 Strict Identifier Verification
victim, access the participant details (e.g., attendee names and
email addresses) of any meetings hosted by the victim, access The root cause of all of the attacks identified in the preceding
the sensitive chat history, impersonate the victim in Zoom sections is failure to verify ownership of the claimed identi-
chat, and sign in to other services where the victim uses Zoom fier. This applies directly to the service itself (as illustrated
as an IdP. When we responsibly disclosed these attacks to by the Classic-Federated Merge, Unexpired Session, Trojan
Zoom in August 2020 and March 2021, they assessed both Identifier, and Unexpired Email Change Attacks), as well as
reports as high severity and fixed the vulnerabilities. to the IdP (see Non-verifying IdP Attack). Although many
services do perform this type of verification, they often do so
6 Discussion asynchronously, allowing the user to use certain features of
the account before the identifier has been verified. Although
In this section we discuss account pre-hijacking attacks from this might improve usability (reduces user friction during sign
the perspective of attackers and defenders, explaining how up), it leaves the user vulnerable to pre-hijacking attacks.
they might be scaled up to target a larger number of users, On the other hand, all of the above attacks could be mit-
as well as identifying the root cause of the vulnerabilities igated if the service or IdP sent a verification email to the
and presenting several defense in depth strategies. We also user-provided email address and required the verification to
sketch out a possible approach for automating the process of be successfully completed before allowing any further actions
scanning for these vulnerabilities, and provide further details associated with the account. A similar approach could be used
about our responsible disclosures to the affected services. 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 relies on the IdP to perform
6.1 Scaling Pre-Hijacking Attacks
verification, it should require a strong guarantee from the IdP
In Section 4, we described the account pre-hijacking attacks that this verification has been performed. Alternatively, the
from the perspective of an attacker targeting a specific victim service could perform its own additional verification, but this
on a specific service. However, it is likely also possible to adds further friction and negatively effect usability.
6.2.2 Defense in Depth number of times a new account can be created for the same
identifier, without the identifier being verified. However, this
In addition to the identifier verification discussed above (or
in turn could allow the attacker to mount a type of Denial-of-
if this is not possible), services can implement the following
Service (DoS) attack by exhausting the account creation quota
recommendations to achieve defense in depth.
of the identifiers of legitimate users. Therefore, the service
Password resets. When the password for an account is can instead reduce the pruning threshold for unverified ac-
reset, the service should perform the following actions: counts and leverage bot-detection frameworks to limit the rate
• Sign out all other sessions and invalidate all other au- at which the attacker can automatically create new accounts.
thentication tokens for that account. This would mitigate Multi-Factor Authentication (MFA). Users can protect
the Unexpired Session Attack. themselves from pre-hijacking attacks by activating MFA in
their accounts. Correctly-implemented MFA will prevent the
• Cancel all pending email change actions for that account attacker from authenticating to a pre-hijacked account after
to mitigate the Unexpired Email Change Attack. the victim starts using this account. In order to prevent the
Unexpired Session Attack, the service must also invalidate
• Notify the user of which federated identities, alternate any sessions created prior to the activation of MFA.
email addresses, and phone numbers are currently linked Additional Security Measures. During our experiments,
to the account and ask them to explicitly select which we observed several additional security measures taken by
ones to retain (i.e., unlink by default). Alternatively, ask some of the services we analyzed, and we highlight these
the user to select any identifiers they do not recognize here. Some services included a link in the verification emails
(i.e., retain by default), but this runs the risk of the user sent to the victim to report suspicious activity (e.g., as dis-
ignoring the prompt. Assuming the user acts correctly, cussed in the Instagram case study). Some services notified
this would mitigate the Non-verifying IdP Attack. users of any security-critical changes to their account, such as
Merging accounts. When a service merges an account email/password changes and new devices/location anomalies.
created via the classic route with one created via the federated Both of these approaches could help to detect or alert the user
route (or vice-versa), the service must ensure that the user to a pre-hijacking attack. Some services allowed creation of
currently controls both accounts. For example, when the user multiple accounts with the same identifier, and thus avoided
attempts to create an account via the federated route but a merging the attacker’s and victim’s accounts.
classic account already exists for the same email address,
the user should be required to provide or reset the password 6.3 Automatically Detecting Vulnerabilities
for the classic account. Additionally, the steps we discussed
above for strengthening the password-reset process should Although our experiments relied on manual testing, we be-
also be applied. This would mitigate the Classic-Federated lieve that it should be possible for service owners to automate
Merge, and Non-verifying IdP Attacks. testing for pre-hijacking vulnerabilities, at least to some extent.
Email change confirmations. When the service sends a For example, service owners likely have access to a private
capability (e.g., a code or a URL with an embedded authen- testing version of the service in which they could temporarily
tication token) to confirm a change of email address, the disable any anti-automation protection measures. This should
validity period of this capability should be as low as possi- make it possible to write and deploy automated scripts that
ble, within the constraints of usability, in order to minimize perform the actions from each phase of the pre-hijacking at-
the window of vulnerability for the Unexpired Email Change tacks in Section 4. These would likely have to be customized
Attack. However, this will not prevent the attacker from con- for the specific service (e.g. to automate service-specific pro-
tinuously requesting new capabilities whenever the previous cesses such as account creation, email change, etc.). The script
ones expire. Therefore, the service must limit the number of could vary the sequence in which these actions are performed
times a new capability can be requested from an account to to test different patterns of interaction. This could be used in
the same, unverified identifier. conjunction with a test oracle that checks the server-side state
Unverified-Account Pruning. Account pruning refers to of the service to identify potential vulnerabilities. Finally, af-
the practice of deleting inactive user accounts (e.g., [25]). Ser- ter executing each test, the state of the test service could be
vices can apply the same process to unverified user accounts reset to a default value, to accelerate the testing process. In
(i.e., accounts pending identifier verification). Lowering the future, we hope that web application vulnerability scanners
time threshold for pruning unverified accounts would reduce might also support this type of semi-automated scanning.
the window of vulnerability for most pre-hijacking attacks
(an exception is the Non-verifying IdP Attack). However, this 6.4 Responsible Disclosure
will not prevent an attacker from creating a new account with
the same identifier after the previous account gets pruned. In Section 5.3, we showed that account pre-hijacking attacks
To prevent this, the service should monitor and/or limit the can have serious consequences including disclosure of sensi-
tive information (e.g., Sections 5.3.1 and 5.3.3), website de- an account through federated means before trying to sign
facement (e.g., Section 5.3.4), and spying on web users (e.g., in. Nevertheless, these reports indicate that the security bug
Section 5.3.5). In light of this, we responsibly disclosed all the bounty research community is already-aware of account pre-
56 vulnerabilities we identified on 35 services. We reported hijacking attacks.
19 of the vulnerabilities via third-party vulnerability coordi- Account hijack with SSO. Mainka et al. [24] explain how
nation platforms, including HackerOne [18], Bugcrowd [11], a web attacker could hijack the victim’s RP account through
and Federacy [15]. We reached out to a further 11 companies a malicious IdP. Similarly, Peles [33] explores the possibility
through their dedicated email addresses and forms for report- of an attacker signing in to the existing RP accounts of the
ing security vulnerabilities. For those services that lacked ded- victim by leveraging a vulnerable IdP that allows SSO logins
icated security channels (4), were reached out through their before the completion of email verification. These are closely
general support emails and forms. For one service, we could related to and influenced the techniques we use in our Non-
not find any of the above contact channels, so we reached verifying IdP Attack. Homakov et al. [20] and Sclafani et
them through their parent company’s Twitter profile. The date al. [35] discuss attacks that enable an attacker to authenticate
on which we disclosed the vulnerabilities to each service is to the victim’s RP account by connecting the attacker’s IdP
shown in the last column of Table 4. account to it. This contributed to the technique we use in
our Trojan Identifier Attack. Although there is a large body
of literature discussing logical vulnerabilities in the login
7 Related Work
process e.g., [5, 6, 38, 40, 41], there has been relatively little
Many of the techniques we use in our pre-hijacking attacks focus on the security of account creation, which as we have
are inspired by prior work on related classes of attacks. shown in this work, is also critical for protecting users.
Preemptive account hijacking. To the best of our knowl- Account hijack without SSO. Zeller et al. [42] present an
edge, Ghasemisharif et al. [17] present the first example of attack in which the attacker associates their own email address
preemptive account hijacking in the scientific literature (see to the victim’s account and takes control of the account by
Section 5 of [17]). Our work builds upon their example, but requesting a password reset link to be sent to the attacker’s
assumes a significantly weaker attacker. Specifically, they email address. Similarly, Innocenti et al. [21] discusses at-
consider an attacker who has gained control of the victim’s tacks based on the password-reset URLs and Lee et al. [23]
federated identity (e.g., the victim’s IdP account). Although presents the scenario where an attacker owns the recycled
this is certainly possible, as they demonstrate in the same phone number of the victim to hijack the accounts of the vic-
work [17], it goes beyond the standard web attacker threat tim through SMS-based password reset. Although the threat
model (e.g., [1]). Additionally, multi-factor authentication model considered in these works are different from ours, they
(MFA) at the IdP, and browser-level protection mechanisms inspired our Unexpired Email Change and Trojan Identifier
such as HTTP Strict-Transport-Security (HSTS) [27], make it Attacks. Additionally, the classic account hijack attack using
more difficult for an attacker to execute their attack. Neverthe- CSRF [13] talks about the capability of the attacker to sign
less, their attack is more powerful than any of ours, since once in to the victim’s account by setting an attacker-chosen pass-
a victim’s IdP account has been compromised, this can be used word on the account. This attack motivated our discovery of
to hijack even the existing RP accounts of the victim. In con- the Classic-Federated Merge Attack.
current work with ours, Ghasemisharif et al. [16] also present Login CSRF. The common element of account pre-
a tool for automated auditing of session management flaws in hijacking and login CSRF attacks (e.g., [9, 39]) is that, in
SSO, which again assumes that the attacker has compromised both cases, the attacker attempts to trick the victim to use an
the victim’s IdP account at the session level. In contrast, we attacker-controlled account. Both classes of attacks thus allow
show that there exists a class of account pre-hijacking attacks the attacker to spy on the actions performed by the victim
that are possible without compromising the victim’s federated while they are signed in to the attacker-controlled account.
identity. These attacks are thus significantly easier to execute, However, the main difference is in the way the victim ends up
as demonstrated by our analysis in Section 5.2. signed in to the attacker-controlled account. In login CSRF
As we explained in Section 6.4, some vendors marked attacks, the victim is forcefully authenticated to the attacker’s
our reports on the Classic-Federated Merge Attack as du- account, which may be noticed by observant users. In contrast,
plicate (indicating that the attack had been reported previ- in account pre-hijacking, the victim willingly signs in to what
ously). Upon further investigation, we identified two recent they believe to be their own account, unaware that it has been
HackerOne reports [14, 19] that mention a variant of our at- pre-hijacked.
tack (referred to as pre-account takeover). In this variant, it
is assumed that the victim will directly try to do federated 8 Conclusion & Future Work
authentication after the attacker has pre-hijacked the account.
In our version of the Classic-Federated Merge Attack, we In this paper, we show that there exists an entire class of
make the assumption that the victim will first try to create account pre-hijacking attacks, which ultimately allow an at-
tacker to take control of a victim’s account. We describe five [4] Babak Amin Azad, Oleksii Starov, Pierre Laperdrix,
specific attacks. To measure the prevalence of these vulnera- and Nick Nikiforakis. Web Runner 2049: Evaluating
bilities in the wild, we analyzed the top 75 popular services Third-Party Anti-bot Services. In Proceedings of the
based on the Alexa global rankings. We found that at least Conference on Detection of Intrusions and Malware
35 of these were vulnerable to one or more pre-hijacking at- and Vulnerability Assessment, 2020.
tacks, including major services such as Dropbox, Instagram,
LinkedIn, Wordpress.com, and Zoom. We disclosed these vul- [5] Alessandro Armando, Roberto Carbone, Luca
nerabilities to the affected organizations, some of which have Compagna, Jorge Cuellar, and Llanos Tobarra. Formal
acknowledged the vulnerabilities as being of high severity. Fi- Analysis of SAML 2.0 Web Browser Single Sign-on:
nally, we analyzed the root cause of these vulnerabilities, and Breaking the SAML-Based Single Sign-on for Google
presented a set of security requirements that would mitigate Apps. In Proceedings of the ACM Workshop on Formal
all the vulnerabilities we identified. Methods in Security Engineering, 2008.
There are several potential avenues for future research re- [6] Guangdong Bai, Jike Lei, Guozhu Meng,
lated to account pre-hijacking attacks. Firstly, account pre- Sai Sathyanarayan Venkatraman, Prateek Saxena, Jun
hijacking attacks are largely possible because of services not Sun, Yang Liu, and Jin Song Dong. AUTHSCAN:
performing strict identifier verification (e.g., to reduce user Automatic Extraction of Web Authentication Protocols
friction during account creation). An empirical evaluation from Implementations. In Proceedings of the Network
of this topic could explore the precise usability benefits and and Distributed System Security Symposium, 2013.
contrast these against the security risks. Secondly, automated
detection of account pre-hijacking vulnerabilities is a promis- [7] Amol Baikar. Facebook OAuth Framework
ing avenue for future work, as such tools could extend the Vulnerability.
evaluation to more websites, mobile applications, and desktop https://www.amolbaikar.com/facebook-oauth-
applications. Although we briefly sketch a design for this in framework-vulnerability/.
Section 6.3, this could be explored in greater detail. Finally,
pre-hijacking attacks such as the Unexpired Email Change [8] Adam Barth. HTTP State Management Mechanism.
Attack show the importance of capability URLs. Further re- https://www.rfc-
search is needed on the types of capability URLs in use, their editor.org/rfc/rfc6265.html.
typical validity periods, and the ways in which they might be [9] Adam Barth, Collin Jackson, and John C. Mitchell.
abused (e.g., [21]). Robust Defenses for Cross-site Request Forgery. In
Proceedings of the ACM Conference on Computer and
9 Acknowledgements Communications Security, 2008.

We thank our shepherd, Emily Stark, and the anonymous re- [10] BBC. Zoom sees more growth after unprecedented
viewers for their valuable feedback. We also thank the vendors 2020.
who collaborated with us during the responsible disclosure https://www.bbc.com/news/business-56247489.
process. This work was supported by a research grant from [11] Bugcrowd. https://www.bugcrowd.com/.
the Microsoft Security Response Center (MSRC).
[12] Clickbait.
https://en.wikipedia.org/wiki/Clickbait.
References
[13] Cross-Site Request Forgery.
[1] Devdatta Akhawe, Adam Barth, Peifung E. Lam, John https://en.wikipedia.org/wiki/Cross-
Mitchell, and Dawn Song. Towards a Formal site_request_forgery.
Foundation of Web Security. In Proceedings of the
IEEE Computer Security Foundations Symposium, [14] Bibek Dhakal. Misconfigured oauth leads to Pre
2010. account takeover, 2021.
https://hackerone.com/reports/1074047.
[2] Devdatta Akhawe and Adrienne Porter Felt. Alice in
Warningland: A Large-Scale Field Study of Browser [15] Federacy. https://www.federacy.com/.
Security Warning Effectiveness. In Proceedings of the
USENIX Security Symposium, 2013. [16] M. Ghasemisharif, C. Kanich, and J. Polakis. Towards
Automated Auditing for Account and Session
[3] Alexa. Top 500 Sites on the Web. Management Flaws in Single Sign-On Deployments. In
https://www.alexa.com/topsites. Proceedings of the IEEE Symposium on Security and
Privacy, 2022.
[17] Mohammad Ghasemisharif, Amrutha Ramesh, Stephen [31] OWASP. Session fixation. https://owasp.org/www-
Checkoway, Chris Kanich, and Jason Polakis. O Single community/attacks/Session_fixation.
Sign-Off, Where Art Thou? An Empirical Analysis of
[32] OWASP. Top Ten 2017 A1:2017-Injection.
Single Sign-On Account Hijacking and Session
https://owasp.org/www-project-top-
Management on the Web. In Proceedings of the
ten/2017/A1_2017-Injection.
USENIX Security Symposium, 2018.
[33] Or Peles. Spoofedme - Intruding Accounts using Social
[18] HackerOne. https://www.hackerone.com/. Login Providers. https://www.slideshare.net/
[19] Ahmad Halabi. Lack of email verification on Signup ibmsecurity/spoofed-me-socialloginattack.
lead to OAuth Misconfiguration - Account Takeover by [34] PortSwigger. Common CSRF vulnerabilities.
creating a backdoor password, 2020. https://portswigger.net/web-security/csrf.
https://hackerone.com/reports/788894.
[35] Stephen Sclafani. CSRF Vulnerability in OAuth 2.0
[20] Egor Homakov. The Most Common OAuth2 Client Implementations.
Vulnerability. http://homakov.blogspot.com/ https://stephensclafani.com/2011/04/06/
2012/07/saferweb-most-common-oauth2.html. oauth-2-0-csrf-vulnerability/.
[21] Tommaso Innocenti, Seyed Ali Mirheidari, Amin [36] Security Assertion Markup Language (SAML) V2.0
Kharraz, Bruno Crispo, and Engin Kirda. You’ve Got Technical Overview.
(a Reset) Mail: A Security Analysis of Email-Based http://docs.oasis-open.org/security/saml/
Password Reset Procedures. In Proceedings of the Post2.0/sstc-saml-tech-overview-2.0.html.
Conference on Detection of Intrusions and Malware
[37] Security Vulnerabilities (Memory Corruption).
and Vulnerability Assessment, 2021.
https://www.cvedetails.com/vulnerability-
[22] Bhavuk Jain. Zero-day in Sign in with Apple. list/opmemc-1/memory-corruption.html.
https://bhavukjain.com/blog/2020/05/30/ [38] Avinash Sudhodanan, Alessandro Armando, Roberto
zeroday-signin-with-apple/. Carbone, and Luca Compagna. Attack Patterns for
[23] Kevin Lee and Arvind Narayanan. Security and Privacy Black-Box Security Testing of Multi-Party Web
Risks of Number Recycling at Mobile Carriers in the Applications. In Proceedings of the Network and
United States. Technical report, Princeton University, Distributed System Security Symposium, 2016.
2021. https://recyclednumbers.cs.princeton. [39] Avinash Sudhodanan, Roberto Carbone, Luca
edu/assets/recycled-numbers-04-28-2021.pdf. Compagna, Nicolas Dolgin, Alessandro Armando, and
[24] Christian Mainka, Vladislav Mladenov, and Jorg Umberto Morelli. Large-Scale Analysis Detection of
Schwenk. Do Not Trust Me: Using Malicious IdPs for Authentication Cross-Site Request Forgeries. In
Analyzing and Attacking Single Sign-on. In Proceedings of the IEEE European Symposium on
Proceedings of the IEEE European Symposium on Security and Privacy, 2017.
Security and Privacy, 2016. [40] San-Tsai Sun and Konstantin Beznosov. The devil is in
the (implementation) details: an empirical analysis of
[25] MantisHub. Pruning User Accounts.
OAuth SSO systems. In Proceedings of the ACM
https://support.mantishub.com/hc/en-us/
Conference on Computer and Communications
articles/203574869-Pruning-User-Accounts.
Security, 2012.
[26] Mozilla. SameSite Cookies. [41] Rui Wang, Shuo Chen, and XiaoFeng Wang. Signing
https://developer.mozilla.org/en-US/docs/ Me onto Your Accounts through Facebook and Google:
Web/HTTP/Headers/Set-Cookie/SameSite. A Traffic-Guided Security Study of Commercially
[27] Mozilla. Strict-Transport-Security. Deployed Single-Sign-On Web Services. In
https://developer.mozilla.org/en-US/docs/ Proceedings of the IEEE Symposium on Security and
Web/HTTP/Headers/Strict-Transport-Security. Privacy, 2012.
[42] William P. Zeller and Edward W. Felten. Cross-Site
[28] OAuth. https://en.wikipedia.org/wiki/OAuth.
Request Forgeries: Exploitation and Prevention.
[29] Okta. https://www.okta.com. Technical report, Princeton University, 2008.
https://people.eecs.berkeley.edu/~daw/
[30] OneLogin. https://www.onelogin.com/. teaching/cs261-f11/reading/csrf.pdf.