Today we begin a three-post series about mobile security. We start with a discussion of vulnerabilities in iOS web browsers. Later this week we'll cover apps executing on jailbroken devices and the detection of jailbroken devices. While the release and adoption of iOS 8 may plug some of the holes discussed in this post, many users will continue to use iOS 7 for some time and may remain vulnerable.
In Q1 2014, the market share of web traffic from mobile browsers exceeded 30% [1], and it is constantly growing. According to data provided by StatCounter, web traffic from iOS devices surpassed that of Mac OS X and Windows 8 [2]. Many vendors are trying to get a piece of the pie by introducing their own browsers on Apple's platform.
In reality, there is only one browser for the iOS platform, Mobile Safari, which is built from the base. The iOS App Store Review Guidelines requires that any other application used for web browsing use the iOS WebKit Framework and Javascript.
UIWebView is the main component of all browsers that allow running web content. The WebKit engine is the same as in Mobile Safari. The main difference is in the UI wrapped around WebKit.
Below I explain a number of vulnerabilities introduced by developers as they add functionality to their browsers.
The UIWebView API is quite simple. It allows you to load html content and offers some basic navigation functionality (goBack, goForward, stopLoading, reload). To manipulate the loaded html content, UIWebView exposes the stringByEvaluatingJavaScriptFromString function. This function allows executing javascript from a string with the same privileges the top frame (there is no possible way to manipulate, for example, iframe content).
Therefore, developers need to implement functionality such as tabs, password managers, address bars and download managers. Each addition in functionality brings with it the potential introduction of new bugs and security issues.
Cross-Site Scripting (XSS) enables attackers to inject client-side scripts into web pages viewed by other users, bypassing the same origin policy (SOP) and executing the injected scripts in the victim browser. UXSS differs in that the attacker exploits a vulnerability in a browser instead of a website. The root cause of this is related to SOP. In most cases, browsers support the use of multiple tabs. On iOS, WebKit does not allow multiple tabs, which means browser developers need to implement all of the required features and functionality themselves. Even though WebKit holds the SOP in it, it is not guaranteed between tabs.
CVE-2013-6893, CVE-2013-7197 and CVE-2012-2899 are a few examples of UXSS bugs in various browsers (Mercury, Yandex, Google).
Improper Content-Disposition handling can also lead to UXSS vulnerabilities.
On iOS, the address bar is not created inside the WebKit component. It must be separately developed by the browser developer. Some browsers have not implemented the address bar correctly, which gives malicious users the ability to change the content of the website without updating the address bar. This presents an opportunity for phishing attacks. ABS bugs were found in Kaspersky Safe Browser (fixed in 1.03 version) and F-Secure Safe browser (fixed in 2.50.201102 version). In some cases, the browser displayed information, such as the SSL certificate being valid, even if the webpage that was loading was using a self-signed certificate.
Other vulnerabilities in iOS browsers include:
As previously mentioned, iOS web browser developers also implement password manager functionality. One vector that can lead to the stealing of passwords from a password manager is using a Man-in-the-Middle (MITM) vulnerability to insert a hidden frame that automatically receives the username/password. The address bar will get updated very briefly, but in the vast majority of cases, this is overlooked by the user.
Finally, the way SSL is handled is important. By default, invalid certificates for iOS UIWebView https requests are rejected without user interaction. With certain bugs, this behavior can be changed (so the user would accept a self-signed certificate). Opera Coast 3.0 was one of the browsers that were vulnerable to a simple MITM attack[4].
I presented more details about the issues described here at the Hack in The Box Amsterdam 2014 conference. The slides can be downloaded from http://haxpo.nl/hitb2014ams-pilorz-zmyslowski/
Special thanks to:
Lukasz Pilorz, Pawel Wyleciał, Aleksander Droś
References
[1]http://www.walkersandsdigital.com/Walker-Sands-Mobile-Traffic-Report-Q1-2014