In this article, John Bielich and Khash Kiani introduce OAuth, and demonstrate one type of approach in which a malicious native client application can compromise sensitive end-user data.
Earlier this year, Khash posted a paper entitled: "Four Attacks on OAuth — How to Secure Your OAuth Implementation" that introduced a common protocol flow, with specific examples and a few insecure implementations. For more information about the protocol, various use cases and key concepts, please refer to the mentioned post and any other freely available OAuth resources on the web.
This article assumes that the readers are familiar with the detailed principles behind OAuth, and that they know how to make GET and POST requests over HTTPS. However, we will still provide a high-level introduction to the protocol.
OAuth
OAuth is a user-centric authorization protocol that is gaining popularity within the social networking space, and amongst other resource providers such as Google and SalesForce. Furthermore, sites such as Facebook are increasingly positioning themselves as Single Sign-On (SSO) providers for other sites using OAuth as the platform. This makes credentials from such providers extremely high-value targets for attackers.
OAuth is a permission-based authorization scheme.
It allows a user to grant access to a third-party application to access his or her protected content hosted by a different site. This is done by having the user redirected to the OAuth provider and authenticating on that server, thereby bypassing the need for the client application to know the credentials. The main goal this protocol attempts to achieve is defeating the password anti-pattern in which users share their credentials with various third-party applications for their service offerings.
OAuth and Embedded Mobile Applications
In mobile operating systems such as iOS, there are controls that can be embedded into the application that enable the login page to be served up within the application itself (in this example, UIWebView). This is often done by client applications to provide a good user experience. However, this approach violates the trust context by not using a web browser (Safari) external to the app. Several of the browser controls and the OAuth redirect schemes are not applicable to facilitating user authorization.
The ideal application flow typically consists of the following steps:
- The client application requests a specific scope of access.
- The client application switches the user to an external web browser, and displays the OAuth authentication page, asking for consent and user permission to grant access to the client application.
- Upon user authentication and approval, the client application receives an Access Token that can be leveraged to access protected resources hosted by Service Provider.
- The callback feature of OAuth is typically leveraged to call the local client app in this scenario.
Building a Malicious Google OAuth Client
As mentioned, the main purpose behind OAuth is to defeat the password anti-pattern, preventing identity attacks through a delegation model where users do not share their Server credentials with third-party Client applications. However, by using embedded web components with OAuth in native mobile applications, we can provide an attack landscape for malicious rich clients to easily compromise user credentials. This compromise would be undetected by either the user or the service provider, and is especially sneaky, as it provides the user with a false sense of safety in the authentication workflow.
In this section, we will demonstrate a malicious iOS application using Google's own OAuth sample iOS application. Our simple modifications will steal user's credentials as they login through Google's authorization endpoint.
The Attack
This sample exploit consists of the following overall approach:
- Downloading the native OAuthSampleTouch mobile Google application.
- Using XCode and the iOS SDK, modify the UIWebViewDelegate's webView:shouldStartLoadWithRequest:navigationType: callback method to intercept the login page before sending the POST request.
- Capture the credentials out of the HTTP body.
- Use the captured credentials. In this case, we simply output the values. We could easily store or send the credentials in the background to another destination.
The Attack Details
First step is to download, compile and run OAuthSampleTouch that comes with the gtm-oauth code. This is the sample app that uses the Google framework which we are compromising.
