Analyzing Android Browser Apps for file:// Vulnerabilities
AAnalyzing Android Browser Apps for file://
Vulnerabilities
Daoyuan Wu and Rocky K. C. Chang
Department of Computing, The Hong Kong Polytechnic University {csdwu,csrchang}@comp.polyu.edu.hk
Abstract.
Securing browsers in mobile devices is very challenging, be-cause these browser apps usually provide browsing services to other appsin the same device. A malicious app installed in a device can potentiallyobtain sensitive information through a browser app. In this paper, weidentify four types of attacks in Android, collectively known as File-Cross, that exploits the vulnerable file:// to obtain users’ private files,such as cookies, bookmarks, and browsing histories. We design an au-tomated system to dynamically test 115 browser apps collected fromGoogle Play and find that 64 of them are vulnerable to the attacks.Among them are the popular Firefox, Baidu and Maxthon browsers, andthe more application-specific ones, including UC Browser HD for tabletusers, Wikipedia Browser, and Kids Safe Browser. A detailed analysis ofthese browsers further shows that 26 browsers (23%) expose their brows-ing interfaces unintentionally. In response to our reports, the developersconcerned promptly patched their browsers by forbidding file:// accessto private file zones, disabling JavaScript execution in file://
URLs, oreven blocking external file://
URLs. We employ the same system tovalidate the ten patches received from the developers and find one stillfailing to block the vulnerability.
Using file:// to browse local files is very common in desktop browsers. How-ever, this file protocol mechanism, when applied to mobile platforms, could causeunexpected security risks. In modern smartphone systems, notably Android andiOS, each app’s sensitive files are stored in their own system-provided privatefile zones, which cannot be accessed by other apps or users. Supporting file:// without additional access control in mobile browsers, however, will break such se-curity boundaries. This file:// vulnerability is further aggravated in Android,because Android browsers usually accept external browsing requests which, inthe absence of any user interaction, can be issued by another (malicious) app.Unlike Android, these requests in iOS must be invoked by users’ clicking.Supporting external file:// browsing requests (or termed as external file://
URLs) is only a necessary condition for realizing actual attacks. In this paper, weshow that combining with the capability of accessing private file zones through file:// , JavaScript support, and other browsers’ flaws (such as auto-file down-load), a malicious app in Android can launch four different types of attacks to a r X i v : . [ c s . CR ] S e p D. Wu and R.K.C. Chang steal a victim browser’s private files (e.g., users’ cookies, bookmarks, and brows-ing histories) or a victim website’s private files (e.g., cookie or content). We referto this class of attacks as
FileCross , in which all attack vectors are deliveredthrough the file:// protocol between a browser app and an attack app. Theattack app can automatically download a private file to the public SD card forexporting, steal a private file by compromising same-origin policy (SOP [1]) onthe “host” level, steal the content of another website by compromising SOP onthe protocol level ( file:// and http(s):// ), and steal a private file by exploit-ing a SOP flaw in handling symbolic links.Several isolated incidences on stealing browsers’ private files were reportedfor Chrome and Firefox [2,3,4]. However, as we will show in this paper, these at-tacks are just instances of the FileCross attacks. To characterize the prevalenceand impact of the FileCross attacks, we develop a system based on dynamicanalysis to automatically test over 100 browser apps in Android. The main ap-proach is to mimic actual attacks and use them to test the browsers on realsmartphones. This system determines whether a browser app is vulnerable tothe four FileCross attacks. It also analyzes whether the app, before and afterpatching, supports file:// , allows access to private file zones through file:// ,and supports JavaScript.The main findings obtained from our analysis of 115 browser apps can besummarized below.1. More than half of the browsers tested are vulnerable to the FileCross at-tacks. In particular, 50% of the most popular browsers (e.g., Firefox, Baidu,and Maxthon) are also vulnerable. Similarly, many major browsers in dif-ferent categories could leak out private information through the FileCrossattacks. Among the four different attacks, the three attacks that are basedon compromising SOP affect 55% of the browsers on Android 4.0, 4.3 or 4.4.2. The file:// vulnerabilities are exploitable in all Android versions (includingthe latest 4.4), and even occur in different web engines. Specifically, oursystem identifies 46 browsers being vulnerable in 4.4 (across all four FileCrossattacks). This result contradicts the general belief that Chrome-based newsystem engine will no longer contain these flaws by default. We are alsocontacting Google Android security team to fix one common flaw at theengine level. Moreover, we detect three vulnerable browsers (Firefox, UCBrowser HD and Sogou) out of 15 browsers that employ custom engines.3. A further analysis reveals that 23% of the browsers expose their browsinginterfaces unintentionally. Had the developers realized the browser inter-faces’ exposure, one third of them would not have been vulnerable to theFileCross attacks. Moreover, 65% of the browsers accept external file:// browsing requests, and 62% even allow file:// access to the private filezones. The latter is necessary for three FileCross attacks. Moreover, 63%support JavaScript execution in file://
URLs which makes three FileCrossattacks possible.4. In response to our vulnerability reports, 19 developers followed up with ourfindings. We have so far received nine patches from them (and will receive nalyzing Android Browser Apps for file://
Vulnerabilities 3 more). An analysis of the patches shows that the patching methods includedisabling the access to unrenderable private files, blocking external file://
URLs, or disabling JavaScript execution in file://
URLs. Most of themcould effectively thwart the attacks. However, our system developed for test-ing browsers finds that one patch failed to block the vulnerability, becausethe patch missed a second attack entry. file://
Vulnerabilities
We have discovered from our evaluation, which will be further elaborated inSection 2.2, that 113 out of 115 browsers in Android expose their browsinginterfaces, and 75 out of the 113 browsers support external browsing requestsfrom other apps through file:// . As illustrated in Fig. 1, an attack app canissue a “malicious” browsing request to a victim browser through the file:// channel. The attack can steal sensitive files directly or indirectly from the victimbrowser’s private file zone by having the URL in the browsing request point toa target sensitive file or a malicious HTML file, respectively.The direct method exploits the fact that some browsers allow file:// re-quests to access their private file zones. The indirect method, on the other hand,exploits the same-origin policy (SOP [1]) flaws in handling file:// requests,and it also requires the JavaScript support for executing the malicious HTMLfile. In our evaluation, 71 browser apps (out of the 75 that support file:// ) al-low the requests received from file:// to access their private file zones, and 72permit JavaScript execution in file://
URLs. Moreover, the indirect methodcan be used to steal sensitive files from websites.Fig. 1 shows examples of four FileCross attack patterns. The first one uses thedirect method, whereas the last three use the indirect method by compromisingthe SOP. The first and fourth attacks are in fact first reported by an individualhacker. We discovered the other two from the Android developer document. Wethus do not claim the discovery of these attacks as our main contribution. Butwe are the first to identify them as a unified attack model (i.e., FileCross) andconduct automated testing to analyze their prevalence in Android browsers. Inaddition, our system to be presented in Section 3 could be extended to detectnew attack patterns.Attack 1 (A1): The file://
URL points to a sensitive file (
Cookies in the figure) in thevictim browser’s private file zone. Some browsers automatically downloadthe requested file to the
Download directory on a SD card. The attack appcan use keyword search to find and read the target file from the SD card (see
Cmd 1 ). The auto-download feature has been identified as a flaw responsiblefor a successful FileCross attack against Chrome for Android [2].Attack 2 (A2): The file://
URL points to a malicious HTML file attack2.html . The at-tacker prepares the HTML file for the browser to retrieve a sensitive file(
Cookies in the figure) from its private file zone. Once the attack HTML file
D. Wu and R.K.C. Chang
Auto-downloaded to the SD card.
Victim Browser
Sensitive files
Private File Zone Exposed Browsing Interface file:///data/data/pkg/dir/Cookies file:///path/attack2.html file:///path/attack4.html file:///path/attack3.html
Attack App attack4.html
attack2
B The Description on The Other Categories of Vulnerable Browsers
In the third category (“Privacy”) of Table 2, three representative vulnerablebrowsers built for users’ privacy are selected. For example, Downloader & PrivateBrowser ( com.app.downloadmanager ) is a quite popular browser that providespassword protection for users’ private files. However, other app can access andsteal these sensitive files by exploiting this app, contradicting their users’ origi-nal intention of using this browser to protect their privacy. Similarly, InBrowser( nu.tommie.inbrowser ) is a browser supports incognito browsing by default. Asanother important example, the Kids Safe Browser ( com.kiddoware.kidsafebrowser )that provides children a safe Internet surfing environment by content filteringjeopardizes children’s privacy by the FileCross attacks.Some users prefer the browsers that are optimized to provide fast browsingexperience. We summarize three such vulnerable browsers in the category of“Fast browsing”. 4G Speed Up Browser ( com.ww4GSpeedUpInternetBrowser )and 3G Speed Up Browser ( com.wSuperFast3GBrowser ) are vulnerable to allattacks A2, A3, and A4.In the last category of “Specialized,” Photon Flash Player & Browser ( com.appsverse.photon )and Galaxy Flash Browser ( galaxy.browser.gb.free ) are quite popular dueto their dedicated support of Flash player in Android browsers. However, bothof them are vulnerable to three kinds of FileCross attacks in all Android ver-sions (except the latter cannot run stably in 4.4). The second case is a dedicatedbrowser for browsing Wikipedia, called Wikidroid ( com.isaacwaller.wikipedia ),allowing users to save their browsing bookmarks. Attackers can launch the File-Cross attacks to steal these bookmarks and use them to infer users’ interests and profiles. The last case is called Mercury Browser ( com.ilegendsoft.mercury )which is selected for its popularity in its iOS version. We suspect that someAndroid users who have migrated from iOS system will possibly install thisbrowser.
C Vulnerability ReportingOur reporting process
As mentioned in Section 5.1, we have spent consid-erable efforts on reporting our identified vulnerabilities to the developers. Ourreporting process was started on February 7 and is still ongoing at the time ofwriting. So far we have reported 39 vulnerable browsers, including all the rep-resentative ones in Table 2. We continue to report the remaining cases and willrelease a project website to help developers better understand the vulnerabilities.We report each case mainly in three steps. First, we send a notice email tothe email address recorded in Google Play, mentioning that we have identifiedvulnerabilities in their browsers without details. After receiving their replies andconfirming their identities, we explain the FileCross attacks that their browsersare vulnerable to. Finally, if they send us a patch, we analyze it using our systemand report to them again whether their patch can correctly block the vulner-ability. For the unresponsive developers, we contact them again until receivingtheir responses.
Responses from developers
We have currently received 19 replies from thedevelopers. Among them, 15 gave us further responses after being notified ofthe vulnerability details, and all of them confirmed our vulnerability reports. Inparticular, we have received two bug bounty gifts from Baidu company. Someexcerpts of developers’ responses can be found in Appendix D. Regarding theaforementioned Firefox issue for attack A1, our discovery of this serious vulnera-bility was also made independently by another security expert. We were told byMozilla that “ this flaw has been fixed in the latest version of Firefox for Android,version 28.0.1 ” just the day before our reporting [29].
D Excerpts of Developers’ Responses
Besides acknowledging our reports, developers of Baidu Browser are also inter-ested in our automated testing system, and their feedbacks are as follows.“
Thank you for your reporting. We confirm that those three vulnerabil-ities affect Baidu Browser inter version, but do not affect its Chineseversion. Please provide us your contact address so we can send a gift foryour nice work. ”“ I am security architect in Baidu Mobile-App-Team. your work is reallyvaluable for us. further, please also scan our Baidu relative apps, . . . ”“ Just as you say, the tablet version also suffers this vulnerability. Wewill fix it soon, and give you the patched version. . . . We will send a giftto you for your excellent work. ” – Responses from Baidu Browser nalyzing Android Browser Apps for file://
Vulnerabilities 21
Some developers keep us updated about their process working on the patches,such as the vendors of InBrowser and Kids Safe Browser.“
We’re very grateful for the detailed error-report and our engineers areworking on the issue as we speak. We’ll publish those changes silently inour Beta stream to start with and then publish publicly within a coupleof weeks. ” – Responses from InBrowserMoreover, we notice some individual developers are more responsible for theirsecurity issues than some big companies. For example, the student developer ofLightning Browser and the individual developer of Easy Browser always notifyus of their patching updates.“