AppSec Blog

AppSec Blog

Password Tracking in Malicious iOS Apps

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:

1. The client application requests a specific scope of access.

2. 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.

3. Upon user authentication and approval, the client application receives an Access Token that can be leveraged to access protected resources hosted by Service Provider.

4. 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:

1. Downloading the native OAuthSampleTouch mobile Google application.

2. 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.

3. Capture the credentials out of the HTTP body.

4. 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.

figure 1 - install OAuthSampleTouch

Secondly, find the GTMOAuthViewControllerTouch. This class handles the interaction for the sample app, including the UIWebView for authentication.

figure 2 - edit GTMOAuthViewController

Thirdly, insert the malicious code in the webView:shouldStartLoadWithRequest:navigation that will process the request being sent before it is sent from your device. This code effectively does the following:

  • Grabs the HTTP BODY and assigns it to a string
  • Creates an array of string components separated by the "&" token to get a name/value pair per array element
  • Iterates through the values, grabbing the "Email" and "Passwd" name/value pairs, which are Google's username / password fields

figure 3- insert evil code in the webView:shouldStartLoadWithRequest:navigationType

Fourthly, we authenticate and grant access to the device.

figure 4 - OAuth process with an embedded view

And lastly, we finish authenticating, granting access, and view the compromised credentials.

figure 5 - outputting credentials

Solutions


The best solution for Client application developers is to follow the recommended flow and use an external browser (in this case, Safari). Although it might diminish the user experience, this approach will allow the user to be assured that the authentication process is outside the context of the application altogether.

From a user's perspective, do not trust native OAuth applications that do not follow the recommended flow and are not capturing your credentials in a trusted and neutral 3rd party application, such as Safari.

And lastly, the protocol needs to mature its support for native mobile applications to implement a stricter client authentication process with consumer credentials, a better browser API support, and also properly notify the OAuth providers upon unauthorized access.

About the Authors


John Bielich is a security consultant with 14 years of experience building and securing web-based software applications, as well as over one year in iOS development and security. He can be reached at: john@codeshuffle.com

Khash Kiani is a principal security consultant and researcher with over 13 years of experience in building and securing software applications for large defense, insurance, retail, technology, and health care organizations. He specializes in application security integration, penetration testing, and social-engineering assessments. Khash currently holds the GIAC GWAPT, GCIH, and GSNA certifications, has published papers and articles on various application security concerns, and spoken at Blackhat US. He can be reached at: khash@thinksec.com

If you liked this post check out SANS' new class on Secure iOS App Development.

 

 

 

 

 

 

 

2 Comments

Posted August 23, 2011 at 10:53 PM | Permalink | Reply

zach

interesting article. this is more about user's security experience than anything.... so what you are saying is that with this attack vector, any native app irrespective of whether you use oauth or not, passwords can be stolen using the webview? sort of scary I think.

Posted August 25, 2011 at 6:27 PM | Permalink | Reply

Bill

I guess the best and most secure way as you pointed out is to open up a browser window and let the user do all the oAuth stuff in there, then redirect back to the app. You can do this on iOS by specifying your own protocol (myapp://) and using this in the redirect url.

But, app-browser-app is a big round trip, you have to maintain state in your app but mostly quite confusing for the end user. There is no perfect solution.

Post a Comment






Captcha

* Indicates a required field.