How bad OAuth 2.0 implementation sabotages mobile app security
Posted by Ted Eull NowSecure Marketing
Researchers unveiled details of a startling claim during the Black Hat Europe 2016 conference this week: 41 percent of the most popular Android apps that implement OAuth 2.0 allow an attacker to remotely impersonate any user account, access personal information (potentially including banking information) from within the app, and make in-app purchases on the user’s dime. Slides from the researchers’ presentation and a whitepaper are now available. The researchers claim the problem results from poor implementation of OAuth 2.0 authorization, which suggests that iOS apps could also be affected. With this news, we hope enterprises and developers are looking for resources to help them secure their apps and avoid bad OAuth 2.0 implementations. Below I provide an overview of OAuth 2.0 and how it affects mobile app security and risk.
What is OAuth (OAuth 2.0)?
OAuth is a widely used method of authorizing users in web and mobile, defined by a standard specification.
The specification states:
The OAuth 2.0 authorization framework enables a third-party application [example: MyTravelApp] to obtain limited access to an HTTP service [MyTravelApp account info], either on behalf of a resource owner [user] by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application [MyTravelApp] to obtain access on its own behalf.
In practice, this framework is used to provide the common “Log in with Facebook”, “Sign in with Google” or similar options in mobile apps, sometimes referred to as “social sign in” or (somewhat inaccurately) “single sign-on”. In these cases, rather than authenticating users directly during the authorization process with an app-specific username and password, instead an app can pass your log-in request to a trusted identity provider (IdP) like Google. The IdP authenticates you and then gives a token to the app vouching that you are a certain user (often responding with your email address, and potentially some other identifying info).
Why is OAuth 2.0 implementation hard?
OAuth 2.0 is a multi-step process, with four main roles and several security factors required. The following image from the Internet Engineering Task Force’s (IETF’s) OAuth 2.0 Authorization Framework illustrates the various steps and roles in the overall protocol flow.
With social sign in, the IdP (e.g., Google) is the Authorization Server and issues the access tokens based on the user authenticating to that service. However, it remains the app developer’s responsibility (not Google’s) to use social sign in correctly and validate client authorization tokens before giving access to an account. Many developers are not succeeding.
In their guide to Google Sign-in for Android, Google speaks directly to one of the flaws called out by the researchers warning “Do not accept plain user IDs, such as those you can get with the GoogleSingInAccount.getId() method.” Facebook provides a Security Checklist for all mobile apps using Facebook Login. The OpenID Foundation has also published guidance about implementing OAuth securely in mobile apps.
In order to accomplish secure authentication and authorization using OAuth 2.0 within a mobile app, you must do the following:
- Secure the transport layer (TLS)
- Validate tokens
- Manage the session
Bad OAuth 2.0 implementation is a mobile app security risk
The Black Hat talk claims that exploiting this flaw in a mobile app allows an attacker to remotely access the account of a different user (or any number of users). If true, this means that any functionality within the app, such as making purchases with the users’ associated payment account, is available to the attacker. In addition, any data residing within the victim app is also available to the attacker. And any of these scenarios are possible without access to a user’s device or having to know the user’s password. An attacker only needs to know (or guess) a user’s ID. In many cases, user IDs might simply be e-mail addresses which can easily be guessed or are publicly available.
Apps that use the OAuth 2.0 framework incorrectly to authenticate using Google, Facebook, Twitter, or another trusted provider may be vulnerable to this attack. To be clear, this is not a flaw within any of these providers, it’s a problem with the implementation of social sign in within some apps. If the vulnerable app is MyTravel (an imaginary app), and the app uses OAuth 2.0 improperly, the attacker can gain access to a user’s MyTravel account, which might include airline itineraries, history, and other sensitive data. In other cases, vulnerable messaging apps might allow an attacker to pose as the user in communications with others.
Another recent example of problematic OAuth implementation within a mobile app was Pokémon GO asking for more permissions than necessary this summer. The scope of a token used in the app’s OAuth flow asked for privileges the app didn’t need. Niantic, the developer of the app, moved quickly to fix the issue by reducing the app’s access to only basic Google account information rather than full account access.
Enterprises are at risk
A growing number of apps use third-party authorization via OAuth 2.0. That includes apps that enterprises develop to connect with their customers, as well as apps used by staff in their day-to-day job duties. A compromise of users’ mobile app accounts erodes trust in a brand, decreases adoption rates and more. Attacks on work-related apps could expose sensitive proprietary data or feed more targeted social engineering attacks.
What should I do?
Like all software, mobile apps require a secure software development lifecycle (SDLC) where reviews and tests are performed throughout development to ensure a secure result. Authentication and authorization is a particularly important area for review and testing. Mobile app security testing solutions can discover important security flaws like vulnerable transport layer security (TLS) or insecure storage of credentials.
Within a mobile app, to achieve secure authentication and authorization using OAuth 2.0 you must properly secure the transport layer, validate tokens, and manage the session.
Secure the Transport Layer
TLS (implemented via HTTPS for web services) is fundamental to mobile security, and yet it’s still often implemented incorrectly. Two NowSecure Secure Mobile Development Best Practices provide more detail about how to Implement Secure Network Transmission Of Sensitive Data and Properly Configure Server-side SSL within mobile apps. Developers should also perform checks (preferably automated) to ensure all connections to back-end services properly implement HTTPS.
Validate Tokens
When a user has been authorized, they receive a token (sent securely with TLS) that enables future access to the resource, such as their account data. But in the apps described by the researchers, the mobile app services failed to validate the token, which enables an attacker to be authorized when they should not be. In some cases the apps failed to even look at the token at all, which is like allowing someone access by checking only the username and ignoring the password!
Manage the Session
Sessions are meant to expire. While mobile apps frequently maintain a logged-in state for convenience, in many cases this should be limited. If you have users create a password or authenticate with a third party like Facebook, you are getting some of their personal info and have a responsibility to protect it. Apps handling sensitive data should re-authorize users on a certain interval, or when sensitive operations/data are accessed, and should offer a secure “log out” function to users. For more information see our best practices: Use Proper Session Management and Institute Local Session Timeout.
Under OAuth 2.0, new access tokens can be created without replicating the full authentication flow, using refresh tokens. A refresh token is a credential (like a username+password) and needs to be stored securely on a mobile device.
In the end, it’s important to distinguish between OAuth and the implementation of OAuth. As a standard, OAuth has done great things for web and mobile app security. A majority of the time when OAuth is mentioned in relation to a security problem, the issue is a developer failing to follow best practices for implementing it.
