igor - Fotolia

News Stay informed about the latest enterprise technology news and product updates.

Poor OAuth implementation leaves millions at risk of stolen data

Researchers find widespread risk for users of apps with insecure OAuth implementation, which could lead to attackers being able to access the data held within a vulnerable app.

Researchers at Black Hat EU 2016 demonstrated a potential attack which relies on insecure OAuth implementation in mobile apps that may leave more than one billion mobile app accounts at risk of stolen data.

The OAuth 2.0 protocol is commonly used for single sign-on (SSO) to allow users to verify sign-in to third-party websites and apps by using an ID provider like Google, Twitter or Facebook. Ronghai Yang, Wing Cheong Lau and Tianyu Liu from The Chinese University of Hong Kong studied the 600 most popular Android apps in the U.S. and China -- which cumulatively have at least 2.4 billion downloads -- and found over 41% have vulnerable OAuth implementations, implying at least 1 billion vulnerable accounts.

While they studied Android apps specifically, the researchers noted "the exploit itself is platform-agnostic: Any iOS or Android user of the vulnerable mobile app is affected as long as he [or] she has used the OAuth2.0-based SSO service with the app before."

OAuth attacks have been seen before, but the researchers said their findings were more dangerous because these bad OAuth implementations "can be exploited remotely and solely by the attacker [signing] into a victim's mobile app account without any involvement [or] awareness of the victim."

The 600 apps studied used OAuth 2.0 from one of the top three ID providers, Facebook, Google and Sina; 41.21% failed to validate the information from the ID provider, marking them vulnerable to this attack. In some cases, the apps did not verify the signature from the ID provider; in others, the apps did not confirm that the user ID returned was bound to the OAuth token. This means an attacker can log in to an app using their own credentials then substitute their own user ID with that of the victim during the OAuth exchange.

"Since the third-party back-end server directly uses the user's identity proof returned from its client-side app to identify the app user without further validation, the attacker can therefore successfully sign into the app as the victim and in most cases have full access to the victim's sensitive information hosted by the third-party app's back-end server," the researchers wrote.

Experts said it is not generally difficult to implement OAuth properly, but Liviu Arsene, senior e-threat researcher at Romania-based antimalware firm Bitdefender, said common mistakes can multiply if developers aren't careful.

"Since this is not a flaw in the OAuth 2.0 mechanism itself, but an implementation fault, it stands to reason that some app developers have skipped the part where the app, for instance, has to verify the signature attached to the authentication information sent by the ID provider," Arsene told SearchSecurity. "Because it has become common practice to copy-paste code -- even bad code -- some mistakes inherently get disseminated across a large number of applications."

Derek Abdine, director at Rapid7, said the man-in-the-middle portion of the exploit to swap user IDs could be packaged as a kit, but obtaining the victim's private account identifier could be more difficult.

"The researchers noted that, in some cases, providers such as Facebook moved to private account identifiers (instead of public identifiers such as email addresses) in 2014. This makes discovery of the identifiers difficult, but not impossible (either through lists, leaked information, or brute forcing)," Abdine told SearchSecurity via email. "However, with a proper list or algorithm to brute force account identifiers, an attacker could, in theory, automate the exploitation process against the mobile application provider and perform actions or pull information on behalf of each affected user account."

The researchers suggested a number of potential remedies for bad OAuth implementations, including: clearer usage guidelines, anchoring trust directly to the ID provider server, issuing private user identifiers on a per-mobile-app basis, and better security testing. However, experts said this all could take time to filter out to the many potentially vulnerable apps.

"There are millions of applications in the Google and Apple app stores, so there is quite a large surface area that is likely affected," Abdine said. "It is also likely that there will be a large number of affected applications for some time, even as Google and Facebook move to help address them."

Arsene said the best approach to start would be more accurate implementation guidelines for app developers.

"Since we're talking about all affected applications being updated as soon as possible, their respective developers would have to start coding the fix as soon as possible," Arsene said. "As for the difficulty of the fix, vulnerable applications could at least be updated to perform additional checks, such as validating the signature attached to the authentication information sent by the ID and checking the OAuth information to see if it's linked to the user ID."

Next Steps

Learn more about whether OAuth 2.0 can strengthen authentication.

Find out the pros and cons of using OAuth 2.0.

Get info on why mobile apps can be a big threat to business security.

Dig Deeper on Application attacks (buffer overflows, cross-site scripting)