Cyber Attack

One Billion Mobile Apps Exposes to Account Hijacking Because of OAuth 2.0 Hack

Sharing is caring!


Third-party applications that allow single sign-on via Facebook and Google and support the OAuth 2.0 protocol, are exposed to account hijacking. Three security researcher form The Chinese University of Hong Kong presented a paper at Blackhat last week.

They have described an attack that takes advantage of poor OAuth 2.0 implementations and puts more than one billion apps at risk. OAuth2.0 protocol has been widely used by mainstream Identity Providers like Fackebook, Google to support Single-Sign-On service. Since this protocol was originally designed to serve the authorization need for 3rd party websites, different pitfalls have been uncovered when adapting OAuth to support mobile app authentication.

The researchers have developed an exploit to examine the implementations of 600 top-ranked US and Chinese mobile apps which use the OAuth2.0-based authen-tication service provided by three top-tier IdPs, namely Facebook, Google or Sina. The researchers found that 41.2 percent of the apps they tested were vulnerable to their attack, including popular dating, travel, shopping, hotel booking, finance, chat, music and news apps.

OAuth2.0 was originally designed to support authorization, to adapt it for authentication, it involves multiple steps.To better support authentication using OAuth2.0,identity provider like Google and Facebook have developed the OpenID Connect (OIDC) protocol and its variants. Although no clear developer guides are provided by provider to de-mystify the possbile pitfalls for mobile OAuth implementations.

Due to various incorrect implementations by 3rd party app developers, an attacker can take advantage of this, Researcher provide step for exploitation, the attacker setups a ssl-enabled-MITM Proxy for her own mobile device to monitor and tamper the network traffic going into and leaving her device. Then attacker installs the vulnerable 3rd party app in her own mobile device. In next step the attacker substitutes her own user id (user id in the IdP or email address) with the victim’s one using the ssl-enabled-MITM proxy. The victim’s user-id is either a publicly available or gusseable. Since the third-party backend server directly uses the user’s identity proof re-turned 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 thethird-party app’s backend server.

Although Facebook has started to issue private per-app user-id for each third-party app since May 2014, for backward compatibility reasons, to-date, Facebook still uses the public user-id to identify early adoptersof a 3rd-party app.

If IdP client-side app, e.g. by Facebook, applies the certificate pinning, the message sent by the IdP server to its client-side app will not be accepted by the latter if it has been tampered by the attacker’s MITM proxy. Attacker can simply uninstall the IdP client-side app so that the IdP SDK (widely used by 3rd-party mobile apps for OAuth2.0) would automatically downgrade to carry out OAuth authentication via the built-in webview browser. Being a general built-in browser, the webview does not support the certificate pinning for specific IdP.

“After signing into the victim’s vulnerable mobile app account using our exploit, the attacker will have, in many cases, full access to the victim’s sensitive and private
information which is hosted by the backend server(s) of the vulnerable mobile app. A massive amount of extremely sensitive personal information is wide-open this includes detailed family/ private photos, personal finance records, as well as the viewing or shopping history of the victims. For some of these mobile applications, the online-currency/ service credits associated with the victim’s account are also at the disposal of the attacker”, Researcher said.

The paper recommends identity providers such as Facebook, Google and Sina improve their security recommendations for developers, and that trust should rely solely on the identity provider’s server, and not on anything signed by a client-side app. Further, the researchers recommend identity providers issue private identifiers rather than relying on global identifiers, and identity providers should also ramp up security testing of apps to include SSO via protocols such as OAuth 2.0 and OpenID Connect.

Join The Discussion