Cross-Platform Analysis of Indirect File Leaks in Android and iOS Applications
CCross-Platform Analysis of Indirect File Leaksin Android and iOS Applications
Daoyuan Wu and Rocky K. C. Chang
Department of Computing, The Hong Kong Polytechnic University { csdwu, csrchang } @comp.polyu.edu.hk This paper was published in IEEE Mobile Security Technologies 2015 [47] with the original title of “Indirect File Leaks in Mobile Applications”.
Abstract —Today, much of our sensitive information is storedinside mobile applications (apps), such as the browsing historiesand chatting logs. To safeguard these privacy files, modern mobilesystems, notably Android and iOS, use sandboxes to isolate apps’file zones from one another. However, we show in this paperthat these private files can still be leaked by indirectly exploitingcomponents that are trusted by the victim apps. In particular,we devise new indirect file leak (IFL) attacks that exploit browserinterfaces, command interpreters, and embedded app servers toleak data from very popular apps, such as Evernote and QQ.Unlike the previous attacks, we demonstrate that these IFLs canaffect both Android and iOS. Moreover, our IFL methods allowan adversary to launch the attacks remotely, without implantingmalicious apps in victim’s smartphones. We finally compare theimpacts of four different types of IFL attacks on Android andiOS, and propose several mitigation methods.
I. I
NTRODUCTION
Mobile applications (apps) are gaining significant popularityin today’s mobile cloud computing era [3], [4]. Much sensitiveuser information is now stored inside mobile apps (on mobiledevices), such as Facebook authentication tokens, Chromebrowsing histories, and Whatsapp chatting logs. To safeguardthese privacy files, modern mobile systems, notably Androidand iOS, use sandboxes to isolate apps’ file zones from oneanother.However, it is still possible for an adversary to steal privateapp files in an indirect manner by exploiting components thatare trusted by the victim apps. We refer to this class of attacksas indirect file leaks (IFLs). Fig. 1 illustrates a high-level IFLmodel. Initially, an adversary cannot directly access a privatefile, formulated as a (cid:58) s . If the adversary can send craftedinputs to a deputy inside the victim app ( a → d ) and theseinputs can trigger the deputy to send the private file to theadversary ( d → s ⇒ a ), then the adversary can indirectlysteal the private file. The whole process, a → d → s ⇒ a ,achieves the goal of s ⇒ a , causing an IFL.In this paper, we devise new IFL attacks that exploit browserinterfaces, command interpreters, and embedded app serversto leak files from very popular apps, such as Evernote andTencent QQ. Unlike prior works [52], [46] that only show localIFL attacks on Android, we demonstrate that three out of our We borrow this term from the classic confused deputy problem [30] torepresent a trusted component in victim apps.
Victim AppDeputy (d)
Othercomponents
Private files(s)
Trusted partiesAdversary (a)
Fig. 1. A high-level IFL model. four IFL attacks affect both Android and iOS. We summarizethese attacks below. • sopIFL attacks bypass the same-origin policy (SOP),which is enforced to protect resources originating fromdifferent origins (i.e., the combination of scheme, do-main, and port), to steal private files via browsing inter-face deputies. Although our prior work [46] has demon-strated such attacks on Android by exploiting numerousAndroid browsers’ SOP flaws on the file:// scheme,we are extending it in this paper to a number of vulnerableiOS apps, such as the very popular Evernote, TencentQQ, and Mail.Ru. We also confirm that the latest iOS 8fails to enforce the appropriate SOP on file:// . Inour analysis, the root case of this attack is that the legacyweb SOP is found to be inadequate for the local schemes,such as file:// . Eradicating the problem may call foran enhanced SOP. • aimIFL attacks also leverage browsing interfaces asdeputies, but they do not need to violate SOP. It can doso by injecting and executing unauthorized JavaScripts directly on target files, instead of requiring a maliciousfile to bypass SOP to access target files as in the sopIFL attacks. Popular Android browsers, such as Baidu, Yan-dex, and 360 Browser, can be easily compromised in thisway, allowing their private files (e.g., cookie and brows-ing history) to be stolen. The high-profile 360 MobileSafe and Baidu Search are also exploitable. Besides theseAndroid apps, we further uncover a vulnerable iOS app,myVault. • cmdIFL attacks exploit command interpreters as a r X i v : . [ c s . CR ] F e b eputies inside victim apps to execute unauthorizedcommands for file leaks. We demonstrate that the topcommand apps on Android, Terminal Emulator and SSH-Droid, can be stealthily exploited to execute arbitrarycommands, possibly with the root privilege. This willjeopardize their own files (e.g., command histories andprivate configuration files), sensitive user photos storedon SD cards, and even other apps’ private files. • serverIFL attacks send unauthorized file extractionrequests to embedded app server deputies inside victimapps to obtain private files. All of the tested popularserver apps, such as WiFi File Transfer (Android) andSimple Transfer (iOS), are vulnerable to these attacks. Itis worth noting that both the cmdIFL and serverIFL attacks use previously unexplored deputies—commandinterpreters and embedded app servers—to launch IFLattacks for the first time in mobile platforms.Besides the cross-platform vulnerability, our IFL methodsalso allow an adversary to launch the attacks remotely, withoutimplanting malicious apps in victim’s phones as in prior works[52], [46]. These IFL attacks can be launched both locally(in the same phone) and remotely (in an Intranet/Internet).Table I highlights the identified IFL vulnerabilities and theirmajor attack channels. Besides local IFL attacks, we show thatbrowsers, such as Baidu and Yandex Browser, can be remotelyexploited by enticing the victim to access a web page. Emailapps (e.g., Mail.Ru) and social apps (e.g., QQ) can be similarlycompromised if the victim opens a malicious attachment or filetransmitted by a remote adversary. In other remote attacks, theadversary can scan the whole Intranet, locate open ports, andexploit vulnerable server apps installed on the victim phone.Furthermore, we analyze the differences between Androidand iOS in terms of the impact of the IFL attacks. Thesedifferences are caused by different system architectures andapp design practices between Android and iOS. Our analysisshows that a common iOS app practice could lead to morepowerful and pervasive sopIFL attacks on iOS than Android.On the other hand, three iOS system characteristics help lessenthe impacts on iOS for the other three IFL attacks. Thesefindings can help developers and OS providers build moresecure apps and mobile systems. Ethical considerations.
All of our vulnerability testing isconducted using our own mobile devices and test accounts.The tests never affect the data security of real-world users. Asthe IFL attacks in mobile apps are client-side vulnerabilities,they cannot affect the server-side integrity.
Real-world impacts.
We have reported most of the identi-fied vulnerabilities to their vendors in a responsible way andare in the process of reporting the remaining vulnerabilities.All of the contacted vendors have acknowledged our reports.For example, Evernote has listed us in its security hall offame. Baidu has ranked one of our reports as the most valuablevulnerability report of the second quarter of 2014, and Qihoo360 has issued us the highest award in its mobile bug bountyprogram history. We have also offered our suggestions to thevendors to fix the identified vulnerabilities.
TABLE IF
OUR
IFL
VULNERABILITIES AND THEIR ATTACK CHANNELS .Attack ChannelsRemote Local sopIFL
Evernote, Tencent QQ UC & QQ browsersMail.Ru 360 & Mail.Ru Cloud aimIFL
Baidu, Yandex, and 360 browsers360 Mobile Safe, Baidu Search, myVault cmdIFL
SSHDroid Terminal Emulator serverIFL
WiFi File Transfer, Simple Transfer
Contributions.
To summarize, we make the following threecontributions: • We devise four new IFL attacks that, for the first time,can affect both Android and iOS and are exploitable notonly locally but also remotely. (Section III & IV) • We identify a number of zero-day IFL vulnerabilities inpopular Android and iOS apps and uncover a serious SOPissue in the latest iOS 8 system. (Section IV) • We analyze the differences between Android and iOS interms of the IFL attacks’ impacts and propose severalmethods to mitigate the attacks. (Section V & VI)II. B
ACKGROUND
A. Sandbox-based App Isolation
Both Android and iOS use sandbox-based app isolation tobuild a trustworthy mobile environment. Each app resides inits own sandbox, with its code and data isolated from otherapps. This isolation is usually enforced at the kernel level. Forexample, Android uses UNIX UID-based protection to isolateeach app, in which each app is treated as an independent userand runs in a separate process with a unique uid .Each app’s sensitive files are stored in their own system-provided isolated (or private) file zone. Unless an app activelyleaks a file (i.e., a direct file leak), other apps have no accessto the protected files. The widely deployed SEAndroid MACsystem [40] further thwarts the risks incurred by direct fileleaks. However, IFLs can still occur in the presence of bothsandbox-based isolation and MAC. Although the actual exe-cuter of the file access is the legal victim app, the file requestis actually initiated and crafted by an adversary. Encryption-based defenses, such as encrypting all private app files, facesimilar limitations as the MAC. To sum up, IFL remains aserious, and yet unsolved, threat, which motivates our study.
B. Terminology
In Table II, we summarize the terms used throughout thispaper. III. T HE IFL A
TTACKS
In this section, we first describe the adversary model andthen detail the four types of IFL attacks introduced in Sec-tion I.
A. Adversary Model
We consider the following three types of adversaries inour IFL attacks. A local adversary can launch only localattacks, whereas the Intranet and Internet adversaries remote
IFL attacks.
ABLE IIT
ERMS AND THEIR DESCRIPTIONS . Term DescriptionPrivate files The files stored in apps’ isolated file zones. In nonlocal IFLattacks, they also include files on a SD card, e.g., user photos.Target file A private file the adversary wants to steal in an IFL attack.Permission A form of privilege representation. For example, the
INTERNET permission on Android and the
Contact permission on iOS.Root A superuser privilege. For example, a rooted phone is a phonethat enables superuser privilege for apps.Browsing Or browsing component. A component with browsing capabili-interface ty, usually built with Android’s WebView or iOS’s UIWebView.Command An app component that can interpret and execute commands.interpreterApp server A server component embedded in an app. • A local adversary is an attack app installed on the samesmartphone as the victim app. It requires few or nopermissions and does not exhibit any typical maliciousapp behavior [51]. The root privilege is never used bythis attack app. We also do not consider screenshotattacks [33] that require strong assumptions. • An Intranet adversary resides in the same Intranet asthe victim’s mobile device. It can send network requeststo any other node within the Intranet. It can sniff thenearby wireless traffic and retrieve unencrypted content.We do not assume that it can launch effective ARPspoofing attacks, as network administrators can detectsuch anomalous events. • An Internet adversary can be located in any host in theInternet. It remotely compromises a victim by (i) enticinga victim to browse a web page under the adversary’scontrol, and/or (ii) sending the victim a malicious filevia email, chatting app, social network, and other means.
B. Bypassing SOP on Browsing Interfaces
The sopIFL attacks bypass SOP to steal private files viabrowsing interfaces. The deputy in this attack is the browsinginterface or rendering engine, whose SOP enforcement isflawed and cannot prevent malicious JavaScript codes fromaccessing a private file. All apps that contain browsing com-ponents are potential victims.The file:// scheme is an ideal medium to launch the sopIFL attacks. Two parts of SOP enforcement on file:// can be exploited to steal local private files. The adversary cancross the origin from a web domain to access local file content,if the cross-scheme SOP enforcement for http(s):// to file:// (labelled as SOPf1 ) is broken. Alternatively, theadversary can leverage a local malicious HTML file in onepath to steal a target file in another path. In this case, the file://
SOP enforcement between the two file origins (la-belled as
SOPf2 ) must be bypassed. Since failure of enforcing
SOPf1 is rare in modern rendering engines, we focus on the sopIFL attacks that will bypass the
SOPf2 .Our recent study [46] shows that Android does not effec-tively enforce
SOPf2 . However, little is known about iOS.This is where our contribution for the sopIFL attacks lies.Contrary to our expectation, these attacks can have higherimpact on the iOS ecosystem than the Android’s. Our testingusing iPhone 6 reveals that even the latest iOS 8 does not properly enforce
SOPf2 . Indeed, iOS never guarantees thispolicy (Section IV-A). In Section V, we identify a commonpractice among the iOS apps that could lead to more pervasiveand powerful sopIFL attacks on iOS than Android.We believe that the root problem is that the legacy SOPcannot adequately cover the local schemes, such as file:// .The typical web SOP principle (i.e., the legacy SOP) allowsfile A (at file:///dir1/a.html ) to access file B (at file:///dir2/b.txt ) because the two origins share thesame scheme, domain (i.e., 127.0.0.1 or localhost), and port. Inpractice, this legal behavior fails to meet the security require-ments for file:// , especially in the mobile environment.Therefore, an enhanced SOP for local schemes, such as addingthe “path” element to the current three-element SOP tuples, isneeded for eradicating this vulnerability. We reported our iOSfindings to Apple on 19 January 2015 and suggested them touse an enhanced file://
SOP at the system or engine level.
C. Unauthorized JavaScript Execution on Target Files
The aimIFL attacks could be regarded as an advancedvariant of the sopIFL attacks. Both attacks use the browsinginterface as the deputy, but the aimIFL attack does not violateSOP. It can do so by injecting and executing unauthorizedJavaScripts directly on target files, instead of requiring amalicious file to bypass SOP to access target files as in the sopIFL attacks.The aimIFL attacks usually consist of two steps. Unau-thorized JavaScript codes are first injected into the targetfile. This can be achieved in different ways, depending onthe type of the target files. For example, if the target is acookie file, the JavaScript codes can be injected via a website’scookie field. The target files are then loaded and rendered. Thepreviously injected JavaScript is executed to steal the currentfile content via an HTML document object model variable,such as document.body.innerHTML . As JavaScript onlyaccesses the current document, this attack does not violateSOP, thus setting this attack apart from the sopIFL attack.It is worth noting that the two steps can also be performedsimultaneously without the user’s knowledge. A victim user’sprivate files will be stolen when he browses a web page underthe attacker’s control. In this paper, we focus on designingremote aimIFL attacks, although they can also be conductedlocally.We identify two types of remote aimIFL attacks illus-trated in Fig. 2. In the first type, a web page tries toload a target file through local schemes like file:// and content:// . The file can be loaded by a file link or anHTML iframe . The link-based loading requires an extra userclicking, whereas the iframe-based loading is automatic anddoes not require any user action. Before loading the targetcookie file, the web page injects malicious JavaScript codes(e.g., ) via the web cookie field. Once the cookiefile is successfully loaded, the JavaScript inside it can stealthe cookie content. As will be shown in Section IV-B, the rowsing UI
It loads the cookie file (1) in a tab via a link;(2) in a HTML iframe http://attacker.org set cookie: ok=
This is a tab or iframe== file content == … … == end of file == (a) Attacks that activelyload a target file.
Renderable UI
Bookmarksset title or url previously:
Me
Recent history · Google · … · Me · … · https://fb.com · … · http://domain.org/? (b) Attacks that exploitvictim apps’ file loadingfeatures.
Fig. 2. Remote aimIFL attacks. popular 360 Mobile Safe, Baidu, and Yandex browsers are allvulnerable to this type of aimIFL attack.The second type of the aimIFL attacks does not activelyload and render target files. Instead, it exploits victim apps’ability to load the content of target files into a renderable userinterface (UI), such as those containing WebView widgets.For example, some browser apps load browsing historiesfrom the history file into a renderable UI. Using this app-loading feature, an adversary simply injects the JavaScript intothe target file. For example, as illustrated in Fig. 2(b), theadversary injects an unauthorized JavaScript into the historyfile through the title or URL field of a web page. When the userswitches to the renderable UI, a new history log containing themalicious title or URL is displayed. The embedded JavaScriptis then executed to steal the history file. These passively loadedfiles are usually rendered in the local domain (e.g., under file:// ). The adversary can also combine an aimIFL attack with a sopIFL attack to steal other private files thatare not loaded by the victim apps. We will detail the affectedapps in Section IV-B.
D. Unauthorized Command Execution on Command Inter-preters
The cmdIFL attacks exploit command interpreters (asdeputies) inside victim apps to execute file operation relatedcommands for IFL attacks. We consider explicitly embeddedcommand interpreters, such as those in command terminalapps. In other words, (remote) code execution vulnerabilitiescontained in host apps are out of the scope.An app is vulnerable to a cmdIFL attack only when itcan be injected with unauthorized commands. To leak privatefiles, the injected commands can (i) set a world-readable filepermission by invoking the chmod command, (ii) export a fileto a public SD card via the cp command, or (iii) send a fileto a remote server through commands like scp . If the victimapp has root permissions, all of these commands can be usedto steal private files in other, possibly more sensitive, apps. To discover and exploit a cmdIFL vulnerability, an adver-sary needs to identify channels that can be used to confusecommand interpreters to accept unauthorized commands. Thecross-app component communication channel [24], [22] onAndroid can be used to launch local cmdIFL attacks, if thecommand interpreter components are exposed. An adversarycan also exploit the URL scheme [43] to achieve the same, ifnot better, attack impacts. Moreover, general remote cmdIFL attacks are also possible, if the command interpreter acceptsremote command requests. In addition, victim apps’ configu-rations stored in public storage can be changed to indirectlyinject commands. Accessibility services can also be misusedto mimic user commands [31].A cmdIFL attack could also be launched through a GUI toattack file manager apps. An adversary can force these appsto perform unauthorized UI-based file operations to leak filecontents. However, this is not a real threat, because such fileoperations have to be conducted by victim users and thusare easily noticed. A smarter adversary can wait for usersto open a sensitive file and launch screenshot attacks [33] tosniff the content. We exclude this scenario also from our treatmodel, because this requires the adversary to closely monitorthe victim’s activity. E. Unauthorized File Extraction via Embedded App Servers
The confused deputies here are the app servers embeddedin victim apps. An adversary sends unauthorized file extrac-tion requests to exploit vulnerable embedded app servers forobtaining private files. The affected app servers are mainlyfile servers (e.g., those that support http:// and ftp:// requests) that provide users with file transmission service be-tween phones and desktops. The command servers mentionedin the last section are another type of candidate servers. Someapps that support multi-function servers are also affected, suchas the very popular AirDroid app, which has over 10 millioninstalls.A serverIFL attack can be conducted in three ways. First,a local attack can be launched from another app installed onthe same smartphone as the victim app. It scans the local hosts’ports and sends packets to the port listened to by the victimapp. Second, adversarial nodes (e.g., phones or laptops) inthe same Intranet can attack the victim app in another device.Within the same Intranet, it is also easy for an adversary toidentify a port opened by the victim app. Third, we show thatremote serverIFL attacks are also possible. Attack vectorsare delivered through the victim’s desktop browsers when theybrowse a malicious web page.A successful serverIFL attack may need to bypassauthentication set up to protect the victim app, such as anauthentication code (e.g., user password) or a confirmationaction (e.g., clicking a confirmation button). Our evaluation inSection IV-D, however, shows that the current authenticationin server apps is nearly broken. Some apps use no or weakauthentication (e.g., using only four random numbers). Almostall channels for transmitting authentication codes and subse-quent session tokens are unencrypted. An Intranet adversary
ABLE III I OS APPS VULNERABLE TO THE
S O P
IFL
ATTACKS . Category Vulnerable Apps Attack ChannelBrowser UC, Mercury LocalBaidu, Sogou, QQ browsersCloud Drive Mail.Ru Cloud Local & WebBaidu Cloud, 360 CloudNote/Read Evernote, QQ Reader Local & WebEmail Mail.Ru RemoteSocial Tencent QQ RemoteUtility Foxit Reader, OliveOffice Local can easily sniff these secrets to bypass the authentication step.IV. U
NCOVERING
IFL V
ULNERABILITIES IN A NDROIDAND I
OS A
PPS
A. SopIFL Vulnerabilities
We uncover a number of vulnerable iOS apps summarizedin Table III. We evaluate them using an iPhone 6 (with thelatest iOS 8) and an iPad 3 (with iOS 7). Our evaluation showsthat both iOS 7 and 8—which are used in around 95 percentof all iOS devices [1]—do not enforce
SOPf2 at the enginelevel. Since all iOS apps can use only the default web engine,the current solution for mitigating the sopIFL vulnerabilitiescan only be done on the application level.To launch a sopIFL attack on the iOS platform, a “ma-licious” HTML file must be delivered to the victim app. Wehave identified three such channels.
Local
The adversary can design stealthy iOS apps (e.g., theJekyll app [44]) to launch local sopIFL attacks, becausesome iOS apps accept external HTML files from otherapps through the “open with” feature . Similarly, Androidbrowsers often use exposed browsing interfaces [46]. Wenotice that local attacks can also be conducted “remotely”by leveraging other apps’ remote channels. For example,an adversary first sends an HTML file to the popularWeChat app installed on a victim device. Since WeChatwill not open this type of file, it will ask the user to openthe file using another app. We find that browser and clouddrive apps are likely to be affected by these local attacks. Web
An adversary can deliver attack vectors through the webservice interfaces of mobile apps. For example, clouddrive and note apps support file sharing on the web. Anadversary can share an HTML file with a victim via webinterfaces.
Remote
Remote sopIFL attacks are possible for some iOSapps. The attachment mechanism in email apps is an idealchannel to launch targeted remote sopIFL attacks. Forexample, once a Mail.Ru iOS user opens an attachedHTML file from an adversary email, the adversary cansteal the victim’s private Mail.Ru files remotely. Simi-larly, the file sending mechanism in social apps, such asthe popular Tencent QQ, can also be exploited.Besides HTML files, we anticipate other types of files forlaunching sopIFL attacks. For example, the commonly usedPDF and flash file formats can execute embedded JavaScript Two “open with” demos implemented in Dropbox and WeChat areavailable at http://goo.gl/H7KXeM. TABLE IV A PPS VULNERABLE TO THE
A I M
IFL
ATTACKS . Attack Name Vulnerable Apps aimIFL-1 via file://
Baidu Browser, On The Road aimIFL-1 via content://
360 Mobile Safe aimIFL-1 via intent://
Yandex and 360 browsersBaidu Search, Baidu Browser aimIFL-2 on Android org.easyweb.browser
Internet Browser, Smart BrowserShady Browser, Zirco Browser aimIFL-2 on iOS myVault automatically steal the file WebView by default does not provide this feature. JS via the web page title ( test ) is injected into the history table of dbbrowser.db . 1 2 open long press Fig. 3. An aimIFL-1 attack exploiting Baidu Browser. codes in a desktop environment [5], [17]. The current mobilesystems have limited support for flash and only run basicJavaScript in PDF files. Once these systems are improved, weexpect that these new attack vectors will bypass the existingprotection. For example, WeChat is immune to the current sopIFL attacks by disabling the opening of HTML files.However, it allows opening PDF files to be opened, whichcould be exploited for future sopIFL attacks. B. AimIFL Vulnerabilities
We summarize the aimIFL vulnerabilities in Table IV.As discussed in Section III-C, these vulnerabilities can beclassified into two types: aimIFL-1 and aimIFL-2 . aimIFL-1 attacks. We attempt an aimIFL-1 attack via file:// on two Android apps, Baidu Browser and On TheRoad. We find it difficult to directly load a file:// content(e.g., via an HTML iframe) from a web page on Android.We thus use an alternative method that asks users to click a file:// link embedded in a web page. This method is ableto exploit On The Road, as the app renders the file:// linkclickable. However, similar to desktop browsers, file:// links in Baidu Browser are not clickable. We find that anadversary can entice a victim to long-press the link, allowingBaidu Browser to pop up a dialog that the user can click.The target file is then rendered and its contents are stolenautomatically. The attack procedure is illustrated in Fig. 3.We find the content:// scheme on Android can alsobe exploited by aimIFL-1 attacks. This scheme is usedto retrieve content or data from the corresponding contentprovider components. Surprisingly, we find that a web pagecan load a local file via the content:// scheme if thessociated content provider implements the openFile(Uriuri, String mode)
API. Launching aimIFL-1 attacksvia content:// is therefore even easier than file:// .We have successfully launched this attack to remotely exploit360 Mobile Safe. Because of the seriousness of this exploit,360 has issued us the highest award in its mobile bug bountyprogram history.Terada [42] points out that the intent:// scheme can beused to remotely attack local Android components. Followingthis idea, we independently identify several popular browsersand the Baidu Search app that can be exploited by aimIFL-1 attacks via intent:// . These victim apps satisfy the follow-ing three conditions, which make them exploitable. • They contain
Intent.parseUri() to intercept an intent://
URI and generate an
Intent structure.This
Intent can invoke any component of the victim,even a private component that has not been exposedto other apps. An adversary can thus design a crafted intent://
URI to deliver attack vectors to a targetcomponent. • They include a component that imports external
Intent parameters to
WebView.loadUrl(String url) .An adversary can thus control this component to renderan arbitrary URI. • The victim component in the last step allows file:// access and its JavaScript execution. The victim can there-fore render a target file via file:// and execute itsembedded JavaScript codes.All the aimIFL-1 attacks discussed above affect onlyAndroid apps. We will explain why it is hard to launch aimIFL-1 attacks on iOS in Section V. aimIFL-2 attacks.
Launching the aimIFL-2 attacks suc-cessfully requires two conditions. The victim app must beable to load the content of a target file into a WebView-based UI gadget, and the adversary must be able to injectan unauthorized JavaScript into the target file.We use the first condition to facilitate the search forvulnerabilities. We focus on Android browsers and iOSWebView-based apps in [9] and inspect their screenshotsto choose which apps to install and test. The
WebView.loadDataWithBaseURL
API is useful for locating vul-nerable Android browsers, because developers often invokethis API to load the local content and their associated assets.We use this API and its first parameter value (e.g., startingwith “file://”) to search Android browser codes and identify avulnerable open source Zirco browser. Interestingly, this vul-nerable Zirco design is also used in several other browsers, in-cluding “Browser for Android” ( org.easyweb.browser )that affects around one million users.One iOS app, myVault, is exploitable by the aimIFL-2 attack. This app allows users to store their private photos,bookmarks, and passwords. Its bookmark store page is an entrypoint where a “malicious” bookmark can be injected to stealthe victim’s bookmarks. Even worse, as iOS does not enforceSOP well on file:// , an adversary can therefore steal othersensitive content through a crafted bookmark.
TABLE V
CMD
IFL
VULNERABILITIES .Apps Vulnerability Cause Attack
C. CmdIFL Vulnerabilities
Table V lists the identified cmdIFL vulnerabilities. Weselect command terminal and server apps in Google Play,because these apps are more likely to contain commandinterpreters than normal apps. More specifically, we evaluatethe top apps, Terminal Emulator and SSHDroid, as they are themost likely to be installed by users with these requirements.For example, Terminal Emulator for Android has over 10million installs, whereas the top two terminal apps have lessthan 0.5 million installs.Both tested command apps are found to be vulnerable tothe cmdIFL attacks. A local attack app can execute arbitrarycommands using the identity of Terminal Emulator, such asexporting its private files (e.g., command histories and privateconfiguration files) to a public SD card. The root cause of thisvulnerability is that the exposed terminal command componentcan be invoked by other local apps with arbitrary commandparameters. Interestingly, we find that Terminal Emulator triesto protect its command component with a dangerous -levelpermission, as shown in part (1) of Fig. 4. The rationalebehind this design is that all command invocations (viathe jackpal.androidterm.RUN_SCRIPT action) nowhave the appropriate authorization through the permissionmechanism. Unfortunately, the adversary does not need totouch the protected command proxy component (“RunScript”).Instead, it directly invokes the underlying command compo-nent (“RemoteInterface” in part (2) of Fig. 4), which is bydefault exposed by Android’s intent filter mechanism [22].Consequently, a crafted input can force the “RemoteInterface”component to execute commands. We reported this issue andits demo attack code to Terminal Emulator’s github page, andhelped the open-source community patch the app [14], [7].The top command server app, SSHDroid, is vulnerable tothe local and Intranet cmdIFL attacks. This app works as
ABLE VI
SERVER
IFL
SECURITY WEAKNESSES IN THE TOP SERVER APPS .App App Transmission Immune to Effective × (setting) (cid:88) (user confirm) (cid:88) (cid:88)
10M - 50M2 WiFi File Transfer http 1234 × (setting) × (setting) × ×
5M - 10M3 Xender http 6789 × (cid:88) (four numbers) (cid:88) ×
1M - 5M4 WiFi File Explorer http 8000 × × (setting) (cid:72)(cid:35) ×
1M - 5M5 com.file.transfer ftp 2121 × × (cid:88) × × × (setting) (cid:88) (cid:72)(cid:35) × (cid:88) (six bytes) (cid:88) ×
865 Ratings8 WiFi Photo Transfer http 15555 × × (setting) (cid:88) ×
661 Ratings9 USB & Wi-Fi Flash Drive http 8080 × × × ×
462 Ratings10 Air Transfer http 8080 × × (setting) (cid:88) ×
138 Ratings * The app install numbers were counted on November 1, 2014. We use rating numbers to estimate the popularity of the iOS apps. an SSH server listening to the default port of 22, but itcannot prevent unauthorized connectors. An adversary doesnot need to fingerprint SSHDroid, because SSHDroid givesthis information to any connector. SSHDroid only has two username choices, the “user” in the normal case or the “root” on arooted phone. It also uses the default “admin” password if theuser does not change it in the settings. Hence, an adversary hasenough pre-knowledge to exploit this app and steal its privatefiles. More alarmingly, SSHDroid always tries to work as the“root”. If it is exploited on a rooted phone, an adversary canexecute root commands and steal the private files of all theinstalled apps.
D. ServerIFL Vulnerabilities
We test the top ten server apps from Google Play and theApple App Store to evaluate the serverIFL vulnerabilities.Table VI summarizes the statistics of their security metrics.All of the tested apps have at least one security weakness thatcan be exploited to launch the serverIFL attacks.Surprisingly, none of these apps provide encrypted trans-mission between file requesters (e.g., users’ desktop browsers)and file servers (i.e., the tested apps). Eighty percent of theapps do not implement this important security guarantee at all.This can cause serious consequences in the wireless setting,which is assumed in these apps’ user models. Two apps alsoprovide this functionality which, however, is not enabled bydefault. We find that the apps’ SSL encryption (when manuallyenabled in the setting) accepts only self-signed certificates,which causes security warnings in client-side browsers, thushurting the user experience.The authentication used in these apps is very weak. Sevenof the ten tested apps do not enforce authentication, includingthe most popular iOS server app, Simple Transfer. An Intranetadversary can thus easily send unauthorized file extractionrequests. The apps that conduct authentication still do nothave guaranteed security due to the aforementioned lack ofencrypted transmission. An adversary can sniff wireless trafficto obtain the secret information used for authentication orthe cookies used for post-authentication transmission. Thesecret information used for authentication is generally notstrong, such as the four-number verification code used inapp serverIFL attacks are also possible. We proposean improved file upload CSRF (cross-site request forgery)attack [8] for this purpose. An adversary uploads an HTMLor PDF file with malicious JavaScript codes through the fileupload CSRF. After the victim opens the uploaded file in hisdesktop browser, the embedded JavaScript runs in the samedomain as other target files and can steal arbitrary file content.We only describe the test results here: • Apps serverIFL attacks possible. • Apps • Apps • Apps • One app, AirDroid, embeds a secret token into eachGET/POST request URL. As CSRF cannot obtain thistoken, the app is safe.Launching stealthy serverIFL attacks usually requiresthat victim apps do not have an effective mechanism todetect illegal connections. Our evaluation reveals that only twoapps have such detection capabilities. AirDroid alerts users toconfirm or reject each new incoming connection and breaksthe last connection. This mechanism is effective in preventingstealthy connections, because it is hard for a local attack app todisable or envelop AirDroid alerts. Simple Transfer displays a“connected” UI when it accepts its first connection. However,it does not further implement multiple-connection detectionsor warnings. This weakness allows an adversary to stealthilyconnect to a victim app after the victim has established itsinitial connection with a legal user browser.To launch effective serverIFL attacks, an attacker couldfingerprint common server apps in advance. As shown inTable VI, the protocols used in the tested apps are quiteindistinguishable (basically HTTP). However, the opened portshave sufficient variability for identifying the apps. Moreover,for the apps with the same port numbers, an adversary caneverage different HTTP responses to distinguish them. Oncethe adversary has constructed a database of fingerprints, it canlaunch targeted serverIFL attacks on the apps.V. A
NDROID VS I
OSOur evaluation reveals four major differences between An-droid and iOS in terms of the impact of the IFL attacks. Wediscuss their implications below.
Implication 1:
The common practice in iOS apps to open(untrusted) files in their own app domain could lead to morepervasive and powerful sopIFL attacks on iOS than Android.
We compare the file-opening behavior in the iOS andAndroid versions of representative apps in different categories.We choose two file types, HTML and PDF, for their abilityto carry attack vectors. We find that most of the tested iOSapps open the HTML files by themselves. In contrast, thecorresponding Android versions choose to let dedicated apps(e.g., browsers) handle the HTML files. The PDF files havesimilar results. Opening untrusted files within the app’s owndomain is thus a common practice in iOS apps, whereasAndroid apps generally ask dedicated apps to open files.However, Google Drive and WeChat for iOS also requireexplicit user actions to open HTML files outside the app. Butsimilar to other iOS apps, they open PDF files internally.This common practice produces more attack surfaces foriOS apps than their Android versions. Asking dedicated appsto handle untrusted files is a more secure design, becausepotential attack vectors are then kept away from the user’sprivate files. The tested Android apps generally use this prac-tice, which makes them immune to sopIFL attacks. Hence, sopIFL attacks on Android are nearly local attacks that forcefiles opened in exposed browsing interfaces, which only affectsbrowser apps and careless apps. In contrast, iOS cases aremore pervasive and span multiple app categories. They arealso more powerful and can be local, web, or remote attacks,as they do not necessarily require locally exposed components.There are many possible reasons for iOS’s this design.We believe that the lack of flexible data sharing on iOS isan important reason responsible for the apps to open filesby themselves. Indeed, the iOS data sharing involves a non-lightweight process of “exporting and importing,” possibly dueto the lack of public SD cards and a content URI mechanism,both of which are supported on Android.
Implication 2:
The randomized app data directory on iOSmakes it difficult to conduct the aimIFL-1 attacks on iOS.
The aimIFL-1 attacks usually require the knowledge ofa full file path. However, iOS assigns a random directoryfor each app’s data zone, which makes it difficult for aremote attacker to construct the full path of a target file.Moreover, this iOS randomness is performed at every in-stallation. Therefore, the directory of an app reinstalled onthe same phone will be different after each new installation.An example of a randomized app directory is , with the unifiedpath prefix /private/var/mobile/Applications/ (on iOS 7) and /private/var/mobile/Containers/Bundle/Application/ (on iOS 8).In comparison, Android names app data directoriesaccording to the app package name. An adversary caneasily construct the app directory using the pattern /data/data/packagename/ . As apps generally donot use their own randomness within this directory, it isstraightforward to obtain the full file path. We only findone exception: Firefox uses a random path strategy inits Android app design. An example of its full file pathis /data/data/org.mozilla.firefox/files/mozilla/62x7scuo.default/cookies.sqlite with the randomized directory underlined.As randomizing the app directory is useful for thwartingthe aimIFL-1 attacks on iOS, we recommend the Androiddevelopers to use this practice in their own app design.
Implication 3:
Apple’s strict app review prevents iOS appsfrom executing bash commands. An adversary therefore cannotfind targets to launch the cmdIFL attacks on iOS.
As stated in [44], Apple has strict regulations for reviewingiOS apps submitted to the App Store. Apple’s app reviewguidelines [2] briefly describe many scenarios that can leadto an app rejection. Among them, rule 2.8 states:
Apps that install or launch other executable codewill be rejected.
This rule implies that running interpreted codes (e.g., bashscripts) is forbidden by Apple. We thus cannot locate any iOSapps that contain command interpreters, which is a necessarycondition for launching the cmdIFL attacks. Although a fewiOS apps (e.g., ipash ME) claim that they provide commandexecution for iOS, they actually only mimic the output and donot run the native commands. They therefore receive customerreviews saying “It’s a fake command line.”To sum up, this iOS restriction makes it nearly impossibleto launch the cmdIFL attacks on iOS, because there are nosuitable app targets in the App Store.
Implication 4: iOS generally does not allow backgroundserver behavior, which reduces the chance of the serverIFL attacks on iOS.
The success of launching the serverIFL attacks dependson whether the adversary can attack victim apps when thephone screen is off or locked. If victim apps do not supportbackground servers, then the attack timing window is short-ened, thus reducing the chance of a successful serverIFL attack. The evaluation in Section IV-D indicates that iOSserver apps usually only work in the foreground. Of the topfive iOS server apps, only Air Transfer can be attacked whenthe screen is off. In contrast, all of the top five Android appssupport background server behavior and are thus exploitablein the same phone setting.We find that it is not easy for iOS developers to implementbackground server behavior. They require advanced tricks [10],[15] and have to worry about violating Apple app reviewpolicies. Thus, developing an app server that can run in thebackground is uncommon on iOS.I. M
ITIGATION M ETHODS
Application-specific defenses are required to mitigate exist-ing IFL risks. Developers can refer to Section IV for avoidingthe same flaws shown in the existing vulnerable apps. Systemflaws in Android and iOS, such as the SOP flaw mentioned inSection III-B, should be also timely fixed. Four implicationsin Section V will be useful to improve both app and systemsecurity at different levels. For example, it is prudent for iOSapps not to open untrusted files in their own app domain andinstead to ask dedicated apps to handle them.We now offer two more suggestions,
NoJS and
AuthAccess ,to further mitigate IFL attacks. • NoJS: disabling JavaScript execution in local schemes tosafeguard against the sopIFL and aimIFL attacks. The serverIFL attacks based on file upload CSRF can besimilarly stopped by opening uploaded files as plain texts. • AuthAccess: restricting commands and network requeststo access apps’ private file zone. Each access should beexplicitly authorized by users. By doing so, the cmdIFL and serverIFL attacks can be mitigated.Beyond vendors’ own ad hoc fixes, a central mitigationsolution is desirable. A possible way is to extend the existingSEAndroid MAC system [40] by leveraging the fine-grainedcontext information to differentiate IFL attack requests fromnormal requests. Prior works [27], [25], [20], [21] have shownhow to collect and enforce process-related context for tacklinglocal permission leak attacks. The local IFL attacks can behandled in a similar way. However, it is challenging forcontext-based enforcement to mitigate the remote IFL attacksbecause remote entities are usually not under defender’scontrol and thus their context cannot be easily obtained.To address this problem, recently proposed user-driven andcontent-based access control [39], [36] may be useful. Wewill investigate how to leverage them to develop an enhancedcontext-based MAC system for the IFL attack mitigation inour future work. VII. R
ELATED W ORK
File leaks in mobile apps.
Compared with the IFLs studiedin this paper, direct file leaks are a more straightforward typeof file leak. Many of these leaks were caused by the settingan insecure (e.g., world-readable) permission for its privatefiles in the apps. For example, Opera [12] and Lookout [16]have made this error. On the other hand, the victim app writessensitive files to public storage (e.g., SD cards and systemdebug logs). Outlook [13] and Evernote [6] put their users atrisk in this way. The recent SEAndroid MAC system defendsagainst these direct leaks, whereas our IFL is still an unsolvedthreat. Moreover, these direct cases are just local leaks onAndroid, whereas we propose multiple forms of remote fileleaks across both Android and iOS.Some IFL attack instances have been studied before, butthey focus only on their specific problems. For example,Zhou et al. [52] study an attack with exposed Android con-tent providers as confused deputies. By issuing unauthorizeddatabase queries to these components, an adversary can steal victim apps’ database files. This attack is one kind of local IFLattacks and only exists on Android. Another example is ourprevious FileCross attacks [46], which belong to the sopIFL attacks discussed in Section III-B. However, it [46] only showslocal sopIFL attacks on Android, whereas we demonstratethat sopIFL issues also exist in a number of iOS apps andcan be remotely exploited.It is worth noting that a blog post [11] reported two local sopIFL issues in Dropbox and Google Drive iOS apps overtwo years ago, but did not mention how to deliver the attackvectors (as we do in Section IV-A). This blog post used theold iOS systems before the recent iOS 7 and 8 to test theproblem and did not show that this issue is widespread in thecurrent iOS ecosystem. We are also the first to identify itsfundamental cause: the legacy web SOP does not adequatelycover the local schemes. Compared with all of these isolatedIFL studies, we are the first to systematically study both localand remote IFL attacks across Android and iOS.
Confused deputy problems on mobile.
The IFL attackis a class of the general confused deputy problem [30]. Anumber of previous works have studied the permission-relatedconfused deputy problem on Android, called permission leakor privilege escalation [24]. They have proposed detectionsystems based on control- and data-flow analysis, includingComDroid [22], Woodpecker [29], CHEX [34], ECVDetec-tor [48], Epicc [38], and SEFA [49]. Some Android app anal-ysis frameworks, such as FlowDroid [18] and Amandroid [45],can be extended to detect this problem. However, it is difficultfor these static tools to analyze the IFL vulnerabilities, becausemost of the IFL attacks do not have explicit vulnerablecode patterns. Using dynamic analysis tools (e.g., [26], [50],[41], [19]) to construct automatic IFL detectors is thereforedesirable. We leave this for our future work. Furthermore,none of the aforementioned studies identify confused deputyproblems on iOS. But as shown in our IFL attacks, it is equally,if not more, important to develop detection tools for iOS.
Mobile browser security.
Our sopIFL and aimIFL attacks are related to mobile browser security. Related workshave studied the threats to Android WebView [35], [23], [37],[46], the security risks in HTML5-based mobile libraries [28]and apps [32], and unauthorized origin crossing in severalpopular Android and iOS apps [43]. Differently, our focusis file leaks via vulnerable browser components. Only theaforementioned work [46] shares the same goal as our study.In addition, a prior work [32] injects unauthorized JavaScriptsinto HTML5-based apps, and their technique is similar to our aimIFL attacks. However, as their goal is to compromisethe victim website’s online credentials (instead of our goal ofstealing local files), they do not need to overcome our chal-lenge of launching local file-stolen attacks from a web origindue to the SOP restriction. Moreover, our aimIFL attacksapply to all mobile apps that contain browser components,rather than just the HTML5-based apps shown in [32].III. C
ONCLUSION
In this paper, we systematically studied indirect file leaks(IFLs) in mobile applications. In particular, we devised fournew IFL attacks that exploit browser interfaces, commandinterpreters, and embedded app servers to leak private filesfrom popular apps. Unlike the previous attacks that work onlyon Android, we demonstrated that these IFLs (three of them)can affect both Android and iOS. The vulnerable apps includeEvernote, QQ, and Mail.Ru on iOS, and Baidu Browser, 360Mobile Safe, and Terminal Emulator on Android. Moreover,we showed that our four IFL attacks can be launched remotely,without implanting malicious apps in victim’s smartphones.This remote attack capability significantly increases the im-pact of the IFL attacks. Finally, we analyzed the differencesbetween Android and iOS in terms of the IFL attacks’ impactsand proposed several methods to mitigate the attacks.
Acknowledgements . We thank all three anonymous re-viewers for their helpful comments. This work was partiallysupported by a grant (ref. no. ITS/073/12) from the InnovationTechnology Fund in Hong Kong.
Additional materials . We will provide supplementary ma-terials, such as detailed vulnerability reports, at this link(https://daoyuan14.github.io/pp/most15.html).R
Proc. ACM AsiaCCS , 2012.[18] S. Arzt, S. Rasthofer, C. Fritz, E. Bodden, A. Bartel, J. Klein, Y. Traon,D. Octeau, and P. McDaniel. Flowdroid: Precise context, flow, field,object-sensitive and lifecycle-aware taint analysis for android apps. In
ACM PLDI , 2014. [19] R. Bhoraskar, S. Han, J. Jeon, T. Azim, S. Chen, J. Jung, S. Nath,R. Wang, and D. Wetherall. Brahmastra: Driving apps to test the securityof third-party components. In
Proc. Usenix Security , 2014.[20] S. Bugiel, L. Davi, A. Dmitrienko, T. Fischer, A. Sadeghi, and B. Shas-try. Towards taming privilege-escalation attacks on Android. In
Proc.ISOC NDSS , 2012.[21] S. Bugiel, S. Heuser, and A. Sadeghi. Flexible and fine-grainedmandatory access control on Android for diverse security and privacypolicies. In
Proc. Usenix Security , 2013.[22] E. Chin, A. Felt, K. Greenwood, and D. Wagner. Analyzing inter-application communication in Android. In
Proc. ACM MobiSys , 2011.[23] E. Chin and D. Wagner. Bifocals: Analyzing webview vulnerabilities inAndroid applications. In
Proc. Springer WISA , 2013.[24] L. Davi, A. Dmitrienko, A. Sadeghi, and M. Winandy. Privilegeescalation attacks on Android. In
Proc. Springer ISC , 2010.[25] M. Dietz, S. Shekhar, Y. Pisetsky, A. Shu, and D. Wallach. Quire:Lightweight provenance for smart phone operating systems. In
Proc.USENIX Security , 2011.[26] W. Enck, P. Gilbert, B. Chun, L. Cox, J. Jung, P. McDaniel, and A. Sheth.Taintdroid: An information-flow tracking system for realtime privacymonitoring on smartphones. In
Proc. Usenix OSDI , 2010.[27] A. Felt, H. Wang, A. Moshchuk, S. Hanna, and E. Chin. Permissionre-delegation: Attacks and defenses. In
Proc. Usenix Security , 2011.[28] M. Georgiev, S. Jana, and V. Shmatikov. Breaking and fixing origin-based access control in hybrid web/mobile application frameworks. In
Proc. ISOC NDSS , 2014.[29] M. Grace, Y. Zhou, Z. Wang, and X. Jiang. Systematic detection ofcapability leaks in stock Android smartphones. In
Proc. ISOC NDSS ,2012.[30] N. Hardy. The confused deputy: (or why capabilities might have beeninvented). In
ACM SIGPOS Operating Systems Review , 1988.[31] Y. Jang, C. Song, S. Chung, T. Wang, and W. Lee. A11y attacks:Exploiting accessibility in operating systems. In
Proc. ACM CCS , 2014.[32] X. Jin, X. Hu, K. Ying, W. Du, H. Yin, and G. Peri. Code injectionattacks on HTML5-based mobile apps: Characterization, detection andmitigation. In
Proc. ACM CCS , 2014.[33] C. Lin, H. Li, X. Zhou, and X. Wang. Screenmilker: How to milk yourAndroid screen for secrets. In
Proc. ISOC NDSS , 2014.[34] L. Lu, Z. Li, Z. Wu, W. Lee, and G. Jiang. CHEX: Statically vettingAndroid apps for component hijacking vulnerabilities. In
Proc. ACMCCS , 2012.[35] T. Luo, H. Hao, W. Du, Y. Wang, and H. Yin. Attacks on webview inthe Android system. In
Proc. ACM ACSAC , 2011.[36] A. Moshchuk, H. Wang, and Y. Liu. Content-based isolation: Rethinkingisolation policy design on client systems. In
Proc. ACM CCS , 2013.[37] A. Nadkarni, V. Tendulkar, and W. Enck. Nativewrap: Ad hoc smart-phone application creation for end users. In
Proc. ACM WiSec , 2014.[38] D. Octeau, P. McDaniel, S. Jha, A. Bartel, E. Bodden, J. Klein, and Y. L.Traon. Effective inter-component communication mapping in Androidwith Epicc: An essential step towards holistic security analysis. In
Proc.Usenix Security , 2013.[39] F. Roesner, T. Kohno, A. Moshchuk, B. Parno, H. Wang, and C. Cowan.User-driven access control: Rethinking permission granting in modernoperating systems. In
Proc. IEEE Symposium on Security and Privacy ,2012.[40] S. Smalley and R. Craig. Security Enhanced (SE) Android: Bringingflexible MAC to Android. In
Proc. ISOC NDSS , 2013.[41] D. Sounthiraraj, J. Sahs, G. Greenwood, Z. Lin, and L. Khan. SMV-Hunter: Large scale, automated detection of SSL/TLS man-in-the-middlevulnerabilities in Android apps. In
Proc. ISOC NDSS
Proc. ACM CCS , 2013.[44] T. Wang, K. Lu, L. Lu, S. Chung, and W. Lee. Jekyll on iOS: Whenbenign apps become evil. In
Proc. Usenix Security , 2013.[45] F. Wei, S. Roy, X. Ou, and Robby. Amandroid: A precise and generalinter-component data flow analysis framework for security vetting ofAndroid apps. In
Proc. ACM CCS , 2014.[46] D. Wu and R. Chang. Analyzing Android Browser Apps for file://Vulnerabilities. In
Proc. Springer Information Security Conference(ISC) , 2014.47] D. Wu and R. K. C. Chang. Indirect file leaks in mobile applications.In
Proc. IEEE Mobile Security Technologies (MoST) , 2015.[48] D. Wu, X. Luo, and R. Chang. A sink-driven approach to detecting ex-posed component vulnerabilities in Android apps.
CoRR , abs/1405.6282,2014.[49] L. Wu, M. Grace, Y. Zhou, C. Wu, and X. Jiang. The impact of vendorcustomizations on Android security. In
Proc. ACM CCS , 2013. [50] L. Yan and H. Yin. Droidscope: Seamlessly reconstructing the OS andDalvik semantic views for dynamic Android malware analysis. In
Proc.USENIX Security , 2012.[51] Y. Zhou and X. Jiang. Dissecting Android malware: Characterizationand evolution. In
Proc. IEEE Symposium on Security and Privacy , 2012.[52] Y. Zhou and X. Jiang. Detecting passive content leaks and pollution inAndroid applications. In