IBM X-Force Finds Social Login Attack That Allows Intrusion to Many Websites’ Local Accounts

Social login is a popular mechanism that offers a convenient way for users to quickly gain access to their Web accounts without the need to enter per-site credentials, allowing for a cohesive and integrated Web experience. It works by letting a user log in to cooperating sites that support social login by using their existing external account as an identity provider (such as a Facebook, Google+ or LinkedIn account). One can recognize a site supporting social login by the “Sign In With Facebook/LinkedIn/etc.” button.

IBM X-Force’s Application Security Research Team has devised a logical attack that allows a malicious user to intrude into user accounts on a relying website — a website that relies on authentication assertions passed to it by the identity provider — by abusing the social login mechanism.

A specific instance of this attack allowed an attacker to intrude into a Slashdot.org user account by using the “Sign In With LinkedIn” service. It should be noted that LinkedIn responded quickly and fixed this vulnerability after the attack was disclosed. Once logged in, the attacker has complete access to the victim’s account. For example, the attacker could access the victim’s private information and impersonate him or her by posting spam messages.

Download the whitepaper for more technical details

IBM X-Force has dubbed this attack “SpoofedMe,” and it requires the following combination of flaws:

• A vulnerability that was found with some social login identity providers, including LinkedIn, Amazon and MYDIGIPASS. (See below for the vendors’ mitigations following the private disclosure.)
• A known design issue present in the affected relying websites, or those that rely on the identity providers to verify a user’s identity.

For the attack to work, the victim’s email address must not already be used by an existing account at the vulnerable identity provider.

In short, to perform the attack, a cybercriminal registers a spoofed account within a vulnerable identity provider using the victim’s email address. Then, without having to actually confirm ownership of the email address, the attacker will log in to the relying website using social login with this fake account. The relying website will check the user details asserted from the identity provider and log the attacker in to the victim’s account based on the victim’s email address value.

The best way to illustrate the attack is through an example. For ease of explanation, we will stick with the example of Slashdot as a vulnerable relying website and LinkedIn as a vulnerable identity provider throughout this post, though LinkedIn has fixed its vulnerability and other providers and relying websites were also affected.

Social Login Explained

As previously mentioned, social login is an authentication mechanism that allows a user to use a single account within an identity provider (such as Facebook, Google+ or LinkedIn) for signing in to various third-party websites. In recent years, the concept of social login has increased in popularity and is commonly seen in websites’ login pages in the form of a sign-in button. Today, most social login implementations are based on the OAuth 1.0 and 2.0 authorization protocols, extended to support authentication.

The following three players are involved in a social login authentication process:

1. User: A website’s user that wants to log in to his or her local webite’s (Slashdot) account.
2. Identity Provider: A company that offers external authentication services, typically a social network provider.
3. Relying Website: A website (Slashdot) that maintains local user accounts and supports social login authentication with certain identity providers it trusts.

Simplified Social Login Authentication Process

1. A user surfs to the Slashdot website and receives a login form. Instead of entering the username and password for Slashdot, she clicks on the “Sign In With LinkedIn” login button.
2. Slashdot directs the user’s browser to LinkedIn for the user to authenticate.
3. The user authenticates with LinkedIn (using her LinkedIn credentials) and authorizes LinkedIn to supply the user’s details (such as username, email, full name and user ID within LinkedIn) to Slashdot.
4. Using HTTP redirect status code, LinkedIn redirects the user back to Slashdot, along with a signed parameter containing the user’s details (or by an access token for Slashdot to use to fetch the user details from LinkedIn servers).
5. Slashdot receives the user’s details from LinkedIn and logs the user in to her local account.

Explaining the Social Login Attack

As the attacker, we would like to be able to intrude into an existing user’s (the victim’s) account within a website supporting a social login option. To achieve this, we will impersonate the victim with the help of the social login authentication process.

The social login attack depends on a combination of two things: the identity provider vulnerability and one of the relying website design problems described below.

The Identity Provider Vulnerability

As seen in Step 4 above, the identity provider (LinkedIn) transfers the user’s identity fields to the relying website (Slashdot). One of the fields is the user’s email address. Many identity providers allow users to create identity accounts using any email address they wish as long as it isn’t already in use by another account within the identity provider’s database. The vulnerability we identified is that some identity providers agree to supply the account’s email addresses as part of the social login authentication process even when the user’s ownership of this email address has not been positively verified.

In fact, intuitively, it is good practice to only supply email addresses that have been verified, as most identity providers do. See Identity Provider Vulnerability section in our paper for more info.

Known Relying Website Design Problems

Both of the following design problems count on the website’s trust in the email address field supplied to it during the social login process:

• Using an Email Address as a Unique Identifier: A common relying website design problem is the use of an email address as a sufficiently unique identifier for its local user accounts without verifying the specific identity provider(s) previously used with the account. This means that claiming (using an identity provider) to own an email address is enough to log a user in to the local account that uses the same email address. This design problem may arise in cases where support for social login providers was added to an existing system without redesigning the user database in the migration process.
• Account Linking: In order to let users log in to their local account using more than one way (such as using LinkedIn sometimes, and using Facebook other times), websites can use a feature called account linking (or merging). The user experience is improved by not forcing the user to remember which of his or her accounts was used to log in to which site. When, for the first time, a user logs in with a different identity provider (than previously used with his or her existing local account) and uses an email address that is identical to that of his or her existing account, a website could assume he or she is the owner of the account and automatically link the new identity with the existing local account without asking for any additional credentials.

Attack Stages

1. In advance, an attacker registers a new account within LinkedIn, using the email address used by the victim’s Slashdot account. The new LinkedIn account will be created, but in an “email-unverified” state.
2. The attacker surfs to Slashdot and chooses the “Sign In With LinkedIn” login option. The attacker’s browser now gets redirected to the authentication form in the LinkedIn website.
3. On LinkedIn, the attacker enters the newly registered account credentials (from Step 1) and agrees to pass his identity details (victim’s email address included) to Slashdot. The attacker’s browser is redirected back to Slashdot to continue login. If successful, either of the following will happen:
4. 1. In the case of the first website design problem presented, Slashdot will log the attacker in to the victim’s Slashdot account, based on the matching email address passed to it via social login.
   2. In the case of the account linking design problem, Slashdot will notice that the email address matches that of another existing Slashdot account and link the attacker’s account with the existing one (victim’s) so the attacker will be logged in to the victim’s account on the website.

As a side effect of Step 1, the victim will receive an “email verification request” that may raise his suspicion, but his response will almost certainly be too late to prevent intrusion to his account.

Real-World Cases

Before announcing the attack, we reviewed the popular identity providers and adhered to IBM Security’s responsible disclosure policy by privately disclosing the attack details to the ones found vulnerable and waiting for them to apply their fixes.

Here are some interesting providers’ cases that are worth mentioning:

• LinkedIn’s “Sign In With LinkedIn” service was vulnerable. A partial list of vulnerable third-party websites that also rely on LinkedIn include Nasdaq.com, Slashdot.org, Crowdfunder.com and Spiceworks.com. LinkedIn’s security team followed our suggestion and fixed the issue by not allowing social login requests that include the email field to continue, in case the email is not verified.
• Amazon’s “Log In With Amazon” service was vulnerable to our attack and allowed a user to change the account email address to another unverified email address after the account was already created. This practice may allow other similar types of attacks. Amazon’s security team added a section to its developer documentation that shows its relying parties how to correctly link local accounts in their systems. In addition, it will add a “verified email” scope for “Log In With Amazon.”
• VASCO’s MYDIGIPASS.com Secure Login service was also vulnerable to our attack, despite the fact that it employs two-factor authentication — a mechanism that authenticates a user’s identity by verifying that the user possesses a (pre-registered) physical device — in addition to entering a password. This mechanism did not block our attack because, as the attacker, we used our own valid physical device (smartphone) while registering a new MYDIGIPASS account with the fake email. Later, when signing in to a website using MYDIGIPASS, we again used our device for authenticating with MYDIGIPASS as any other valid member. VASCO’s security team fixed the issue by only supplying the email field to its relying websites when the user’s email address is verified, and if the user actively chose to share it.

Demo

Below is a video of the attack (taken before LinkedIn patched its vulnerability), on a Slashdot.org website account, using LinkedIn as the vulnerable identity provider. The video shows how easy it is for an attacker to perform the attack:

https://www.youtube.com/watch?v=kC0s3S00Dmk

We start by creating a Slashdot account that will be used as our victim. We do it by signing in to Slashdot using the victim’s Gmail account. Then, as the attacker, using another browser that doesn’t share cookies with the former browser, we create a LinkedIn account with the victim’s email address and leave it in an email unverified state (Step 1).

Next, we go to Slashdot and use the “Sign In With LinkedIn” login option, authenticating with our newly created LinkedIn account (Steps 2 and 3). As a result, Slashdot is passed the victim’s email address and logs the attacker in to the victim’s account (Step 4).

Mitigation

We strongly recommend that developers of both websites that use social login and future identity providers follow the Mitigation section in our white paper. While fixing the identity provider vulnerability would be enough for this attack to be blocked (attack Stage 4 won’t be reached), it is important for websites that are vulnerable to fix the website design problem because it may expose their users to similar attacks.

Acknowledgment

We would like to thank the security teams of LinkedIn, Amazon, MYDIGIPASS and others for efficiently handling this security issue.

Credit

Or Peles (@peles_o), IBM Security Systems

Roee Hay (@roeehay), IBM Security Systems