Three researchers from the Chinese University of Hong Kong discovered a flaw in how app developers and identity providers support Single-Sign-On (SSO) via the OAuth 2.0 protocol, a flaw that allows an attacker to assume the identity of another person.

Researchers said they tested their exploit only on Android devices and found that 41% of the top 600 most popular Android apps in the US and China were vulnerable to their hijacking technique.

Extrapolating their results, researchers believe that around over one billion Android users might be vulnerable to this attack. Furthermore, the hijacking technique is not Android specific, and an attacker can modify it to attack iOS users as well.

Problem lies with how app developers implemented OAuth 2.0 operations

At the heart of the issue is the fact that the OAuth 2.0 protocol wasn't designed with mobile devices in mind, being created in an era when third-party authentication needed to be supported via websites only.

After mobile app usage had grown, the people behind OAuth 2.0 adapted the protocol for mobile usage, but this differed from the Web-based use cases, with a few extra steps.

The problem was exacerbated by Identity Providers, such as Google, Facebook, Sina, Twitter, and others, who failed to provide proper implementation documentation for app-based SSO operations.

Because of this, many mobile app developers that wanted to support a "Sign in / Log in with XXX" feature have left holes in the authentication procedure, which is a very sinuous and complicated process, with multiple steps that involves four entities: (1) mobile app server, (2) mobile app, (3) Identity Provider mobile app, and (4) Identity Provider server.

The biggest issue is the failure to validate data the mobile app server received from the other steps in the process.

Attack works on both Android and iOS devices

Researchers figured out that they could install a Man-in-the-Middle SSL proxy on their own phones, install the mobile app of a vulnerable Identity Provider, and the app where they wanted to hijack the victim's account.

Example:

Attacker installs the Facebook and IMDb mobile apps.

The attacker tries to log in on the IMDb app with his Facebook identity.

The MitM proxy allows him to intercept the authentification response from the Facebook app (which came from the Facebook server), and alter its content with the email and name of the victim's account he wants to hijack.

Attacker logs in on IMDb with a victim's Facebook identity.

Basically, an attacker only needed to know a victim's name and the email he used to register on Facebook.

While rating movies in the name of another person can only be considered a prank, imagine if the attacker would authenticate with your identity on a mobile app where you saved financial information, such as credit card details.

Attacker hijacking trip planners, hotel booking apps, ride sharing apps, financial management applications, or dating apps, can lead to serious consequences.

The research team said they reported the issue to companies that provide identity services via OAuth 2.0 servers, who reacted positively, promising to inform all third-party app developers that have implemented SSO incorrectly, and also promised to issue clearer guidelines for OAuth 2.0 implementations.

Researchers also stressed that their exploit does not attack OAuth directly, but the incorrect manner in which app developers have coded their apps, ignoring security safeguards that the protocol presented, which some of them ignored, most likely out of a lack of proper documentation.

A technical write-up detailing the OAuth 2.0 exploit in finer detail can be found in the research team's Black Hat Europe presentation.