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 Chinese University of Hong Kong researchers presented at Black Hat EU last week a paper called “Signing into One Billion Mobile LApp Accounts Effortlessly with OAuth 2.0.” The paper describes an attack that takes advantage of poor OAuth 2.0 implementations and puts more than one billion apps in jeopardy.
The researchers examined 600 top U.S. and Chinese Android mobile apps that use OAuth 2.0 APIs from Facebook, Google and Sina—which operates Weibo in China—and support SSO for third-party apps. 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. None of the apps were named in the paper, but some have been downloaded hundreds of millions of times and can be exploited for anything from free phone calls to fraudulent purchases.
The researchers said the apps they tested had been downloaded more than 2.4 billion times in aggregate, meaning that more than one billion are vulnerable.
“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 (chat logs, photos, contact lists) which is hosted by the backend server(s) of the vulnerable mobile app,” wrote researchers Ronghai Yang, Wing Cheong Lau, and Tianyu Liu. “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.”
The researchers note that OAuth 2.0 does not define security requirements, nor how its backend should securely interact with third-party apps. This has spawned a number of customized API extensions to support SSO.
“Unfortunately, the implicit security assumptions and operational requirements of such home-brewed adaptations/ APIs are often not clearly documented or well-understood by the 3rd-party mobile app developers,” the researchers wrote. “Worse still, there is also a lack of security focused SSO-API-usage-guidelines for the 3rd-party app developers.”
The attack requires no interaction with a victim or their device. As described in the paper, it requires an attacker-owned SSL man-in-the-middle proxy to be set up for the attacker’s device. The proxy monitors inbound and outbound traffic from their device. With a vulnerable third-party app on their device, the attacker would then sign in, via OAuth 2.0, with their own credentials. The proxy would capture the outbound exchange and the attacker could then substitute their user ID with a victim’s (this would be obtained from public information).
“Since the third-party backend 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 backend server,” the researchers wrote, adding, “The root cause of this vulnerability is a common, but misplaced trust in the authenticating information received by the 3rd party app’s backend server from its own client-side mobile app, which in turn, relies on potentially tampered information obtained from the client-side mobile app of the IdP.”
Facebook mitigates this attack to a degree because it has supported certificate pinning since May 2014 and would therefore not accept tampered messages. But there’s a hitch there; the researchers learned that for backwards compatibility, Facebook identifies early adopters of a mobile app using the public user ID, therefore, if a user has signed into the app via OAuth before May, 2014, they’re still exposed to the attack.
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.
