IBM X-Force researchers have recently found a new Attack related to Social Login mechanism. Named as"SpoofedMe", Social Login Attack enables intrusion to Many Websites' Local Accounts. 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. When LinkedIn was informed about the vulnerability, they responded quickly and patched it after the attack was disclosed. Once logged in, the attacker has complete command over victim's account. For example, the attacker could access the victim's private information and impersonate him or her by posting spam messages.

The attack is said to require 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.)

, 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.

To perform the attack, a cyber criminal 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.

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:

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

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. Slashdot directs the user's browser to LinkedIn for the user to authenticate. 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. 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). Slashdot receives the user's details from LinkedIn and logs the user in to her local account.

Attack Stages

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. 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. 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: 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. 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.

IBM Researchers took real-world cases and found vulnerable website. Amazon, LinkedIn and MYDIGIPASS.com were found to be vulnerable to the IBM Researchers attack. MYDIGIPASS.com despite having a 2-step authentication, allows attacker to intrude easily.

Mitigation

IBM Researchers recommended that developers of both the websites that use social login and future identity providers follow the following Mitigation measures:

Identity Provider Mitigation

1. The recommended, and restrictive, mitigation would state that identity providers would not supply an unverified email address value as part of social login process. We encountered this method while checking Facebook Connect and Google+ Sign-In services behavior. 2. The less restrictive mitigation would be supplying an email_verified boolean field (similar to OpenID Connect optional field discussed above) along with the email address field, that indicates whether the email address has been verified. In this approach, the identity provider risks having the third-party website developers ignore this field, and still allowing the attack to happen.

Third-Party Website Mitigation

The only claims that should uniquely identify the user are the subject (the user's user-id in the identity provider) and issuer (the identity provider itself), used together. These are the only claims that a third-party website can rely upon as a stable identifier for the end user, since the subject claim must be locally unique and never reassigned within the identity provider for a particular end user. This should be a best practice for the social login protocols (as long as the user-id is really locally unique and never reassigned within the identity provider).

Amazon, LinkedIN, MYDIGIPASS security teams helped IBM X-Force researchers in completing this research and IBM acknowledged their efforts well.