Demystifying Resource Management Risks in Emerging MobileApp-in-App Ecosystems

Haoran Lu Luyi Xinglowast Yue Xiao Yifan Zhang Xiaojing Liao XiaoFeng Wang Xueqiang WangIndiana University Bloomington

haorlu luyixing xiaoyue yz113 xliao xw7 xw48iuedu

ABSTRACTApp-in-app is a new and trending mobile computing paradigm inwhich native app-like software modules called sub-apps are hostedby popular mobile apps such as Wechat Alipay Baidu TikTokand Chrome to enrich the host apprsquos functionalities and to forman ldquoall-in-one app ecosystem Sub-apps access system resourcesthrough the host and their functionalities come close to regularmobile apps (taking photos recording voices banking shoppingetc) Less clear however is whether the host app typically a third-party app is capable of securely managing sub-apps and their accessto system resources In this paper we report the first systematicstudy on the resource management in app-in-app systems Ourstudy reveals high-impact security flaws which allow the adversaryto stealthily escalate privilege (eg accessing the camera photogallery microphone etc) or acquire sensitive data (eg locationpasswords of Amazon Google etc) To understand the impactsof those flaws we developed an analysis tool that automaticallyassesses 11 popular app-in-app platforms on both Android and iOSOur results brought to light the prevalence of the security flawsWe further discuss the lessons learned and propose mitigationstrategies

1 INTRODUCTIONA new mobile-computing paradigm dubbed app-in-app is gain-ing popularity in the past years Under this paradigm a mobileapp called host app or host operates a set of sub-apps as its in-appcomponents These sub-apps give users native app like experienceand enriched functionalities (e-commerce banking health travelmanagement food ordering etc) thereby increasing their ldquostick-nessrdquo to the host one does not need to leave the app if it doeseverything [93] They are installed by the users from the hostrsquossub-app store just like Google Play and Apple app store whichfosters an ecosystem around the host app As a prominent exampleit is reported that Wechat the 5th most-used app in the world [27]has one million sub-apps in its sub-app store and 200 million dailysub-app users [5 6] In the meantime sub-app vendors also benefitfrom the hostrsquos large customer base For example YuXiaoge ane-commerce retailer is known to make more than 15 million USDof monthly sales through its sub-app [28] in Wechat which allowsit to access Wechatrsquos one billion users worldwide [25] Anotherexample is Pinduoduo a group-buying platform that has acquired300 million users in three years from its wildly successful Wechatsub-app [25 29] Nowadays this app-in-app paradigm has beensupported by many popular apps such as Wechat Alipay TikTokBaidu Chrome Firefox etc with other major app vendors alsoactively participating in these hostsrsquo ecosystems

lowastCorresponding author

New security risks in the app-in-app paradigm An app-in-app system is under the control of the host app which allocatesresources to sub-apps including system resources it acquires fromthe OS For this purpose the host app acts like the OS eg provid-ing its own APIs (aka sub-app API ) to its sub-apps for resourcesaccess Also like the OS the host app mediates sub-appsrsquo access tosecurity-critical resources (eg GPS location microphone cameraBluetooth photos etc) with its own permission-based access con-trol mechanism Further a sub-apprsquos interactions with the user gothrough the hostrsquos user interface (UI) usually the host creates adedicated (fullscreen) window for each sub-app Even the lifecycleof the sub-app is controlled by the host which decides when itshould be closed if resources are in high demand

What comes with the app-in-app systems are new security risksinherent to the paradigm Prior research on mobile permissionre-delegation attacks [56] (aka confused deputy) shows that aprivileged app (deputy) may leak OS resources to malicious appswith the exposure of its internal functions (through unprotectedpublic interface) either unintentionally or deliberately (when thedeputy opts to not implement protection since it will not bear theconsequences of the attacks) For an app-in-app system howeverthe host is designed to mediate sub-appsrsquo access to sensitive systemresources (eg location microphone camera photos etc) andavoid the re-delegation risks However it is never clear whether athird-party app ndash the host ndash is capable of properly managing theOS resources Indeed this can be very difficult since the host doesnot have full information about resource management at the OSlevel for example the full list of permissions required for resourceaccess has never been made public by mobile OS vendors and isvery hard to obtain [35 46]

Besides resources accessed through system APIs user interface(UI) also needs protection whose improper management opensavenues to phishing attacks [38 49] State-of-the-art defense againstmobile phishing [49 58 96] relies on identifying the foregroundapp if the user knows exactly which app she is interacting with shewould not expose secrets to the unintended one Such protectionhowever does not work under the app-in-app UI model since asub-app is rendered in the hostrsquos window a malicious sub-app canbe hard to differentiate from the host and other sub-apps providingsecurity-critical services (eg e-commerce banking health etc)With the importance of those potential security risks little has beendone so far to understand whether the app-in-app paradigm hasbeen adequately protectedOur study In this paper we report the first systematic securityanalysis on app-in-app systems across Android and iOS Our re-search brought to light the fundamental conflicts between the richnative app-like functionalities expected from the sub-app and thefundamental lack of capabilities for a third-party app ndash the host ndash

1

to securely mediate access to system resources it acquired Moreseriously we found that the functionality- and user-oriented app-in-app ecosystems actually undermine the security protection ofmodern mobile OSes by introducing new risks to their otherwisesecure permission-based resource control

In particular the hosts generally fail to provide sound securitypolicies and effective control to protect sensitive system resourcesfrom unauthorized sub-apps For example Wi-Fi scan is guardedby a dangerous permission (ie location) on Android and an enti-tlement on iOS because this capability can leak user location [37]However Wechat discloses it to sub-apps (on both OSes) withoutproper authorization ndash a serious violation of permission protectionon user location Similar problems are also discovered on otherresources managed by popular host apps which allow the adver-sary through an unauthorized sub-app to stealthily gain access tomicrophone location camera etc in the absence of a user consentFundamentally the problem comes from a knowledge gap the hostdeveloper fundamentally lacks the OS level knowledge and there-fore is not in position to design sound sub-app level permissionpolicies that comply with the OS level resource protection Bridg-ing this knowledge gap presents new challenges to the design ofapp-in-app systems such as misleading developer documentationsand conflicting OS-level security policies between Android and iOSwhich have not been systematically studied before (Section 31)

Also our research shows that an app-in-app system underminesthe protection enforced by a mobile OS by rendering the state-of-the-art UI deception defense ineffective (Section 32) We presentan attack vector that is inherent in the app-in-app UI model whichintroduces realistic security hazards during app-user interactionsExploiting the weakness a malicious sub-app leveraging its UIembedded in its hostrsquos window can strategically impersonate thehost to get sensitive information from the user such as accountpasswords Our research shows that leading host apps such as Safari(on iOS) Chrome (on Android) Wechat and Alipay (on both OSes)are all vulnerable allowing a malicious sub-app to steal the userrsquospasswords for Amazon Google various mobile wallets etc

Further as mainstream app vendors participate in app-in-appparadigm by releasing sub-apps that are functionality-equivalentto their regular mobile apps [29] (eg e-commerce banking travelhealth etc) their (sub-)apps can no longer benefit from the protec-tion offered by modern mobile OSes ndash which have been hardenedafter years of open security research Safeguarding sub-apps to-day mostly relies on individual host vendors who however fail todemonstrate that they are up to this challenge our study showsthat even leading host apps with more than 100 million downloadson Google Play and Apple App Store (eg Wechat Alipay Tiktok)expose new attack surfaces and exploitable weaknesses throughtheir app-in-app supports (Section 3)Impacts To understand the scope and magnitude of the newlydiscovered security risks (called app-in-app flaws or APINA flawsfor short) we analyzed 11 most popular commodity app-in-app plat-forms on both iOS and Android including Wechat Alipay TikTokJinRiTouTiao Chrome Safari etc To enable systematic measure-ment and analysis of these flaws on a large scale we developed ascanner called Apinat (short for App-in-app Threat Scanner) to

report whether a host app contains APINA flaws leveraging a com-bination of test case generation dynamic analysis and lightweightcomputer vision techniques

Running Apinat on the popular platforms we found significantand broad impacts of APINA flaws (Section 43) every single app-in-app system we studied is vulnerable and exploitable with seriousconsequences (Table 4) More specifically APINA flaws allow theadversary (ie either a malicious sub-app or native app) to stealthilyacquire critical system capabilities (eg accessing camera micro-phone connecting to arbitrary Wi-Fi access point connecting thephone to arbitrary Bluetooth device etc) without the user consentand steal usersrsquo private data (eg location account credentials ofAmazon and top banks credit cards mailing address travel logshealth statistics) We reported our findings to all affected vendorswho acknowledged that what we found are real and significantGoogleWechat and Alipay all awarded us through their bug bountyprograms The demos of our attacks are available [12]Contributions The contributions are outlined as followsbullWe conducted the first systematic security analysis on the app-in-app paradigm and discovered a series of unexpected security-critical flaws Our findings bring in new insights into the funda-mental security limitations and challenges in designing this newcomputing platform and ecosystem and are invaluable to the en-hancement of its security protection Also we believe that ourfindings are just a tip of the iceberg and will inspire the follow-upresearch on this directionbullWe developed new techniques to detect APINA flaws and mea-sure their pervasiveness and impacts in 11 real-world app-in-appsystems We demonstrate that the APINA flaws are indeed preva-lent across both Android and iOS with severe security and privacyimplications We release the source code of our tool [12]bullWe discuss mitigation strategies and the lessons learned for build-ing a more secure app-in-app system

2 MOBILE APP-IN-APP SYSTEMSA unique feature of app-in-app paradigm is its sophisticated sub-apps which are designed to provide native-app experience [5] As aninstance Wechat has provided ldquomini-programsrdquo since 2017 whichare essentially sub-apps hosted inside the Wechat app Anotherexample of the app-in-app paradigm in our study is the mobilebrowser supporting standaloneWebApp sinceWebApp is designedto act like regular native app aWeb App is launched from the homescreen and takes a dedicated entire window (separated from thebrowser window) just like a standalone native app ndash as advocatedby Google and Apple [44 78] Using Web App such as Pinterest isnot like interacting with a webpage [4] but more like launchingthe regular Pinterest mobile app except that its whole window iscreated by the browser which is transparent to the users

Table 1 shows 11 popular app-in-app ecosystems we studiedbesides Wechat other host apps are also remarkably popular egAlipay has one billionmonthly active users and 120000 sub-apps [9]Also high-profile retailers app and service providers (eg AmazonMicrosoft Airbnb Samsung HSBC JDcom Starbucks McDon-aldrsquos) actively contribute to the trending app-in-app paradigm byreleasing sub-apps to these hosts

2

Table 1 Popular host apps and the amount of sub-apps avail-able in the host apps

Host App Functionality (of the host itself except sub-apps) Number ofSub-App

Number ofDownloads

WeChat Instant Messaging Social NetworkingSocial Media VoIP Mobile Wallet 1M+ 200M+

AlipayMobile Wallet FinanceInvestment Management

Shopping News Social NetworkingUtility Bill Management Travel

120000+ 1B+

Chrome Web Browser NAdagger 1B+Safari Web Browser NAdagger NAdagger

TikTok Video Sharing Instant MessagingPersonal Blog Game Center NAdagger 500M+

JinRiTouTiao News Feeding live streaming NAdagger 1M+

QQInstant Messaging VideoAudio Chatting

File Transfer Personal BlogGame Center Mobile payment

NAdagger 10M+

Firefox Web Browser NAdagger 100M+Opera Web Browser NAdagger 100M +

Baidu Search engine News Short VideosVoice Recognition Readings NAdagger 230M+

DingTalk Address Book Mobile Office Tool BoxVideo Conference 20000 500K+

Total - 1M+ 26B+

dagger Lack public information

21 ArchitectureTo enable native-app experience for sub-apps each host app pro-vides a set of sub-app APIs for sub-apps to access diverse systemresources (such as the camera microphone Bluetooth NFC Con-tacts photos) Also the sub-app is cross-platform it is typicallydeveloped in script languages (particularly JavaScript [20]) andruns on both the Android and iOS version of its host app Thesefeatures are fulfilled by the host app through a cross-platform run-time called sub-app runtime in this paper Below we summarize itstypical architecture which we learned through reverse engineeringpopular host apps (Table 1)

Figure 1 outlines a typical app-in-app architecture from the per-spective of resource access Specifically the host app consists of asub-app layer where all sub-apps live and a sub-app runtime wherea generic abstraction was provided for system and host app resourceaccess Sub-app runtime bridges sub-app API calls (in JavaScript)into the native layer (in Java on Android and Objective-C [39]or Swift [40] on iOS) of host apps The native layer then enforceshome-grown permissions of the host app (aka sub-app permis-sions) and either accesses host resources or calls correspondingsystem APIs to access system resources

Specifically in the script layer invoking a sub-app API (egconnectWiFi) will trigger an Encapsulation lib which then calls anative function (eg dispatcherdispatch(rsquoconnectWiFirsquo)) tobridge the control flow into native layer Particularly we found twocommon bridge techniques adopted by host apps WebView [79]and React Native [55] To use Webview a host app leverages aWebView API addJavascriptInterface(obj lsquodispatcherrsquo)to expose a native object obj aliased lsquodispatcherrsquo to the script layerits dispatch function is then accessible in script layer as mentionedabove Given each sub-app API the dispatch function invokes thecorresponding native-layer libraries to check sub-app permissionand access resources To use the React Native bridge the majordifference here is how to expose the native object to script layerdispatcher objectrsquos class in the native layer namely Dispatchermust inherit an Interface ReactPackage of React Native framework

Figure 1 A typical app-in-app architecture

dispatcher object is then specified in a configuration file andexposed to the script layer by React Native framework [55]

22 Security Model in Resource Managementbull Sub-app permission The app-in-app system uses the traditionalpermission label assignment model to protect sub-app APIs Inparticular sub-app requests a list of sub-app permissions whichgovern the access to the sub-app APIs If the sub-app APIs accesssensitive system resources (ie protected by dangerous [76] permis-sions on Android or entitlements [17] on iOS1) or sensitive host appresources (non-system resources under host apprsquos control such asuser profile ID gender managed by Wechat) a host app enforcessub-app permissions for calling the sub-app APIs For exampleWechat defines a sub-app permission named scoperecord to pro-tect its sub-app API wxstartRecord which is used to record audiousing the phonersquos microphone Note that host apps typically donot intend to protect less sensitive system resources ie thoseprotected only by Android normal permissions or not protected byOSesbull Isolation Each sub-app has its unique ID assigned by the hostapp Sub-app cannot access resources of the OS host app and othernative apps and sub-apps without going through an authorizedchannel provided by the host Each sub-app has a unique datastorage managed by the host appbull Sub-app vetting Like traditional app stores all sub-app storesin our study also require a sub-app to be reviewed before beingpublished The sub-app vetting process consists of risk assessmentalong with additional criteria to determine whether a sub-appviolates user privacy or data security requirements Examples ofthe security requirements include any sub-app shall not requestor induce users to enter the host apprsquos user ID and passwords [30]and user data collected via a sub-app may not be sold transferredtraded or disclosed [51]

23 Comparison with Existing AppEncapsulation Systems

Similar to the app-in-app system other approaches can also ldquoencap-sulaterdquo an application to run in the execution environment provided1iOS entitlements which confer security permissions and capabilities [41] are strictlyprotected by Apple and must be explicitly declared and vetted [108]

3

Table 2 Comparison with existing app encapsulation sys-tems ( Not Supported Partially Supported Fully Sup-ported)

System Features And

roid

Plug

inFram

ework

App

Sanb

oxing

Brow

serE

xtension

Phon

eGap

App

App

-in-app

Sub-app API ecosystemfor system resource access

dagger dagger

The host has rich functionalitiesapart from hosting

Mandatorysub-app destruction

dagger supported by HTML5 API which is standardized by W3C and thus much easier tomanage than sub-app API

by another app A prominent example is Android Plugin framework(eg Parallel Space [23] DroidPlugin [15] and VirtualApp [26])an app virtualization technology through which a ldquohost app canload other Android apps (called ldquopluginrdquo apps) from their APK filesto run in the hostrsquos own process [111 112] This is done throughwrapping the system APIs for invoking plug-in apps which sharethe hostrsquos UID and permissions during their executions [99 111]Also mobile app sandboxing (eg Boxify [47] and NJAS [50]) isanother way to virtualize apps The idea is to encapsulate untrustedapps in a restricted execution environment within the context ofa trusted sandbox app which provides an emulation layer to ab-stract the underlying OS and interposes all interactions (eg sys-tem calls binder IPC) between the untrusted app and the OS [47]Other app-encapsulation solutions include Browser extension2 (egAdBlock [8] EditThisCookie [16]) where a small program cus-tomizes a web browser with the support of HTML5 (for controlledsystem-resource access) and extension APIs (for browser-resourceaccess) [13] and PhoneGap apps (or HTML5 based mobile apps)where a middleware framework (eg PhoneGap [24] Cordova [11]Ionic [19]) is used to allow the developer to create mobile appsusing web technologies [31 86]

Table 2 compares the above solutions with the app-in-app systemin terms of their security implications As we can see here unlikethe app virtualization based Plugin framework and app sandboxingthe app-in-app platform builds up its own API ecosystem (ie sub-app APIs) for sub-apps to access system resources which entailsnon-trivial efforts to define and maintain its security model such asthe sub-app API permission policies Such policies are standardizedfor HTML5 APIs used by browser extensions [103] but are ad-hocopaque and often inadequate for the sub-app APIs that are muchmore powerful and access more sophisticated system resourcesthan HTML5 thereby opening new attack avenues (see Section 31and Table 7 in Appendix) Furthermore compared with other solu-tions dedicated to application encapsulation the app-in-app host2Browser extension is different from the deprecated Browser Plugin architecture [14]Browser Plugin is generally not considered as an encapsulation system since the pluginsare independent executables and their access to system resources are not encapsulatedby the browser

has its own rich functionalities (eg mobile wallets messagingsee Table 1) which are often shared with the sub-apps For exam-ple e-commerce sub-apps (eg Amazon Pinduoduo) leverage thehostrsquos built-in wallet feature for convenient payment process (seeSection 32) In our study we found that such interactions (betweenthe sub-app and the host app) actually exposes a new attack sur-face (Section 32) Also the upper limit on the number of sub-appsthat can run concurrently on an app-in-app platform is public andfixed (8 in Chrome 5 in Wechat 4 in Alipay) whenever the limitis reached the host has to terminate a sub-app in order to launcha new one This feature which does not exist in other systemscan be abused for deception attack as discovered in our research(Section 33)

24 Adversary ModelWe assume the host app is benign which aims to provide a secureenvironment to run sub-apps On the victimrsquos Android or iOS de-vices where at least one app-in-app system is used we consideran adversary with his malicious app3 or sub-app installed Notethat none of our attacks requires the victim to install both InSection 3 we show that such malware can successfully pass thevetting of popular sub-app stores Google Play third-party appstores etc The malware sample does not have system privilege andin some of our attacks may need to ask for a set of common permis-sions from the users (eg Androidrsquos READ_EXTERNAL_STORAGE andWRITE_EXTERNAL_STORAGE) depending on specific attacks Suchpermissions are extensively requested by popular apps such asFacebook Gmail and Pinterest Therefore we believe that claimingthem by the malicious app will not arouse obvious suspicion

3 DESIGN CHALLENGES AND PITFALLSIn this section we report our security analysis on resource manage-ment in app-in-app systems Our research shows that all app-in-appsystems we studied including Wechat Alipay TikTok ChromeSafari etc are subject to various APINA flaws leading to seri-ous exposure of system resources and new deception attacks Morespecifically the security analysis has been systematically performedby assessing two general categories of resources system resourcesaccessible through system APIs and user interfaces For each re-source we looked at the security policies that should be in placethe mechanism that enforces the policies and the user interactionswith security implications

31 System Resource ExposureSub-apps access system resources through sub-appAPIs (Section 21)However for the host as a third-party app constructing sound sub-app API permission policies that govern system resources entailschallenges that are unexpected before As a result sensitive systemresources are often unwittingly exposed to unauthorized sub-appsEscaped sub-app API Sub-app APIs are protected by sub-apppermissions which are supposed to be consistent with the permis-sions required by the OS when using the relevant system APIs theywrap For example since the OS requires permissions to use its

3In this paper we use the term app and native app interchangeably Also although thehost app is a native app itself the term app or native app in this paper always refers toan app that is not a host app for ease of presentation

4

Figure 2 Misleading Android documentation

audio recording APIs (RECORD_AUDIO [72] permission on Androidand Microphone Usage [42] entitlement on iOS) the sub-app APIto record audio (eg wxstartRecord in Wechat) should also beprotected by a sub-app permission (eg by sub-app permissionscoperecord in Wechat) However in our study we found theinconsistency in permission requirement between sub-app API andsystem API indicating that the host fails to create the correct per-mission policies that govern sub-app API for system resource accessAs a result certain sub-app APIs that wrap permission-protectedsystem APIs are completely open to any sub-apps without requir-ing a sub-app permission exposing sensitive system resources Wename such unprotected sub-app API escaped sub-app API and theproblem System Resource Exposure

An example discovered in our research is the unprotectedWechatsub-app API wxgetWifiList that performs WiFi scan a capa-bility protected by the underlying OSes against user location leakeg through an entitlement Hotspot Helper on iOS and danger-ous level location permissions (ACCESS_COARSE_LOCATION andACCESS_FINE_LOCATION) on Android This exposes the WiFi scancapability to sub-apps leaking out user location to them Notethat a high-profile host app (eg Wechat) is typically granted thelocation permission and many other permissions due to its richfunctionalities (see Table 9 in Appendix) As a result through thedelegation the host makes to the sub-app escaped sub-app APIeffectively opens a door for the adversary to gain unauthorized ac-cess to system resources In addition to wxgetWifiList we foundmany other escaped APIs in popular app-in-app systems affectingdiverse sensitive resources across iOS and Android (Section 43)

Looking into the possible root causes we found that it is verychallenging for an app-in-app system to soundly define sub-appAPI permission policies that comply with the OSes in governing sys-tem resources due to the incomplete knowledge about permissionchecks that happen at related system APIs Specifically official API-permission maps for both Android and iOS have never been madepublic Although several prior attempts [35 45 46 56] have beenmade to automatically map Android APIs to their required permis-sions we found that the prior results are incomplete (Section 43)and highly likely to introduce escaped sub-app APIs if they are usedto design a sub-app permission system Consider the above exam-ple of WiFi scan recent results [35 46] (on Android API level 25)report that a related Android API WifiManagergetScanResultsrequires just a normal permission ACCESS_WIFI_STATE but failto mention that dangerous permission location is also required(required since Android API level 23 [80]) Further Section 43 re-ports more escaped sub-app APIs possibly caused by the incompleteAPI-permission maps

Such API-permission mapping information has also not beenwell recorded by the developer documentation We found that suchdocumentation can be misleading or confusing Again let us useWi-Fi scan as an example as shown in Figure 2 the Android

documentation [75] may introduce the misconception that declar-ing ManifestpermissionCHANGE_WIFI_STATE is sufficient forWi-Fi scan Similar misguidance also appears on the Android doc-umentation for Bluetooth scan etc and has likely caused otherescaped sub-app APIs we found (Section 43)

Another observation of our study is that since sub-app APIis designed to be cross-platform (Section 21) the effort to buildsub-app API permission policies that comply with all OSes hasbeen complicated by the inconsistency between Android and iOSin resource protection Consider Bluetooth scan as an examplethe Android API BluetoothLeScannerstartScan requires thedangerous location permission while iOS does not Such a dis-crepancy likely causes confusion in app-in-app design which istypically built for both OSes with uniform security policies Whenthis happens we found that the app-in-app designer tends to leavethe related sub-app API unprotected For example the sub-app APIsfor Bluetooth scan are not protected in multiple host apps (egwxgetBluetoothDevices in Wechat) Actually the difference inpolicy-level protection could result from an additional securityguard put in place by the OS which is unaware to the app-in-appdesigner For example combining together Signal Strength andDevice ID of nearby Bluetooth devices reveals geo-locations [37]On Android the pair is returned together by the above Bluetoothscan API BluetoothLeScannerstartScan which thus needs apermission check on iOS however the pair has been partially ob-fuscated (Device ID is randomized) and is thus unprotected Wesuspect that the inconsistency as observed on capabilitiesresourcesWi-Fi scan Wi-Fi connect iBeacon etc is likely responsiblefor other escaped sub-app APIs we discovered (see Section 43)Discussion Android 60 (API level 23) started to use a runtimepermission model a user grants permissions at the apprsquos runtimewhen permissions are requested (eg when the app launches orwhen the user accesses a specific feature) [73] In this scenariowhen an escaped sub-app API tries to silently access a resourcethe host may have not been granted a permission to access thatresource thus a permission will be explicitly required Howeverthe OSrsquo permission granting window will show to the user thatit is the host app who requests the permission not the sub-appThis misleading request may lead to the wrongly inherited trustassociated with the hosts and make users grant the permissioninappropriately This is also the case on iOS when a permissionwindow pops up to confirm the hostrsquos access to a resource

Furthermore Table 9 in Appendix lists all Android dangerouspermissions and iOS entitlements requested by the vulnerable hostsright after launching It shows that the hosts proactively requestnecessary permissionsentitlements even before accessing any spe-cific features due to usability consideration [92] Those capabilitiesof the hosts will always be stealthily delegated to the sub-app viaescaped sub-app APIs which present serious risksAttacks and vendor acknowledgements We implemented anattack sub-app which ran inWechat v673 to steal userrsquos location onboth Android and iOS The attack sub-app utilized Wechat escapedsub-app API wxgetWifiList to perform Wi-Fi scan and snifferthe surrounding Wi-Fi access points The scan results included sen-sitive information ie BSSID Signal Strength and Device ID ofnearby Wi-Fi access points which enabled to infer the geolocation

5

(a) Real Prominent UI (b) Fake Prominent UI

Figure 3 Safarirsquos Prominent UI confusion on iOS

of a user [37] This attack sub-app successfully passed the vettingof Wechat sub-app store and ran on both iOS and Android versionsof Wechat Note that our attack sub-app has less than 200 lines ofcode which indicates that it is cost-effective for the adversary todevelop APINA flaws malware in the wild Besides we successfullybuilt attack sub-apps in other host apps eg Alipay DingTalk etcand reported the problems to all affected host-app vendors Theyall acknowledged the problem in particular Wechat and Alipayawarded us through bug bounty programs for this flaw

32 Sub-window DeceptionAnother unique app-in-app feature is the functionality-level inter-actions between the host and sub-app For this need the host doesnot fully isolate itself from sub-apps which unwittingly introducesnew attack surfaces and high spoofing risks against host-app UIBrowsersrsquo Prominent UI confusion To bring a native app-likeexperience Safari on iOS and Chrome on Android open each sub-app (ie Web App Progressive Web App or PWA) in an entirededicated window separate from the browser window just like anative app [44 78] ndash without any browser UI such as the addressbar Web App is programmed with JavaScript and HTML but mustmeet certain standards [68] With user confirmation the browsercan install a Web App to the phonersquos home screen (through anAPK [69] package created by Chrome or a Web Clip [44] createdby Safari) Such Web App takes the full screen if ldquostandalone orldquofullscreen is specified in its manifest file EachWeb App is clearlyassociated with specific Web domain when installed When the usernavigates to out-of-scope URL (ie of different origin) in a WebApp the browser displays a Prominent UI ndash a banner at the top ofthe screen (Figure 3a) showing the origin and secure connectionstatus ndash due to the lack of address bar According to Web Appdocumentation [67] users rely on such Prominent UI to be awarewhen they navigate out of scope an important security notice

Based on a study [57] mobile phishing attacks tend to happenwhen users become accustomed to familiar repeated contexts Morespecifically if users frequently encounter legitimate context theywill become conditioned to reflexively respond to it Here the cur-rent design of Web App conditions users to see the Prominent UI inout-of-scope navigation which we found poses a spoofable context

(a) Authentic wallet UI (b) Bogus wallet UI

Figure 4 Mobile wallet UI confusion

Specifically Web App is designed to embrace out-of-scope brows-ing [104] and let users freely navigate to other Web domains forservices such as login through FacebookGoogle (aka SSO [107])payment through PayPal etc The problem is that when a victimuser navigates out of scope eg to Facebook login page a mali-cious Web App can actually navigate to an in-scope phishing pageimitating Facebook showing a bogus Prominent UI (as if shown bythe browser) to misleadingly inform the victim that she is on a realFacebook domain (Figure 3b) In this way the malicious Web Appcan collect victim usersrsquo secrets such as Facebook passwords

We call this problem Sub-window Deception ndash sub-window meanspart of a window Prior phishing attacks in browsers exploredhow a webpage can go full screen and spoof the address bar [12] as another instance of mobile browser UI attacks our attackcomplements the prior understanding by exploiting ProminentUI ndash the counterpart of address bar in the context of native app-like Web App Note that address bar differs from Prominent UIin design based on the Web specification [106] browsers ldquoshouldprovide a means of exiting fullscreen that always works and advertisethis to the user [106] so users can see the real address bar whenthey want (although browsers may not implement this protectionproperly [89]) Web App users however lack practical mechanismsto verify the authenticity of Prominent UI today This attack appliesto general Web App on both iOS and Android we reported it toW3C4 Apple Google Firefox and Opera which all acknowledgedthe importance of the problemMobile Wallet UI confusion Wechat and Alipay both featuremobile wallets which can be leveraged by e-commerce sub-appsto provide users a convenient payment process Amazon sub-appfor example after a user clicks its ldquocheckout with Wechat wal-letrdquo button will invoke a sub-app API (eg wxrequestPaymentin Wechat) to trigger the hostrsquos wallet the host then reclaims acentral portion of the screen from the sub-app to show its walletUI (highlighed in Figure 4a) for the user to enter her wallet pass-word and finish the payment Such a context can condition usersto reflexively provide wallet passwords at checkout and thereforepresents a practical spoofing target Specifically when a victim userclicks the ldquocheck out button in a malicious e-commerce sub-app itcan show a bogus wallet UI (Figure 4b) to collect the userrsquos walletpassword instead of invoking the real wallet

4We do not provide the link to our report for anonymization purpose

6

(a) Real sub-app task (b) Bogus sub-app task

Figure 5 Dedicated task for every sub-app in Recents screen

Up to our knowledge state-of-the-art mobile anti-phishing tech-niques cannot identify our attacks for example [49 58 96] mainlyrely on identifying the app of the whole foreground window so theuser would not expose secrets to the unintended app this cannotidentify a sub-window at the sub-app level ndash whether it belongs toa sub-app or the host app

Our study shows that a bogus sub-window presents a practicalattack vector in app-in-app since a window portion (sub-window)can be used by both the sub- or host- app in accustomed contextswithout differentiation through clear identification From a broadersense we believe the spoofing risk is also high if the OS showsits pop-up atop an app (so malicious app can show a bogus onewhen the OS does not) however in sharp contrast such pop-upis not sub-window (but whole window) and known anti-phishingtechniques (eg [49]) to identify (the owner of) the whole windowcan defeat itAttacks and vendor acknowledgementsWe implemented PoCattacks in Safari on iOS Chrome on Android and Wechat on bothOSes in Safari and Chrome our malicious Web App impersonatesProminent UI to spoof Facebook login page in Wechat our mali-cious sub-app mimics the wallet UI to steal wallet password (seevideo demo online [12]) Our malicious sub-app passed the vettingof Wechatrsquos sub-app store Note that Web App does not have appstores and can be installed after visiting its URL In addition wereported the problems to all affected host vendors who all acknowl-edged that the threats were practical and severe Wechat and Alipayawarded us through their bug bounty programs

33 Sub-app Lifecycle HijackingAs app vendors follow the app-in-app trend by releasing sub-appsit is unclear whether their users remain equally protected as beforeUnfortunately our study shows that even highly credible host appscannot fully eliminate new attack surfaces incurred by app-in-appRecents screen takeover The Recents screen (aka recent task listor recent apps) [64] is a system-owned UI of Android to list recentlyaccessed task (Figure 5a) In particular each launched native appwill have a task in Recents screen similarly a host app creates aseparate task for every launched sub-app which appears in Recentsscreen Limited by the OS each host app can only create a fixednumber of tasks in Recents screen pre-specified as activities inits manifest file In our research we found that host apps all specify

a small magic number (eg 8 in Chrome 5 in Wechat 4 in Alipay3 in JinRiTouTiao) for the task limit

When an additional sub-app will be opened after the task limitis reached the host app silently executes a mandatory recyclingprocess closing the first opened sub-app to recycle its task forlaunching the new one The recycling process is transparent tousers for the possible purpose of not interrupting the user experi-ence Such a mandatory sub-app recycling mechanism introducesa new risk once the recycling is traceable by a malicious appie the adversary knows which sub-app has been recycled and atwhat time it can stealthily insert a phishing task into the Recentsscreen to imitate the silently recycled sub-app For this purposethe adversary needs to acquire the information about a hostrsquos taskrecycling which turns out to be feasible due to the presence ofvarious information-leak avenues that can be hard to eliminate Inour study we found a side channel that enables recycling track-ing in multiple host apps In particular possibly due to the richfunctionalities of sub-apps which require resource files (eg userdata logs icon and image texture) the host app creates a folderin Android external storage [18] to cache sub-app resources Suchexternal storage can be monitored by an Android native app totrack which sub-app is launched and at what time (by monitoringsub-app icon which will be downloaded at launch see PoC attackbelow) Thereby once the number of launched sub-apps reachesthe hostrsquos task limit the sub-app to recycle can be inferred Hencea malicious native app can insert a bogus task in Recents screento mimic the recycled sub-app at this point the bogus task is theonly one in Recents screen that represents the target sub-app thatrsquosspoofed (Figure 5b)

This attack is a kind of mobile task hijacking attacks [52 97]Regarding its root cause the mandatory sub-app recycling opens anew attack surface for app-in-app systems since it makes it possiblefor malicious apps to track a sub-apprsquos lifecycle termination Notethat the attack surface becomes exploitable in the presence of sidechannels eg external storage which itself is a relatively trivialbug Other side channels could also be used for the attack once theyarise (see discussion below) Eliminating this attack surface maynot be trivial in practice since the maximum task number of a hostin Recents screen is not dynamically scalable (statically specifiedin manifest) limited by the OS Although the very recent Androidsupports dynamic task no host app we studied (Table 3) adoptedit possibly for the purpose of supporting older Android versionsgiven the notorious Android version fragmentation [74]Attacks and vendor acknowledgementsWe implemented PoCattacks on Alipay andWechat which cache sub-app resources in theexternal storage and enable recycling tracking Specifically Alipaystores the caches at sdcardalipaymultimedia When a sub-app such as Amazon is launched its icon will be downloaded toit if not already there Our malicious Android app with a commonpermission WRITE_EXTERNAL_STORAGE can remove cached iconsperiodically andmonitor when they reappear to knowwhat specificsub-app is launched and at what time In our attack of Alipay oncethe malicious app infers that five sub-apps have been launched(submit-app task limit of Alipay is 4) it will insert a bogus task inRecents screen to mimic the first sub-app which is recycled Oncethe victim user enters the spoofing task through Recents screenit can lure the user to leak secrets such as passwords Note that

7

our malware successfully passed the vetting of popular app storesincluding Google Play We reported the problem (demo online [12])to Wechat and Alipay which both acknowledged the problem andawarded us through bug bountiesDiscussion on other side channels As mentioned earlier otherside channels once found can also be used for impersonating therecycled sub-app Prior research [113] shows that the operationsof Android apps can be easily tracked through the Android pro-cess file system (procfs) Although Android has been continuouslybeefing up its privacy protection until Android 9 still some globalstatistics under procfs are exposed Particularly we found that theTCP connection status under procnettcp can be accessed byany app without permission on Android 9 and below From the filewe can see the IP addresses of all TCP connections on an Androidphone which are labeled by randomly assigned User IDs Interest-ingly we found that an invoked sub-app makes a sequence of TCPconnections and the endpoints of the connections (domains) canuniquely fingerprint its initiation eg Amazon sub-app connects to4 unique endpoints with 8 consecutive HTTPS requests in the firstfew seconds after it is launched In our research we sampled 8 high-profile sub-apps in Wechat and identified the sequences of theircommunication endpoints as observed when they are triggered (seeTable 8 in Appendix) Through this side channel a malicious nativeapp is able to infer the launch of a specific sub-app so it can waituntil it is terminated for task recycling (eg after 5 other sub-appsare found to be started through the procfs when the magic numberis 5) to create a task to impersonate the sub-app Note that the mali-cious app can resolve the endpoint domains from IP addresses usingAndroid API InetaddressgetCanonicalHostName [81] withoutrequiring any permission which was implemented and confirmedin our study

Until April 2020 84 of the Android devices are still runningAndroid 9 or earlier versions [33] and therefore are vulnerable toour attack On Android 10 which was released in September 2019the procfs used in our attack has been closed by SEAndroid [70 83]and thus the attack is ineffective Seeking a more powerful attackavenue is left to the future research

4 APINA FLAWS IN THEWILDIn this section we report a measurement study that reveals thescope and magnitude of APINA flaws in the wild The study ismade possible by an automatic analysis tool we built called Apinat(short for App-in-app Threat Scanner) which helped us identifyapp-in-app hosts that are susceptible to APINA flaws

41 Identifying System Resource ExposureDesign Apinat aims to find System Resource Exposure flaws byidentifying escaped sub-app API The idea is to find sub-app APIthat is unprotected by sub-app permission while its correspondingsystem API is permission-protected A naive idea is to call eachsub-app API and find out whether the OS checks the permissions ofthe host app eg by looking at permission pop-ups or system logsThis does not work because the permission asked by the OS can berelated to the host apprsquos own rich functionalities not the sub-appAPI To systematically find escaped sub-app API our methodologytracks the system API invocations triggered by a sub-app API via

a dynamic analysis (Step S1 S2) and then utilizes system API-permission maps to derive required permissions of the sub-appAPI (Step S3) which will be compared to the corresponding sub-app permission If a sub-app API is not protected by any sub-apppermission while its corresponding system APIs are guarded by theAndroid dangerous permissions5 or iOS entitlements an escapedsub-app API is found (Step S4) Following we describe how thisdesign works and how it was implemented in our research onAndroid Since sub-app APIs are cross-platform we were able toextend all the findings made by our technique from Android to iOSby simply validating these findings on the Apple platformStep S1 generating test cases To conduct a dynamic analysis wefirst need to generate test cases with valid arguments to invoke eachsub-app API without triggering exceptions For each API we targetthat at least one invocation is successful The argument types ofJavaScript APIs are either primitive or Object [21] To produce testcases for primitive arguments we leveraged Mozillarsquos funfuzz [22]a JavaScript toolkit ForObject arguments we recursively generatedtest cases leveraging funfuzz because an Object includes keyvaluepairs its key is primitive and the value is either primitive or ObjectAll test cases were then used by a sub-app we built to invoke sub-app APIs If all test cases for an API failed we manually inspectedthe API to address the issues such as formatted inputs (eg UUID)stateful calls (an API needs to be invoked before another) etcStep S2 tracking system API As mentioned in Section 21 theexecution of a sub-app API enters the native layer of the hostthrough a dispatcherdispatch function and then its controlflow reaches system APIs (Figure 1) Therefore Step S2 first iden-tifies the dispatcherdispatch function in the host apprsquos nativelayer then tracks its call graph to find the system APIs triggeredby the sub-app API call as elaborated below

(1) Find the dispatcherdispatch function in the native layer Asmentioned earlier Webview and React Native are bridge techniquesto expose dispatcherdispatch to JavaScript layer Note thatthough the object alias (dispatcher) and function name (dispatch)vary across host apps they can be obtained by inspecting functioninvocations in Encapsulation lib (Figure 1) which is a preprocess-ing step in our study Note that the Encapsulation lib usually canbe found in JavaScript files packaged in the host app (eg underassets folder) So all we need is to identify the dispatcher objectin the native layer based on the obtained alias

To this end S2 implements an Xposed [7] (a framework to in-strument Android app execution) module to hook Webview APIaddJavascriptInterface(obj alias) (that exposes Java objectto JavaScript through an alias) and inspect its arguments at run-time if the ldquoalias argumentrsquos value matches the dispatcher aliasdiscovered the ldquoobj is the dispatcher object that we are lookingfor The analysis of React Native bridge is slightly different wehook its API createNativeModules to get its Java objects exposedto JavaScript our Xposed module then calls each exposed objectrsquosgetNamemethod to get its alias ndash if this alias matches the dispatcheralias discovered the object is what we are looking for

5Host apps are typically third-party apps that cannot call privileged system APIs pro-tected by ldquosignature or ldquosignatureOrSystem level permissions [65] or they typicallydo not delegate the access to such APIs through sub-app APIs

8

(2) Track execution of the dispatcherdispatch function Our toolthen tracks the call graph of the dispatch function to find the calledsystem APIs ndash which are called to fulfill the sub-app API call Specif-ically our Xposed module hooks dispatch function and AndroidAPI and inspects their respective call stack traces However wefound that dispatchrsquos thread sometimes does not call Android APIsdirectly it triggers additional thread to call Android APIs likelyfor not to block the dispatch thread This introduces a challengeXposed outputs the above two stack traces by threads ndash one stacktrace with Android API call and the other with dispatch functioncall ndash but cannot correlate two threads if one triggers the otherTherefore we still cannot confirm that the Android APIs are in-voked due to dispatch Hence we developed techniques to deal withthe multi-threading challenge

In our study we found that Handler a typical multi-threadingmechanism of Android is commonly used by dispatchrsquos thread totrigger a new thread Thus we implemented our own thread corre-lation technique based on the Handler mechanism in our Xposedmodule More specifically in the Handlermechanism a triggeringthread that holds a handler instance will submit a runnable to amessage queue via calling the handlerpost(runnable) methodHere the runnable is an instance of Java Runnable [3] with codein its run() method Then the runnable is taken out of the queueby another thread which we name as the handler thread andgets executed in the handler thread Hence as checked in ourXposed module if the executed runnable in a handler thread isthe same instance with one submitted by a triggering thread thenwe correlate the two threads Through such techniques we foundAndroid APIs are indeed called in such handler thread followingthe dispatch threadrsquos triggering ndash this confirms the Android APIcall caused by the dispatcherdispatch functionStep S3 synthesizingAPI-permissionmapping As mentionedin Section 31 system API-permission mappings are incompletewhich can lead to escaped sub-app APIs How to derive a completemapping remains an open question in system security researchand program analysis Here our idea is to supplement recent map-pings [35 46] leveraging documentation analysis we automaticallyextract explicitly declared permissions for system APIs in the devel-oper manuals assuming that explicit specification at least reflectsintended protection of the OS with rare faults Note that certainportion of the documentation (Figure 2) can be misleading to hu-man readers due to incomplete presentation but we observed thatan exhaustive machine-based search on the whole corpus of mobileOSes (eg the entire documentation for all 2497 SDK classes of An-droid API level 27) can help us derive a significantly more completemapping than state-of-the-art mappings [35 46] (see evaluationbelow) For instance after a full scan of Android WifiManager man-ual [75] we were able to flag ACCESS_FINE_LOCATION as a requiredpermission for multiple Wi-Fi scan related APIs (see Figure 8 inAppendix) which has never been included in state-of-the-art map-pings [35 46]

In our implementation we developed a Web crawler to fetchall manuals from Android developer portal [62] and extractedthe description for each public API From the description we ex-tracted the declared permissions based on a few key observations

if the description of an API does not contain a ldquopermission key-word it is very likely that the API does not explicitly requirepermissions otherwise its description usually includes a ldquoper-mission keyword and the exact permission string constants de-fined in Android class androidManifestpermission [77] suchas ACCESS_FINE_LOCATION Based on such observation we per-formed a light-weight string matching to find explicit permissionrequirement of Android APIs (we discuss the sophisticated NLP-based direction in Section 5)

Step S3 also derives a sub-app API-permission map given itsrelatively small size (ie 50 to 172 sub-app APIs in each host com-pared to 35847 public Android APIs found by our Web crawler)we extracted the map by searching ldquopermission related keywordsin sub-app developer manual and manually confirmed the resultStep S4 reporting flaws S4 reports an escaped sub-app API if itis not protected by sub-app permission while its correspondingAndroid API(s) is protected by dangerous permission(s) That is aSystem Resource Exposure flaw is found

For iOS however a comprehensive detection is much more dif-ficult than Android especially because obtaining a system API-entitlement mapping is much more challenging First we are notaware of any work that has produced a mapping on iOS for us tostart with Second we observed that iOS documentation is not asprecise as Android in this regard which describes required enti-tlements for iOS classes but not for individual system API To stillhelp us understand the impact of escaped sub-app API on iOS weextended our findings of escaped sub-app API from Android to iOSif its corresponding iOS API requires an entitlement it is consideredto affect iOS as well This was done by manually searching corre-sponding iOS API for a given escaped sub-app API and checkingwhether any entitlement is asked when the iOS API is invoked inan iOS app we builtEvaluation We evaluated the effectiveness and performance of ouranalysis tool (source code released [12]) on a Google Pixel 2 phoneand iPhone 8 against 11 host apps The evaluation was performedon three Android versions (81 9 10 corresponding to API level 2728 29) and two iOS versions (12 134)bullOverall detection resultsApinat found 39 System Resource Exposureflaws all of them affect Android 81 9 and 10 13 of them affectiOS 12 and 134 We manually validated that all discovered flawsare true in two steps (1) confirming that the sub-app API requiresno sub-app permission through a testing sub-app (2) confirmingthat the corresponding system API(s) has permission protectionthrough a testing native app on Android and iOSbull Evaluating individual steps Step S1 generated test cases for all927 sub-app APIs under test in less than one hour All sub-app APIswere successfully invoked at least once without exception on eachAndroid version In this experiment we did not measure the hostrsquoscode coverage because the host includes implementation of its ownrich functionalities that are unrelated to sub-app API Thus it is notmeaningful to compute the percentage of covered host app code

Step S2 took less than 30 seconds for each sub-app API to reportits corresponding system APIs on each Android version The num-ber of system APIs (protected by dangerous permissions) hookedby S2 is 111 129 145 on the three Android versions respectivelyTo evaluate the correctness of our thread correlation we created

9

a test app which triggered new threads leveraging the Handlermechanism Our test showed that our tool correctly correlated thetriggering and triggered threads on each Android version

Step S3 produced the API-permission mapping including 94public APIs protected by dangerous permissions at API level 27103 APIs at API level 28 and 119 at API level 29 This step took ourapproach three hours to process the descriptions of 35847 42302and 44323 public APIs on the three API versions respectively Tovalidate the correctness of the mapping we constructed a test app toinvoke all the APIs and verify the required permissions at runtimeFor all three Android versions our permission mapping of all except6 APIs are correct Specifically the mapping of 92 APIs out of 94is correct (979 precision) at the API level 27 The two false casesare unprotected APIs hasPermission and requestPermission inclass UsbManager [66] At API 28 the mapping shows a precisionof 971 with one new false case than what was found on API 27(3 cases in total) API 29 shows a precision of 95 with three newcases than API 28 (6 cases in total) Figure 6 and 7 in Appendixlist all six false cases Their descriptions are more complex and weenvision that a natural language processing (NLP) based approachcan further improve our precision (see discussion in Section 5)

To evaluate the coverage of our documentation analysis toolwe randomly selected the documentation of 153 classes 641 APIs(out of 2164 classes) and then manually reviewed and identified52 API-permission mappings as the ground truth Running on theaforementioned documentation our analysis tool shows a precisionof 100 and a recall of 100 to identify API-permission mappingfrom the documentation

We also compared the completeness of our mapping with recentmappings [35 46] They collectively reported 50 public AndroidAPIs that require dangerous permissions on API level 25 (we werenot able to get results of newer Android from the authors) as asignificant improvement our tool was able to find 91 APIs (82more) that require dangerous permissions on the same API versionDiscussion Apinat may not find all escaped sub-app APIs In par-ticular Step S3 cannot derive a complete mapping if the documen-tation is incomplete [56] or too sophisticated to process Apinatonly looks for system resource exposure by public system APIs andundocumented system APIs used by host apps may also lead to theflaw but remain undetected Also Apinat falls short in analyzingobfuscated host apps eg that uses dynamic code loading andimplementations in CC++ Hence Apinat did not scan Web AppAPIs due to the extensive CC++ implementation in browsers Inaddition incorrect documentation (which we assume is rare andindeed our tool did not report any false escaped sub-app API ) mightlead to false alarms if not properly validated

42 Finding UI Deception FlawsDesign To find out the opportunities for Sub-window Deception(Section 32) in a host app Apinat looks for the apprsquos sensitive sub-windows which can be the targets of the attack As discovered inthe wallet UI confusion (Figure 4b) the hostrsquos sub-windows thatare likely to show up in the presence of a sub-app tends to be thosethat can be triggered through sub-app APIs If such a sub-windowalso contains sensitive information our approach then reports it asa potential target for Sub-window Deception

Implementation To detect such sub-windows Apinat monitorsthe change of the host UI in response to each sub-app API callto identify the sub-window triggered by the API call and thendetermines whether it carries sensitive content Specifically ourapproach first constructs a testing sub-app with an empty UI Thenit runs the sub-app API test cases in Section 41 to call each sub-appAPI through the testing sub-app and further inspects the UI screen-shots before and after the call for changes This is done through apixel-to-pixel comparison of two screenshots To capture the screen-shots we developed a screen projection service on Android usingthe Media Projection [63] API Also our screenshot compari-son was implemented using the OpenCV cv2absdiff API [85]For each sub-window identified our approach continues to findthose associated with sensitive information For this purpose itextracts strings from sub-window screenshots using the onlineOCR service [34] From the strings Apinat further utilizes a list of121 sensitive data keywords and the keyword pair list from recentresearch [91] to recognize those carrying sensitive content Notethat like a mobile OS an app-in-app system also provides a set ofsub-app APIs for sub-apps to dynamically generate UI componentssuch as wxcreateCanvasContextdraw() in Wechat To controlfalse positives Apinat omits such sub-app APIs based on the APIcategory in the sub-app API documentation As a result Apinat suc-cessfully detected 6 Sub-window Deception flaws (Section 43) ForiOS we got the same result since sub-app APIs are across-platformthe one triggers a sub-window on one OS also does that on theother (see Section 2)Evaluation Apinat detected 5 sub-app APIs associated with the UIdeception flaw we manually confirmed that all of them trigger sub-windows with sensitive information Also all of them affect bothAndroid (version 81 9 10) and iOS (version 12 134) Performance-wise the screenshot comparison and OCR analysis together tookless than 5 seconds on a desktop with Intel i5 27 GHz CPU and 8GB memoryDiscussion Soundly detecting whether a host app is susceptibleto Sub-app Lifecycle Hijacking (Section 33) is difficult especiallybecause it entails detection of side-channel information leakagewhich can happen in many ways and is hard to capture in generalTo measure a lower bound of the pervasiveness of the problemwe checked whether the hosts in our study (Table 1) had the sameinformation leakage and lifecycle design as reported in Section 33As a result 3 host apps on Android (Wechat Alipay DingTalk) aresusceptible which were all manually confirmed to be exploitable

43 Measurement of ImpactFlaw landscape With the help of Apinat we analyzed 11 highlypopular host apps (Table 1) on Android and iOS and found theyare all vulnerable to APINA flaws (Table 3) Altogether we found 52APINA flaws including 39 System Resource Exposure 10 Sub-windowDeception and 3 hosts vulnerable to Sub-app Lifecycle Hijacking

For System Resource Exposure in total we uncover 39 escaped sub-app APIs associated with 5 categories of exposed system resources4 Android dangerous permissions and 6 iOS entitlements Table 5shows the flaw number for each category of resources (the secondcolumn) and illustrates 8 escaped sub-app APIs with correspondingAndroid permission(s) and iOS entitlement(s) ignored to enforce

10

Table 3 Eleven vulnerable host apps on Android and iOS(A Alipay B Baidu C Chrome D DingTalk F FirefoxJJinRiTouTiao O Opera Q QQ S Safari T TikTok WWechat) NA denotes the flaw does not apply to the OS

Type of APINA Flaw iOS AndroidSystem Resource Exposure A D J Q T W A D J Q T WSub-window Deception A B D W S Q A B C D F W O QSub-app Lifecycle Hijacking NA A W Q

on them All 39 escaped sub-app APIs are listed in our releaseddataset [12] Also Table 6 illustrates 6 Sub-window Deception in non-browser hosts additionally all four browsers we studied (ChromeSafari Firefox Opera) are susceptible to the same Prominent UIattackResource comparison between Android and iOS Althoughfinding the full API-entitlement mapping for iOS is hard we ob-served a few differences between Android and iOS in system re-source protectionbull iOS is less affected than Android Out of 39 escaped sub-app APIs13 are related to iOS which appears to be less affected and harderto be exploited There are two reasons behind the observation asdiscovered in our study First certain iOS APIs return less informa-tion than its Android counterparts (ie those related to Bluetoothsee Section 31) and thus is less susceptible to privacy risk (locationleakage) Hence all 27 Bluetooth related escaped sub-app APIs donot affect iOS (see Table 5) Second WiFi related escaped sub-appAPIs (see Table 5) are much harder to exploit on iOS since Applehas extra protection besides entitlement Specifically right beforethe programmaticWiFi operation an iOS appmust obtain the userrsquosexplicit consent the app must instruct the user to manually openthe WiFi setting page in the Settings app and then return to theiOS app [43] ndash an indicator of user intention for the app to operateWiFibull iOS entitlement fails to communicate risks to the user On Androidwhen the permission ACCESS_FINE_LOCATION is used for protect-ing the operation Wi-Fi scan it indicates a risk that the WiFioperation may leak location a highly private data On iOS how-ever the entitlement for Wi-Fi scan ie Hotspot Helper failsto communicate such a risk Actually to get this entitlement for aniOS app app developers must file a special written request by justi-fying that the app does not have malicious intention Apple reviewsthe request internally and possibly assesses the risks of locationleakage behind the scene However the name of this entitlementand its documentation we could find does not show that Wi-Fiscan needs location protection on iOS This may have been oneof the factors leading to escaped sub-app API wxgetWifiList (seeTable 5) which performs Wi-Fi scan without protectionAttack consequences The system resources exposed by escapedsub-app API and the risks can be identified from the API namesand the permissions they violate (see Table 5) For example unautho-rized sub-apps can use escaped sub-appAPI wxgetRecorderManag-er to record audio (violating Androidrsquos RECORD_AUDIO permission)We summarize the attack consequences in Table 4 Further Sub-window Deception leads to phishing on popular Web services (egFacebook) mobile wallets and sensitive host UIs For exampleWechat has a UI triggered by sub-app API (wxaddPhoneContact)

Table 4 Examples of APINA attack consequences

Flaw Type Consequences (what the adversary is able to do)

SystemResourceExposure

record audio operate camerainfer victimsrsquo geo-location (thus track users)

connect victimrsquos device to arbitrary Wi-Fi (thus manipulatenetwork traffic perform man-in-the-middle (MITM) or phishing)

and steal sensitive QR code etcSub-windowDeception

steal account credentials on Facebook Google Amazon etcsteal mobile wallet passwords contacts etc

Sub-appLifecycleHijacking

steal money (payments in shopping sub-app)steal personal secrets (eg answers tosecurity questions health records etc)

steal business documents (from a document processingand management sub-app published by Microsoft)

steal account credentials of Amazon ICBCCCB HSBC (1st 2nd 7th largest banks in the world)

Airbnb Weibo Starbucks McDonaldrsquos etc

for users to enter contact information (Table 6) attacking this UImay leak contacts which are highly private Last Sub-app LifecycleHijacking affects three hosts (Table 3) and the risks come fromimitating sub-apps supported by these hosts such as sub-apps forAmazon health banking Airbnb etc (see Table 4)Cases Studies We discuss a few other problems we observed inapp-in-app ecosystembull Keeping up with the OS evolution Sub-app API permission policyshould keep up as the OS always evolves newer OS version oftenintroduces more strict protection against sensitive resources Forexample since Android 10 an app that accesses location in the back-ground needs an additional dangerous permission ACCESS_BACKGRO-UND_LOCATION in addition to the regular location permission [82]This protects user location against illicit tracking However sub-app API for accessing location in hosts TikTok and Alipay did notkeep up with such a new protection thus leaving their users at risk

As another example for the WiFi and Bluetooth scan that canleak location Android 9 and 10 require ACCESS_FINE_LOCATIONpermission while Android 81 is less restrictive and ACCESS_COARSE_LOCATION is sufficient (see Table 5) Note that Android uses the firstpermission to control access to precise location (eg GPS data)and uses the second one for coarse-grained positioning (with anaccuracy approximately at the level of a city block [10]) Interest-ingly all hosts we studied only define a general location sub-apppermission to govern location API (eg scopeuserLocation inWechat) but do not differentiate the two levels of accuracybull Too many APIs for one permission APIs of apparently differentfunctionalities should never be governed by the same permissionHowever in the host TikTok (an extremely popular short-videosharing app with more than 500million downloads on Google Play)three sub-appAPIs ttscanCode ttchooseImage and ttchoos-eVideo (for scanning QR code accessing photos and videos) aregoverned by the same permission scopecamera and thus inade-quately protected For example a malicious sub-app that is grantedpermission by the user to scan QR code also behind the scenesilently gets access to API ttchooseImage that accesses user pho-tos posing a serious privacy risk

5 LESSONS AND MITIGATION STRATEGYLessons learned The most important lesson learnt from our re-search is the caution one should take when building a third-party

11

Table 5 Summary of System Resources Exposure flaws (NA means the flaw does not affect the OS)

SystemResourceExposed

of

FlawsExample of Escaped

Sub-app API Dangerous Permission Android API Entitlement iOS Class

Microphone 1 WechatwxgetRecorderManager RECORD_AUDIO mediaMediaRecorder

CaptureRequest Microphone Usage AVAudioRecorder

Camera 3 Alipay myscan CAMERA CameraManageropen-CameraCaptureRequest Camera Usage AVCaptureSession

Wi-Fi 4WeChatwxgetWifiList

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetScanResults Hotspot Helper dagger NEHotspotHelper

JinRiTouTiaoTikTokttgetConnectedWifi

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetConnectionInfo Access WiFi Information dagger CNCopyCurrent-

NetworkInfo

Bluetooth 27

Alipay mystartBluetoothDevicesDiscovery

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan NA NADingTalk

ddgetBluetoothDevicesAlipay

mygetBLEDeviceServices

iBeacon 4 Alipay mygetBeaconsACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan Location Usage CLBeaconRegion

dagger Much harder to exploit on iOS due to the requirement of explicit user approvalDagger Android 9 and 10 require ACCESS_FINE_LOCATION permission while Android 81 requires ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION

Table 6 Examples of Sub-window Deception flaws

Host App Triggering Sub-App API Legitimate (and spoofable)Functionality of the Sub-window

Alipay mytradePay Request password ofAlipay mobile wallet

Baidu swanrequestPolymerPayment Request passwords ofmultiple mobile wallets

DingTalk ddpay Request password ofAlipay mobile wallet

WechatwxaddPhoneContact Enter new contacts

wxrequestPayment Request password ofWechat mobile wallet

QQ new in-app message Display instant messagesand enter a reply

sub-ecosystem on top of the operating system In such a case thethird-party OS-like app strives to provide a secure self-containedenvironment However whether it undermines OS security andbrings in new risks to modern mobile applications need to be eval-uated to identify the security gap between the new sub-ecosystemand the OSes Our measurement study shows that popular host appsare generally susceptible to APINA flaws indicating that the app-in-app system vendors today either fail to identify or are unpreparedfor the new risks

Fundamentally APINA risks come from the limited app-levelcapabilities the host app has in managing OS resources lack ofOS-level support and missing of sub-app API standard Hencedown the road it will require non-trivial joint efforts to fundamen-tally eliminate APINA risks More specifically escaped sub-app APIshows that a third-party host fundamentally lacks the full OS-levelknowledge on system resource protection While such knowledgecan come from different sources eg program analysis on relevantOS modules [35 46] developer documentations technical reportsetc each source only contributes a partial view Hence joint effortsneed to be made in the future to synthesize such knowledge Ourstudy also brings to light that such efforts are by no means trivialndash even the two leading mobile OSes have apparently confusingconflicting security policies Synthesizing such a knowledge base

will not only benefit the app-in-app paradigm but also make theOSrsquo security mechanism more transparent for thorough auditing

Our findings also highlight that prior OS lessons cannot fullyeliminate new risks incurred by the new paradigm which necessi-tates thorough assessment regarding its new attack surfaces Forexample a malicious sub-app a sub-window and a task in Recentsscreen all come as new attack vectors that pose credible new threatsto usersrsquo most sensitive credentials and privacyMitigation strategy Following we propose the short-term miti-gation and discuss the long-term strategybull Escaped Sub-app API Eliminating the risk requires the host tohave full OS-level knowledge about resource control (eg API-permission mapping) which is difficult In the meantime our toolApinat together with our API-permission mapping (released on-line [12]) can help host app vendors identify escaped sub-app APIsNote that since Apinat can identify escaped sub-app API with itsignored permissions with respect to specific OS version (see Sec-tion 43) host vendors may leverage our tool to assess whether theirsub-app API permission policy is always compliant with newly re-leased OS version and thus keep up the pace

Further we envision two possible future directions that couldlead to more viable solutions First as demonstrated by our anal-ysis tool Apinat although it is hard for todayrsquos program analy-sis techniques to derive a complete system API-permission map-ping [35 46] we could significantly improve its accuracy and com-prehensiveness through developer documentation analysis Ourcurrent documentation analysis is rather preliminary but still effec-tive as demonstrated in our study (Section 4) Down the road wecould develop natural language processing (NLP) based techniquesfor deriving more complete knowledge about API permission poli-cies With the techniques an analysis could cover a wider spectrumof literature including iOS documents research papers technicalreports etc which will help derive up-to-date knowledge aboutresource-management policies

Second the app-in-app community should work together tostandardize sub-app APIs and their permission policies as donein the HTML5 community on HTML5 APIs For the time being

12

different app-in-app vendors bring in their own APIs for accessinga wide spectrum of systems resources (see our comparison betweensub-app API and HTML5 API in Table 7 in Appendix) often withoutproper safeguard in place not to mention any effort to standardizethe protectionbull Sub-window deception The risk comes from the UI confusionwhether a window portion in the sub-app window belongs to thesub-app or the host (Figure 3b) To mitigate the risk we envision ahigher degree of UI isolation between the sub-app and the host thesub-apprsquos window should always be separated from that of the hostand the host should never reclaim any window portion from thesub-applsquos window Regarding the Wallet UI confusion (Section 32)for example Wechat should display its wallet UI only in its ownwindow and advertise to users that any UI component inside thesub-app window belongs to the sub-app

A question arises whether a malicious sub-app can fake a crashand then show spoofing content in the sub-app window to resem-ble the host This can be mitigated through additional protectionsupported by the host Specifically the host app could keep mon-itoring the UI of its sub-apps (eg through PixelCopy API onAndroid [71]) to detect whether a UI object in the sub-app is similarto a sub-window or a security-sensitive UI object associated withhost app For performance concern the host app could utilize thestate-of-the-art object detection model (eg Fast Region-based Con-volutional Network based model [61] and YOLO [32 95]) for thereal-time security-sensitive UI object recognition as reported inprior research [95] Fast YOLO yields the performance of 155 framesper second Note that the effectiveness efficiency and deploymentfeasibility of such an approach need to be carefully explored andevaluated which we leave for our future researchbull Sub-app lifecycle hijacking To mitigate this risk a short-termdefense is to place all sub-app resources in the phonersquos internalstorage so our current exploit (leveraging monitoring the phonersquosexternal storage) to track sub-app lifecyle termination (Section 33)can be mitigated However it is always a concern that sub-appsmay deplete the limited space on a phonersquos internal storage Along term solution needs to consider how to make the sub-apptasks dynamically scalable to ensure that the sub-app recycling isno longer traceable and thus the attack surface is fundamentallyeliminated This nonetheless calls for support from modern OSesfor the emerging app-in-app paradigm

6 RELATEDWORKAs mentioned in Section 2 recent years witnessed several tech-niques to support the functionality of app encapsulation (eg Plu-gin frameworks app sandboxing browser extension and PhoneGapapp see Table 2) Accordingly numerous studies have looked intothe flaws in these app encapsulation systems considering the se-curity analysis of Plugin frameworks a set of flaws were revealed[99 111 112] including no permission management and no isola-tion of the virtualized apps Compared with Plugin frameworks theapp-in-app paradigm has a much stronger security model and ourstudy investigates the design challenges and pitfalls in the securitymechanism Meanwhile the security and privacy implications ofbrowser extensions have been extensively studied [48 54 84 98]

Furthermore the current security studies on PhoneGap apps fo-cus on the flaws of PhoneGap frameworkrsquos access control policy[60 90 100 101] For example Song et al [101] revealed that thebridges added by the framework to the browser are not correctlyprotected by the same origin policy Jin et al [86] introduced mul-tiple channels (eg barcode SMS file system Contact) for codeinjection attacks in PhoneGap apps Different from these works wefocus on the unique features of the app-in-app paradigm (Table 2)and reveal multiple new attack surfaces which have never beenstudied before

The closer to our study are the works of Web App and WebViewvulnerability assessment Up to our knowledge only one paper[87] analyzed security issue of Web App in which the securityand privacy risks on HTML5 features in PWA were investigatedIn our attack on Web App we did not focus on HTML5 featuresbut a general UI isolation and management model in app-in-appparadigm Also although WebView technique is used in some ofthe app-in-app systems in sharp contrast to the works on Webviewweaknesses [36 60 88 102 105 109 110] our study explores thesecurity implications and challenges for a third-party app tomanageoperating system resources Another set of works related to ourstudy is the exploitation of mobile UI deception Prior phishingattacks [38 49 53 57 97] mislead victims about the foregroundapp aiming at information theft in spoofing apps Correspondingcountermeasures [49 58 96] emphasize identifying the app of thewhole foreground window and thus cannot thwart Sub-windowDeception due to the inability to identify sub-windows Furtheranother angle of UI deception is clickjacking [59 94] which aredifferent from our mobile-phishing attacks7 CONCLUSIONIn this paper we present the first systematic security analysis on re-source management in high-profile app-in-app systems Our studyshows that such systems are susceptible to a set of serious securityflaws Our measurement study further sheds light on their perva-siveness in the real-world Further our study brings in new insightsinto the fundamental security limitations of this new paradigm andfurther contributes to a better understanding of its mitigation strat-egy an important step towards building a more secure app-in-appecosystem

8 ACKNOWLEDGMENTWe would like to thank our shepherd Yanick Fratantonio and theanonymous reviewers for their insightful comments This work issupported in part by the NSF CNS-1618493 1801432 1838083

REFERENCES[1] 2011 HTML5 Fullscreen API Attack httpsferossorghtml5-fullscreen-api-

attack[2] 2011 The Inception Bar httpsjameshfishercom20190427the-inception-

bar-a-new-phishing-method[3] 2018 Java Runnable httpsdocsoraclecomjavase7docsapijavalang

Runnablehtml[4] 2018 A one year PWA retrospective httpsmediumcompinterest-

engineeringa-one-year-pwa-retrospective-f4a2f4129e05[5] 2018 Wechat 1 million sub-apps httpswwwscmpcomtecharticle2153705

tencents-wechat-now-host-1-million-mini-programs[6] 2018 WeChat reaches 1M sub-apps half the size of Applersquos App Store https

techcrunchcom20181107wechat-mini-apps-200-million-users[7] 2018 Xposed httpsapixposedinforeferencepackageshtml[8] 2019 AdBlock httpsgetadblockcom

13

to securely mediate access to system resources it acquired Moreseriously we found that the functionality- and user-oriented app-in-app ecosystems actually undermine the security protection ofmodern mobile OSes by introducing new risks to their otherwisesecure permission-based resource control

In particular the hosts generally fail to provide sound securitypolicies and effective control to protect sensitive system resourcesfrom unauthorized sub-apps For example Wi-Fi scan is guardedby a dangerous permission (ie location) on Android and an enti-tlement on iOS because this capability can leak user location [37]However Wechat discloses it to sub-apps (on both OSes) withoutproper authorization ndash a serious violation of permission protectionon user location Similar problems are also discovered on otherresources managed by popular host apps which allow the adver-sary through an unauthorized sub-app to stealthily gain access tomicrophone location camera etc in the absence of a user consentFundamentally the problem comes from a knowledge gap the hostdeveloper fundamentally lacks the OS level knowledge and there-fore is not in position to design sound sub-app level permissionpolicies that comply with the OS level resource protection Bridg-ing this knowledge gap presents new challenges to the design ofapp-in-app systems such as misleading developer documentationsand conflicting OS-level security policies between Android and iOSwhich have not been systematically studied before (Section 31)

Also our research shows that an app-in-app system underminesthe protection enforced by a mobile OS by rendering the state-of-the-art UI deception defense ineffective (Section 32) We presentan attack vector that is inherent in the app-in-app UI model whichintroduces realistic security hazards during app-user interactionsExploiting the weakness a malicious sub-app leveraging its UIembedded in its hostrsquos window can strategically impersonate thehost to get sensitive information from the user such as accountpasswords Our research shows that leading host apps such as Safari(on iOS) Chrome (on Android) Wechat and Alipay (on both OSes)are all vulnerable allowing a malicious sub-app to steal the userrsquospasswords for Amazon Google various mobile wallets etc

Further as mainstream app vendors participate in app-in-appparadigm by releasing sub-apps that are functionality-equivalentto their regular mobile apps [29] (eg e-commerce banking travelhealth etc) their (sub-)apps can no longer benefit from the protec-tion offered by modern mobile OSes ndash which have been hardenedafter years of open security research Safeguarding sub-apps to-day mostly relies on individual host vendors who however fail todemonstrate that they are up to this challenge our study showsthat even leading host apps with more than 100 million downloadson Google Play and Apple App Store (eg Wechat Alipay Tiktok)expose new attack surfaces and exploitable weaknesses throughtheir app-in-app supports (Section 3)Impacts To understand the scope and magnitude of the newlydiscovered security risks (called app-in-app flaws or APINA flawsfor short) we analyzed 11 most popular commodity app-in-app plat-forms on both iOS and Android including Wechat Alipay TikTokJinRiTouTiao Chrome Safari etc To enable systematic measure-ment and analysis of these flaws on a large scale we developed ascanner called Apinat (short for App-in-app Threat Scanner) to

report whether a host app contains APINA flaws leveraging a com-bination of test case generation dynamic analysis and lightweightcomputer vision techniques

Running Apinat on the popular platforms we found significantand broad impacts of APINA flaws (Section 43) every single app-in-app system we studied is vulnerable and exploitable with seriousconsequences (Table 4) More specifically APINA flaws allow theadversary (ie either a malicious sub-app or native app) to stealthilyacquire critical system capabilities (eg accessing camera micro-phone connecting to arbitrary Wi-Fi access point connecting thephone to arbitrary Bluetooth device etc) without the user consentand steal usersrsquo private data (eg location account credentials ofAmazon and top banks credit cards mailing address travel logshealth statistics) We reported our findings to all affected vendorswho acknowledged that what we found are real and significantGoogleWechat and Alipay all awarded us through their bug bountyprograms The demos of our attacks are available [12]Contributions The contributions are outlined as followsbullWe conducted the first systematic security analysis on the app-in-app paradigm and discovered a series of unexpected security-critical flaws Our findings bring in new insights into the funda-mental security limitations and challenges in designing this newcomputing platform and ecosystem and are invaluable to the en-hancement of its security protection Also we believe that ourfindings are just a tip of the iceberg and will inspire the follow-upresearch on this directionbullWe developed new techniques to detect APINA flaws and mea-sure their pervasiveness and impacts in 11 real-world app-in-appsystems We demonstrate that the APINA flaws are indeed preva-lent across both Android and iOS with severe security and privacyimplications We release the source code of our tool [12]bullWe discuss mitigation strategies and the lessons learned for build-ing a more secure app-in-app system

2 MOBILE APP-IN-APP SYSTEMSA unique feature of app-in-app paradigm is its sophisticated sub-apps which are designed to provide native-app experience [5] As aninstance Wechat has provided ldquomini-programsrdquo since 2017 whichare essentially sub-apps hosted inside the Wechat app Anotherexample of the app-in-app paradigm in our study is the mobilebrowser supporting standaloneWebApp sinceWebApp is designedto act like regular native app aWeb App is launched from the homescreen and takes a dedicated entire window (separated from thebrowser window) just like a standalone native app ndash as advocatedby Google and Apple [44 78] Using Web App such as Pinterest isnot like interacting with a webpage [4] but more like launchingthe regular Pinterest mobile app except that its whole window iscreated by the browser which is transparent to the users

Table 1 shows 11 popular app-in-app ecosystems we studiedbesides Wechat other host apps are also remarkably popular egAlipay has one billionmonthly active users and 120000 sub-apps [9]Also high-profile retailers app and service providers (eg AmazonMicrosoft Airbnb Samsung HSBC JDcom Starbucks McDon-aldrsquos) actively contribute to the trending app-in-app paradigm byreleasing sub-apps to these hosts

2

Table 1 Popular host apps and the amount of sub-apps avail-able in the host apps

Host App Functionality (of the host itself except sub-apps) Number ofSub-App

Number ofDownloads

WeChat Instant Messaging Social NetworkingSocial Media VoIP Mobile Wallet 1M+ 200M+

AlipayMobile Wallet FinanceInvestment Management

Shopping News Social NetworkingUtility Bill Management Travel

120000+ 1B+

Chrome Web Browser NAdagger 1B+Safari Web Browser NAdagger NAdagger

TikTok Video Sharing Instant MessagingPersonal Blog Game Center NAdagger 500M+

JinRiTouTiao News Feeding live streaming NAdagger 1M+

QQInstant Messaging VideoAudio Chatting

File Transfer Personal BlogGame Center Mobile payment

NAdagger 10M+

Firefox Web Browser NAdagger 100M+Opera Web Browser NAdagger 100M +

Baidu Search engine News Short VideosVoice Recognition Readings NAdagger 230M+

DingTalk Address Book Mobile Office Tool BoxVideo Conference 20000 500K+

Total - 1M+ 26B+

dagger Lack public information

21 ArchitectureTo enable native-app experience for sub-apps each host app pro-vides a set of sub-app APIs for sub-apps to access diverse systemresources (such as the camera microphone Bluetooth NFC Con-tacts photos) Also the sub-app is cross-platform it is typicallydeveloped in script languages (particularly JavaScript [20]) andruns on both the Android and iOS version of its host app Thesefeatures are fulfilled by the host app through a cross-platform run-time called sub-app runtime in this paper Below we summarize itstypical architecture which we learned through reverse engineeringpopular host apps (Table 1)

Figure 1 outlines a typical app-in-app architecture from the per-spective of resource access Specifically the host app consists of asub-app layer where all sub-apps live and a sub-app runtime wherea generic abstraction was provided for system and host app resourceaccess Sub-app runtime bridges sub-app API calls (in JavaScript)into the native layer (in Java on Android and Objective-C [39]or Swift [40] on iOS) of host apps The native layer then enforceshome-grown permissions of the host app (aka sub-app permis-sions) and either accesses host resources or calls correspondingsystem APIs to access system resources

Specifically in the script layer invoking a sub-app API (egconnectWiFi) will trigger an Encapsulation lib which then calls anative function (eg dispatcherdispatch(rsquoconnectWiFirsquo)) tobridge the control flow into native layer Particularly we found twocommon bridge techniques adopted by host apps WebView [79]and React Native [55] To use Webview a host app leverages aWebView API addJavascriptInterface(obj lsquodispatcherrsquo)to expose a native object obj aliased lsquodispatcherrsquo to the script layerits dispatch function is then accessible in script layer as mentionedabove Given each sub-app API the dispatch function invokes thecorresponding native-layer libraries to check sub-app permissionand access resources To use the React Native bridge the majordifference here is how to expose the native object to script layerdispatcher objectrsquos class in the native layer namely Dispatchermust inherit an Interface ReactPackage of React Native framework

Figure 1 A typical app-in-app architecture

dispatcher object is then specified in a configuration file andexposed to the script layer by React Native framework [55]

22 Security Model in Resource Managementbull Sub-app permission The app-in-app system uses the traditionalpermission label assignment model to protect sub-app APIs Inparticular sub-app requests a list of sub-app permissions whichgovern the access to the sub-app APIs If the sub-app APIs accesssensitive system resources (ie protected by dangerous [76] permis-sions on Android or entitlements [17] on iOS1) or sensitive host appresources (non-system resources under host apprsquos control such asuser profile ID gender managed by Wechat) a host app enforcessub-app permissions for calling the sub-app APIs For exampleWechat defines a sub-app permission named scoperecord to pro-tect its sub-app API wxstartRecord which is used to record audiousing the phonersquos microphone Note that host apps typically donot intend to protect less sensitive system resources ie thoseprotected only by Android normal permissions or not protected byOSesbull Isolation Each sub-app has its unique ID assigned by the hostapp Sub-app cannot access resources of the OS host app and othernative apps and sub-apps without going through an authorizedchannel provided by the host Each sub-app has a unique datastorage managed by the host appbull Sub-app vetting Like traditional app stores all sub-app storesin our study also require a sub-app to be reviewed before beingpublished The sub-app vetting process consists of risk assessmentalong with additional criteria to determine whether a sub-appviolates user privacy or data security requirements Examples ofthe security requirements include any sub-app shall not requestor induce users to enter the host apprsquos user ID and passwords [30]and user data collected via a sub-app may not be sold transferredtraded or disclosed [51]

23 Comparison with Existing AppEncapsulation Systems

Similar to the app-in-app system other approaches can also ldquoencap-sulaterdquo an application to run in the execution environment provided1iOS entitlements which confer security permissions and capabilities [41] are strictlyprotected by Apple and must be explicitly declared and vetted [108]

3

Table 2 Comparison with existing app encapsulation sys-tems ( Not Supported Partially Supported Fully Sup-ported)

System Features And

roid

Plug

inFram

ework

App

Sanb

oxing

Brow

serE

xtension

Phon

eGap

App

App

-in-app

Sub-app API ecosystemfor system resource access

dagger dagger

The host has rich functionalitiesapart from hosting

Mandatorysub-app destruction

dagger supported by HTML5 API which is standardized by W3C and thus much easier tomanage than sub-app API

by another app A prominent example is Android Plugin framework(eg Parallel Space [23] DroidPlugin [15] and VirtualApp [26])an app virtualization technology through which a ldquohost app canload other Android apps (called ldquopluginrdquo apps) from their APK filesto run in the hostrsquos own process [111 112] This is done throughwrapping the system APIs for invoking plug-in apps which sharethe hostrsquos UID and permissions during their executions [99 111]Also mobile app sandboxing (eg Boxify [47] and NJAS [50]) isanother way to virtualize apps The idea is to encapsulate untrustedapps in a restricted execution environment within the context ofa trusted sandbox app which provides an emulation layer to ab-stract the underlying OS and interposes all interactions (eg sys-tem calls binder IPC) between the untrusted app and the OS [47]Other app-encapsulation solutions include Browser extension2 (egAdBlock [8] EditThisCookie [16]) where a small program cus-tomizes a web browser with the support of HTML5 (for controlledsystem-resource access) and extension APIs (for browser-resourceaccess) [13] and PhoneGap apps (or HTML5 based mobile apps)where a middleware framework (eg PhoneGap [24] Cordova [11]Ionic [19]) is used to allow the developer to create mobile appsusing web technologies [31 86]

Table 2 compares the above solutions with the app-in-app systemin terms of their security implications As we can see here unlikethe app virtualization based Plugin framework and app sandboxingthe app-in-app platform builds up its own API ecosystem (ie sub-app APIs) for sub-apps to access system resources which entailsnon-trivial efforts to define and maintain its security model such asthe sub-app API permission policies Such policies are standardizedfor HTML5 APIs used by browser extensions [103] but are ad-hocopaque and often inadequate for the sub-app APIs that are muchmore powerful and access more sophisticated system resourcesthan HTML5 thereby opening new attack avenues (see Section 31and Table 7 in Appendix) Furthermore compared with other solu-tions dedicated to application encapsulation the app-in-app host2Browser extension is different from the deprecated Browser Plugin architecture [14]Browser Plugin is generally not considered as an encapsulation system since the pluginsare independent executables and their access to system resources are not encapsulatedby the browser

has its own rich functionalities (eg mobile wallets messagingsee Table 1) which are often shared with the sub-apps For exam-ple e-commerce sub-apps (eg Amazon Pinduoduo) leverage thehostrsquos built-in wallet feature for convenient payment process (seeSection 32) In our study we found that such interactions (betweenthe sub-app and the host app) actually exposes a new attack sur-face (Section 32) Also the upper limit on the number of sub-appsthat can run concurrently on an app-in-app platform is public andfixed (8 in Chrome 5 in Wechat 4 in Alipay) whenever the limitis reached the host has to terminate a sub-app in order to launcha new one This feature which does not exist in other systemscan be abused for deception attack as discovered in our research(Section 33)

24 Adversary ModelWe assume the host app is benign which aims to provide a secureenvironment to run sub-apps On the victimrsquos Android or iOS de-vices where at least one app-in-app system is used we consideran adversary with his malicious app3 or sub-app installed Notethat none of our attacks requires the victim to install both InSection 3 we show that such malware can successfully pass thevetting of popular sub-app stores Google Play third-party appstores etc The malware sample does not have system privilege andin some of our attacks may need to ask for a set of common permis-sions from the users (eg Androidrsquos READ_EXTERNAL_STORAGE andWRITE_EXTERNAL_STORAGE) depending on specific attacks Suchpermissions are extensively requested by popular apps such asFacebook Gmail and Pinterest Therefore we believe that claimingthem by the malicious app will not arouse obvious suspicion

3 DESIGN CHALLENGES AND PITFALLSIn this section we report our security analysis on resource manage-ment in app-in-app systems Our research shows that all app-in-appsystems we studied including Wechat Alipay TikTok ChromeSafari etc are subject to various APINA flaws leading to seri-ous exposure of system resources and new deception attacks Morespecifically the security analysis has been systematically performedby assessing two general categories of resources system resourcesaccessible through system APIs and user interfaces For each re-source we looked at the security policies that should be in placethe mechanism that enforces the policies and the user interactionswith security implications

31 System Resource ExposureSub-apps access system resources through sub-appAPIs (Section 21)However for the host as a third-party app constructing sound sub-app API permission policies that govern system resources entailschallenges that are unexpected before As a result sensitive systemresources are often unwittingly exposed to unauthorized sub-appsEscaped sub-app API Sub-app APIs are protected by sub-apppermissions which are supposed to be consistent with the permis-sions required by the OS when using the relevant system APIs theywrap For example since the OS requires permissions to use its

3In this paper we use the term app and native app interchangeably Also although thehost app is a native app itself the term app or native app in this paper always refers toan app that is not a host app for ease of presentation

4

Figure 2 Misleading Android documentation

audio recording APIs (RECORD_AUDIO [72] permission on Androidand Microphone Usage [42] entitlement on iOS) the sub-app APIto record audio (eg wxstartRecord in Wechat) should also beprotected by a sub-app permission (eg by sub-app permissionscoperecord in Wechat) However in our study we found theinconsistency in permission requirement between sub-app API andsystem API indicating that the host fails to create the correct per-mission policies that govern sub-app API for system resource accessAs a result certain sub-app APIs that wrap permission-protectedsystem APIs are completely open to any sub-apps without requir-ing a sub-app permission exposing sensitive system resources Wename such unprotected sub-app API escaped sub-app API and theproblem System Resource Exposure

An example discovered in our research is the unprotectedWechatsub-app API wxgetWifiList that performs WiFi scan a capa-bility protected by the underlying OSes against user location leakeg through an entitlement Hotspot Helper on iOS and danger-ous level location permissions (ACCESS_COARSE_LOCATION andACCESS_FINE_LOCATION) on Android This exposes the WiFi scancapability to sub-apps leaking out user location to them Notethat a high-profile host app (eg Wechat) is typically granted thelocation permission and many other permissions due to its richfunctionalities (see Table 9 in Appendix) As a result through thedelegation the host makes to the sub-app escaped sub-app APIeffectively opens a door for the adversary to gain unauthorized ac-cess to system resources In addition to wxgetWifiList we foundmany other escaped APIs in popular app-in-app systems affectingdiverse sensitive resources across iOS and Android (Section 43)

Looking into the possible root causes we found that it is verychallenging for an app-in-app system to soundly define sub-appAPI permission policies that comply with the OSes in governing sys-tem resources due to the incomplete knowledge about permissionchecks that happen at related system APIs Specifically official API-permission maps for both Android and iOS have never been madepublic Although several prior attempts [35 45 46 56] have beenmade to automatically map Android APIs to their required permis-sions we found that the prior results are incomplete (Section 43)and highly likely to introduce escaped sub-app APIs if they are usedto design a sub-app permission system Consider the above exam-ple of WiFi scan recent results [35 46] (on Android API level 25)report that a related Android API WifiManagergetScanResultsrequires just a normal permission ACCESS_WIFI_STATE but failto mention that dangerous permission location is also required(required since Android API level 23 [80]) Further Section 43 re-ports more escaped sub-app APIs possibly caused by the incompleteAPI-permission maps

Such API-permission mapping information has also not beenwell recorded by the developer documentation We found that suchdocumentation can be misleading or confusing Again let us useWi-Fi scan as an example as shown in Figure 2 the Android

documentation [75] may introduce the misconception that declar-ing ManifestpermissionCHANGE_WIFI_STATE is sufficient forWi-Fi scan Similar misguidance also appears on the Android doc-umentation for Bluetooth scan etc and has likely caused otherescaped sub-app APIs we found (Section 43)

Another observation of our study is that since sub-app APIis designed to be cross-platform (Section 21) the effort to buildsub-app API permission policies that comply with all OSes hasbeen complicated by the inconsistency between Android and iOSin resource protection Consider Bluetooth scan as an examplethe Android API BluetoothLeScannerstartScan requires thedangerous location permission while iOS does not Such a dis-crepancy likely causes confusion in app-in-app design which istypically built for both OSes with uniform security policies Whenthis happens we found that the app-in-app designer tends to leavethe related sub-app API unprotected For example the sub-app APIsfor Bluetooth scan are not protected in multiple host apps (egwxgetBluetoothDevices in Wechat) Actually the difference inpolicy-level protection could result from an additional securityguard put in place by the OS which is unaware to the app-in-appdesigner For example combining together Signal Strength andDevice ID of nearby Bluetooth devices reveals geo-locations [37]On Android the pair is returned together by the above Bluetoothscan API BluetoothLeScannerstartScan which thus needs apermission check on iOS however the pair has been partially ob-fuscated (Device ID is randomized) and is thus unprotected Wesuspect that the inconsistency as observed on capabilitiesresourcesWi-Fi scan Wi-Fi connect iBeacon etc is likely responsiblefor other escaped sub-app APIs we discovered (see Section 43)Discussion Android 60 (API level 23) started to use a runtimepermission model a user grants permissions at the apprsquos runtimewhen permissions are requested (eg when the app launches orwhen the user accesses a specific feature) [73] In this scenariowhen an escaped sub-app API tries to silently access a resourcethe host may have not been granted a permission to access thatresource thus a permission will be explicitly required Howeverthe OSrsquo permission granting window will show to the user thatit is the host app who requests the permission not the sub-appThis misleading request may lead to the wrongly inherited trustassociated with the hosts and make users grant the permissioninappropriately This is also the case on iOS when a permissionwindow pops up to confirm the hostrsquos access to a resource

Furthermore Table 9 in Appendix lists all Android dangerouspermissions and iOS entitlements requested by the vulnerable hostsright after launching It shows that the hosts proactively requestnecessary permissionsentitlements even before accessing any spe-cific features due to usability consideration [92] Those capabilitiesof the hosts will always be stealthily delegated to the sub-app viaescaped sub-app APIs which present serious risksAttacks and vendor acknowledgements We implemented anattack sub-app which ran inWechat v673 to steal userrsquos location onboth Android and iOS The attack sub-app utilized Wechat escapedsub-app API wxgetWifiList to perform Wi-Fi scan and snifferthe surrounding Wi-Fi access points The scan results included sen-sitive information ie BSSID Signal Strength and Device ID ofnearby Wi-Fi access points which enabled to infer the geolocation

5

(a) Real Prominent UI (b) Fake Prominent UI

Figure 3 Safarirsquos Prominent UI confusion on iOS

of a user [37] This attack sub-app successfully passed the vettingof Wechat sub-app store and ran on both iOS and Android versionsof Wechat Note that our attack sub-app has less than 200 lines ofcode which indicates that it is cost-effective for the adversary todevelop APINA flaws malware in the wild Besides we successfullybuilt attack sub-apps in other host apps eg Alipay DingTalk etcand reported the problems to all affected host-app vendors Theyall acknowledged the problem in particular Wechat and Alipayawarded us through bug bounty programs for this flaw

32 Sub-window DeceptionAnother unique app-in-app feature is the functionality-level inter-actions between the host and sub-app For this need the host doesnot fully isolate itself from sub-apps which unwittingly introducesnew attack surfaces and high spoofing risks against host-app UIBrowsersrsquo Prominent UI confusion To bring a native app-likeexperience Safari on iOS and Chrome on Android open each sub-app (ie Web App Progressive Web App or PWA) in an entirededicated window separate from the browser window just like anative app [44 78] ndash without any browser UI such as the addressbar Web App is programmed with JavaScript and HTML but mustmeet certain standards [68] With user confirmation the browsercan install a Web App to the phonersquos home screen (through anAPK [69] package created by Chrome or a Web Clip [44] createdby Safari) Such Web App takes the full screen if ldquostandalone orldquofullscreen is specified in its manifest file EachWeb App is clearlyassociated with specific Web domain when installed When the usernavigates to out-of-scope URL (ie of different origin) in a WebApp the browser displays a Prominent UI ndash a banner at the top ofthe screen (Figure 3a) showing the origin and secure connectionstatus ndash due to the lack of address bar According to Web Appdocumentation [67] users rely on such Prominent UI to be awarewhen they navigate out of scope an important security notice

Based on a study [57] mobile phishing attacks tend to happenwhen users become accustomed to familiar repeated contexts Morespecifically if users frequently encounter legitimate context theywill become conditioned to reflexively respond to it Here the cur-rent design of Web App conditions users to see the Prominent UI inout-of-scope navigation which we found poses a spoofable context

(a) Authentic wallet UI (b) Bogus wallet UI

Figure 4 Mobile wallet UI confusion

Specifically Web App is designed to embrace out-of-scope brows-ing [104] and let users freely navigate to other Web domains forservices such as login through FacebookGoogle (aka SSO [107])payment through PayPal etc The problem is that when a victimuser navigates out of scope eg to Facebook login page a mali-cious Web App can actually navigate to an in-scope phishing pageimitating Facebook showing a bogus Prominent UI (as if shown bythe browser) to misleadingly inform the victim that she is on a realFacebook domain (Figure 3b) In this way the malicious Web Appcan collect victim usersrsquo secrets such as Facebook passwords

We call this problem Sub-window Deception ndash sub-window meanspart of a window Prior phishing attacks in browsers exploredhow a webpage can go full screen and spoof the address bar [12] as another instance of mobile browser UI attacks our attackcomplements the prior understanding by exploiting ProminentUI ndash the counterpart of address bar in the context of native app-like Web App Note that address bar differs from Prominent UIin design based on the Web specification [106] browsers ldquoshouldprovide a means of exiting fullscreen that always works and advertisethis to the user [106] so users can see the real address bar whenthey want (although browsers may not implement this protectionproperly [89]) Web App users however lack practical mechanismsto verify the authenticity of Prominent UI today This attack appliesto general Web App on both iOS and Android we reported it toW3C4 Apple Google Firefox and Opera which all acknowledgedthe importance of the problemMobile Wallet UI confusion Wechat and Alipay both featuremobile wallets which can be leveraged by e-commerce sub-appsto provide users a convenient payment process Amazon sub-appfor example after a user clicks its ldquocheckout with Wechat wal-letrdquo button will invoke a sub-app API (eg wxrequestPaymentin Wechat) to trigger the hostrsquos wallet the host then reclaims acentral portion of the screen from the sub-app to show its walletUI (highlighed in Figure 4a) for the user to enter her wallet pass-word and finish the payment Such a context can condition usersto reflexively provide wallet passwords at checkout and thereforepresents a practical spoofing target Specifically when a victim userclicks the ldquocheck out button in a malicious e-commerce sub-app itcan show a bogus wallet UI (Figure 4b) to collect the userrsquos walletpassword instead of invoking the real wallet

4We do not provide the link to our report for anonymization purpose

6

(a) Real sub-app task (b) Bogus sub-app task

Figure 5 Dedicated task for every sub-app in Recents screen

Up to our knowledge state-of-the-art mobile anti-phishing tech-niques cannot identify our attacks for example [49 58 96] mainlyrely on identifying the app of the whole foreground window so theuser would not expose secrets to the unintended app this cannotidentify a sub-window at the sub-app level ndash whether it belongs toa sub-app or the host app

Our study shows that a bogus sub-window presents a practicalattack vector in app-in-app since a window portion (sub-window)can be used by both the sub- or host- app in accustomed contextswithout differentiation through clear identification From a broadersense we believe the spoofing risk is also high if the OS showsits pop-up atop an app (so malicious app can show a bogus onewhen the OS does not) however in sharp contrast such pop-upis not sub-window (but whole window) and known anti-phishingtechniques (eg [49]) to identify (the owner of) the whole windowcan defeat itAttacks and vendor acknowledgementsWe implemented PoCattacks in Safari on iOS Chrome on Android and Wechat on bothOSes in Safari and Chrome our malicious Web App impersonatesProminent UI to spoof Facebook login page in Wechat our mali-cious sub-app mimics the wallet UI to steal wallet password (seevideo demo online [12]) Our malicious sub-app passed the vettingof Wechatrsquos sub-app store Note that Web App does not have appstores and can be installed after visiting its URL In addition wereported the problems to all affected host vendors who all acknowl-edged that the threats were practical and severe Wechat and Alipayawarded us through their bug bounty programs

33 Sub-app Lifecycle HijackingAs app vendors follow the app-in-app trend by releasing sub-appsit is unclear whether their users remain equally protected as beforeUnfortunately our study shows that even highly credible host appscannot fully eliminate new attack surfaces incurred by app-in-appRecents screen takeover The Recents screen (aka recent task listor recent apps) [64] is a system-owned UI of Android to list recentlyaccessed task (Figure 5a) In particular each launched native appwill have a task in Recents screen similarly a host app creates aseparate task for every launched sub-app which appears in Recentsscreen Limited by the OS each host app can only create a fixednumber of tasks in Recents screen pre-specified as activities inits manifest file In our research we found that host apps all specify

a small magic number (eg 8 in Chrome 5 in Wechat 4 in Alipay3 in JinRiTouTiao) for the task limit

When an additional sub-app will be opened after the task limitis reached the host app silently executes a mandatory recyclingprocess closing the first opened sub-app to recycle its task forlaunching the new one The recycling process is transparent tousers for the possible purpose of not interrupting the user experi-ence Such a mandatory sub-app recycling mechanism introducesa new risk once the recycling is traceable by a malicious appie the adversary knows which sub-app has been recycled and atwhat time it can stealthily insert a phishing task into the Recentsscreen to imitate the silently recycled sub-app For this purposethe adversary needs to acquire the information about a hostrsquos taskrecycling which turns out to be feasible due to the presence ofvarious information-leak avenues that can be hard to eliminate Inour study we found a side channel that enables recycling track-ing in multiple host apps In particular possibly due to the richfunctionalities of sub-apps which require resource files (eg userdata logs icon and image texture) the host app creates a folderin Android external storage [18] to cache sub-app resources Suchexternal storage can be monitored by an Android native app totrack which sub-app is launched and at what time (by monitoringsub-app icon which will be downloaded at launch see PoC attackbelow) Thereby once the number of launched sub-apps reachesthe hostrsquos task limit the sub-app to recycle can be inferred Hencea malicious native app can insert a bogus task in Recents screento mimic the recycled sub-app at this point the bogus task is theonly one in Recents screen that represents the target sub-app thatrsquosspoofed (Figure 5b)

This attack is a kind of mobile task hijacking attacks [52 97]Regarding its root cause the mandatory sub-app recycling opens anew attack surface for app-in-app systems since it makes it possiblefor malicious apps to track a sub-apprsquos lifecycle termination Notethat the attack surface becomes exploitable in the presence of sidechannels eg external storage which itself is a relatively trivialbug Other side channels could also be used for the attack once theyarise (see discussion below) Eliminating this attack surface maynot be trivial in practice since the maximum task number of a hostin Recents screen is not dynamically scalable (statically specifiedin manifest) limited by the OS Although the very recent Androidsupports dynamic task no host app we studied (Table 3) adoptedit possibly for the purpose of supporting older Android versionsgiven the notorious Android version fragmentation [74]Attacks and vendor acknowledgementsWe implemented PoCattacks on Alipay andWechat which cache sub-app resources in theexternal storage and enable recycling tracking Specifically Alipaystores the caches at sdcardalipaymultimedia When a sub-app such as Amazon is launched its icon will be downloaded toit if not already there Our malicious Android app with a commonpermission WRITE_EXTERNAL_STORAGE can remove cached iconsperiodically andmonitor when they reappear to knowwhat specificsub-app is launched and at what time In our attack of Alipay oncethe malicious app infers that five sub-apps have been launched(submit-app task limit of Alipay is 4) it will insert a bogus task inRecents screen to mimic the first sub-app which is recycled Oncethe victim user enters the spoofing task through Recents screenit can lure the user to leak secrets such as passwords Note that

7

our malware successfully passed the vetting of popular app storesincluding Google Play We reported the problem (demo online [12])to Wechat and Alipay which both acknowledged the problem andawarded us through bug bountiesDiscussion on other side channels As mentioned earlier otherside channels once found can also be used for impersonating therecycled sub-app Prior research [113] shows that the operationsof Android apps can be easily tracked through the Android pro-cess file system (procfs) Although Android has been continuouslybeefing up its privacy protection until Android 9 still some globalstatistics under procfs are exposed Particularly we found that theTCP connection status under procnettcp can be accessed byany app without permission on Android 9 and below From the filewe can see the IP addresses of all TCP connections on an Androidphone which are labeled by randomly assigned User IDs Interest-ingly we found that an invoked sub-app makes a sequence of TCPconnections and the endpoints of the connections (domains) canuniquely fingerprint its initiation eg Amazon sub-app connects to4 unique endpoints with 8 consecutive HTTPS requests in the firstfew seconds after it is launched In our research we sampled 8 high-profile sub-apps in Wechat and identified the sequences of theircommunication endpoints as observed when they are triggered (seeTable 8 in Appendix) Through this side channel a malicious nativeapp is able to infer the launch of a specific sub-app so it can waituntil it is terminated for task recycling (eg after 5 other sub-appsare found to be started through the procfs when the magic numberis 5) to create a task to impersonate the sub-app Note that the mali-cious app can resolve the endpoint domains from IP addresses usingAndroid API InetaddressgetCanonicalHostName [81] withoutrequiring any permission which was implemented and confirmedin our study

Until April 2020 84 of the Android devices are still runningAndroid 9 or earlier versions [33] and therefore are vulnerable toour attack On Android 10 which was released in September 2019the procfs used in our attack has been closed by SEAndroid [70 83]and thus the attack is ineffective Seeking a more powerful attackavenue is left to the future research

4 APINA FLAWS IN THEWILDIn this section we report a measurement study that reveals thescope and magnitude of APINA flaws in the wild The study ismade possible by an automatic analysis tool we built called Apinat(short for App-in-app Threat Scanner) which helped us identifyapp-in-app hosts that are susceptible to APINA flaws

41 Identifying System Resource ExposureDesign Apinat aims to find System Resource Exposure flaws byidentifying escaped sub-app API The idea is to find sub-app APIthat is unprotected by sub-app permission while its correspondingsystem API is permission-protected A naive idea is to call eachsub-app API and find out whether the OS checks the permissions ofthe host app eg by looking at permission pop-ups or system logsThis does not work because the permission asked by the OS can berelated to the host apprsquos own rich functionalities not the sub-appAPI To systematically find escaped sub-app API our methodologytracks the system API invocations triggered by a sub-app API via

a dynamic analysis (Step S1 S2) and then utilizes system API-permission maps to derive required permissions of the sub-appAPI (Step S3) which will be compared to the corresponding sub-app permission If a sub-app API is not protected by any sub-apppermission while its corresponding system APIs are guarded by theAndroid dangerous permissions5 or iOS entitlements an escapedsub-app API is found (Step S4) Following we describe how thisdesign works and how it was implemented in our research onAndroid Since sub-app APIs are cross-platform we were able toextend all the findings made by our technique from Android to iOSby simply validating these findings on the Apple platformStep S1 generating test cases To conduct a dynamic analysis wefirst need to generate test cases with valid arguments to invoke eachsub-app API without triggering exceptions For each API we targetthat at least one invocation is successful The argument types ofJavaScript APIs are either primitive or Object [21] To produce testcases for primitive arguments we leveraged Mozillarsquos funfuzz [22]a JavaScript toolkit ForObject arguments we recursively generatedtest cases leveraging funfuzz because an Object includes keyvaluepairs its key is primitive and the value is either primitive or ObjectAll test cases were then used by a sub-app we built to invoke sub-app APIs If all test cases for an API failed we manually inspectedthe API to address the issues such as formatted inputs (eg UUID)stateful calls (an API needs to be invoked before another) etcStep S2 tracking system API As mentioned in Section 21 theexecution of a sub-app API enters the native layer of the hostthrough a dispatcherdispatch function and then its controlflow reaches system APIs (Figure 1) Therefore Step S2 first iden-tifies the dispatcherdispatch function in the host apprsquos nativelayer then tracks its call graph to find the system APIs triggeredby the sub-app API call as elaborated below

(1) Find the dispatcherdispatch function in the native layer Asmentioned earlier Webview and React Native are bridge techniquesto expose dispatcherdispatch to JavaScript layer Note thatthough the object alias (dispatcher) and function name (dispatch)vary across host apps they can be obtained by inspecting functioninvocations in Encapsulation lib (Figure 1) which is a preprocess-ing step in our study Note that the Encapsulation lib usually canbe found in JavaScript files packaged in the host app (eg underassets folder) So all we need is to identify the dispatcher objectin the native layer based on the obtained alias

To this end S2 implements an Xposed [7] (a framework to in-strument Android app execution) module to hook Webview APIaddJavascriptInterface(obj alias) (that exposes Java objectto JavaScript through an alias) and inspect its arguments at run-time if the ldquoalias argumentrsquos value matches the dispatcher aliasdiscovered the ldquoobj is the dispatcher object that we are lookingfor The analysis of React Native bridge is slightly different wehook its API createNativeModules to get its Java objects exposedto JavaScript our Xposed module then calls each exposed objectrsquosgetNamemethod to get its alias ndash if this alias matches the dispatcheralias discovered the object is what we are looking for

5Host apps are typically third-party apps that cannot call privileged system APIs pro-tected by ldquosignature or ldquosignatureOrSystem level permissions [65] or they typicallydo not delegate the access to such APIs through sub-app APIs

8

(2) Track execution of the dispatcherdispatch function Our toolthen tracks the call graph of the dispatch function to find the calledsystem APIs ndash which are called to fulfill the sub-app API call Specif-ically our Xposed module hooks dispatch function and AndroidAPI and inspects their respective call stack traces However wefound that dispatchrsquos thread sometimes does not call Android APIsdirectly it triggers additional thread to call Android APIs likelyfor not to block the dispatch thread This introduces a challengeXposed outputs the above two stack traces by threads ndash one stacktrace with Android API call and the other with dispatch functioncall ndash but cannot correlate two threads if one triggers the otherTherefore we still cannot confirm that the Android APIs are in-voked due to dispatch Hence we developed techniques to deal withthe multi-threading challenge

In our study we found that Handler a typical multi-threadingmechanism of Android is commonly used by dispatchrsquos thread totrigger a new thread Thus we implemented our own thread corre-lation technique based on the Handler mechanism in our Xposedmodule More specifically in the Handlermechanism a triggeringthread that holds a handler instance will submit a runnable to amessage queue via calling the handlerpost(runnable) methodHere the runnable is an instance of Java Runnable [3] with codein its run() method Then the runnable is taken out of the queueby another thread which we name as the handler thread andgets executed in the handler thread Hence as checked in ourXposed module if the executed runnable in a handler thread isthe same instance with one submitted by a triggering thread thenwe correlate the two threads Through such techniques we foundAndroid APIs are indeed called in such handler thread followingthe dispatch threadrsquos triggering ndash this confirms the Android APIcall caused by the dispatcherdispatch functionStep S3 synthesizingAPI-permissionmapping As mentionedin Section 31 system API-permission mappings are incompletewhich can lead to escaped sub-app APIs How to derive a completemapping remains an open question in system security researchand program analysis Here our idea is to supplement recent map-pings [35 46] leveraging documentation analysis we automaticallyextract explicitly declared permissions for system APIs in the devel-oper manuals assuming that explicit specification at least reflectsintended protection of the OS with rare faults Note that certainportion of the documentation (Figure 2) can be misleading to hu-man readers due to incomplete presentation but we observed thatan exhaustive machine-based search on the whole corpus of mobileOSes (eg the entire documentation for all 2497 SDK classes of An-droid API level 27) can help us derive a significantly more completemapping than state-of-the-art mappings [35 46] (see evaluationbelow) For instance after a full scan of Android WifiManager man-ual [75] we were able to flag ACCESS_FINE_LOCATION as a requiredpermission for multiple Wi-Fi scan related APIs (see Figure 8 inAppendix) which has never been included in state-of-the-art map-pings [35 46]

In our implementation we developed a Web crawler to fetchall manuals from Android developer portal [62] and extractedthe description for each public API From the description we ex-tracted the declared permissions based on a few key observations

if the description of an API does not contain a ldquopermission key-word it is very likely that the API does not explicitly requirepermissions otherwise its description usually includes a ldquoper-mission keyword and the exact permission string constants de-fined in Android class androidManifestpermission [77] suchas ACCESS_FINE_LOCATION Based on such observation we per-formed a light-weight string matching to find explicit permissionrequirement of Android APIs (we discuss the sophisticated NLP-based direction in Section 5)

Step S3 also derives a sub-app API-permission map given itsrelatively small size (ie 50 to 172 sub-app APIs in each host com-pared to 35847 public Android APIs found by our Web crawler)we extracted the map by searching ldquopermission related keywordsin sub-app developer manual and manually confirmed the resultStep S4 reporting flaws S4 reports an escaped sub-app API if itis not protected by sub-app permission while its correspondingAndroid API(s) is protected by dangerous permission(s) That is aSystem Resource Exposure flaw is found

For iOS however a comprehensive detection is much more dif-ficult than Android especially because obtaining a system API-entitlement mapping is much more challenging First we are notaware of any work that has produced a mapping on iOS for us tostart with Second we observed that iOS documentation is not asprecise as Android in this regard which describes required enti-tlements for iOS classes but not for individual system API To stillhelp us understand the impact of escaped sub-app API on iOS weextended our findings of escaped sub-app API from Android to iOSif its corresponding iOS API requires an entitlement it is consideredto affect iOS as well This was done by manually searching corre-sponding iOS API for a given escaped sub-app API and checkingwhether any entitlement is asked when the iOS API is invoked inan iOS app we builtEvaluation We evaluated the effectiveness and performance of ouranalysis tool (source code released [12]) on a Google Pixel 2 phoneand iPhone 8 against 11 host apps The evaluation was performedon three Android versions (81 9 10 corresponding to API level 2728 29) and two iOS versions (12 134)bullOverall detection resultsApinat found 39 System Resource Exposureflaws all of them affect Android 81 9 and 10 13 of them affectiOS 12 and 134 We manually validated that all discovered flawsare true in two steps (1) confirming that the sub-app API requiresno sub-app permission through a testing sub-app (2) confirmingthat the corresponding system API(s) has permission protectionthrough a testing native app on Android and iOSbull Evaluating individual steps Step S1 generated test cases for all927 sub-app APIs under test in less than one hour All sub-app APIswere successfully invoked at least once without exception on eachAndroid version In this experiment we did not measure the hostrsquoscode coverage because the host includes implementation of its ownrich functionalities that are unrelated to sub-app API Thus it is notmeaningful to compute the percentage of covered host app code

Step S2 took less than 30 seconds for each sub-app API to reportits corresponding system APIs on each Android version The num-ber of system APIs (protected by dangerous permissions) hookedby S2 is 111 129 145 on the three Android versions respectivelyTo evaluate the correctness of our thread correlation we created

9

a test app which triggered new threads leveraging the Handlermechanism Our test showed that our tool correctly correlated thetriggering and triggered threads on each Android version

Step S3 produced the API-permission mapping including 94public APIs protected by dangerous permissions at API level 27103 APIs at API level 28 and 119 at API level 29 This step took ourapproach three hours to process the descriptions of 35847 42302and 44323 public APIs on the three API versions respectively Tovalidate the correctness of the mapping we constructed a test app toinvoke all the APIs and verify the required permissions at runtimeFor all three Android versions our permission mapping of all except6 APIs are correct Specifically the mapping of 92 APIs out of 94is correct (979 precision) at the API level 27 The two false casesare unprotected APIs hasPermission and requestPermission inclass UsbManager [66] At API 28 the mapping shows a precisionof 971 with one new false case than what was found on API 27(3 cases in total) API 29 shows a precision of 95 with three newcases than API 28 (6 cases in total) Figure 6 and 7 in Appendixlist all six false cases Their descriptions are more complex and weenvision that a natural language processing (NLP) based approachcan further improve our precision (see discussion in Section 5)

To evaluate the coverage of our documentation analysis toolwe randomly selected the documentation of 153 classes 641 APIs(out of 2164 classes) and then manually reviewed and identified52 API-permission mappings as the ground truth Running on theaforementioned documentation our analysis tool shows a precisionof 100 and a recall of 100 to identify API-permission mappingfrom the documentation

We also compared the completeness of our mapping with recentmappings [35 46] They collectively reported 50 public AndroidAPIs that require dangerous permissions on API level 25 (we werenot able to get results of newer Android from the authors) as asignificant improvement our tool was able to find 91 APIs (82more) that require dangerous permissions on the same API versionDiscussion Apinat may not find all escaped sub-app APIs In par-ticular Step S3 cannot derive a complete mapping if the documen-tation is incomplete [56] or too sophisticated to process Apinatonly looks for system resource exposure by public system APIs andundocumented system APIs used by host apps may also lead to theflaw but remain undetected Also Apinat falls short in analyzingobfuscated host apps eg that uses dynamic code loading andimplementations in CC++ Hence Apinat did not scan Web AppAPIs due to the extensive CC++ implementation in browsers Inaddition incorrect documentation (which we assume is rare andindeed our tool did not report any false escaped sub-app API ) mightlead to false alarms if not properly validated

42 Finding UI Deception FlawsDesign To find out the opportunities for Sub-window Deception(Section 32) in a host app Apinat looks for the apprsquos sensitive sub-windows which can be the targets of the attack As discovered inthe wallet UI confusion (Figure 4b) the hostrsquos sub-windows thatare likely to show up in the presence of a sub-app tends to be thosethat can be triggered through sub-app APIs If such a sub-windowalso contains sensitive information our approach then reports it asa potential target for Sub-window Deception

Implementation To detect such sub-windows Apinat monitorsthe change of the host UI in response to each sub-app API callto identify the sub-window triggered by the API call and thendetermines whether it carries sensitive content Specifically ourapproach first constructs a testing sub-app with an empty UI Thenit runs the sub-app API test cases in Section 41 to call each sub-appAPI through the testing sub-app and further inspects the UI screen-shots before and after the call for changes This is done through apixel-to-pixel comparison of two screenshots To capture the screen-shots we developed a screen projection service on Android usingthe Media Projection [63] API Also our screenshot compari-son was implemented using the OpenCV cv2absdiff API [85]For each sub-window identified our approach continues to findthose associated with sensitive information For this purpose itextracts strings from sub-window screenshots using the onlineOCR service [34] From the strings Apinat further utilizes a list of121 sensitive data keywords and the keyword pair list from recentresearch [91] to recognize those carrying sensitive content Notethat like a mobile OS an app-in-app system also provides a set ofsub-app APIs for sub-apps to dynamically generate UI componentssuch as wxcreateCanvasContextdraw() in Wechat To controlfalse positives Apinat omits such sub-app APIs based on the APIcategory in the sub-app API documentation As a result Apinat suc-cessfully detected 6 Sub-window Deception flaws (Section 43) ForiOS we got the same result since sub-app APIs are across-platformthe one triggers a sub-window on one OS also does that on theother (see Section 2)Evaluation Apinat detected 5 sub-app APIs associated with the UIdeception flaw we manually confirmed that all of them trigger sub-windows with sensitive information Also all of them affect bothAndroid (version 81 9 10) and iOS (version 12 134) Performance-wise the screenshot comparison and OCR analysis together tookless than 5 seconds on a desktop with Intel i5 27 GHz CPU and 8GB memoryDiscussion Soundly detecting whether a host app is susceptibleto Sub-app Lifecycle Hijacking (Section 33) is difficult especiallybecause it entails detection of side-channel information leakagewhich can happen in many ways and is hard to capture in generalTo measure a lower bound of the pervasiveness of the problemwe checked whether the hosts in our study (Table 1) had the sameinformation leakage and lifecycle design as reported in Section 33As a result 3 host apps on Android (Wechat Alipay DingTalk) aresusceptible which were all manually confirmed to be exploitable

43 Measurement of ImpactFlaw landscape With the help of Apinat we analyzed 11 highlypopular host apps (Table 1) on Android and iOS and found theyare all vulnerable to APINA flaws (Table 3) Altogether we found 52APINA flaws including 39 System Resource Exposure 10 Sub-windowDeception and 3 hosts vulnerable to Sub-app Lifecycle Hijacking

For System Resource Exposure in total we uncover 39 escaped sub-app APIs associated with 5 categories of exposed system resources4 Android dangerous permissions and 6 iOS entitlements Table 5shows the flaw number for each category of resources (the secondcolumn) and illustrates 8 escaped sub-app APIs with correspondingAndroid permission(s) and iOS entitlement(s) ignored to enforce

10

Table 3 Eleven vulnerable host apps on Android and iOS(A Alipay B Baidu C Chrome D DingTalk F FirefoxJJinRiTouTiao O Opera Q QQ S Safari T TikTok WWechat) NA denotes the flaw does not apply to the OS

Type of APINA Flaw iOS AndroidSystem Resource Exposure A D J Q T W A D J Q T WSub-window Deception A B D W S Q A B C D F W O QSub-app Lifecycle Hijacking NA A W Q

on them All 39 escaped sub-app APIs are listed in our releaseddataset [12] Also Table 6 illustrates 6 Sub-window Deception in non-browser hosts additionally all four browsers we studied (ChromeSafari Firefox Opera) are susceptible to the same Prominent UIattackResource comparison between Android and iOS Althoughfinding the full API-entitlement mapping for iOS is hard we ob-served a few differences between Android and iOS in system re-source protectionbull iOS is less affected than Android Out of 39 escaped sub-app APIs13 are related to iOS which appears to be less affected and harderto be exploited There are two reasons behind the observation asdiscovered in our study First certain iOS APIs return less informa-tion than its Android counterparts (ie those related to Bluetoothsee Section 31) and thus is less susceptible to privacy risk (locationleakage) Hence all 27 Bluetooth related escaped sub-app APIs donot affect iOS (see Table 5) Second WiFi related escaped sub-appAPIs (see Table 5) are much harder to exploit on iOS since Applehas extra protection besides entitlement Specifically right beforethe programmaticWiFi operation an iOS appmust obtain the userrsquosexplicit consent the app must instruct the user to manually openthe WiFi setting page in the Settings app and then return to theiOS app [43] ndash an indicator of user intention for the app to operateWiFibull iOS entitlement fails to communicate risks to the user On Androidwhen the permission ACCESS_FINE_LOCATION is used for protect-ing the operation Wi-Fi scan it indicates a risk that the WiFioperation may leak location a highly private data On iOS how-ever the entitlement for Wi-Fi scan ie Hotspot Helper failsto communicate such a risk Actually to get this entitlement for aniOS app app developers must file a special written request by justi-fying that the app does not have malicious intention Apple reviewsthe request internally and possibly assesses the risks of locationleakage behind the scene However the name of this entitlementand its documentation we could find does not show that Wi-Fiscan needs location protection on iOS This may have been oneof the factors leading to escaped sub-app API wxgetWifiList (seeTable 5) which performs Wi-Fi scan without protectionAttack consequences The system resources exposed by escapedsub-app API and the risks can be identified from the API namesand the permissions they violate (see Table 5) For example unautho-rized sub-apps can use escaped sub-appAPI wxgetRecorderManag-er to record audio (violating Androidrsquos RECORD_AUDIO permission)We summarize the attack consequences in Table 4 Further Sub-window Deception leads to phishing on popular Web services (egFacebook) mobile wallets and sensitive host UIs For exampleWechat has a UI triggered by sub-app API (wxaddPhoneContact)

Table 4 Examples of APINA attack consequences

Flaw Type Consequences (what the adversary is able to do)

SystemResourceExposure

record audio operate camerainfer victimsrsquo geo-location (thus track users)

connect victimrsquos device to arbitrary Wi-Fi (thus manipulatenetwork traffic perform man-in-the-middle (MITM) or phishing)

and steal sensitive QR code etcSub-windowDeception

steal account credentials on Facebook Google Amazon etcsteal mobile wallet passwords contacts etc

Sub-appLifecycleHijacking

steal money (payments in shopping sub-app)steal personal secrets (eg answers tosecurity questions health records etc)

steal business documents (from a document processingand management sub-app published by Microsoft)

steal account credentials of Amazon ICBCCCB HSBC (1st 2nd 7th largest banks in the world)

Airbnb Weibo Starbucks McDonaldrsquos etc

for users to enter contact information (Table 6) attacking this UImay leak contacts which are highly private Last Sub-app LifecycleHijacking affects three hosts (Table 3) and the risks come fromimitating sub-apps supported by these hosts such as sub-apps forAmazon health banking Airbnb etc (see Table 4)Cases Studies We discuss a few other problems we observed inapp-in-app ecosystembull Keeping up with the OS evolution Sub-app API permission policyshould keep up as the OS always evolves newer OS version oftenintroduces more strict protection against sensitive resources Forexample since Android 10 an app that accesses location in the back-ground needs an additional dangerous permission ACCESS_BACKGRO-UND_LOCATION in addition to the regular location permission [82]This protects user location against illicit tracking However sub-app API for accessing location in hosts TikTok and Alipay did notkeep up with such a new protection thus leaving their users at risk

As another example for the WiFi and Bluetooth scan that canleak location Android 9 and 10 require ACCESS_FINE_LOCATIONpermission while Android 81 is less restrictive and ACCESS_COARSE_LOCATION is sufficient (see Table 5) Note that Android uses the firstpermission to control access to precise location (eg GPS data)and uses the second one for coarse-grained positioning (with anaccuracy approximately at the level of a city block [10]) Interest-ingly all hosts we studied only define a general location sub-apppermission to govern location API (eg scopeuserLocation inWechat) but do not differentiate the two levels of accuracybull Too many APIs for one permission APIs of apparently differentfunctionalities should never be governed by the same permissionHowever in the host TikTok (an extremely popular short-videosharing app with more than 500million downloads on Google Play)three sub-appAPIs ttscanCode ttchooseImage and ttchoos-eVideo (for scanning QR code accessing photos and videos) aregoverned by the same permission scopecamera and thus inade-quately protected For example a malicious sub-app that is grantedpermission by the user to scan QR code also behind the scenesilently gets access to API ttchooseImage that accesses user pho-tos posing a serious privacy risk

5 LESSONS AND MITIGATION STRATEGYLessons learned The most important lesson learnt from our re-search is the caution one should take when building a third-party

11

Table 5 Summary of System Resources Exposure flaws (NA means the flaw does not affect the OS)

SystemResourceExposed

of

FlawsExample of Escaped

Sub-app API Dangerous Permission Android API Entitlement iOS Class

Microphone 1 WechatwxgetRecorderManager RECORD_AUDIO mediaMediaRecorder

CaptureRequest Microphone Usage AVAudioRecorder

Camera 3 Alipay myscan CAMERA CameraManageropen-CameraCaptureRequest Camera Usage AVCaptureSession

Wi-Fi 4WeChatwxgetWifiList

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetScanResults Hotspot Helper dagger NEHotspotHelper

JinRiTouTiaoTikTokttgetConnectedWifi

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetConnectionInfo Access WiFi Information dagger CNCopyCurrent-

NetworkInfo

Bluetooth 27

Alipay mystartBluetoothDevicesDiscovery

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan NA NADingTalk

ddgetBluetoothDevicesAlipay

mygetBLEDeviceServices

iBeacon 4 Alipay mygetBeaconsACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan Location Usage CLBeaconRegion

dagger Much harder to exploit on iOS due to the requirement of explicit user approvalDagger Android 9 and 10 require ACCESS_FINE_LOCATION permission while Android 81 requires ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION

Table 6 Examples of Sub-window Deception flaws

Host App Triggering Sub-App API Legitimate (and spoofable)Functionality of the Sub-window

Alipay mytradePay Request password ofAlipay mobile wallet

Baidu swanrequestPolymerPayment Request passwords ofmultiple mobile wallets

DingTalk ddpay Request password ofAlipay mobile wallet

WechatwxaddPhoneContact Enter new contacts

wxrequestPayment Request password ofWechat mobile wallet

QQ new in-app message Display instant messagesand enter a reply

sub-ecosystem on top of the operating system In such a case thethird-party OS-like app strives to provide a secure self-containedenvironment However whether it undermines OS security andbrings in new risks to modern mobile applications need to be eval-uated to identify the security gap between the new sub-ecosystemand the OSes Our measurement study shows that popular host appsare generally susceptible to APINA flaws indicating that the app-in-app system vendors today either fail to identify or are unpreparedfor the new risks

Fundamentally APINA risks come from the limited app-levelcapabilities the host app has in managing OS resources lack ofOS-level support and missing of sub-app API standard Hencedown the road it will require non-trivial joint efforts to fundamen-tally eliminate APINA risks More specifically escaped sub-app APIshows that a third-party host fundamentally lacks the full OS-levelknowledge on system resource protection While such knowledgecan come from different sources eg program analysis on relevantOS modules [35 46] developer documentations technical reportsetc each source only contributes a partial view Hence joint effortsneed to be made in the future to synthesize such knowledge Ourstudy also brings to light that such efforts are by no means trivialndash even the two leading mobile OSes have apparently confusingconflicting security policies Synthesizing such a knowledge base

will not only benefit the app-in-app paradigm but also make theOSrsquo security mechanism more transparent for thorough auditing

Our findings also highlight that prior OS lessons cannot fullyeliminate new risks incurred by the new paradigm which necessi-tates thorough assessment regarding its new attack surfaces Forexample a malicious sub-app a sub-window and a task in Recentsscreen all come as new attack vectors that pose credible new threatsto usersrsquo most sensitive credentials and privacyMitigation strategy Following we propose the short-term miti-gation and discuss the long-term strategybull Escaped Sub-app API Eliminating the risk requires the host tohave full OS-level knowledge about resource control (eg API-permission mapping) which is difficult In the meantime our toolApinat together with our API-permission mapping (released on-line [12]) can help host app vendors identify escaped sub-app APIsNote that since Apinat can identify escaped sub-app API with itsignored permissions with respect to specific OS version (see Sec-tion 43) host vendors may leverage our tool to assess whether theirsub-app API permission policy is always compliant with newly re-leased OS version and thus keep up the pace

Further we envision two possible future directions that couldlead to more viable solutions First as demonstrated by our anal-ysis tool Apinat although it is hard for todayrsquos program analy-sis techniques to derive a complete system API-permission map-ping [35 46] we could significantly improve its accuracy and com-prehensiveness through developer documentation analysis Ourcurrent documentation analysis is rather preliminary but still effec-tive as demonstrated in our study (Section 4) Down the road wecould develop natural language processing (NLP) based techniquesfor deriving more complete knowledge about API permission poli-cies With the techniques an analysis could cover a wider spectrumof literature including iOS documents research papers technicalreports etc which will help derive up-to-date knowledge aboutresource-management policies

Second the app-in-app community should work together tostandardize sub-app APIs and their permission policies as donein the HTML5 community on HTML5 APIs For the time being

12

different app-in-app vendors bring in their own APIs for accessinga wide spectrum of systems resources (see our comparison betweensub-app API and HTML5 API in Table 7 in Appendix) often withoutproper safeguard in place not to mention any effort to standardizethe protectionbull Sub-window deception The risk comes from the UI confusionwhether a window portion in the sub-app window belongs to thesub-app or the host (Figure 3b) To mitigate the risk we envision ahigher degree of UI isolation between the sub-app and the host thesub-apprsquos window should always be separated from that of the hostand the host should never reclaim any window portion from thesub-applsquos window Regarding the Wallet UI confusion (Section 32)for example Wechat should display its wallet UI only in its ownwindow and advertise to users that any UI component inside thesub-app window belongs to the sub-app

A question arises whether a malicious sub-app can fake a crashand then show spoofing content in the sub-app window to resem-ble the host This can be mitigated through additional protectionsupported by the host Specifically the host app could keep mon-itoring the UI of its sub-apps (eg through PixelCopy API onAndroid [71]) to detect whether a UI object in the sub-app is similarto a sub-window or a security-sensitive UI object associated withhost app For performance concern the host app could utilize thestate-of-the-art object detection model (eg Fast Region-based Con-volutional Network based model [61] and YOLO [32 95]) for thereal-time security-sensitive UI object recognition as reported inprior research [95] Fast YOLO yields the performance of 155 framesper second Note that the effectiveness efficiency and deploymentfeasibility of such an approach need to be carefully explored andevaluated which we leave for our future researchbull Sub-app lifecycle hijacking To mitigate this risk a short-termdefense is to place all sub-app resources in the phonersquos internalstorage so our current exploit (leveraging monitoring the phonersquosexternal storage) to track sub-app lifecyle termination (Section 33)can be mitigated However it is always a concern that sub-appsmay deplete the limited space on a phonersquos internal storage Along term solution needs to consider how to make the sub-apptasks dynamically scalable to ensure that the sub-app recycling isno longer traceable and thus the attack surface is fundamentallyeliminated This nonetheless calls for support from modern OSesfor the emerging app-in-app paradigm

6 RELATEDWORKAs mentioned in Section 2 recent years witnessed several tech-niques to support the functionality of app encapsulation (eg Plu-gin frameworks app sandboxing browser extension and PhoneGapapp see Table 2) Accordingly numerous studies have looked intothe flaws in these app encapsulation systems considering the se-curity analysis of Plugin frameworks a set of flaws were revealed[99 111 112] including no permission management and no isola-tion of the virtualized apps Compared with Plugin frameworks theapp-in-app paradigm has a much stronger security model and ourstudy investigates the design challenges and pitfalls in the securitymechanism Meanwhile the security and privacy implications ofbrowser extensions have been extensively studied [48 54 84 98]

Furthermore the current security studies on PhoneGap apps fo-cus on the flaws of PhoneGap frameworkrsquos access control policy[60 90 100 101] For example Song et al [101] revealed that thebridges added by the framework to the browser are not correctlyprotected by the same origin policy Jin et al [86] introduced mul-tiple channels (eg barcode SMS file system Contact) for codeinjection attacks in PhoneGap apps Different from these works wefocus on the unique features of the app-in-app paradigm (Table 2)and reveal multiple new attack surfaces which have never beenstudied before

The closer to our study are the works of Web App and WebViewvulnerability assessment Up to our knowledge only one paper[87] analyzed security issue of Web App in which the securityand privacy risks on HTML5 features in PWA were investigatedIn our attack on Web App we did not focus on HTML5 featuresbut a general UI isolation and management model in app-in-appparadigm Also although WebView technique is used in some ofthe app-in-app systems in sharp contrast to the works on Webviewweaknesses [36 60 88 102 105 109 110] our study explores thesecurity implications and challenges for a third-party app tomanageoperating system resources Another set of works related to ourstudy is the exploitation of mobile UI deception Prior phishingattacks [38 49 53 57 97] mislead victims about the foregroundapp aiming at information theft in spoofing apps Correspondingcountermeasures [49 58 96] emphasize identifying the app of thewhole foreground window and thus cannot thwart Sub-windowDeception due to the inability to identify sub-windows Furtheranother angle of UI deception is clickjacking [59 94] which aredifferent from our mobile-phishing attacks7 CONCLUSIONIn this paper we present the first systematic security analysis on re-source management in high-profile app-in-app systems Our studyshows that such systems are susceptible to a set of serious securityflaws Our measurement study further sheds light on their perva-siveness in the real-world Further our study brings in new insightsinto the fundamental security limitations of this new paradigm andfurther contributes to a better understanding of its mitigation strat-egy an important step towards building a more secure app-in-appecosystem

8 ACKNOWLEDGMENTWe would like to thank our shepherd Yanick Fratantonio and theanonymous reviewers for their insightful comments This work issupported in part by the NSF CNS-1618493 1801432 1838083

REFERENCES[1] 2011 HTML5 Fullscreen API Attack httpsferossorghtml5-fullscreen-api-

attack[2] 2011 The Inception Bar httpsjameshfishercom20190427the-inception-

bar-a-new-phishing-method[3] 2018 Java Runnable httpsdocsoraclecomjavase7docsapijavalang

Runnablehtml[4] 2018 A one year PWA retrospective httpsmediumcompinterest-

engineeringa-one-year-pwa-retrospective-f4a2f4129e05[5] 2018 Wechat 1 million sub-apps httpswwwscmpcomtecharticle2153705

tencents-wechat-now-host-1-million-mini-programs[6] 2018 WeChat reaches 1M sub-apps half the size of Applersquos App Store https

techcrunchcom20181107wechat-mini-apps-200-million-users[7] 2018 Xposed httpsapixposedinforeferencepackageshtml[8] 2019 AdBlock httpsgetadblockcom

13

Table 1 Popular host apps and the amount of sub-apps avail-able in the host apps

Host App Functionality (of the host itself except sub-apps) Number ofSub-App

Number ofDownloads

WeChat Instant Messaging Social NetworkingSocial Media VoIP Mobile Wallet 1M+ 200M+

AlipayMobile Wallet FinanceInvestment Management

Shopping News Social NetworkingUtility Bill Management Travel

120000+ 1B+

Chrome Web Browser NAdagger 1B+Safari Web Browser NAdagger NAdagger

TikTok Video Sharing Instant MessagingPersonal Blog Game Center NAdagger 500M+

JinRiTouTiao News Feeding live streaming NAdagger 1M+

QQInstant Messaging VideoAudio Chatting

File Transfer Personal BlogGame Center Mobile payment

NAdagger 10M+

Firefox Web Browser NAdagger 100M+Opera Web Browser NAdagger 100M +

Baidu Search engine News Short VideosVoice Recognition Readings NAdagger 230M+

DingTalk Address Book Mobile Office Tool BoxVideo Conference 20000 500K+

Total - 1M+ 26B+

dagger Lack public information

21 ArchitectureTo enable native-app experience for sub-apps each host app pro-vides a set of sub-app APIs for sub-apps to access diverse systemresources (such as the camera microphone Bluetooth NFC Con-tacts photos) Also the sub-app is cross-platform it is typicallydeveloped in script languages (particularly JavaScript [20]) andruns on both the Android and iOS version of its host app Thesefeatures are fulfilled by the host app through a cross-platform run-time called sub-app runtime in this paper Below we summarize itstypical architecture which we learned through reverse engineeringpopular host apps (Table 1)

Figure 1 outlines a typical app-in-app architecture from the per-spective of resource access Specifically the host app consists of asub-app layer where all sub-apps live and a sub-app runtime wherea generic abstraction was provided for system and host app resourceaccess Sub-app runtime bridges sub-app API calls (in JavaScript)into the native layer (in Java on Android and Objective-C [39]or Swift [40] on iOS) of host apps The native layer then enforceshome-grown permissions of the host app (aka sub-app permis-sions) and either accesses host resources or calls correspondingsystem APIs to access system resources

Specifically in the script layer invoking a sub-app API (egconnectWiFi) will trigger an Encapsulation lib which then calls anative function (eg dispatcherdispatch(rsquoconnectWiFirsquo)) tobridge the control flow into native layer Particularly we found twocommon bridge techniques adopted by host apps WebView [79]and React Native [55] To use Webview a host app leverages aWebView API addJavascriptInterface(obj lsquodispatcherrsquo)to expose a native object obj aliased lsquodispatcherrsquo to the script layerits dispatch function is then accessible in script layer as mentionedabove Given each sub-app API the dispatch function invokes thecorresponding native-layer libraries to check sub-app permissionand access resources To use the React Native bridge the majordifference here is how to expose the native object to script layerdispatcher objectrsquos class in the native layer namely Dispatchermust inherit an Interface ReactPackage of React Native framework

Figure 1 A typical app-in-app architecture

dispatcher object is then specified in a configuration file andexposed to the script layer by React Native framework [55]

22 Security Model in Resource Managementbull Sub-app permission The app-in-app system uses the traditionalpermission label assignment model to protect sub-app APIs Inparticular sub-app requests a list of sub-app permissions whichgovern the access to the sub-app APIs If the sub-app APIs accesssensitive system resources (ie protected by dangerous [76] permis-sions on Android or entitlements [17] on iOS1) or sensitive host appresources (non-system resources under host apprsquos control such asuser profile ID gender managed by Wechat) a host app enforcessub-app permissions for calling the sub-app APIs For exampleWechat defines a sub-app permission named scoperecord to pro-tect its sub-app API wxstartRecord which is used to record audiousing the phonersquos microphone Note that host apps typically donot intend to protect less sensitive system resources ie thoseprotected only by Android normal permissions or not protected byOSesbull Isolation Each sub-app has its unique ID assigned by the hostapp Sub-app cannot access resources of the OS host app and othernative apps and sub-apps without going through an authorizedchannel provided by the host Each sub-app has a unique datastorage managed by the host appbull Sub-app vetting Like traditional app stores all sub-app storesin our study also require a sub-app to be reviewed before beingpublished The sub-app vetting process consists of risk assessmentalong with additional criteria to determine whether a sub-appviolates user privacy or data security requirements Examples ofthe security requirements include any sub-app shall not requestor induce users to enter the host apprsquos user ID and passwords [30]and user data collected via a sub-app may not be sold transferredtraded or disclosed [51]

23 Comparison with Existing AppEncapsulation Systems

Similar to the app-in-app system other approaches can also ldquoencap-sulaterdquo an application to run in the execution environment provided1iOS entitlements which confer security permissions and capabilities [41] are strictlyprotected by Apple and must be explicitly declared and vetted [108]

3

Table 2 Comparison with existing app encapsulation sys-tems ( Not Supported Partially Supported Fully Sup-ported)

System Features And

roid

Plug

inFram

ework

App

Sanb

oxing

Brow

serE

xtension

Phon

eGap

App

App

-in-app

Sub-app API ecosystemfor system resource access

dagger dagger

The host has rich functionalitiesapart from hosting

Mandatorysub-app destruction

dagger supported by HTML5 API which is standardized by W3C and thus much easier tomanage than sub-app API

by another app A prominent example is Android Plugin framework(eg Parallel Space [23] DroidPlugin [15] and VirtualApp [26])an app virtualization technology through which a ldquohost app canload other Android apps (called ldquopluginrdquo apps) from their APK filesto run in the hostrsquos own process [111 112] This is done throughwrapping the system APIs for invoking plug-in apps which sharethe hostrsquos UID and permissions during their executions [99 111]Also mobile app sandboxing (eg Boxify [47] and NJAS [50]) isanother way to virtualize apps The idea is to encapsulate untrustedapps in a restricted execution environment within the context ofa trusted sandbox app which provides an emulation layer to ab-stract the underlying OS and interposes all interactions (eg sys-tem calls binder IPC) between the untrusted app and the OS [47]Other app-encapsulation solutions include Browser extension2 (egAdBlock [8] EditThisCookie [16]) where a small program cus-tomizes a web browser with the support of HTML5 (for controlledsystem-resource access) and extension APIs (for browser-resourceaccess) [13] and PhoneGap apps (or HTML5 based mobile apps)where a middleware framework (eg PhoneGap [24] Cordova [11]Ionic [19]) is used to allow the developer to create mobile appsusing web technologies [31 86]

Table 2 compares the above solutions with the app-in-app systemin terms of their security implications As we can see here unlikethe app virtualization based Plugin framework and app sandboxingthe app-in-app platform builds up its own API ecosystem (ie sub-app APIs) for sub-apps to access system resources which entailsnon-trivial efforts to define and maintain its security model such asthe sub-app API permission policies Such policies are standardizedfor HTML5 APIs used by browser extensions [103] but are ad-hocopaque and often inadequate for the sub-app APIs that are muchmore powerful and access more sophisticated system resourcesthan HTML5 thereby opening new attack avenues (see Section 31and Table 7 in Appendix) Furthermore compared with other solu-tions dedicated to application encapsulation the app-in-app host2Browser extension is different from the deprecated Browser Plugin architecture [14]Browser Plugin is generally not considered as an encapsulation system since the pluginsare independent executables and their access to system resources are not encapsulatedby the browser

has its own rich functionalities (eg mobile wallets messagingsee Table 1) which are often shared with the sub-apps For exam-ple e-commerce sub-apps (eg Amazon Pinduoduo) leverage thehostrsquos built-in wallet feature for convenient payment process (seeSection 32) In our study we found that such interactions (betweenthe sub-app and the host app) actually exposes a new attack sur-face (Section 32) Also the upper limit on the number of sub-appsthat can run concurrently on an app-in-app platform is public andfixed (8 in Chrome 5 in Wechat 4 in Alipay) whenever the limitis reached the host has to terminate a sub-app in order to launcha new one This feature which does not exist in other systemscan be abused for deception attack as discovered in our research(Section 33)

24 Adversary ModelWe assume the host app is benign which aims to provide a secureenvironment to run sub-apps On the victimrsquos Android or iOS de-vices where at least one app-in-app system is used we consideran adversary with his malicious app3 or sub-app installed Notethat none of our attacks requires the victim to install both InSection 3 we show that such malware can successfully pass thevetting of popular sub-app stores Google Play third-party appstores etc The malware sample does not have system privilege andin some of our attacks may need to ask for a set of common permis-sions from the users (eg Androidrsquos READ_EXTERNAL_STORAGE andWRITE_EXTERNAL_STORAGE) depending on specific attacks Suchpermissions are extensively requested by popular apps such asFacebook Gmail and Pinterest Therefore we believe that claimingthem by the malicious app will not arouse obvious suspicion

3 DESIGN CHALLENGES AND PITFALLSIn this section we report our security analysis on resource manage-ment in app-in-app systems Our research shows that all app-in-appsystems we studied including Wechat Alipay TikTok ChromeSafari etc are subject to various APINA flaws leading to seri-ous exposure of system resources and new deception attacks Morespecifically the security analysis has been systematically performedby assessing two general categories of resources system resourcesaccessible through system APIs and user interfaces For each re-source we looked at the security policies that should be in placethe mechanism that enforces the policies and the user interactionswith security implications

31 System Resource ExposureSub-apps access system resources through sub-appAPIs (Section 21)However for the host as a third-party app constructing sound sub-app API permission policies that govern system resources entailschallenges that are unexpected before As a result sensitive systemresources are often unwittingly exposed to unauthorized sub-appsEscaped sub-app API Sub-app APIs are protected by sub-apppermissions which are supposed to be consistent with the permis-sions required by the OS when using the relevant system APIs theywrap For example since the OS requires permissions to use its

3In this paper we use the term app and native app interchangeably Also although thehost app is a native app itself the term app or native app in this paper always refers toan app that is not a host app for ease of presentation

4

Figure 2 Misleading Android documentation

audio recording APIs (RECORD_AUDIO [72] permission on Androidand Microphone Usage [42] entitlement on iOS) the sub-app APIto record audio (eg wxstartRecord in Wechat) should also beprotected by a sub-app permission (eg by sub-app permissionscoperecord in Wechat) However in our study we found theinconsistency in permission requirement between sub-app API andsystem API indicating that the host fails to create the correct per-mission policies that govern sub-app API for system resource accessAs a result certain sub-app APIs that wrap permission-protectedsystem APIs are completely open to any sub-apps without requir-ing a sub-app permission exposing sensitive system resources Wename such unprotected sub-app API escaped sub-app API and theproblem System Resource Exposure

An example discovered in our research is the unprotectedWechatsub-app API wxgetWifiList that performs WiFi scan a capa-bility protected by the underlying OSes against user location leakeg through an entitlement Hotspot Helper on iOS and danger-ous level location permissions (ACCESS_COARSE_LOCATION andACCESS_FINE_LOCATION) on Android This exposes the WiFi scancapability to sub-apps leaking out user location to them Notethat a high-profile host app (eg Wechat) is typically granted thelocation permission and many other permissions due to its richfunctionalities (see Table 9 in Appendix) As a result through thedelegation the host makes to the sub-app escaped sub-app APIeffectively opens a door for the adversary to gain unauthorized ac-cess to system resources In addition to wxgetWifiList we foundmany other escaped APIs in popular app-in-app systems affectingdiverse sensitive resources across iOS and Android (Section 43)

Looking into the possible root causes we found that it is verychallenging for an app-in-app system to soundly define sub-appAPI permission policies that comply with the OSes in governing sys-tem resources due to the incomplete knowledge about permissionchecks that happen at related system APIs Specifically official API-permission maps for both Android and iOS have never been madepublic Although several prior attempts [35 45 46 56] have beenmade to automatically map Android APIs to their required permis-sions we found that the prior results are incomplete (Section 43)and highly likely to introduce escaped sub-app APIs if they are usedto design a sub-app permission system Consider the above exam-ple of WiFi scan recent results [35 46] (on Android API level 25)report that a related Android API WifiManagergetScanResultsrequires just a normal permission ACCESS_WIFI_STATE but failto mention that dangerous permission location is also required(required since Android API level 23 [80]) Further Section 43 re-ports more escaped sub-app APIs possibly caused by the incompleteAPI-permission maps

Such API-permission mapping information has also not beenwell recorded by the developer documentation We found that suchdocumentation can be misleading or confusing Again let us useWi-Fi scan as an example as shown in Figure 2 the Android

documentation [75] may introduce the misconception that declar-ing ManifestpermissionCHANGE_WIFI_STATE is sufficient forWi-Fi scan Similar misguidance also appears on the Android doc-umentation for Bluetooth scan etc and has likely caused otherescaped sub-app APIs we found (Section 43)

Another observation of our study is that since sub-app APIis designed to be cross-platform (Section 21) the effort to buildsub-app API permission policies that comply with all OSes hasbeen complicated by the inconsistency between Android and iOSin resource protection Consider Bluetooth scan as an examplethe Android API BluetoothLeScannerstartScan requires thedangerous location permission while iOS does not Such a dis-crepancy likely causes confusion in app-in-app design which istypically built for both OSes with uniform security policies Whenthis happens we found that the app-in-app designer tends to leavethe related sub-app API unprotected For example the sub-app APIsfor Bluetooth scan are not protected in multiple host apps (egwxgetBluetoothDevices in Wechat) Actually the difference inpolicy-level protection could result from an additional securityguard put in place by the OS which is unaware to the app-in-appdesigner For example combining together Signal Strength andDevice ID of nearby Bluetooth devices reveals geo-locations [37]On Android the pair is returned together by the above Bluetoothscan API BluetoothLeScannerstartScan which thus needs apermission check on iOS however the pair has been partially ob-fuscated (Device ID is randomized) and is thus unprotected Wesuspect that the inconsistency as observed on capabilitiesresourcesWi-Fi scan Wi-Fi connect iBeacon etc is likely responsiblefor other escaped sub-app APIs we discovered (see Section 43)Discussion Android 60 (API level 23) started to use a runtimepermission model a user grants permissions at the apprsquos runtimewhen permissions are requested (eg when the app launches orwhen the user accesses a specific feature) [73] In this scenariowhen an escaped sub-app API tries to silently access a resourcethe host may have not been granted a permission to access thatresource thus a permission will be explicitly required Howeverthe OSrsquo permission granting window will show to the user thatit is the host app who requests the permission not the sub-appThis misleading request may lead to the wrongly inherited trustassociated with the hosts and make users grant the permissioninappropriately This is also the case on iOS when a permissionwindow pops up to confirm the hostrsquos access to a resource

Furthermore Table 9 in Appendix lists all Android dangerouspermissions and iOS entitlements requested by the vulnerable hostsright after launching It shows that the hosts proactively requestnecessary permissionsentitlements even before accessing any spe-cific features due to usability consideration [92] Those capabilitiesof the hosts will always be stealthily delegated to the sub-app viaescaped sub-app APIs which present serious risksAttacks and vendor acknowledgements We implemented anattack sub-app which ran inWechat v673 to steal userrsquos location onboth Android and iOS The attack sub-app utilized Wechat escapedsub-app API wxgetWifiList to perform Wi-Fi scan and snifferthe surrounding Wi-Fi access points The scan results included sen-sitive information ie BSSID Signal Strength and Device ID ofnearby Wi-Fi access points which enabled to infer the geolocation

5

(a) Real Prominent UI (b) Fake Prominent UI

Figure 3 Safarirsquos Prominent UI confusion on iOS

of a user [37] This attack sub-app successfully passed the vettingof Wechat sub-app store and ran on both iOS and Android versionsof Wechat Note that our attack sub-app has less than 200 lines ofcode which indicates that it is cost-effective for the adversary todevelop APINA flaws malware in the wild Besides we successfullybuilt attack sub-apps in other host apps eg Alipay DingTalk etcand reported the problems to all affected host-app vendors Theyall acknowledged the problem in particular Wechat and Alipayawarded us through bug bounty programs for this flaw

32 Sub-window DeceptionAnother unique app-in-app feature is the functionality-level inter-actions between the host and sub-app For this need the host doesnot fully isolate itself from sub-apps which unwittingly introducesnew attack surfaces and high spoofing risks against host-app UIBrowsersrsquo Prominent UI confusion To bring a native app-likeexperience Safari on iOS and Chrome on Android open each sub-app (ie Web App Progressive Web App or PWA) in an entirededicated window separate from the browser window just like anative app [44 78] ndash without any browser UI such as the addressbar Web App is programmed with JavaScript and HTML but mustmeet certain standards [68] With user confirmation the browsercan install a Web App to the phonersquos home screen (through anAPK [69] package created by Chrome or a Web Clip [44] createdby Safari) Such Web App takes the full screen if ldquostandalone orldquofullscreen is specified in its manifest file EachWeb App is clearlyassociated with specific Web domain when installed When the usernavigates to out-of-scope URL (ie of different origin) in a WebApp the browser displays a Prominent UI ndash a banner at the top ofthe screen (Figure 3a) showing the origin and secure connectionstatus ndash due to the lack of address bar According to Web Appdocumentation [67] users rely on such Prominent UI to be awarewhen they navigate out of scope an important security notice

Based on a study [57] mobile phishing attacks tend to happenwhen users become accustomed to familiar repeated contexts Morespecifically if users frequently encounter legitimate context theywill become conditioned to reflexively respond to it Here the cur-rent design of Web App conditions users to see the Prominent UI inout-of-scope navigation which we found poses a spoofable context

(a) Authentic wallet UI (b) Bogus wallet UI

Figure 4 Mobile wallet UI confusion

Specifically Web App is designed to embrace out-of-scope brows-ing [104] and let users freely navigate to other Web domains forservices such as login through FacebookGoogle (aka SSO [107])payment through PayPal etc The problem is that when a victimuser navigates out of scope eg to Facebook login page a mali-cious Web App can actually navigate to an in-scope phishing pageimitating Facebook showing a bogus Prominent UI (as if shown bythe browser) to misleadingly inform the victim that she is on a realFacebook domain (Figure 3b) In this way the malicious Web Appcan collect victim usersrsquo secrets such as Facebook passwords

We call this problem Sub-window Deception ndash sub-window meanspart of a window Prior phishing attacks in browsers exploredhow a webpage can go full screen and spoof the address bar [12] as another instance of mobile browser UI attacks our attackcomplements the prior understanding by exploiting ProminentUI ndash the counterpart of address bar in the context of native app-like Web App Note that address bar differs from Prominent UIin design based on the Web specification [106] browsers ldquoshouldprovide a means of exiting fullscreen that always works and advertisethis to the user [106] so users can see the real address bar whenthey want (although browsers may not implement this protectionproperly [89]) Web App users however lack practical mechanismsto verify the authenticity of Prominent UI today This attack appliesto general Web App on both iOS and Android we reported it toW3C4 Apple Google Firefox and Opera which all acknowledgedthe importance of the problemMobile Wallet UI confusion Wechat and Alipay both featuremobile wallets which can be leveraged by e-commerce sub-appsto provide users a convenient payment process Amazon sub-appfor example after a user clicks its ldquocheckout with Wechat wal-letrdquo button will invoke a sub-app API (eg wxrequestPaymentin Wechat) to trigger the hostrsquos wallet the host then reclaims acentral portion of the screen from the sub-app to show its walletUI (highlighed in Figure 4a) for the user to enter her wallet pass-word and finish the payment Such a context can condition usersto reflexively provide wallet passwords at checkout and thereforepresents a practical spoofing target Specifically when a victim userclicks the ldquocheck out button in a malicious e-commerce sub-app itcan show a bogus wallet UI (Figure 4b) to collect the userrsquos walletpassword instead of invoking the real wallet

4We do not provide the link to our report for anonymization purpose

6

(a) Real sub-app task (b) Bogus sub-app task

Figure 5 Dedicated task for every sub-app in Recents screen

Up to our knowledge state-of-the-art mobile anti-phishing tech-niques cannot identify our attacks for example [49 58 96] mainlyrely on identifying the app of the whole foreground window so theuser would not expose secrets to the unintended app this cannotidentify a sub-window at the sub-app level ndash whether it belongs toa sub-app or the host app

Our study shows that a bogus sub-window presents a practicalattack vector in app-in-app since a window portion (sub-window)can be used by both the sub- or host- app in accustomed contextswithout differentiation through clear identification From a broadersense we believe the spoofing risk is also high if the OS showsits pop-up atop an app (so malicious app can show a bogus onewhen the OS does not) however in sharp contrast such pop-upis not sub-window (but whole window) and known anti-phishingtechniques (eg [49]) to identify (the owner of) the whole windowcan defeat itAttacks and vendor acknowledgementsWe implemented PoCattacks in Safari on iOS Chrome on Android and Wechat on bothOSes in Safari and Chrome our malicious Web App impersonatesProminent UI to spoof Facebook login page in Wechat our mali-cious sub-app mimics the wallet UI to steal wallet password (seevideo demo online [12]) Our malicious sub-app passed the vettingof Wechatrsquos sub-app store Note that Web App does not have appstores and can be installed after visiting its URL In addition wereported the problems to all affected host vendors who all acknowl-edged that the threats were practical and severe Wechat and Alipayawarded us through their bug bounty programs

33 Sub-app Lifecycle HijackingAs app vendors follow the app-in-app trend by releasing sub-appsit is unclear whether their users remain equally protected as beforeUnfortunately our study shows that even highly credible host appscannot fully eliminate new attack surfaces incurred by app-in-appRecents screen takeover The Recents screen (aka recent task listor recent apps) [64] is a system-owned UI of Android to list recentlyaccessed task (Figure 5a) In particular each launched native appwill have a task in Recents screen similarly a host app creates aseparate task for every launched sub-app which appears in Recentsscreen Limited by the OS each host app can only create a fixednumber of tasks in Recents screen pre-specified as activities inits manifest file In our research we found that host apps all specify

a small magic number (eg 8 in Chrome 5 in Wechat 4 in Alipay3 in JinRiTouTiao) for the task limit

When an additional sub-app will be opened after the task limitis reached the host app silently executes a mandatory recyclingprocess closing the first opened sub-app to recycle its task forlaunching the new one The recycling process is transparent tousers for the possible purpose of not interrupting the user experi-ence Such a mandatory sub-app recycling mechanism introducesa new risk once the recycling is traceable by a malicious appie the adversary knows which sub-app has been recycled and atwhat time it can stealthily insert a phishing task into the Recentsscreen to imitate the silently recycled sub-app For this purposethe adversary needs to acquire the information about a hostrsquos taskrecycling which turns out to be feasible due to the presence ofvarious information-leak avenues that can be hard to eliminate Inour study we found a side channel that enables recycling track-ing in multiple host apps In particular possibly due to the richfunctionalities of sub-apps which require resource files (eg userdata logs icon and image texture) the host app creates a folderin Android external storage [18] to cache sub-app resources Suchexternal storage can be monitored by an Android native app totrack which sub-app is launched and at what time (by monitoringsub-app icon which will be downloaded at launch see PoC attackbelow) Thereby once the number of launched sub-apps reachesthe hostrsquos task limit the sub-app to recycle can be inferred Hencea malicious native app can insert a bogus task in Recents screento mimic the recycled sub-app at this point the bogus task is theonly one in Recents screen that represents the target sub-app thatrsquosspoofed (Figure 5b)

This attack is a kind of mobile task hijacking attacks [52 97]Regarding its root cause the mandatory sub-app recycling opens anew attack surface for app-in-app systems since it makes it possiblefor malicious apps to track a sub-apprsquos lifecycle termination Notethat the attack surface becomes exploitable in the presence of sidechannels eg external storage which itself is a relatively trivialbug Other side channels could also be used for the attack once theyarise (see discussion below) Eliminating this attack surface maynot be trivial in practice since the maximum task number of a hostin Recents screen is not dynamically scalable (statically specifiedin manifest) limited by the OS Although the very recent Androidsupports dynamic task no host app we studied (Table 3) adoptedit possibly for the purpose of supporting older Android versionsgiven the notorious Android version fragmentation [74]Attacks and vendor acknowledgementsWe implemented PoCattacks on Alipay andWechat which cache sub-app resources in theexternal storage and enable recycling tracking Specifically Alipaystores the caches at sdcardalipaymultimedia When a sub-app such as Amazon is launched its icon will be downloaded toit if not already there Our malicious Android app with a commonpermission WRITE_EXTERNAL_STORAGE can remove cached iconsperiodically andmonitor when they reappear to knowwhat specificsub-app is launched and at what time In our attack of Alipay oncethe malicious app infers that five sub-apps have been launched(submit-app task limit of Alipay is 4) it will insert a bogus task inRecents screen to mimic the first sub-app which is recycled Oncethe victim user enters the spoofing task through Recents screenit can lure the user to leak secrets such as passwords Note that

7

our malware successfully passed the vetting of popular app storesincluding Google Play We reported the problem (demo online [12])to Wechat and Alipay which both acknowledged the problem andawarded us through bug bountiesDiscussion on other side channels As mentioned earlier otherside channels once found can also be used for impersonating therecycled sub-app Prior research [113] shows that the operationsof Android apps can be easily tracked through the Android pro-cess file system (procfs) Although Android has been continuouslybeefing up its privacy protection until Android 9 still some globalstatistics under procfs are exposed Particularly we found that theTCP connection status under procnettcp can be accessed byany app without permission on Android 9 and below From the filewe can see the IP addresses of all TCP connections on an Androidphone which are labeled by randomly assigned User IDs Interest-ingly we found that an invoked sub-app makes a sequence of TCPconnections and the endpoints of the connections (domains) canuniquely fingerprint its initiation eg Amazon sub-app connects to4 unique endpoints with 8 consecutive HTTPS requests in the firstfew seconds after it is launched In our research we sampled 8 high-profile sub-apps in Wechat and identified the sequences of theircommunication endpoints as observed when they are triggered (seeTable 8 in Appendix) Through this side channel a malicious nativeapp is able to infer the launch of a specific sub-app so it can waituntil it is terminated for task recycling (eg after 5 other sub-appsare found to be started through the procfs when the magic numberis 5) to create a task to impersonate the sub-app Note that the mali-cious app can resolve the endpoint domains from IP addresses usingAndroid API InetaddressgetCanonicalHostName [81] withoutrequiring any permission which was implemented and confirmedin our study

Until April 2020 84 of the Android devices are still runningAndroid 9 or earlier versions [33] and therefore are vulnerable toour attack On Android 10 which was released in September 2019the procfs used in our attack has been closed by SEAndroid [70 83]and thus the attack is ineffective Seeking a more powerful attackavenue is left to the future research

4 APINA FLAWS IN THEWILDIn this section we report a measurement study that reveals thescope and magnitude of APINA flaws in the wild The study ismade possible by an automatic analysis tool we built called Apinat(short for App-in-app Threat Scanner) which helped us identifyapp-in-app hosts that are susceptible to APINA flaws

41 Identifying System Resource ExposureDesign Apinat aims to find System Resource Exposure flaws byidentifying escaped sub-app API The idea is to find sub-app APIthat is unprotected by sub-app permission while its correspondingsystem API is permission-protected A naive idea is to call eachsub-app API and find out whether the OS checks the permissions ofthe host app eg by looking at permission pop-ups or system logsThis does not work because the permission asked by the OS can berelated to the host apprsquos own rich functionalities not the sub-appAPI To systematically find escaped sub-app API our methodologytracks the system API invocations triggered by a sub-app API via

a dynamic analysis (Step S1 S2) and then utilizes system API-permission maps to derive required permissions of the sub-appAPI (Step S3) which will be compared to the corresponding sub-app permission If a sub-app API is not protected by any sub-apppermission while its corresponding system APIs are guarded by theAndroid dangerous permissions5 or iOS entitlements an escapedsub-app API is found (Step S4) Following we describe how thisdesign works and how it was implemented in our research onAndroid Since sub-app APIs are cross-platform we were able toextend all the findings made by our technique from Android to iOSby simply validating these findings on the Apple platformStep S1 generating test cases To conduct a dynamic analysis wefirst need to generate test cases with valid arguments to invoke eachsub-app API without triggering exceptions For each API we targetthat at least one invocation is successful The argument types ofJavaScript APIs are either primitive or Object [21] To produce testcases for primitive arguments we leveraged Mozillarsquos funfuzz [22]a JavaScript toolkit ForObject arguments we recursively generatedtest cases leveraging funfuzz because an Object includes keyvaluepairs its key is primitive and the value is either primitive or ObjectAll test cases were then used by a sub-app we built to invoke sub-app APIs If all test cases for an API failed we manually inspectedthe API to address the issues such as formatted inputs (eg UUID)stateful calls (an API needs to be invoked before another) etcStep S2 tracking system API As mentioned in Section 21 theexecution of a sub-app API enters the native layer of the hostthrough a dispatcherdispatch function and then its controlflow reaches system APIs (Figure 1) Therefore Step S2 first iden-tifies the dispatcherdispatch function in the host apprsquos nativelayer then tracks its call graph to find the system APIs triggeredby the sub-app API call as elaborated below

(1) Find the dispatcherdispatch function in the native layer Asmentioned earlier Webview and React Native are bridge techniquesto expose dispatcherdispatch to JavaScript layer Note thatthough the object alias (dispatcher) and function name (dispatch)vary across host apps they can be obtained by inspecting functioninvocations in Encapsulation lib (Figure 1) which is a preprocess-ing step in our study Note that the Encapsulation lib usually canbe found in JavaScript files packaged in the host app (eg underassets folder) So all we need is to identify the dispatcher objectin the native layer based on the obtained alias

To this end S2 implements an Xposed [7] (a framework to in-strument Android app execution) module to hook Webview APIaddJavascriptInterface(obj alias) (that exposes Java objectto JavaScript through an alias) and inspect its arguments at run-time if the ldquoalias argumentrsquos value matches the dispatcher aliasdiscovered the ldquoobj is the dispatcher object that we are lookingfor The analysis of React Native bridge is slightly different wehook its API createNativeModules to get its Java objects exposedto JavaScript our Xposed module then calls each exposed objectrsquosgetNamemethod to get its alias ndash if this alias matches the dispatcheralias discovered the object is what we are looking for

5Host apps are typically third-party apps that cannot call privileged system APIs pro-tected by ldquosignature or ldquosignatureOrSystem level permissions [65] or they typicallydo not delegate the access to such APIs through sub-app APIs

8

(2) Track execution of the dispatcherdispatch function Our toolthen tracks the call graph of the dispatch function to find the calledsystem APIs ndash which are called to fulfill the sub-app API call Specif-ically our Xposed module hooks dispatch function and AndroidAPI and inspects their respective call stack traces However wefound that dispatchrsquos thread sometimes does not call Android APIsdirectly it triggers additional thread to call Android APIs likelyfor not to block the dispatch thread This introduces a challengeXposed outputs the above two stack traces by threads ndash one stacktrace with Android API call and the other with dispatch functioncall ndash but cannot correlate two threads if one triggers the otherTherefore we still cannot confirm that the Android APIs are in-voked due to dispatch Hence we developed techniques to deal withthe multi-threading challenge

In our study we found that Handler a typical multi-threadingmechanism of Android is commonly used by dispatchrsquos thread totrigger a new thread Thus we implemented our own thread corre-lation technique based on the Handler mechanism in our Xposedmodule More specifically in the Handlermechanism a triggeringthread that holds a handler instance will submit a runnable to amessage queue via calling the handlerpost(runnable) methodHere the runnable is an instance of Java Runnable [3] with codein its run() method Then the runnable is taken out of the queueby another thread which we name as the handler thread andgets executed in the handler thread Hence as checked in ourXposed module if the executed runnable in a handler thread isthe same instance with one submitted by a triggering thread thenwe correlate the two threads Through such techniques we foundAndroid APIs are indeed called in such handler thread followingthe dispatch threadrsquos triggering ndash this confirms the Android APIcall caused by the dispatcherdispatch functionStep S3 synthesizingAPI-permissionmapping As mentionedin Section 31 system API-permission mappings are incompletewhich can lead to escaped sub-app APIs How to derive a completemapping remains an open question in system security researchand program analysis Here our idea is to supplement recent map-pings [35 46] leveraging documentation analysis we automaticallyextract explicitly declared permissions for system APIs in the devel-oper manuals assuming that explicit specification at least reflectsintended protection of the OS with rare faults Note that certainportion of the documentation (Figure 2) can be misleading to hu-man readers due to incomplete presentation but we observed thatan exhaustive machine-based search on the whole corpus of mobileOSes (eg the entire documentation for all 2497 SDK classes of An-droid API level 27) can help us derive a significantly more completemapping than state-of-the-art mappings [35 46] (see evaluationbelow) For instance after a full scan of Android WifiManager man-ual [75] we were able to flag ACCESS_FINE_LOCATION as a requiredpermission for multiple Wi-Fi scan related APIs (see Figure 8 inAppendix) which has never been included in state-of-the-art map-pings [35 46]

In our implementation we developed a Web crawler to fetchall manuals from Android developer portal [62] and extractedthe description for each public API From the description we ex-tracted the declared permissions based on a few key observations

if the description of an API does not contain a ldquopermission key-word it is very likely that the API does not explicitly requirepermissions otherwise its description usually includes a ldquoper-mission keyword and the exact permission string constants de-fined in Android class androidManifestpermission [77] suchas ACCESS_FINE_LOCATION Based on such observation we per-formed a light-weight string matching to find explicit permissionrequirement of Android APIs (we discuss the sophisticated NLP-based direction in Section 5)

Step S3 also derives a sub-app API-permission map given itsrelatively small size (ie 50 to 172 sub-app APIs in each host com-pared to 35847 public Android APIs found by our Web crawler)we extracted the map by searching ldquopermission related keywordsin sub-app developer manual and manually confirmed the resultStep S4 reporting flaws S4 reports an escaped sub-app API if itis not protected by sub-app permission while its correspondingAndroid API(s) is protected by dangerous permission(s) That is aSystem Resource Exposure flaw is found

For iOS however a comprehensive detection is much more dif-ficult than Android especially because obtaining a system API-entitlement mapping is much more challenging First we are notaware of any work that has produced a mapping on iOS for us tostart with Second we observed that iOS documentation is not asprecise as Android in this regard which describes required enti-tlements for iOS classes but not for individual system API To stillhelp us understand the impact of escaped sub-app API on iOS weextended our findings of escaped sub-app API from Android to iOSif its corresponding iOS API requires an entitlement it is consideredto affect iOS as well This was done by manually searching corre-sponding iOS API for a given escaped sub-app API and checkingwhether any entitlement is asked when the iOS API is invoked inan iOS app we builtEvaluation We evaluated the effectiveness and performance of ouranalysis tool (source code released [12]) on a Google Pixel 2 phoneand iPhone 8 against 11 host apps The evaluation was performedon three Android versions (81 9 10 corresponding to API level 2728 29) and two iOS versions (12 134)bullOverall detection resultsApinat found 39 System Resource Exposureflaws all of them affect Android 81 9 and 10 13 of them affectiOS 12 and 134 We manually validated that all discovered flawsare true in two steps (1) confirming that the sub-app API requiresno sub-app permission through a testing sub-app (2) confirmingthat the corresponding system API(s) has permission protectionthrough a testing native app on Android and iOSbull Evaluating individual steps Step S1 generated test cases for all927 sub-app APIs under test in less than one hour All sub-app APIswere successfully invoked at least once without exception on eachAndroid version In this experiment we did not measure the hostrsquoscode coverage because the host includes implementation of its ownrich functionalities that are unrelated to sub-app API Thus it is notmeaningful to compute the percentage of covered host app code

Step S2 took less than 30 seconds for each sub-app API to reportits corresponding system APIs on each Android version The num-ber of system APIs (protected by dangerous permissions) hookedby S2 is 111 129 145 on the three Android versions respectivelyTo evaluate the correctness of our thread correlation we created

9

a test app which triggered new threads leveraging the Handlermechanism Our test showed that our tool correctly correlated thetriggering and triggered threads on each Android version

Step S3 produced the API-permission mapping including 94public APIs protected by dangerous permissions at API level 27103 APIs at API level 28 and 119 at API level 29 This step took ourapproach three hours to process the descriptions of 35847 42302and 44323 public APIs on the three API versions respectively Tovalidate the correctness of the mapping we constructed a test app toinvoke all the APIs and verify the required permissions at runtimeFor all three Android versions our permission mapping of all except6 APIs are correct Specifically the mapping of 92 APIs out of 94is correct (979 precision) at the API level 27 The two false casesare unprotected APIs hasPermission and requestPermission inclass UsbManager [66] At API 28 the mapping shows a precisionof 971 with one new false case than what was found on API 27(3 cases in total) API 29 shows a precision of 95 with three newcases than API 28 (6 cases in total) Figure 6 and 7 in Appendixlist all six false cases Their descriptions are more complex and weenvision that a natural language processing (NLP) based approachcan further improve our precision (see discussion in Section 5)

To evaluate the coverage of our documentation analysis toolwe randomly selected the documentation of 153 classes 641 APIs(out of 2164 classes) and then manually reviewed and identified52 API-permission mappings as the ground truth Running on theaforementioned documentation our analysis tool shows a precisionof 100 and a recall of 100 to identify API-permission mappingfrom the documentation

We also compared the completeness of our mapping with recentmappings [35 46] They collectively reported 50 public AndroidAPIs that require dangerous permissions on API level 25 (we werenot able to get results of newer Android from the authors) as asignificant improvement our tool was able to find 91 APIs (82more) that require dangerous permissions on the same API versionDiscussion Apinat may not find all escaped sub-app APIs In par-ticular Step S3 cannot derive a complete mapping if the documen-tation is incomplete [56] or too sophisticated to process Apinatonly looks for system resource exposure by public system APIs andundocumented system APIs used by host apps may also lead to theflaw but remain undetected Also Apinat falls short in analyzingobfuscated host apps eg that uses dynamic code loading andimplementations in CC++ Hence Apinat did not scan Web AppAPIs due to the extensive CC++ implementation in browsers Inaddition incorrect documentation (which we assume is rare andindeed our tool did not report any false escaped sub-app API ) mightlead to false alarms if not properly validated

42 Finding UI Deception FlawsDesign To find out the opportunities for Sub-window Deception(Section 32) in a host app Apinat looks for the apprsquos sensitive sub-windows which can be the targets of the attack As discovered inthe wallet UI confusion (Figure 4b) the hostrsquos sub-windows thatare likely to show up in the presence of a sub-app tends to be thosethat can be triggered through sub-app APIs If such a sub-windowalso contains sensitive information our approach then reports it asa potential target for Sub-window Deception

Implementation To detect such sub-windows Apinat monitorsthe change of the host UI in response to each sub-app API callto identify the sub-window triggered by the API call and thendetermines whether it carries sensitive content Specifically ourapproach first constructs a testing sub-app with an empty UI Thenit runs the sub-app API test cases in Section 41 to call each sub-appAPI through the testing sub-app and further inspects the UI screen-shots before and after the call for changes This is done through apixel-to-pixel comparison of two screenshots To capture the screen-shots we developed a screen projection service on Android usingthe Media Projection [63] API Also our screenshot compari-son was implemented using the OpenCV cv2absdiff API [85]For each sub-window identified our approach continues to findthose associated with sensitive information For this purpose itextracts strings from sub-window screenshots using the onlineOCR service [34] From the strings Apinat further utilizes a list of121 sensitive data keywords and the keyword pair list from recentresearch [91] to recognize those carrying sensitive content Notethat like a mobile OS an app-in-app system also provides a set ofsub-app APIs for sub-apps to dynamically generate UI componentssuch as wxcreateCanvasContextdraw() in Wechat To controlfalse positives Apinat omits such sub-app APIs based on the APIcategory in the sub-app API documentation As a result Apinat suc-cessfully detected 6 Sub-window Deception flaws (Section 43) ForiOS we got the same result since sub-app APIs are across-platformthe one triggers a sub-window on one OS also does that on theother (see Section 2)Evaluation Apinat detected 5 sub-app APIs associated with the UIdeception flaw we manually confirmed that all of them trigger sub-windows with sensitive information Also all of them affect bothAndroid (version 81 9 10) and iOS (version 12 134) Performance-wise the screenshot comparison and OCR analysis together tookless than 5 seconds on a desktop with Intel i5 27 GHz CPU and 8GB memoryDiscussion Soundly detecting whether a host app is susceptibleto Sub-app Lifecycle Hijacking (Section 33) is difficult especiallybecause it entails detection of side-channel information leakagewhich can happen in many ways and is hard to capture in generalTo measure a lower bound of the pervasiveness of the problemwe checked whether the hosts in our study (Table 1) had the sameinformation leakage and lifecycle design as reported in Section 33As a result 3 host apps on Android (Wechat Alipay DingTalk) aresusceptible which were all manually confirmed to be exploitable

43 Measurement of ImpactFlaw landscape With the help of Apinat we analyzed 11 highlypopular host apps (Table 1) on Android and iOS and found theyare all vulnerable to APINA flaws (Table 3) Altogether we found 52APINA flaws including 39 System Resource Exposure 10 Sub-windowDeception and 3 hosts vulnerable to Sub-app Lifecycle Hijacking

For System Resource Exposure in total we uncover 39 escaped sub-app APIs associated with 5 categories of exposed system resources4 Android dangerous permissions and 6 iOS entitlements Table 5shows the flaw number for each category of resources (the secondcolumn) and illustrates 8 escaped sub-app APIs with correspondingAndroid permission(s) and iOS entitlement(s) ignored to enforce

10

Table 3 Eleven vulnerable host apps on Android and iOS(A Alipay B Baidu C Chrome D DingTalk F FirefoxJJinRiTouTiao O Opera Q QQ S Safari T TikTok WWechat) NA denotes the flaw does not apply to the OS

Type of APINA Flaw iOS AndroidSystem Resource Exposure A D J Q T W A D J Q T WSub-window Deception A B D W S Q A B C D F W O QSub-app Lifecycle Hijacking NA A W Q

on them All 39 escaped sub-app APIs are listed in our releaseddataset [12] Also Table 6 illustrates 6 Sub-window Deception in non-browser hosts additionally all four browsers we studied (ChromeSafari Firefox Opera) are susceptible to the same Prominent UIattackResource comparison between Android and iOS Althoughfinding the full API-entitlement mapping for iOS is hard we ob-served a few differences between Android and iOS in system re-source protectionbull iOS is less affected than Android Out of 39 escaped sub-app APIs13 are related to iOS which appears to be less affected and harderto be exploited There are two reasons behind the observation asdiscovered in our study First certain iOS APIs return less informa-tion than its Android counterparts (ie those related to Bluetoothsee Section 31) and thus is less susceptible to privacy risk (locationleakage) Hence all 27 Bluetooth related escaped sub-app APIs donot affect iOS (see Table 5) Second WiFi related escaped sub-appAPIs (see Table 5) are much harder to exploit on iOS since Applehas extra protection besides entitlement Specifically right beforethe programmaticWiFi operation an iOS appmust obtain the userrsquosexplicit consent the app must instruct the user to manually openthe WiFi setting page in the Settings app and then return to theiOS app [43] ndash an indicator of user intention for the app to operateWiFibull iOS entitlement fails to communicate risks to the user On Androidwhen the permission ACCESS_FINE_LOCATION is used for protect-ing the operation Wi-Fi scan it indicates a risk that the WiFioperation may leak location a highly private data On iOS how-ever the entitlement for Wi-Fi scan ie Hotspot Helper failsto communicate such a risk Actually to get this entitlement for aniOS app app developers must file a special written request by justi-fying that the app does not have malicious intention Apple reviewsthe request internally and possibly assesses the risks of locationleakage behind the scene However the name of this entitlementand its documentation we could find does not show that Wi-Fiscan needs location protection on iOS This may have been oneof the factors leading to escaped sub-app API wxgetWifiList (seeTable 5) which performs Wi-Fi scan without protectionAttack consequences The system resources exposed by escapedsub-app API and the risks can be identified from the API namesand the permissions they violate (see Table 5) For example unautho-rized sub-apps can use escaped sub-appAPI wxgetRecorderManag-er to record audio (violating Androidrsquos RECORD_AUDIO permission)We summarize the attack consequences in Table 4 Further Sub-window Deception leads to phishing on popular Web services (egFacebook) mobile wallets and sensitive host UIs For exampleWechat has a UI triggered by sub-app API (wxaddPhoneContact)

Table 4 Examples of APINA attack consequences

Flaw Type Consequences (what the adversary is able to do)

SystemResourceExposure

record audio operate camerainfer victimsrsquo geo-location (thus track users)

connect victimrsquos device to arbitrary Wi-Fi (thus manipulatenetwork traffic perform man-in-the-middle (MITM) or phishing)

and steal sensitive QR code etcSub-windowDeception

steal account credentials on Facebook Google Amazon etcsteal mobile wallet passwords contacts etc

Sub-appLifecycleHijacking

steal money (payments in shopping sub-app)steal personal secrets (eg answers tosecurity questions health records etc)

steal business documents (from a document processingand management sub-app published by Microsoft)

steal account credentials of Amazon ICBCCCB HSBC (1st 2nd 7th largest banks in the world)

Airbnb Weibo Starbucks McDonaldrsquos etc

for users to enter contact information (Table 6) attacking this UImay leak contacts which are highly private Last Sub-app LifecycleHijacking affects three hosts (Table 3) and the risks come fromimitating sub-apps supported by these hosts such as sub-apps forAmazon health banking Airbnb etc (see Table 4)Cases Studies We discuss a few other problems we observed inapp-in-app ecosystembull Keeping up with the OS evolution Sub-app API permission policyshould keep up as the OS always evolves newer OS version oftenintroduces more strict protection against sensitive resources Forexample since Android 10 an app that accesses location in the back-ground needs an additional dangerous permission ACCESS_BACKGRO-UND_LOCATION in addition to the regular location permission [82]This protects user location against illicit tracking However sub-app API for accessing location in hosts TikTok and Alipay did notkeep up with such a new protection thus leaving their users at risk

As another example for the WiFi and Bluetooth scan that canleak location Android 9 and 10 require ACCESS_FINE_LOCATIONpermission while Android 81 is less restrictive and ACCESS_COARSE_LOCATION is sufficient (see Table 5) Note that Android uses the firstpermission to control access to precise location (eg GPS data)and uses the second one for coarse-grained positioning (with anaccuracy approximately at the level of a city block [10]) Interest-ingly all hosts we studied only define a general location sub-apppermission to govern location API (eg scopeuserLocation inWechat) but do not differentiate the two levels of accuracybull Too many APIs for one permission APIs of apparently differentfunctionalities should never be governed by the same permissionHowever in the host TikTok (an extremely popular short-videosharing app with more than 500million downloads on Google Play)three sub-appAPIs ttscanCode ttchooseImage and ttchoos-eVideo (for scanning QR code accessing photos and videos) aregoverned by the same permission scopecamera and thus inade-quately protected For example a malicious sub-app that is grantedpermission by the user to scan QR code also behind the scenesilently gets access to API ttchooseImage that accesses user pho-tos posing a serious privacy risk

5 LESSONS AND MITIGATION STRATEGYLessons learned The most important lesson learnt from our re-search is the caution one should take when building a third-party

11

Table 5 Summary of System Resources Exposure flaws (NA means the flaw does not affect the OS)

SystemResourceExposed

of

FlawsExample of Escaped

Sub-app API Dangerous Permission Android API Entitlement iOS Class

Microphone 1 WechatwxgetRecorderManager RECORD_AUDIO mediaMediaRecorder

CaptureRequest Microphone Usage AVAudioRecorder

Camera 3 Alipay myscan CAMERA CameraManageropen-CameraCaptureRequest Camera Usage AVCaptureSession

Wi-Fi 4WeChatwxgetWifiList

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetScanResults Hotspot Helper dagger NEHotspotHelper

JinRiTouTiaoTikTokttgetConnectedWifi

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetConnectionInfo Access WiFi Information dagger CNCopyCurrent-

NetworkInfo

Bluetooth 27

Alipay mystartBluetoothDevicesDiscovery

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan NA NADingTalk

ddgetBluetoothDevicesAlipay

mygetBLEDeviceServices

iBeacon 4 Alipay mygetBeaconsACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan Location Usage CLBeaconRegion

dagger Much harder to exploit on iOS due to the requirement of explicit user approvalDagger Android 9 and 10 require ACCESS_FINE_LOCATION permission while Android 81 requires ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION

Table 6 Examples of Sub-window Deception flaws

Host App Triggering Sub-App API Legitimate (and spoofable)Functionality of the Sub-window

Alipay mytradePay Request password ofAlipay mobile wallet

Baidu swanrequestPolymerPayment Request passwords ofmultiple mobile wallets

DingTalk ddpay Request password ofAlipay mobile wallet

WechatwxaddPhoneContact Enter new contacts

wxrequestPayment Request password ofWechat mobile wallet

QQ new in-app message Display instant messagesand enter a reply

sub-ecosystem on top of the operating system In such a case thethird-party OS-like app strives to provide a secure self-containedenvironment However whether it undermines OS security andbrings in new risks to modern mobile applications need to be eval-uated to identify the security gap between the new sub-ecosystemand the OSes Our measurement study shows that popular host appsare generally susceptible to APINA flaws indicating that the app-in-app system vendors today either fail to identify or are unpreparedfor the new risks

Fundamentally APINA risks come from the limited app-levelcapabilities the host app has in managing OS resources lack ofOS-level support and missing of sub-app API standard Hencedown the road it will require non-trivial joint efforts to fundamen-tally eliminate APINA risks More specifically escaped sub-app APIshows that a third-party host fundamentally lacks the full OS-levelknowledge on system resource protection While such knowledgecan come from different sources eg program analysis on relevantOS modules [35 46] developer documentations technical reportsetc each source only contributes a partial view Hence joint effortsneed to be made in the future to synthesize such knowledge Ourstudy also brings to light that such efforts are by no means trivialndash even the two leading mobile OSes have apparently confusingconflicting security policies Synthesizing such a knowledge base

will not only benefit the app-in-app paradigm but also make theOSrsquo security mechanism more transparent for thorough auditing

Our findings also highlight that prior OS lessons cannot fullyeliminate new risks incurred by the new paradigm which necessi-tates thorough assessment regarding its new attack surfaces Forexample a malicious sub-app a sub-window and a task in Recentsscreen all come as new attack vectors that pose credible new threatsto usersrsquo most sensitive credentials and privacyMitigation strategy Following we propose the short-term miti-gation and discuss the long-term strategybull Escaped Sub-app API Eliminating the risk requires the host tohave full OS-level knowledge about resource control (eg API-permission mapping) which is difficult In the meantime our toolApinat together with our API-permission mapping (released on-line [12]) can help host app vendors identify escaped sub-app APIsNote that since Apinat can identify escaped sub-app API with itsignored permissions with respect to specific OS version (see Sec-tion 43) host vendors may leverage our tool to assess whether theirsub-app API permission policy is always compliant with newly re-leased OS version and thus keep up the pace

Further we envision two possible future directions that couldlead to more viable solutions First as demonstrated by our anal-ysis tool Apinat although it is hard for todayrsquos program analy-sis techniques to derive a complete system API-permission map-ping [35 46] we could significantly improve its accuracy and com-prehensiveness through developer documentation analysis Ourcurrent documentation analysis is rather preliminary but still effec-tive as demonstrated in our study (Section 4) Down the road wecould develop natural language processing (NLP) based techniquesfor deriving more complete knowledge about API permission poli-cies With the techniques an analysis could cover a wider spectrumof literature including iOS documents research papers technicalreports etc which will help derive up-to-date knowledge aboutresource-management policies

Second the app-in-app community should work together tostandardize sub-app APIs and their permission policies as donein the HTML5 community on HTML5 APIs For the time being

12

different app-in-app vendors bring in their own APIs for accessinga wide spectrum of systems resources (see our comparison betweensub-app API and HTML5 API in Table 7 in Appendix) often withoutproper safeguard in place not to mention any effort to standardizethe protectionbull Sub-window deception The risk comes from the UI confusionwhether a window portion in the sub-app window belongs to thesub-app or the host (Figure 3b) To mitigate the risk we envision ahigher degree of UI isolation between the sub-app and the host thesub-apprsquos window should always be separated from that of the hostand the host should never reclaim any window portion from thesub-applsquos window Regarding the Wallet UI confusion (Section 32)for example Wechat should display its wallet UI only in its ownwindow and advertise to users that any UI component inside thesub-app window belongs to the sub-app

A question arises whether a malicious sub-app can fake a crashand then show spoofing content in the sub-app window to resem-ble the host This can be mitigated through additional protectionsupported by the host Specifically the host app could keep mon-itoring the UI of its sub-apps (eg through PixelCopy API onAndroid [71]) to detect whether a UI object in the sub-app is similarto a sub-window or a security-sensitive UI object associated withhost app For performance concern the host app could utilize thestate-of-the-art object detection model (eg Fast Region-based Con-volutional Network based model [61] and YOLO [32 95]) for thereal-time security-sensitive UI object recognition as reported inprior research [95] Fast YOLO yields the performance of 155 framesper second Note that the effectiveness efficiency and deploymentfeasibility of such an approach need to be carefully explored andevaluated which we leave for our future researchbull Sub-app lifecycle hijacking To mitigate this risk a short-termdefense is to place all sub-app resources in the phonersquos internalstorage so our current exploit (leveraging monitoring the phonersquosexternal storage) to track sub-app lifecyle termination (Section 33)can be mitigated However it is always a concern that sub-appsmay deplete the limited space on a phonersquos internal storage Along term solution needs to consider how to make the sub-apptasks dynamically scalable to ensure that the sub-app recycling isno longer traceable and thus the attack surface is fundamentallyeliminated This nonetheless calls for support from modern OSesfor the emerging app-in-app paradigm

6 RELATEDWORKAs mentioned in Section 2 recent years witnessed several tech-niques to support the functionality of app encapsulation (eg Plu-gin frameworks app sandboxing browser extension and PhoneGapapp see Table 2) Accordingly numerous studies have looked intothe flaws in these app encapsulation systems considering the se-curity analysis of Plugin frameworks a set of flaws were revealed[99 111 112] including no permission management and no isola-tion of the virtualized apps Compared with Plugin frameworks theapp-in-app paradigm has a much stronger security model and ourstudy investigates the design challenges and pitfalls in the securitymechanism Meanwhile the security and privacy implications ofbrowser extensions have been extensively studied [48 54 84 98]

Furthermore the current security studies on PhoneGap apps fo-cus on the flaws of PhoneGap frameworkrsquos access control policy[60 90 100 101] For example Song et al [101] revealed that thebridges added by the framework to the browser are not correctlyprotected by the same origin policy Jin et al [86] introduced mul-tiple channels (eg barcode SMS file system Contact) for codeinjection attacks in PhoneGap apps Different from these works wefocus on the unique features of the app-in-app paradigm (Table 2)and reveal multiple new attack surfaces which have never beenstudied before

The closer to our study are the works of Web App and WebViewvulnerability assessment Up to our knowledge only one paper[87] analyzed security issue of Web App in which the securityand privacy risks on HTML5 features in PWA were investigatedIn our attack on Web App we did not focus on HTML5 featuresbut a general UI isolation and management model in app-in-appparadigm Also although WebView technique is used in some ofthe app-in-app systems in sharp contrast to the works on Webviewweaknesses [36 60 88 102 105 109 110] our study explores thesecurity implications and challenges for a third-party app tomanageoperating system resources Another set of works related to ourstudy is the exploitation of mobile UI deception Prior phishingattacks [38 49 53 57 97] mislead victims about the foregroundapp aiming at information theft in spoofing apps Correspondingcountermeasures [49 58 96] emphasize identifying the app of thewhole foreground window and thus cannot thwart Sub-windowDeception due to the inability to identify sub-windows Furtheranother angle of UI deception is clickjacking [59 94] which aredifferent from our mobile-phishing attacks7 CONCLUSIONIn this paper we present the first systematic security analysis on re-source management in high-profile app-in-app systems Our studyshows that such systems are susceptible to a set of serious securityflaws Our measurement study further sheds light on their perva-siveness in the real-world Further our study brings in new insightsinto the fundamental security limitations of this new paradigm andfurther contributes to a better understanding of its mitigation strat-egy an important step towards building a more secure app-in-appecosystem

8 ACKNOWLEDGMENTWe would like to thank our shepherd Yanick Fratantonio and theanonymous reviewers for their insightful comments This work issupported in part by the NSF CNS-1618493 1801432 1838083

REFERENCES[1] 2011 HTML5 Fullscreen API Attack httpsferossorghtml5-fullscreen-api-

attack[2] 2011 The Inception Bar httpsjameshfishercom20190427the-inception-

bar-a-new-phishing-method[3] 2018 Java Runnable httpsdocsoraclecomjavase7docsapijavalang

Runnablehtml[4] 2018 A one year PWA retrospective httpsmediumcompinterest-

engineeringa-one-year-pwa-retrospective-f4a2f4129e05[5] 2018 Wechat 1 million sub-apps httpswwwscmpcomtecharticle2153705

tencents-wechat-now-host-1-million-mini-programs[6] 2018 WeChat reaches 1M sub-apps half the size of Applersquos App Store https

techcrunchcom20181107wechat-mini-apps-200-million-users[7] 2018 Xposed httpsapixposedinforeferencepackageshtml[8] 2019 AdBlock httpsgetadblockcom

13

Table 2 Comparison with existing app encapsulation sys-tems ( Not Supported Partially Supported Fully Sup-ported)

System Features And

roid

Plug

inFram

ework

App

Sanb

oxing

Brow

serE

xtension

Phon

eGap

App

App

-in-app

Sub-app API ecosystemfor system resource access

dagger dagger

The host has rich functionalitiesapart from hosting

Mandatorysub-app destruction

dagger supported by HTML5 API which is standardized by W3C and thus much easier tomanage than sub-app API

by another app A prominent example is Android Plugin framework(eg Parallel Space [23] DroidPlugin [15] and VirtualApp [26])an app virtualization technology through which a ldquohost app canload other Android apps (called ldquopluginrdquo apps) from their APK filesto run in the hostrsquos own process [111 112] This is done throughwrapping the system APIs for invoking plug-in apps which sharethe hostrsquos UID and permissions during their executions [99 111]Also mobile app sandboxing (eg Boxify [47] and NJAS [50]) isanother way to virtualize apps The idea is to encapsulate untrustedapps in a restricted execution environment within the context ofa trusted sandbox app which provides an emulation layer to ab-stract the underlying OS and interposes all interactions (eg sys-tem calls binder IPC) between the untrusted app and the OS [47]Other app-encapsulation solutions include Browser extension2 (egAdBlock [8] EditThisCookie [16]) where a small program cus-tomizes a web browser with the support of HTML5 (for controlledsystem-resource access) and extension APIs (for browser-resourceaccess) [13] and PhoneGap apps (or HTML5 based mobile apps)where a middleware framework (eg PhoneGap [24] Cordova [11]Ionic [19]) is used to allow the developer to create mobile appsusing web technologies [31 86]

Table 2 compares the above solutions with the app-in-app systemin terms of their security implications As we can see here unlikethe app virtualization based Plugin framework and app sandboxingthe app-in-app platform builds up its own API ecosystem (ie sub-app APIs) for sub-apps to access system resources which entailsnon-trivial efforts to define and maintain its security model such asthe sub-app API permission policies Such policies are standardizedfor HTML5 APIs used by browser extensions [103] but are ad-hocopaque and often inadequate for the sub-app APIs that are muchmore powerful and access more sophisticated system resourcesthan HTML5 thereby opening new attack avenues (see Section 31and Table 7 in Appendix) Furthermore compared with other solu-tions dedicated to application encapsulation the app-in-app host2Browser extension is different from the deprecated Browser Plugin architecture [14]Browser Plugin is generally not considered as an encapsulation system since the pluginsare independent executables and their access to system resources are not encapsulatedby the browser

has its own rich functionalities (eg mobile wallets messagingsee Table 1) which are often shared with the sub-apps For exam-ple e-commerce sub-apps (eg Amazon Pinduoduo) leverage thehostrsquos built-in wallet feature for convenient payment process (seeSection 32) In our study we found that such interactions (betweenthe sub-app and the host app) actually exposes a new attack sur-face (Section 32) Also the upper limit on the number of sub-appsthat can run concurrently on an app-in-app platform is public andfixed (8 in Chrome 5 in Wechat 4 in Alipay) whenever the limitis reached the host has to terminate a sub-app in order to launcha new one This feature which does not exist in other systemscan be abused for deception attack as discovered in our research(Section 33)

24 Adversary ModelWe assume the host app is benign which aims to provide a secureenvironment to run sub-apps On the victimrsquos Android or iOS de-vices where at least one app-in-app system is used we consideran adversary with his malicious app3 or sub-app installed Notethat none of our attacks requires the victim to install both InSection 3 we show that such malware can successfully pass thevetting of popular sub-app stores Google Play third-party appstores etc The malware sample does not have system privilege andin some of our attacks may need to ask for a set of common permis-sions from the users (eg Androidrsquos READ_EXTERNAL_STORAGE andWRITE_EXTERNAL_STORAGE) depending on specific attacks Suchpermissions are extensively requested by popular apps such asFacebook Gmail and Pinterest Therefore we believe that claimingthem by the malicious app will not arouse obvious suspicion

3 DESIGN CHALLENGES AND PITFALLSIn this section we report our security analysis on resource manage-ment in app-in-app systems Our research shows that all app-in-appsystems we studied including Wechat Alipay TikTok ChromeSafari etc are subject to various APINA flaws leading to seri-ous exposure of system resources and new deception attacks Morespecifically the security analysis has been systematically performedby assessing two general categories of resources system resourcesaccessible through system APIs and user interfaces For each re-source we looked at the security policies that should be in placethe mechanism that enforces the policies and the user interactionswith security implications

31 System Resource ExposureSub-apps access system resources through sub-appAPIs (Section 21)However for the host as a third-party app constructing sound sub-app API permission policies that govern system resources entailschallenges that are unexpected before As a result sensitive systemresources are often unwittingly exposed to unauthorized sub-appsEscaped sub-app API Sub-app APIs are protected by sub-apppermissions which are supposed to be consistent with the permis-sions required by the OS when using the relevant system APIs theywrap For example since the OS requires permissions to use its

3In this paper we use the term app and native app interchangeably Also although thehost app is a native app itself the term app or native app in this paper always refers toan app that is not a host app for ease of presentation

4

Figure 2 Misleading Android documentation

audio recording APIs (RECORD_AUDIO [72] permission on Androidand Microphone Usage [42] entitlement on iOS) the sub-app APIto record audio (eg wxstartRecord in Wechat) should also beprotected by a sub-app permission (eg by sub-app permissionscoperecord in Wechat) However in our study we found theinconsistency in permission requirement between sub-app API andsystem API indicating that the host fails to create the correct per-mission policies that govern sub-app API for system resource accessAs a result certain sub-app APIs that wrap permission-protectedsystem APIs are completely open to any sub-apps without requir-ing a sub-app permission exposing sensitive system resources Wename such unprotected sub-app API escaped sub-app API and theproblem System Resource Exposure

An example discovered in our research is the unprotectedWechatsub-app API wxgetWifiList that performs WiFi scan a capa-bility protected by the underlying OSes against user location leakeg through an entitlement Hotspot Helper on iOS and danger-ous level location permissions (ACCESS_COARSE_LOCATION andACCESS_FINE_LOCATION) on Android This exposes the WiFi scancapability to sub-apps leaking out user location to them Notethat a high-profile host app (eg Wechat) is typically granted thelocation permission and many other permissions due to its richfunctionalities (see Table 9 in Appendix) As a result through thedelegation the host makes to the sub-app escaped sub-app APIeffectively opens a door for the adversary to gain unauthorized ac-cess to system resources In addition to wxgetWifiList we foundmany other escaped APIs in popular app-in-app systems affectingdiverse sensitive resources across iOS and Android (Section 43)

Looking into the possible root causes we found that it is verychallenging for an app-in-app system to soundly define sub-appAPI permission policies that comply with the OSes in governing sys-tem resources due to the incomplete knowledge about permissionchecks that happen at related system APIs Specifically official API-permission maps for both Android and iOS have never been madepublic Although several prior attempts [35 45 46 56] have beenmade to automatically map Android APIs to their required permis-sions we found that the prior results are incomplete (Section 43)and highly likely to introduce escaped sub-app APIs if they are usedto design a sub-app permission system Consider the above exam-ple of WiFi scan recent results [35 46] (on Android API level 25)report that a related Android API WifiManagergetScanResultsrequires just a normal permission ACCESS_WIFI_STATE but failto mention that dangerous permission location is also required(required since Android API level 23 [80]) Further Section 43 re-ports more escaped sub-app APIs possibly caused by the incompleteAPI-permission maps

Such API-permission mapping information has also not beenwell recorded by the developer documentation We found that suchdocumentation can be misleading or confusing Again let us useWi-Fi scan as an example as shown in Figure 2 the Android

documentation [75] may introduce the misconception that declar-ing ManifestpermissionCHANGE_WIFI_STATE is sufficient forWi-Fi scan Similar misguidance also appears on the Android doc-umentation for Bluetooth scan etc and has likely caused otherescaped sub-app APIs we found (Section 43)

Another observation of our study is that since sub-app APIis designed to be cross-platform (Section 21) the effort to buildsub-app API permission policies that comply with all OSes hasbeen complicated by the inconsistency between Android and iOSin resource protection Consider Bluetooth scan as an examplethe Android API BluetoothLeScannerstartScan requires thedangerous location permission while iOS does not Such a dis-crepancy likely causes confusion in app-in-app design which istypically built for both OSes with uniform security policies Whenthis happens we found that the app-in-app designer tends to leavethe related sub-app API unprotected For example the sub-app APIsfor Bluetooth scan are not protected in multiple host apps (egwxgetBluetoothDevices in Wechat) Actually the difference inpolicy-level protection could result from an additional securityguard put in place by the OS which is unaware to the app-in-appdesigner For example combining together Signal Strength andDevice ID of nearby Bluetooth devices reveals geo-locations [37]On Android the pair is returned together by the above Bluetoothscan API BluetoothLeScannerstartScan which thus needs apermission check on iOS however the pair has been partially ob-fuscated (Device ID is randomized) and is thus unprotected Wesuspect that the inconsistency as observed on capabilitiesresourcesWi-Fi scan Wi-Fi connect iBeacon etc is likely responsiblefor other escaped sub-app APIs we discovered (see Section 43)Discussion Android 60 (API level 23) started to use a runtimepermission model a user grants permissions at the apprsquos runtimewhen permissions are requested (eg when the app launches orwhen the user accesses a specific feature) [73] In this scenariowhen an escaped sub-app API tries to silently access a resourcethe host may have not been granted a permission to access thatresource thus a permission will be explicitly required Howeverthe OSrsquo permission granting window will show to the user thatit is the host app who requests the permission not the sub-appThis misleading request may lead to the wrongly inherited trustassociated with the hosts and make users grant the permissioninappropriately This is also the case on iOS when a permissionwindow pops up to confirm the hostrsquos access to a resource

Furthermore Table 9 in Appendix lists all Android dangerouspermissions and iOS entitlements requested by the vulnerable hostsright after launching It shows that the hosts proactively requestnecessary permissionsentitlements even before accessing any spe-cific features due to usability consideration [92] Those capabilitiesof the hosts will always be stealthily delegated to the sub-app viaescaped sub-app APIs which present serious risksAttacks and vendor acknowledgements We implemented anattack sub-app which ran inWechat v673 to steal userrsquos location onboth Android and iOS The attack sub-app utilized Wechat escapedsub-app API wxgetWifiList to perform Wi-Fi scan and snifferthe surrounding Wi-Fi access points The scan results included sen-sitive information ie BSSID Signal Strength and Device ID ofnearby Wi-Fi access points which enabled to infer the geolocation

5

(a) Real Prominent UI (b) Fake Prominent UI

Figure 3 Safarirsquos Prominent UI confusion on iOS

of a user [37] This attack sub-app successfully passed the vettingof Wechat sub-app store and ran on both iOS and Android versionsof Wechat Note that our attack sub-app has less than 200 lines ofcode which indicates that it is cost-effective for the adversary todevelop APINA flaws malware in the wild Besides we successfullybuilt attack sub-apps in other host apps eg Alipay DingTalk etcand reported the problems to all affected host-app vendors Theyall acknowledged the problem in particular Wechat and Alipayawarded us through bug bounty programs for this flaw

32 Sub-window DeceptionAnother unique app-in-app feature is the functionality-level inter-actions between the host and sub-app For this need the host doesnot fully isolate itself from sub-apps which unwittingly introducesnew attack surfaces and high spoofing risks against host-app UIBrowsersrsquo Prominent UI confusion To bring a native app-likeexperience Safari on iOS and Chrome on Android open each sub-app (ie Web App Progressive Web App or PWA) in an entirededicated window separate from the browser window just like anative app [44 78] ndash without any browser UI such as the addressbar Web App is programmed with JavaScript and HTML but mustmeet certain standards [68] With user confirmation the browsercan install a Web App to the phonersquos home screen (through anAPK [69] package created by Chrome or a Web Clip [44] createdby Safari) Such Web App takes the full screen if ldquostandalone orldquofullscreen is specified in its manifest file EachWeb App is clearlyassociated with specific Web domain when installed When the usernavigates to out-of-scope URL (ie of different origin) in a WebApp the browser displays a Prominent UI ndash a banner at the top ofthe screen (Figure 3a) showing the origin and secure connectionstatus ndash due to the lack of address bar According to Web Appdocumentation [67] users rely on such Prominent UI to be awarewhen they navigate out of scope an important security notice

Based on a study [57] mobile phishing attacks tend to happenwhen users become accustomed to familiar repeated contexts Morespecifically if users frequently encounter legitimate context theywill become conditioned to reflexively respond to it Here the cur-rent design of Web App conditions users to see the Prominent UI inout-of-scope navigation which we found poses a spoofable context

(a) Authentic wallet UI (b) Bogus wallet UI

Figure 4 Mobile wallet UI confusion

Specifically Web App is designed to embrace out-of-scope brows-ing [104] and let users freely navigate to other Web domains forservices such as login through FacebookGoogle (aka SSO [107])payment through PayPal etc The problem is that when a victimuser navigates out of scope eg to Facebook login page a mali-cious Web App can actually navigate to an in-scope phishing pageimitating Facebook showing a bogus Prominent UI (as if shown bythe browser) to misleadingly inform the victim that she is on a realFacebook domain (Figure 3b) In this way the malicious Web Appcan collect victim usersrsquo secrets such as Facebook passwords

We call this problem Sub-window Deception ndash sub-window meanspart of a window Prior phishing attacks in browsers exploredhow a webpage can go full screen and spoof the address bar [12] as another instance of mobile browser UI attacks our attackcomplements the prior understanding by exploiting ProminentUI ndash the counterpart of address bar in the context of native app-like Web App Note that address bar differs from Prominent UIin design based on the Web specification [106] browsers ldquoshouldprovide a means of exiting fullscreen that always works and advertisethis to the user [106] so users can see the real address bar whenthey want (although browsers may not implement this protectionproperly [89]) Web App users however lack practical mechanismsto verify the authenticity of Prominent UI today This attack appliesto general Web App on both iOS and Android we reported it toW3C4 Apple Google Firefox and Opera which all acknowledgedthe importance of the problemMobile Wallet UI confusion Wechat and Alipay both featuremobile wallets which can be leveraged by e-commerce sub-appsto provide users a convenient payment process Amazon sub-appfor example after a user clicks its ldquocheckout with Wechat wal-letrdquo button will invoke a sub-app API (eg wxrequestPaymentin Wechat) to trigger the hostrsquos wallet the host then reclaims acentral portion of the screen from the sub-app to show its walletUI (highlighed in Figure 4a) for the user to enter her wallet pass-word and finish the payment Such a context can condition usersto reflexively provide wallet passwords at checkout and thereforepresents a practical spoofing target Specifically when a victim userclicks the ldquocheck out button in a malicious e-commerce sub-app itcan show a bogus wallet UI (Figure 4b) to collect the userrsquos walletpassword instead of invoking the real wallet

4We do not provide the link to our report for anonymization purpose

6

(a) Real sub-app task (b) Bogus sub-app task

Figure 5 Dedicated task for every sub-app in Recents screen

Up to our knowledge state-of-the-art mobile anti-phishing tech-niques cannot identify our attacks for example [49 58 96] mainlyrely on identifying the app of the whole foreground window so theuser would not expose secrets to the unintended app this cannotidentify a sub-window at the sub-app level ndash whether it belongs toa sub-app or the host app

Our study shows that a bogus sub-window presents a practicalattack vector in app-in-app since a window portion (sub-window)can be used by both the sub- or host- app in accustomed contextswithout differentiation through clear identification From a broadersense we believe the spoofing risk is also high if the OS showsits pop-up atop an app (so malicious app can show a bogus onewhen the OS does not) however in sharp contrast such pop-upis not sub-window (but whole window) and known anti-phishingtechniques (eg [49]) to identify (the owner of) the whole windowcan defeat itAttacks and vendor acknowledgementsWe implemented PoCattacks in Safari on iOS Chrome on Android and Wechat on bothOSes in Safari and Chrome our malicious Web App impersonatesProminent UI to spoof Facebook login page in Wechat our mali-cious sub-app mimics the wallet UI to steal wallet password (seevideo demo online [12]) Our malicious sub-app passed the vettingof Wechatrsquos sub-app store Note that Web App does not have appstores and can be installed after visiting its URL In addition wereported the problems to all affected host vendors who all acknowl-edged that the threats were practical and severe Wechat and Alipayawarded us through their bug bounty programs

33 Sub-app Lifecycle HijackingAs app vendors follow the app-in-app trend by releasing sub-appsit is unclear whether their users remain equally protected as beforeUnfortunately our study shows that even highly credible host appscannot fully eliminate new attack surfaces incurred by app-in-appRecents screen takeover The Recents screen (aka recent task listor recent apps) [64] is a system-owned UI of Android to list recentlyaccessed task (Figure 5a) In particular each launched native appwill have a task in Recents screen similarly a host app creates aseparate task for every launched sub-app which appears in Recentsscreen Limited by the OS each host app can only create a fixednumber of tasks in Recents screen pre-specified as activities inits manifest file In our research we found that host apps all specify

a small magic number (eg 8 in Chrome 5 in Wechat 4 in Alipay3 in JinRiTouTiao) for the task limit

When an additional sub-app will be opened after the task limitis reached the host app silently executes a mandatory recyclingprocess closing the first opened sub-app to recycle its task forlaunching the new one The recycling process is transparent tousers for the possible purpose of not interrupting the user experi-ence Such a mandatory sub-app recycling mechanism introducesa new risk once the recycling is traceable by a malicious appie the adversary knows which sub-app has been recycled and atwhat time it can stealthily insert a phishing task into the Recentsscreen to imitate the silently recycled sub-app For this purposethe adversary needs to acquire the information about a hostrsquos taskrecycling which turns out to be feasible due to the presence ofvarious information-leak avenues that can be hard to eliminate Inour study we found a side channel that enables recycling track-ing in multiple host apps In particular possibly due to the richfunctionalities of sub-apps which require resource files (eg userdata logs icon and image texture) the host app creates a folderin Android external storage [18] to cache sub-app resources Suchexternal storage can be monitored by an Android native app totrack which sub-app is launched and at what time (by monitoringsub-app icon which will be downloaded at launch see PoC attackbelow) Thereby once the number of launched sub-apps reachesthe hostrsquos task limit the sub-app to recycle can be inferred Hencea malicious native app can insert a bogus task in Recents screento mimic the recycled sub-app at this point the bogus task is theonly one in Recents screen that represents the target sub-app thatrsquosspoofed (Figure 5b)

This attack is a kind of mobile task hijacking attacks [52 97]Regarding its root cause the mandatory sub-app recycling opens anew attack surface for app-in-app systems since it makes it possiblefor malicious apps to track a sub-apprsquos lifecycle termination Notethat the attack surface becomes exploitable in the presence of sidechannels eg external storage which itself is a relatively trivialbug Other side channels could also be used for the attack once theyarise (see discussion below) Eliminating this attack surface maynot be trivial in practice since the maximum task number of a hostin Recents screen is not dynamically scalable (statically specifiedin manifest) limited by the OS Although the very recent Androidsupports dynamic task no host app we studied (Table 3) adoptedit possibly for the purpose of supporting older Android versionsgiven the notorious Android version fragmentation [74]Attacks and vendor acknowledgementsWe implemented PoCattacks on Alipay andWechat which cache sub-app resources in theexternal storage and enable recycling tracking Specifically Alipaystores the caches at sdcardalipaymultimedia When a sub-app such as Amazon is launched its icon will be downloaded toit if not already there Our malicious Android app with a commonpermission WRITE_EXTERNAL_STORAGE can remove cached iconsperiodically andmonitor when they reappear to knowwhat specificsub-app is launched and at what time In our attack of Alipay oncethe malicious app infers that five sub-apps have been launched(submit-app task limit of Alipay is 4) it will insert a bogus task inRecents screen to mimic the first sub-app which is recycled Oncethe victim user enters the spoofing task through Recents screenit can lure the user to leak secrets such as passwords Note that

7

our malware successfully passed the vetting of popular app storesincluding Google Play We reported the problem (demo online [12])to Wechat and Alipay which both acknowledged the problem andawarded us through bug bountiesDiscussion on other side channels As mentioned earlier otherside channels once found can also be used for impersonating therecycled sub-app Prior research [113] shows that the operationsof Android apps can be easily tracked through the Android pro-cess file system (procfs) Although Android has been continuouslybeefing up its privacy protection until Android 9 still some globalstatistics under procfs are exposed Particularly we found that theTCP connection status under procnettcp can be accessed byany app without permission on Android 9 and below From the filewe can see the IP addresses of all TCP connections on an Androidphone which are labeled by randomly assigned User IDs Interest-ingly we found that an invoked sub-app makes a sequence of TCPconnections and the endpoints of the connections (domains) canuniquely fingerprint its initiation eg Amazon sub-app connects to4 unique endpoints with 8 consecutive HTTPS requests in the firstfew seconds after it is launched In our research we sampled 8 high-profile sub-apps in Wechat and identified the sequences of theircommunication endpoints as observed when they are triggered (seeTable 8 in Appendix) Through this side channel a malicious nativeapp is able to infer the launch of a specific sub-app so it can waituntil it is terminated for task recycling (eg after 5 other sub-appsare found to be started through the procfs when the magic numberis 5) to create a task to impersonate the sub-app Note that the mali-cious app can resolve the endpoint domains from IP addresses usingAndroid API InetaddressgetCanonicalHostName [81] withoutrequiring any permission which was implemented and confirmedin our study

Until April 2020 84 of the Android devices are still runningAndroid 9 or earlier versions [33] and therefore are vulnerable toour attack On Android 10 which was released in September 2019the procfs used in our attack has been closed by SEAndroid [70 83]and thus the attack is ineffective Seeking a more powerful attackavenue is left to the future research

4 APINA FLAWS IN THEWILDIn this section we report a measurement study that reveals thescope and magnitude of APINA flaws in the wild The study ismade possible by an automatic analysis tool we built called Apinat(short for App-in-app Threat Scanner) which helped us identifyapp-in-app hosts that are susceptible to APINA flaws

41 Identifying System Resource ExposureDesign Apinat aims to find System Resource Exposure flaws byidentifying escaped sub-app API The idea is to find sub-app APIthat is unprotected by sub-app permission while its correspondingsystem API is permission-protected A naive idea is to call eachsub-app API and find out whether the OS checks the permissions ofthe host app eg by looking at permission pop-ups or system logsThis does not work because the permission asked by the OS can berelated to the host apprsquos own rich functionalities not the sub-appAPI To systematically find escaped sub-app API our methodologytracks the system API invocations triggered by a sub-app API via

a dynamic analysis (Step S1 S2) and then utilizes system API-permission maps to derive required permissions of the sub-appAPI (Step S3) which will be compared to the corresponding sub-app permission If a sub-app API is not protected by any sub-apppermission while its corresponding system APIs are guarded by theAndroid dangerous permissions5 or iOS entitlements an escapedsub-app API is found (Step S4) Following we describe how thisdesign works and how it was implemented in our research onAndroid Since sub-app APIs are cross-platform we were able toextend all the findings made by our technique from Android to iOSby simply validating these findings on the Apple platformStep S1 generating test cases To conduct a dynamic analysis wefirst need to generate test cases with valid arguments to invoke eachsub-app API without triggering exceptions For each API we targetthat at least one invocation is successful The argument types ofJavaScript APIs are either primitive or Object [21] To produce testcases for primitive arguments we leveraged Mozillarsquos funfuzz [22]a JavaScript toolkit ForObject arguments we recursively generatedtest cases leveraging funfuzz because an Object includes keyvaluepairs its key is primitive and the value is either primitive or ObjectAll test cases were then used by a sub-app we built to invoke sub-app APIs If all test cases for an API failed we manually inspectedthe API to address the issues such as formatted inputs (eg UUID)stateful calls (an API needs to be invoked before another) etcStep S2 tracking system API As mentioned in Section 21 theexecution of a sub-app API enters the native layer of the hostthrough a dispatcherdispatch function and then its controlflow reaches system APIs (Figure 1) Therefore Step S2 first iden-tifies the dispatcherdispatch function in the host apprsquos nativelayer then tracks its call graph to find the system APIs triggeredby the sub-app API call as elaborated below

(1) Find the dispatcherdispatch function in the native layer Asmentioned earlier Webview and React Native are bridge techniquesto expose dispatcherdispatch to JavaScript layer Note thatthough the object alias (dispatcher) and function name (dispatch)vary across host apps they can be obtained by inspecting functioninvocations in Encapsulation lib (Figure 1) which is a preprocess-ing step in our study Note that the Encapsulation lib usually canbe found in JavaScript files packaged in the host app (eg underassets folder) So all we need is to identify the dispatcher objectin the native layer based on the obtained alias

To this end S2 implements an Xposed [7] (a framework to in-strument Android app execution) module to hook Webview APIaddJavascriptInterface(obj alias) (that exposes Java objectto JavaScript through an alias) and inspect its arguments at run-time if the ldquoalias argumentrsquos value matches the dispatcher aliasdiscovered the ldquoobj is the dispatcher object that we are lookingfor The analysis of React Native bridge is slightly different wehook its API createNativeModules to get its Java objects exposedto JavaScript our Xposed module then calls each exposed objectrsquosgetNamemethod to get its alias ndash if this alias matches the dispatcheralias discovered the object is what we are looking for

5Host apps are typically third-party apps that cannot call privileged system APIs pro-tected by ldquosignature or ldquosignatureOrSystem level permissions [65] or they typicallydo not delegate the access to such APIs through sub-app APIs

8

(2) Track execution of the dispatcherdispatch function Our toolthen tracks the call graph of the dispatch function to find the calledsystem APIs ndash which are called to fulfill the sub-app API call Specif-ically our Xposed module hooks dispatch function and AndroidAPI and inspects their respective call stack traces However wefound that dispatchrsquos thread sometimes does not call Android APIsdirectly it triggers additional thread to call Android APIs likelyfor not to block the dispatch thread This introduces a challengeXposed outputs the above two stack traces by threads ndash one stacktrace with Android API call and the other with dispatch functioncall ndash but cannot correlate two threads if one triggers the otherTherefore we still cannot confirm that the Android APIs are in-voked due to dispatch Hence we developed techniques to deal withthe multi-threading challenge

In our study we found that Handler a typical multi-threadingmechanism of Android is commonly used by dispatchrsquos thread totrigger a new thread Thus we implemented our own thread corre-lation technique based on the Handler mechanism in our Xposedmodule More specifically in the Handlermechanism a triggeringthread that holds a handler instance will submit a runnable to amessage queue via calling the handlerpost(runnable) methodHere the runnable is an instance of Java Runnable [3] with codein its run() method Then the runnable is taken out of the queueby another thread which we name as the handler thread andgets executed in the handler thread Hence as checked in ourXposed module if the executed runnable in a handler thread isthe same instance with one submitted by a triggering thread thenwe correlate the two threads Through such techniques we foundAndroid APIs are indeed called in such handler thread followingthe dispatch threadrsquos triggering ndash this confirms the Android APIcall caused by the dispatcherdispatch functionStep S3 synthesizingAPI-permissionmapping As mentionedin Section 31 system API-permission mappings are incompletewhich can lead to escaped sub-app APIs How to derive a completemapping remains an open question in system security researchand program analysis Here our idea is to supplement recent map-pings [35 46] leveraging documentation analysis we automaticallyextract explicitly declared permissions for system APIs in the devel-oper manuals assuming that explicit specification at least reflectsintended protection of the OS with rare faults Note that certainportion of the documentation (Figure 2) can be misleading to hu-man readers due to incomplete presentation but we observed thatan exhaustive machine-based search on the whole corpus of mobileOSes (eg the entire documentation for all 2497 SDK classes of An-droid API level 27) can help us derive a significantly more completemapping than state-of-the-art mappings [35 46] (see evaluationbelow) For instance after a full scan of Android WifiManager man-ual [75] we were able to flag ACCESS_FINE_LOCATION as a requiredpermission for multiple Wi-Fi scan related APIs (see Figure 8 inAppendix) which has never been included in state-of-the-art map-pings [35 46]

In our implementation we developed a Web crawler to fetchall manuals from Android developer portal [62] and extractedthe description for each public API From the description we ex-tracted the declared permissions based on a few key observations

if the description of an API does not contain a ldquopermission key-word it is very likely that the API does not explicitly requirepermissions otherwise its description usually includes a ldquoper-mission keyword and the exact permission string constants de-fined in Android class androidManifestpermission [77] suchas ACCESS_FINE_LOCATION Based on such observation we per-formed a light-weight string matching to find explicit permissionrequirement of Android APIs (we discuss the sophisticated NLP-based direction in Section 5)

Step S3 also derives a sub-app API-permission map given itsrelatively small size (ie 50 to 172 sub-app APIs in each host com-pared to 35847 public Android APIs found by our Web crawler)we extracted the map by searching ldquopermission related keywordsin sub-app developer manual and manually confirmed the resultStep S4 reporting flaws S4 reports an escaped sub-app API if itis not protected by sub-app permission while its correspondingAndroid API(s) is protected by dangerous permission(s) That is aSystem Resource Exposure flaw is found

For iOS however a comprehensive detection is much more dif-ficult than Android especially because obtaining a system API-entitlement mapping is much more challenging First we are notaware of any work that has produced a mapping on iOS for us tostart with Second we observed that iOS documentation is not asprecise as Android in this regard which describes required enti-tlements for iOS classes but not for individual system API To stillhelp us understand the impact of escaped sub-app API on iOS weextended our findings of escaped sub-app API from Android to iOSif its corresponding iOS API requires an entitlement it is consideredto affect iOS as well This was done by manually searching corre-sponding iOS API for a given escaped sub-app API and checkingwhether any entitlement is asked when the iOS API is invoked inan iOS app we builtEvaluation We evaluated the effectiveness and performance of ouranalysis tool (source code released [12]) on a Google Pixel 2 phoneand iPhone 8 against 11 host apps The evaluation was performedon three Android versions (81 9 10 corresponding to API level 2728 29) and two iOS versions (12 134)bullOverall detection resultsApinat found 39 System Resource Exposureflaws all of them affect Android 81 9 and 10 13 of them affectiOS 12 and 134 We manually validated that all discovered flawsare true in two steps (1) confirming that the sub-app API requiresno sub-app permission through a testing sub-app (2) confirmingthat the corresponding system API(s) has permission protectionthrough a testing native app on Android and iOSbull Evaluating individual steps Step S1 generated test cases for all927 sub-app APIs under test in less than one hour All sub-app APIswere successfully invoked at least once without exception on eachAndroid version In this experiment we did not measure the hostrsquoscode coverage because the host includes implementation of its ownrich functionalities that are unrelated to sub-app API Thus it is notmeaningful to compute the percentage of covered host app code

Step S2 took less than 30 seconds for each sub-app API to reportits corresponding system APIs on each Android version The num-ber of system APIs (protected by dangerous permissions) hookedby S2 is 111 129 145 on the three Android versions respectivelyTo evaluate the correctness of our thread correlation we created

9

a test app which triggered new threads leveraging the Handlermechanism Our test showed that our tool correctly correlated thetriggering and triggered threads on each Android version

Step S3 produced the API-permission mapping including 94public APIs protected by dangerous permissions at API level 27103 APIs at API level 28 and 119 at API level 29 This step took ourapproach three hours to process the descriptions of 35847 42302and 44323 public APIs on the three API versions respectively Tovalidate the correctness of the mapping we constructed a test app toinvoke all the APIs and verify the required permissions at runtimeFor all three Android versions our permission mapping of all except6 APIs are correct Specifically the mapping of 92 APIs out of 94is correct (979 precision) at the API level 27 The two false casesare unprotected APIs hasPermission and requestPermission inclass UsbManager [66] At API 28 the mapping shows a precisionof 971 with one new false case than what was found on API 27(3 cases in total) API 29 shows a precision of 95 with three newcases than API 28 (6 cases in total) Figure 6 and 7 in Appendixlist all six false cases Their descriptions are more complex and weenvision that a natural language processing (NLP) based approachcan further improve our precision (see discussion in Section 5)

To evaluate the coverage of our documentation analysis toolwe randomly selected the documentation of 153 classes 641 APIs(out of 2164 classes) and then manually reviewed and identified52 API-permission mappings as the ground truth Running on theaforementioned documentation our analysis tool shows a precisionof 100 and a recall of 100 to identify API-permission mappingfrom the documentation

We also compared the completeness of our mapping with recentmappings [35 46] They collectively reported 50 public AndroidAPIs that require dangerous permissions on API level 25 (we werenot able to get results of newer Android from the authors) as asignificant improvement our tool was able to find 91 APIs (82more) that require dangerous permissions on the same API versionDiscussion Apinat may not find all escaped sub-app APIs In par-ticular Step S3 cannot derive a complete mapping if the documen-tation is incomplete [56] or too sophisticated to process Apinatonly looks for system resource exposure by public system APIs andundocumented system APIs used by host apps may also lead to theflaw but remain undetected Also Apinat falls short in analyzingobfuscated host apps eg that uses dynamic code loading andimplementations in CC++ Hence Apinat did not scan Web AppAPIs due to the extensive CC++ implementation in browsers Inaddition incorrect documentation (which we assume is rare andindeed our tool did not report any false escaped sub-app API ) mightlead to false alarms if not properly validated

42 Finding UI Deception FlawsDesign To find out the opportunities for Sub-window Deception(Section 32) in a host app Apinat looks for the apprsquos sensitive sub-windows which can be the targets of the attack As discovered inthe wallet UI confusion (Figure 4b) the hostrsquos sub-windows thatare likely to show up in the presence of a sub-app tends to be thosethat can be triggered through sub-app APIs If such a sub-windowalso contains sensitive information our approach then reports it asa potential target for Sub-window Deception

Implementation To detect such sub-windows Apinat monitorsthe change of the host UI in response to each sub-app API callto identify the sub-window triggered by the API call and thendetermines whether it carries sensitive content Specifically ourapproach first constructs a testing sub-app with an empty UI Thenit runs the sub-app API test cases in Section 41 to call each sub-appAPI through the testing sub-app and further inspects the UI screen-shots before and after the call for changes This is done through apixel-to-pixel comparison of two screenshots To capture the screen-shots we developed a screen projection service on Android usingthe Media Projection [63] API Also our screenshot compari-son was implemented using the OpenCV cv2absdiff API [85]For each sub-window identified our approach continues to findthose associated with sensitive information For this purpose itextracts strings from sub-window screenshots using the onlineOCR service [34] From the strings Apinat further utilizes a list of121 sensitive data keywords and the keyword pair list from recentresearch [91] to recognize those carrying sensitive content Notethat like a mobile OS an app-in-app system also provides a set ofsub-app APIs for sub-apps to dynamically generate UI componentssuch as wxcreateCanvasContextdraw() in Wechat To controlfalse positives Apinat omits such sub-app APIs based on the APIcategory in the sub-app API documentation As a result Apinat suc-cessfully detected 6 Sub-window Deception flaws (Section 43) ForiOS we got the same result since sub-app APIs are across-platformthe one triggers a sub-window on one OS also does that on theother (see Section 2)Evaluation Apinat detected 5 sub-app APIs associated with the UIdeception flaw we manually confirmed that all of them trigger sub-windows with sensitive information Also all of them affect bothAndroid (version 81 9 10) and iOS (version 12 134) Performance-wise the screenshot comparison and OCR analysis together tookless than 5 seconds on a desktop with Intel i5 27 GHz CPU and 8GB memoryDiscussion Soundly detecting whether a host app is susceptibleto Sub-app Lifecycle Hijacking (Section 33) is difficult especiallybecause it entails detection of side-channel information leakagewhich can happen in many ways and is hard to capture in generalTo measure a lower bound of the pervasiveness of the problemwe checked whether the hosts in our study (Table 1) had the sameinformation leakage and lifecycle design as reported in Section 33As a result 3 host apps on Android (Wechat Alipay DingTalk) aresusceptible which were all manually confirmed to be exploitable

43 Measurement of ImpactFlaw landscape With the help of Apinat we analyzed 11 highlypopular host apps (Table 1) on Android and iOS and found theyare all vulnerable to APINA flaws (Table 3) Altogether we found 52APINA flaws including 39 System Resource Exposure 10 Sub-windowDeception and 3 hosts vulnerable to Sub-app Lifecycle Hijacking

For System Resource Exposure in total we uncover 39 escaped sub-app APIs associated with 5 categories of exposed system resources4 Android dangerous permissions and 6 iOS entitlements Table 5shows the flaw number for each category of resources (the secondcolumn) and illustrates 8 escaped sub-app APIs with correspondingAndroid permission(s) and iOS entitlement(s) ignored to enforce

10

Table 3 Eleven vulnerable host apps on Android and iOS(A Alipay B Baidu C Chrome D DingTalk F FirefoxJJinRiTouTiao O Opera Q QQ S Safari T TikTok WWechat) NA denotes the flaw does not apply to the OS

Type of APINA Flaw iOS AndroidSystem Resource Exposure A D J Q T W A D J Q T WSub-window Deception A B D W S Q A B C D F W O QSub-app Lifecycle Hijacking NA A W Q

on them All 39 escaped sub-app APIs are listed in our releaseddataset [12] Also Table 6 illustrates 6 Sub-window Deception in non-browser hosts additionally all four browsers we studied (ChromeSafari Firefox Opera) are susceptible to the same Prominent UIattackResource comparison between Android and iOS Althoughfinding the full API-entitlement mapping for iOS is hard we ob-served a few differences between Android and iOS in system re-source protectionbull iOS is less affected than Android Out of 39 escaped sub-app APIs13 are related to iOS which appears to be less affected and harderto be exploited There are two reasons behind the observation asdiscovered in our study First certain iOS APIs return less informa-tion than its Android counterparts (ie those related to Bluetoothsee Section 31) and thus is less susceptible to privacy risk (locationleakage) Hence all 27 Bluetooth related escaped sub-app APIs donot affect iOS (see Table 5) Second WiFi related escaped sub-appAPIs (see Table 5) are much harder to exploit on iOS since Applehas extra protection besides entitlement Specifically right beforethe programmaticWiFi operation an iOS appmust obtain the userrsquosexplicit consent the app must instruct the user to manually openthe WiFi setting page in the Settings app and then return to theiOS app [43] ndash an indicator of user intention for the app to operateWiFibull iOS entitlement fails to communicate risks to the user On Androidwhen the permission ACCESS_FINE_LOCATION is used for protect-ing the operation Wi-Fi scan it indicates a risk that the WiFioperation may leak location a highly private data On iOS how-ever the entitlement for Wi-Fi scan ie Hotspot Helper failsto communicate such a risk Actually to get this entitlement for aniOS app app developers must file a special written request by justi-fying that the app does not have malicious intention Apple reviewsthe request internally and possibly assesses the risks of locationleakage behind the scene However the name of this entitlementand its documentation we could find does not show that Wi-Fiscan needs location protection on iOS This may have been oneof the factors leading to escaped sub-app API wxgetWifiList (seeTable 5) which performs Wi-Fi scan without protectionAttack consequences The system resources exposed by escapedsub-app API and the risks can be identified from the API namesand the permissions they violate (see Table 5) For example unautho-rized sub-apps can use escaped sub-appAPI wxgetRecorderManag-er to record audio (violating Androidrsquos RECORD_AUDIO permission)We summarize the attack consequences in Table 4 Further Sub-window Deception leads to phishing on popular Web services (egFacebook) mobile wallets and sensitive host UIs For exampleWechat has a UI triggered by sub-app API (wxaddPhoneContact)

Table 4 Examples of APINA attack consequences

Flaw Type Consequences (what the adversary is able to do)

SystemResourceExposure

record audio operate camerainfer victimsrsquo geo-location (thus track users)

connect victimrsquos device to arbitrary Wi-Fi (thus manipulatenetwork traffic perform man-in-the-middle (MITM) or phishing)

and steal sensitive QR code etcSub-windowDeception

steal account credentials on Facebook Google Amazon etcsteal mobile wallet passwords contacts etc

Sub-appLifecycleHijacking

steal money (payments in shopping sub-app)steal personal secrets (eg answers tosecurity questions health records etc)

steal business documents (from a document processingand management sub-app published by Microsoft)

steal account credentials of Amazon ICBCCCB HSBC (1st 2nd 7th largest banks in the world)

Airbnb Weibo Starbucks McDonaldrsquos etc

for users to enter contact information (Table 6) attacking this UImay leak contacts which are highly private Last Sub-app LifecycleHijacking affects three hosts (Table 3) and the risks come fromimitating sub-apps supported by these hosts such as sub-apps forAmazon health banking Airbnb etc (see Table 4)Cases Studies We discuss a few other problems we observed inapp-in-app ecosystembull Keeping up with the OS evolution Sub-app API permission policyshould keep up as the OS always evolves newer OS version oftenintroduces more strict protection against sensitive resources Forexample since Android 10 an app that accesses location in the back-ground needs an additional dangerous permission ACCESS_BACKGRO-UND_LOCATION in addition to the regular location permission [82]This protects user location against illicit tracking However sub-app API for accessing location in hosts TikTok and Alipay did notkeep up with such a new protection thus leaving their users at risk

As another example for the WiFi and Bluetooth scan that canleak location Android 9 and 10 require ACCESS_FINE_LOCATIONpermission while Android 81 is less restrictive and ACCESS_COARSE_LOCATION is sufficient (see Table 5) Note that Android uses the firstpermission to control access to precise location (eg GPS data)and uses the second one for coarse-grained positioning (with anaccuracy approximately at the level of a city block [10]) Interest-ingly all hosts we studied only define a general location sub-apppermission to govern location API (eg scopeuserLocation inWechat) but do not differentiate the two levels of accuracybull Too many APIs for one permission APIs of apparently differentfunctionalities should never be governed by the same permissionHowever in the host TikTok (an extremely popular short-videosharing app with more than 500million downloads on Google Play)three sub-appAPIs ttscanCode ttchooseImage and ttchoos-eVideo (for scanning QR code accessing photos and videos) aregoverned by the same permission scopecamera and thus inade-quately protected For example a malicious sub-app that is grantedpermission by the user to scan QR code also behind the scenesilently gets access to API ttchooseImage that accesses user pho-tos posing a serious privacy risk

5 LESSONS AND MITIGATION STRATEGYLessons learned The most important lesson learnt from our re-search is the caution one should take when building a third-party

11

Table 5 Summary of System Resources Exposure flaws (NA means the flaw does not affect the OS)

SystemResourceExposed

of

FlawsExample of Escaped

Sub-app API Dangerous Permission Android API Entitlement iOS Class

Microphone 1 WechatwxgetRecorderManager RECORD_AUDIO mediaMediaRecorder

CaptureRequest Microphone Usage AVAudioRecorder

Camera 3 Alipay myscan CAMERA CameraManageropen-CameraCaptureRequest Camera Usage AVCaptureSession

Wi-Fi 4WeChatwxgetWifiList

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetScanResults Hotspot Helper dagger NEHotspotHelper

JinRiTouTiaoTikTokttgetConnectedWifi

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetConnectionInfo Access WiFi Information dagger CNCopyCurrent-

NetworkInfo

Bluetooth 27

Alipay mystartBluetoothDevicesDiscovery

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan NA NADingTalk

ddgetBluetoothDevicesAlipay

mygetBLEDeviceServices

iBeacon 4 Alipay mygetBeaconsACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan Location Usage CLBeaconRegion

dagger Much harder to exploit on iOS due to the requirement of explicit user approvalDagger Android 9 and 10 require ACCESS_FINE_LOCATION permission while Android 81 requires ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION

Table 6 Examples of Sub-window Deception flaws

Host App Triggering Sub-App API Legitimate (and spoofable)Functionality of the Sub-window

Alipay mytradePay Request password ofAlipay mobile wallet

Baidu swanrequestPolymerPayment Request passwords ofmultiple mobile wallets

DingTalk ddpay Request password ofAlipay mobile wallet

WechatwxaddPhoneContact Enter new contacts

wxrequestPayment Request password ofWechat mobile wallet

QQ new in-app message Display instant messagesand enter a reply

sub-ecosystem on top of the operating system In such a case thethird-party OS-like app strives to provide a secure self-containedenvironment However whether it undermines OS security andbrings in new risks to modern mobile applications need to be eval-uated to identify the security gap between the new sub-ecosystemand the OSes Our measurement study shows that popular host appsare generally susceptible to APINA flaws indicating that the app-in-app system vendors today either fail to identify or are unpreparedfor the new risks

Fundamentally APINA risks come from the limited app-levelcapabilities the host app has in managing OS resources lack ofOS-level support and missing of sub-app API standard Hencedown the road it will require non-trivial joint efforts to fundamen-tally eliminate APINA risks More specifically escaped sub-app APIshows that a third-party host fundamentally lacks the full OS-levelknowledge on system resource protection While such knowledgecan come from different sources eg program analysis on relevantOS modules [35 46] developer documentations technical reportsetc each source only contributes a partial view Hence joint effortsneed to be made in the future to synthesize such knowledge Ourstudy also brings to light that such efforts are by no means trivialndash even the two leading mobile OSes have apparently confusingconflicting security policies Synthesizing such a knowledge base

will not only benefit the app-in-app paradigm but also make theOSrsquo security mechanism more transparent for thorough auditing

Our findings also highlight that prior OS lessons cannot fullyeliminate new risks incurred by the new paradigm which necessi-tates thorough assessment regarding its new attack surfaces Forexample a malicious sub-app a sub-window and a task in Recentsscreen all come as new attack vectors that pose credible new threatsto usersrsquo most sensitive credentials and privacyMitigation strategy Following we propose the short-term miti-gation and discuss the long-term strategybull Escaped Sub-app API Eliminating the risk requires the host tohave full OS-level knowledge about resource control (eg API-permission mapping) which is difficult In the meantime our toolApinat together with our API-permission mapping (released on-line [12]) can help host app vendors identify escaped sub-app APIsNote that since Apinat can identify escaped sub-app API with itsignored permissions with respect to specific OS version (see Sec-tion 43) host vendors may leverage our tool to assess whether theirsub-app API permission policy is always compliant with newly re-leased OS version and thus keep up the pace

Further we envision two possible future directions that couldlead to more viable solutions First as demonstrated by our anal-ysis tool Apinat although it is hard for todayrsquos program analy-sis techniques to derive a complete system API-permission map-ping [35 46] we could significantly improve its accuracy and com-prehensiveness through developer documentation analysis Ourcurrent documentation analysis is rather preliminary but still effec-tive as demonstrated in our study (Section 4) Down the road wecould develop natural language processing (NLP) based techniquesfor deriving more complete knowledge about API permission poli-cies With the techniques an analysis could cover a wider spectrumof literature including iOS documents research papers technicalreports etc which will help derive up-to-date knowledge aboutresource-management policies

Second the app-in-app community should work together tostandardize sub-app APIs and their permission policies as donein the HTML5 community on HTML5 APIs For the time being

12

different app-in-app vendors bring in their own APIs for accessinga wide spectrum of systems resources (see our comparison betweensub-app API and HTML5 API in Table 7 in Appendix) often withoutproper safeguard in place not to mention any effort to standardizethe protectionbull Sub-window deception The risk comes from the UI confusionwhether a window portion in the sub-app window belongs to thesub-app or the host (Figure 3b) To mitigate the risk we envision ahigher degree of UI isolation between the sub-app and the host thesub-apprsquos window should always be separated from that of the hostand the host should never reclaim any window portion from thesub-applsquos window Regarding the Wallet UI confusion (Section 32)for example Wechat should display its wallet UI only in its ownwindow and advertise to users that any UI component inside thesub-app window belongs to the sub-app

A question arises whether a malicious sub-app can fake a crashand then show spoofing content in the sub-app window to resem-ble the host This can be mitigated through additional protectionsupported by the host Specifically the host app could keep mon-itoring the UI of its sub-apps (eg through PixelCopy API onAndroid [71]) to detect whether a UI object in the sub-app is similarto a sub-window or a security-sensitive UI object associated withhost app For performance concern the host app could utilize thestate-of-the-art object detection model (eg Fast Region-based Con-volutional Network based model [61] and YOLO [32 95]) for thereal-time security-sensitive UI object recognition as reported inprior research [95] Fast YOLO yields the performance of 155 framesper second Note that the effectiveness efficiency and deploymentfeasibility of such an approach need to be carefully explored andevaluated which we leave for our future researchbull Sub-app lifecycle hijacking To mitigate this risk a short-termdefense is to place all sub-app resources in the phonersquos internalstorage so our current exploit (leveraging monitoring the phonersquosexternal storage) to track sub-app lifecyle termination (Section 33)can be mitigated However it is always a concern that sub-appsmay deplete the limited space on a phonersquos internal storage Along term solution needs to consider how to make the sub-apptasks dynamically scalable to ensure that the sub-app recycling isno longer traceable and thus the attack surface is fundamentallyeliminated This nonetheless calls for support from modern OSesfor the emerging app-in-app paradigm

6 RELATEDWORKAs mentioned in Section 2 recent years witnessed several tech-niques to support the functionality of app encapsulation (eg Plu-gin frameworks app sandboxing browser extension and PhoneGapapp see Table 2) Accordingly numerous studies have looked intothe flaws in these app encapsulation systems considering the se-curity analysis of Plugin frameworks a set of flaws were revealed[99 111 112] including no permission management and no isola-tion of the virtualized apps Compared with Plugin frameworks theapp-in-app paradigm has a much stronger security model and ourstudy investigates the design challenges and pitfalls in the securitymechanism Meanwhile the security and privacy implications ofbrowser extensions have been extensively studied [48 54 84 98]

Furthermore the current security studies on PhoneGap apps fo-cus on the flaws of PhoneGap frameworkrsquos access control policy[60 90 100 101] For example Song et al [101] revealed that thebridges added by the framework to the browser are not correctlyprotected by the same origin policy Jin et al [86] introduced mul-tiple channels (eg barcode SMS file system Contact) for codeinjection attacks in PhoneGap apps Different from these works wefocus on the unique features of the app-in-app paradigm (Table 2)and reveal multiple new attack surfaces which have never beenstudied before

The closer to our study are the works of Web App and WebViewvulnerability assessment Up to our knowledge only one paper[87] analyzed security issue of Web App in which the securityand privacy risks on HTML5 features in PWA were investigatedIn our attack on Web App we did not focus on HTML5 featuresbut a general UI isolation and management model in app-in-appparadigm Also although WebView technique is used in some ofthe app-in-app systems in sharp contrast to the works on Webviewweaknesses [36 60 88 102 105 109 110] our study explores thesecurity implications and challenges for a third-party app tomanageoperating system resources Another set of works related to ourstudy is the exploitation of mobile UI deception Prior phishingattacks [38 49 53 57 97] mislead victims about the foregroundapp aiming at information theft in spoofing apps Correspondingcountermeasures [49 58 96] emphasize identifying the app of thewhole foreground window and thus cannot thwart Sub-windowDeception due to the inability to identify sub-windows Furtheranother angle of UI deception is clickjacking [59 94] which aredifferent from our mobile-phishing attacks7 CONCLUSIONIn this paper we present the first systematic security analysis on re-source management in high-profile app-in-app systems Our studyshows that such systems are susceptible to a set of serious securityflaws Our measurement study further sheds light on their perva-siveness in the real-world Further our study brings in new insightsinto the fundamental security limitations of this new paradigm andfurther contributes to a better understanding of its mitigation strat-egy an important step towards building a more secure app-in-appecosystem

8 ACKNOWLEDGMENTWe would like to thank our shepherd Yanick Fratantonio and theanonymous reviewers for their insightful comments This work issupported in part by the NSF CNS-1618493 1801432 1838083

REFERENCES[1] 2011 HTML5 Fullscreen API Attack httpsferossorghtml5-fullscreen-api-

attack[2] 2011 The Inception Bar httpsjameshfishercom20190427the-inception-

bar-a-new-phishing-method[3] 2018 Java Runnable httpsdocsoraclecomjavase7docsapijavalang

Runnablehtml[4] 2018 A one year PWA retrospective httpsmediumcompinterest-

engineeringa-one-year-pwa-retrospective-f4a2f4129e05[5] 2018 Wechat 1 million sub-apps httpswwwscmpcomtecharticle2153705

tencents-wechat-now-host-1-million-mini-programs[6] 2018 WeChat reaches 1M sub-apps half the size of Applersquos App Store https

techcrunchcom20181107wechat-mini-apps-200-million-users[7] 2018 Xposed httpsapixposedinforeferencepackageshtml[8] 2019 AdBlock httpsgetadblockcom

13

Figure 2 Misleading Android documentation

audio recording APIs (RECORD_AUDIO [72] permission on Androidand Microphone Usage [42] entitlement on iOS) the sub-app APIto record audio (eg wxstartRecord in Wechat) should also beprotected by a sub-app permission (eg by sub-app permissionscoperecord in Wechat) However in our study we found theinconsistency in permission requirement between sub-app API andsystem API indicating that the host fails to create the correct per-mission policies that govern sub-app API for system resource accessAs a result certain sub-app APIs that wrap permission-protectedsystem APIs are completely open to any sub-apps without requir-ing a sub-app permission exposing sensitive system resources Wename such unprotected sub-app API escaped sub-app API and theproblem System Resource Exposure

An example discovered in our research is the unprotectedWechatsub-app API wxgetWifiList that performs WiFi scan a capa-bility protected by the underlying OSes against user location leakeg through an entitlement Hotspot Helper on iOS and danger-ous level location permissions (ACCESS_COARSE_LOCATION andACCESS_FINE_LOCATION) on Android This exposes the WiFi scancapability to sub-apps leaking out user location to them Notethat a high-profile host app (eg Wechat) is typically granted thelocation permission and many other permissions due to its richfunctionalities (see Table 9 in Appendix) As a result through thedelegation the host makes to the sub-app escaped sub-app APIeffectively opens a door for the adversary to gain unauthorized ac-cess to system resources In addition to wxgetWifiList we foundmany other escaped APIs in popular app-in-app systems affectingdiverse sensitive resources across iOS and Android (Section 43)

Looking into the possible root causes we found that it is verychallenging for an app-in-app system to soundly define sub-appAPI permission policies that comply with the OSes in governing sys-tem resources due to the incomplete knowledge about permissionchecks that happen at related system APIs Specifically official API-permission maps for both Android and iOS have never been madepublic Although several prior attempts [35 45 46 56] have beenmade to automatically map Android APIs to their required permis-sions we found that the prior results are incomplete (Section 43)and highly likely to introduce escaped sub-app APIs if they are usedto design a sub-app permission system Consider the above exam-ple of WiFi scan recent results [35 46] (on Android API level 25)report that a related Android API WifiManagergetScanResultsrequires just a normal permission ACCESS_WIFI_STATE but failto mention that dangerous permission location is also required(required since Android API level 23 [80]) Further Section 43 re-ports more escaped sub-app APIs possibly caused by the incompleteAPI-permission maps

Such API-permission mapping information has also not beenwell recorded by the developer documentation We found that suchdocumentation can be misleading or confusing Again let us useWi-Fi scan as an example as shown in Figure 2 the Android

documentation [75] may introduce the misconception that declar-ing ManifestpermissionCHANGE_WIFI_STATE is sufficient forWi-Fi scan Similar misguidance also appears on the Android doc-umentation for Bluetooth scan etc and has likely caused otherescaped sub-app APIs we found (Section 43)

Another observation of our study is that since sub-app APIis designed to be cross-platform (Section 21) the effort to buildsub-app API permission policies that comply with all OSes hasbeen complicated by the inconsistency between Android and iOSin resource protection Consider Bluetooth scan as an examplethe Android API BluetoothLeScannerstartScan requires thedangerous location permission while iOS does not Such a dis-crepancy likely causes confusion in app-in-app design which istypically built for both OSes with uniform security policies Whenthis happens we found that the app-in-app designer tends to leavethe related sub-app API unprotected For example the sub-app APIsfor Bluetooth scan are not protected in multiple host apps (egwxgetBluetoothDevices in Wechat) Actually the difference inpolicy-level protection could result from an additional securityguard put in place by the OS which is unaware to the app-in-appdesigner For example combining together Signal Strength andDevice ID of nearby Bluetooth devices reveals geo-locations [37]On Android the pair is returned together by the above Bluetoothscan API BluetoothLeScannerstartScan which thus needs apermission check on iOS however the pair has been partially ob-fuscated (Device ID is randomized) and is thus unprotected Wesuspect that the inconsistency as observed on capabilitiesresourcesWi-Fi scan Wi-Fi connect iBeacon etc is likely responsiblefor other escaped sub-app APIs we discovered (see Section 43)Discussion Android 60 (API level 23) started to use a runtimepermission model a user grants permissions at the apprsquos runtimewhen permissions are requested (eg when the app launches orwhen the user accesses a specific feature) [73] In this scenariowhen an escaped sub-app API tries to silently access a resourcethe host may have not been granted a permission to access thatresource thus a permission will be explicitly required Howeverthe OSrsquo permission granting window will show to the user thatit is the host app who requests the permission not the sub-appThis misleading request may lead to the wrongly inherited trustassociated with the hosts and make users grant the permissioninappropriately This is also the case on iOS when a permissionwindow pops up to confirm the hostrsquos access to a resource

Furthermore Table 9 in Appendix lists all Android dangerouspermissions and iOS entitlements requested by the vulnerable hostsright after launching It shows that the hosts proactively requestnecessary permissionsentitlements even before accessing any spe-cific features due to usability consideration [92] Those capabilitiesof the hosts will always be stealthily delegated to the sub-app viaescaped sub-app APIs which present serious risksAttacks and vendor acknowledgements We implemented anattack sub-app which ran inWechat v673 to steal userrsquos location onboth Android and iOS The attack sub-app utilized Wechat escapedsub-app API wxgetWifiList to perform Wi-Fi scan and snifferthe surrounding Wi-Fi access points The scan results included sen-sitive information ie BSSID Signal Strength and Device ID ofnearby Wi-Fi access points which enabled to infer the geolocation

5

(a) Real Prominent UI (b) Fake Prominent UI

Figure 3 Safarirsquos Prominent UI confusion on iOS

of a user [37] This attack sub-app successfully passed the vettingof Wechat sub-app store and ran on both iOS and Android versionsof Wechat Note that our attack sub-app has less than 200 lines ofcode which indicates that it is cost-effective for the adversary todevelop APINA flaws malware in the wild Besides we successfullybuilt attack sub-apps in other host apps eg Alipay DingTalk etcand reported the problems to all affected host-app vendors Theyall acknowledged the problem in particular Wechat and Alipayawarded us through bug bounty programs for this flaw

32 Sub-window DeceptionAnother unique app-in-app feature is the functionality-level inter-actions between the host and sub-app For this need the host doesnot fully isolate itself from sub-apps which unwittingly introducesnew attack surfaces and high spoofing risks against host-app UIBrowsersrsquo Prominent UI confusion To bring a native app-likeexperience Safari on iOS and Chrome on Android open each sub-app (ie Web App Progressive Web App or PWA) in an entirededicated window separate from the browser window just like anative app [44 78] ndash without any browser UI such as the addressbar Web App is programmed with JavaScript and HTML but mustmeet certain standards [68] With user confirmation the browsercan install a Web App to the phonersquos home screen (through anAPK [69] package created by Chrome or a Web Clip [44] createdby Safari) Such Web App takes the full screen if ldquostandalone orldquofullscreen is specified in its manifest file EachWeb App is clearlyassociated with specific Web domain when installed When the usernavigates to out-of-scope URL (ie of different origin) in a WebApp the browser displays a Prominent UI ndash a banner at the top ofthe screen (Figure 3a) showing the origin and secure connectionstatus ndash due to the lack of address bar According to Web Appdocumentation [67] users rely on such Prominent UI to be awarewhen they navigate out of scope an important security notice

Based on a study [57] mobile phishing attacks tend to happenwhen users become accustomed to familiar repeated contexts Morespecifically if users frequently encounter legitimate context theywill become conditioned to reflexively respond to it Here the cur-rent design of Web App conditions users to see the Prominent UI inout-of-scope navigation which we found poses a spoofable context

(a) Authentic wallet UI (b) Bogus wallet UI

Figure 4 Mobile wallet UI confusion

Specifically Web App is designed to embrace out-of-scope brows-ing [104] and let users freely navigate to other Web domains forservices such as login through FacebookGoogle (aka SSO [107])payment through PayPal etc The problem is that when a victimuser navigates out of scope eg to Facebook login page a mali-cious Web App can actually navigate to an in-scope phishing pageimitating Facebook showing a bogus Prominent UI (as if shown bythe browser) to misleadingly inform the victim that she is on a realFacebook domain (Figure 3b) In this way the malicious Web Appcan collect victim usersrsquo secrets such as Facebook passwords

We call this problem Sub-window Deception ndash sub-window meanspart of a window Prior phishing attacks in browsers exploredhow a webpage can go full screen and spoof the address bar [12] as another instance of mobile browser UI attacks our attackcomplements the prior understanding by exploiting ProminentUI ndash the counterpart of address bar in the context of native app-like Web App Note that address bar differs from Prominent UIin design based on the Web specification [106] browsers ldquoshouldprovide a means of exiting fullscreen that always works and advertisethis to the user [106] so users can see the real address bar whenthey want (although browsers may not implement this protectionproperly [89]) Web App users however lack practical mechanismsto verify the authenticity of Prominent UI today This attack appliesto general Web App on both iOS and Android we reported it toW3C4 Apple Google Firefox and Opera which all acknowledgedthe importance of the problemMobile Wallet UI confusion Wechat and Alipay both featuremobile wallets which can be leveraged by e-commerce sub-appsto provide users a convenient payment process Amazon sub-appfor example after a user clicks its ldquocheckout with Wechat wal-letrdquo button will invoke a sub-app API (eg wxrequestPaymentin Wechat) to trigger the hostrsquos wallet the host then reclaims acentral portion of the screen from the sub-app to show its walletUI (highlighed in Figure 4a) for the user to enter her wallet pass-word and finish the payment Such a context can condition usersto reflexively provide wallet passwords at checkout and thereforepresents a practical spoofing target Specifically when a victim userclicks the ldquocheck out button in a malicious e-commerce sub-app itcan show a bogus wallet UI (Figure 4b) to collect the userrsquos walletpassword instead of invoking the real wallet

4We do not provide the link to our report for anonymization purpose

6

(a) Real sub-app task (b) Bogus sub-app task

Figure 5 Dedicated task for every sub-app in Recents screen

Up to our knowledge state-of-the-art mobile anti-phishing tech-niques cannot identify our attacks for example [49 58 96] mainlyrely on identifying the app of the whole foreground window so theuser would not expose secrets to the unintended app this cannotidentify a sub-window at the sub-app level ndash whether it belongs toa sub-app or the host app

Our study shows that a bogus sub-window presents a practicalattack vector in app-in-app since a window portion (sub-window)can be used by both the sub- or host- app in accustomed contextswithout differentiation through clear identification From a broadersense we believe the spoofing risk is also high if the OS showsits pop-up atop an app (so malicious app can show a bogus onewhen the OS does not) however in sharp contrast such pop-upis not sub-window (but whole window) and known anti-phishingtechniques (eg [49]) to identify (the owner of) the whole windowcan defeat itAttacks and vendor acknowledgementsWe implemented PoCattacks in Safari on iOS Chrome on Android and Wechat on bothOSes in Safari and Chrome our malicious Web App impersonatesProminent UI to spoof Facebook login page in Wechat our mali-cious sub-app mimics the wallet UI to steal wallet password (seevideo demo online [12]) Our malicious sub-app passed the vettingof Wechatrsquos sub-app store Note that Web App does not have appstores and can be installed after visiting its URL In addition wereported the problems to all affected host vendors who all acknowl-edged that the threats were practical and severe Wechat and Alipayawarded us through their bug bounty programs

33 Sub-app Lifecycle HijackingAs app vendors follow the app-in-app trend by releasing sub-appsit is unclear whether their users remain equally protected as beforeUnfortunately our study shows that even highly credible host appscannot fully eliminate new attack surfaces incurred by app-in-appRecents screen takeover The Recents screen (aka recent task listor recent apps) [64] is a system-owned UI of Android to list recentlyaccessed task (Figure 5a) In particular each launched native appwill have a task in Recents screen similarly a host app creates aseparate task for every launched sub-app which appears in Recentsscreen Limited by the OS each host app can only create a fixednumber of tasks in Recents screen pre-specified as activities inits manifest file In our research we found that host apps all specify

a small magic number (eg 8 in Chrome 5 in Wechat 4 in Alipay3 in JinRiTouTiao) for the task limit

When an additional sub-app will be opened after the task limitis reached the host app silently executes a mandatory recyclingprocess closing the first opened sub-app to recycle its task forlaunching the new one The recycling process is transparent tousers for the possible purpose of not interrupting the user experi-ence Such a mandatory sub-app recycling mechanism introducesa new risk once the recycling is traceable by a malicious appie the adversary knows which sub-app has been recycled and atwhat time it can stealthily insert a phishing task into the Recentsscreen to imitate the silently recycled sub-app For this purposethe adversary needs to acquire the information about a hostrsquos taskrecycling which turns out to be feasible due to the presence ofvarious information-leak avenues that can be hard to eliminate Inour study we found a side channel that enables recycling track-ing in multiple host apps In particular possibly due to the richfunctionalities of sub-apps which require resource files (eg userdata logs icon and image texture) the host app creates a folderin Android external storage [18] to cache sub-app resources Suchexternal storage can be monitored by an Android native app totrack which sub-app is launched and at what time (by monitoringsub-app icon which will be downloaded at launch see PoC attackbelow) Thereby once the number of launched sub-apps reachesthe hostrsquos task limit the sub-app to recycle can be inferred Hencea malicious native app can insert a bogus task in Recents screento mimic the recycled sub-app at this point the bogus task is theonly one in Recents screen that represents the target sub-app thatrsquosspoofed (Figure 5b)

This attack is a kind of mobile task hijacking attacks [52 97]Regarding its root cause the mandatory sub-app recycling opens anew attack surface for app-in-app systems since it makes it possiblefor malicious apps to track a sub-apprsquos lifecycle termination Notethat the attack surface becomes exploitable in the presence of sidechannels eg external storage which itself is a relatively trivialbug Other side channels could also be used for the attack once theyarise (see discussion below) Eliminating this attack surface maynot be trivial in practice since the maximum task number of a hostin Recents screen is not dynamically scalable (statically specifiedin manifest) limited by the OS Although the very recent Androidsupports dynamic task no host app we studied (Table 3) adoptedit possibly for the purpose of supporting older Android versionsgiven the notorious Android version fragmentation [74]Attacks and vendor acknowledgementsWe implemented PoCattacks on Alipay andWechat which cache sub-app resources in theexternal storage and enable recycling tracking Specifically Alipaystores the caches at sdcardalipaymultimedia When a sub-app such as Amazon is launched its icon will be downloaded toit if not already there Our malicious Android app with a commonpermission WRITE_EXTERNAL_STORAGE can remove cached iconsperiodically andmonitor when they reappear to knowwhat specificsub-app is launched and at what time In our attack of Alipay oncethe malicious app infers that five sub-apps have been launched(submit-app task limit of Alipay is 4) it will insert a bogus task inRecents screen to mimic the first sub-app which is recycled Oncethe victim user enters the spoofing task through Recents screenit can lure the user to leak secrets such as passwords Note that

7

our malware successfully passed the vetting of popular app storesincluding Google Play We reported the problem (demo online [12])to Wechat and Alipay which both acknowledged the problem andawarded us through bug bountiesDiscussion on other side channels As mentioned earlier otherside channels once found can also be used for impersonating therecycled sub-app Prior research [113] shows that the operationsof Android apps can be easily tracked through the Android pro-cess file system (procfs) Although Android has been continuouslybeefing up its privacy protection until Android 9 still some globalstatistics under procfs are exposed Particularly we found that theTCP connection status under procnettcp can be accessed byany app without permission on Android 9 and below From the filewe can see the IP addresses of all TCP connections on an Androidphone which are labeled by randomly assigned User IDs Interest-ingly we found that an invoked sub-app makes a sequence of TCPconnections and the endpoints of the connections (domains) canuniquely fingerprint its initiation eg Amazon sub-app connects to4 unique endpoints with 8 consecutive HTTPS requests in the firstfew seconds after it is launched In our research we sampled 8 high-profile sub-apps in Wechat and identified the sequences of theircommunication endpoints as observed when they are triggered (seeTable 8 in Appendix) Through this side channel a malicious nativeapp is able to infer the launch of a specific sub-app so it can waituntil it is terminated for task recycling (eg after 5 other sub-appsare found to be started through the procfs when the magic numberis 5) to create a task to impersonate the sub-app Note that the mali-cious app can resolve the endpoint domains from IP addresses usingAndroid API InetaddressgetCanonicalHostName [81] withoutrequiring any permission which was implemented and confirmedin our study

Until April 2020 84 of the Android devices are still runningAndroid 9 or earlier versions [33] and therefore are vulnerable toour attack On Android 10 which was released in September 2019the procfs used in our attack has been closed by SEAndroid [70 83]and thus the attack is ineffective Seeking a more powerful attackavenue is left to the future research

4 APINA FLAWS IN THEWILDIn this section we report a measurement study that reveals thescope and magnitude of APINA flaws in the wild The study ismade possible by an automatic analysis tool we built called Apinat(short for App-in-app Threat Scanner) which helped us identifyapp-in-app hosts that are susceptible to APINA flaws

41 Identifying System Resource ExposureDesign Apinat aims to find System Resource Exposure flaws byidentifying escaped sub-app API The idea is to find sub-app APIthat is unprotected by sub-app permission while its correspondingsystem API is permission-protected A naive idea is to call eachsub-app API and find out whether the OS checks the permissions ofthe host app eg by looking at permission pop-ups or system logsThis does not work because the permission asked by the OS can berelated to the host apprsquos own rich functionalities not the sub-appAPI To systematically find escaped sub-app API our methodologytracks the system API invocations triggered by a sub-app API via

a dynamic analysis (Step S1 S2) and then utilizes system API-permission maps to derive required permissions of the sub-appAPI (Step S3) which will be compared to the corresponding sub-app permission If a sub-app API is not protected by any sub-apppermission while its corresponding system APIs are guarded by theAndroid dangerous permissions5 or iOS entitlements an escapedsub-app API is found (Step S4) Following we describe how thisdesign works and how it was implemented in our research onAndroid Since sub-app APIs are cross-platform we were able toextend all the findings made by our technique from Android to iOSby simply validating these findings on the Apple platformStep S1 generating test cases To conduct a dynamic analysis wefirst need to generate test cases with valid arguments to invoke eachsub-app API without triggering exceptions For each API we targetthat at least one invocation is successful The argument types ofJavaScript APIs are either primitive or Object [21] To produce testcases for primitive arguments we leveraged Mozillarsquos funfuzz [22]a JavaScript toolkit ForObject arguments we recursively generatedtest cases leveraging funfuzz because an Object includes keyvaluepairs its key is primitive and the value is either primitive or ObjectAll test cases were then used by a sub-app we built to invoke sub-app APIs If all test cases for an API failed we manually inspectedthe API to address the issues such as formatted inputs (eg UUID)stateful calls (an API needs to be invoked before another) etcStep S2 tracking system API As mentioned in Section 21 theexecution of a sub-app API enters the native layer of the hostthrough a dispatcherdispatch function and then its controlflow reaches system APIs (Figure 1) Therefore Step S2 first iden-tifies the dispatcherdispatch function in the host apprsquos nativelayer then tracks its call graph to find the system APIs triggeredby the sub-app API call as elaborated below

(1) Find the dispatcherdispatch function in the native layer Asmentioned earlier Webview and React Native are bridge techniquesto expose dispatcherdispatch to JavaScript layer Note thatthough the object alias (dispatcher) and function name (dispatch)vary across host apps they can be obtained by inspecting functioninvocations in Encapsulation lib (Figure 1) which is a preprocess-ing step in our study Note that the Encapsulation lib usually canbe found in JavaScript files packaged in the host app (eg underassets folder) So all we need is to identify the dispatcher objectin the native layer based on the obtained alias

To this end S2 implements an Xposed [7] (a framework to in-strument Android app execution) module to hook Webview APIaddJavascriptInterface(obj alias) (that exposes Java objectto JavaScript through an alias) and inspect its arguments at run-time if the ldquoalias argumentrsquos value matches the dispatcher aliasdiscovered the ldquoobj is the dispatcher object that we are lookingfor The analysis of React Native bridge is slightly different wehook its API createNativeModules to get its Java objects exposedto JavaScript our Xposed module then calls each exposed objectrsquosgetNamemethod to get its alias ndash if this alias matches the dispatcheralias discovered the object is what we are looking for

5Host apps are typically third-party apps that cannot call privileged system APIs pro-tected by ldquosignature or ldquosignatureOrSystem level permissions [65] or they typicallydo not delegate the access to such APIs through sub-app APIs

8

(2) Track execution of the dispatcherdispatch function Our toolthen tracks the call graph of the dispatch function to find the calledsystem APIs ndash which are called to fulfill the sub-app API call Specif-ically our Xposed module hooks dispatch function and AndroidAPI and inspects their respective call stack traces However wefound that dispatchrsquos thread sometimes does not call Android APIsdirectly it triggers additional thread to call Android APIs likelyfor not to block the dispatch thread This introduces a challengeXposed outputs the above two stack traces by threads ndash one stacktrace with Android API call and the other with dispatch functioncall ndash but cannot correlate two threads if one triggers the otherTherefore we still cannot confirm that the Android APIs are in-voked due to dispatch Hence we developed techniques to deal withthe multi-threading challenge

In our study we found that Handler a typical multi-threadingmechanism of Android is commonly used by dispatchrsquos thread totrigger a new thread Thus we implemented our own thread corre-lation technique based on the Handler mechanism in our Xposedmodule More specifically in the Handlermechanism a triggeringthread that holds a handler instance will submit a runnable to amessage queue via calling the handlerpost(runnable) methodHere the runnable is an instance of Java Runnable [3] with codein its run() method Then the runnable is taken out of the queueby another thread which we name as the handler thread andgets executed in the handler thread Hence as checked in ourXposed module if the executed runnable in a handler thread isthe same instance with one submitted by a triggering thread thenwe correlate the two threads Through such techniques we foundAndroid APIs are indeed called in such handler thread followingthe dispatch threadrsquos triggering ndash this confirms the Android APIcall caused by the dispatcherdispatch functionStep S3 synthesizingAPI-permissionmapping As mentionedin Section 31 system API-permission mappings are incompletewhich can lead to escaped sub-app APIs How to derive a completemapping remains an open question in system security researchand program analysis Here our idea is to supplement recent map-pings [35 46] leveraging documentation analysis we automaticallyextract explicitly declared permissions for system APIs in the devel-oper manuals assuming that explicit specification at least reflectsintended protection of the OS with rare faults Note that certainportion of the documentation (Figure 2) can be misleading to hu-man readers due to incomplete presentation but we observed thatan exhaustive machine-based search on the whole corpus of mobileOSes (eg the entire documentation for all 2497 SDK classes of An-droid API level 27) can help us derive a significantly more completemapping than state-of-the-art mappings [35 46] (see evaluationbelow) For instance after a full scan of Android WifiManager man-ual [75] we were able to flag ACCESS_FINE_LOCATION as a requiredpermission for multiple Wi-Fi scan related APIs (see Figure 8 inAppendix) which has never been included in state-of-the-art map-pings [35 46]

In our implementation we developed a Web crawler to fetchall manuals from Android developer portal [62] and extractedthe description for each public API From the description we ex-tracted the declared permissions based on a few key observations

if the description of an API does not contain a ldquopermission key-word it is very likely that the API does not explicitly requirepermissions otherwise its description usually includes a ldquoper-mission keyword and the exact permission string constants de-fined in Android class androidManifestpermission [77] suchas ACCESS_FINE_LOCATION Based on such observation we per-formed a light-weight string matching to find explicit permissionrequirement of Android APIs (we discuss the sophisticated NLP-based direction in Section 5)

Step S3 also derives a sub-app API-permission map given itsrelatively small size (ie 50 to 172 sub-app APIs in each host com-pared to 35847 public Android APIs found by our Web crawler)we extracted the map by searching ldquopermission related keywordsin sub-app developer manual and manually confirmed the resultStep S4 reporting flaws S4 reports an escaped sub-app API if itis not protected by sub-app permission while its correspondingAndroid API(s) is protected by dangerous permission(s) That is aSystem Resource Exposure flaw is found

For iOS however a comprehensive detection is much more dif-ficult than Android especially because obtaining a system API-entitlement mapping is much more challenging First we are notaware of any work that has produced a mapping on iOS for us tostart with Second we observed that iOS documentation is not asprecise as Android in this regard which describes required enti-tlements for iOS classes but not for individual system API To stillhelp us understand the impact of escaped sub-app API on iOS weextended our findings of escaped sub-app API from Android to iOSif its corresponding iOS API requires an entitlement it is consideredto affect iOS as well This was done by manually searching corre-sponding iOS API for a given escaped sub-app API and checkingwhether any entitlement is asked when the iOS API is invoked inan iOS app we builtEvaluation We evaluated the effectiveness and performance of ouranalysis tool (source code released [12]) on a Google Pixel 2 phoneand iPhone 8 against 11 host apps The evaluation was performedon three Android versions (81 9 10 corresponding to API level 2728 29) and two iOS versions (12 134)bullOverall detection resultsApinat found 39 System Resource Exposureflaws all of them affect Android 81 9 and 10 13 of them affectiOS 12 and 134 We manually validated that all discovered flawsare true in two steps (1) confirming that the sub-app API requiresno sub-app permission through a testing sub-app (2) confirmingthat the corresponding system API(s) has permission protectionthrough a testing native app on Android and iOSbull Evaluating individual steps Step S1 generated test cases for all927 sub-app APIs under test in less than one hour All sub-app APIswere successfully invoked at least once without exception on eachAndroid version In this experiment we did not measure the hostrsquoscode coverage because the host includes implementation of its ownrich functionalities that are unrelated to sub-app API Thus it is notmeaningful to compute the percentage of covered host app code

Step S2 took less than 30 seconds for each sub-app API to reportits corresponding system APIs on each Android version The num-ber of system APIs (protected by dangerous permissions) hookedby S2 is 111 129 145 on the three Android versions respectivelyTo evaluate the correctness of our thread correlation we created

9

a test app which triggered new threads leveraging the Handlermechanism Our test showed that our tool correctly correlated thetriggering and triggered threads on each Android version

Step S3 produced the API-permission mapping including 94public APIs protected by dangerous permissions at API level 27103 APIs at API level 28 and 119 at API level 29 This step took ourapproach three hours to process the descriptions of 35847 42302and 44323 public APIs on the three API versions respectively Tovalidate the correctness of the mapping we constructed a test app toinvoke all the APIs and verify the required permissions at runtimeFor all three Android versions our permission mapping of all except6 APIs are correct Specifically the mapping of 92 APIs out of 94is correct (979 precision) at the API level 27 The two false casesare unprotected APIs hasPermission and requestPermission inclass UsbManager [66] At API 28 the mapping shows a precisionof 971 with one new false case than what was found on API 27(3 cases in total) API 29 shows a precision of 95 with three newcases than API 28 (6 cases in total) Figure 6 and 7 in Appendixlist all six false cases Their descriptions are more complex and weenvision that a natural language processing (NLP) based approachcan further improve our precision (see discussion in Section 5)

To evaluate the coverage of our documentation analysis toolwe randomly selected the documentation of 153 classes 641 APIs(out of 2164 classes) and then manually reviewed and identified52 API-permission mappings as the ground truth Running on theaforementioned documentation our analysis tool shows a precisionof 100 and a recall of 100 to identify API-permission mappingfrom the documentation

We also compared the completeness of our mapping with recentmappings [35 46] They collectively reported 50 public AndroidAPIs that require dangerous permissions on API level 25 (we werenot able to get results of newer Android from the authors) as asignificant improvement our tool was able to find 91 APIs (82more) that require dangerous permissions on the same API versionDiscussion Apinat may not find all escaped sub-app APIs In par-ticular Step S3 cannot derive a complete mapping if the documen-tation is incomplete [56] or too sophisticated to process Apinatonly looks for system resource exposure by public system APIs andundocumented system APIs used by host apps may also lead to theflaw but remain undetected Also Apinat falls short in analyzingobfuscated host apps eg that uses dynamic code loading andimplementations in CC++ Hence Apinat did not scan Web AppAPIs due to the extensive CC++ implementation in browsers Inaddition incorrect documentation (which we assume is rare andindeed our tool did not report any false escaped sub-app API ) mightlead to false alarms if not properly validated

42 Finding UI Deception FlawsDesign To find out the opportunities for Sub-window Deception(Section 32) in a host app Apinat looks for the apprsquos sensitive sub-windows which can be the targets of the attack As discovered inthe wallet UI confusion (Figure 4b) the hostrsquos sub-windows thatare likely to show up in the presence of a sub-app tends to be thosethat can be triggered through sub-app APIs If such a sub-windowalso contains sensitive information our approach then reports it asa potential target for Sub-window Deception

Implementation To detect such sub-windows Apinat monitorsthe change of the host UI in response to each sub-app API callto identify the sub-window triggered by the API call and thendetermines whether it carries sensitive content Specifically ourapproach first constructs a testing sub-app with an empty UI Thenit runs the sub-app API test cases in Section 41 to call each sub-appAPI through the testing sub-app and further inspects the UI screen-shots before and after the call for changes This is done through apixel-to-pixel comparison of two screenshots To capture the screen-shots we developed a screen projection service on Android usingthe Media Projection [63] API Also our screenshot compari-son was implemented using the OpenCV cv2absdiff API [85]For each sub-window identified our approach continues to findthose associated with sensitive information For this purpose itextracts strings from sub-window screenshots using the onlineOCR service [34] From the strings Apinat further utilizes a list of121 sensitive data keywords and the keyword pair list from recentresearch [91] to recognize those carrying sensitive content Notethat like a mobile OS an app-in-app system also provides a set ofsub-app APIs for sub-apps to dynamically generate UI componentssuch as wxcreateCanvasContextdraw() in Wechat To controlfalse positives Apinat omits such sub-app APIs based on the APIcategory in the sub-app API documentation As a result Apinat suc-cessfully detected 6 Sub-window Deception flaws (Section 43) ForiOS we got the same result since sub-app APIs are across-platformthe one triggers a sub-window on one OS also does that on theother (see Section 2)Evaluation Apinat detected 5 sub-app APIs associated with the UIdeception flaw we manually confirmed that all of them trigger sub-windows with sensitive information Also all of them affect bothAndroid (version 81 9 10) and iOS (version 12 134) Performance-wise the screenshot comparison and OCR analysis together tookless than 5 seconds on a desktop with Intel i5 27 GHz CPU and 8GB memoryDiscussion Soundly detecting whether a host app is susceptibleto Sub-app Lifecycle Hijacking (Section 33) is difficult especiallybecause it entails detection of side-channel information leakagewhich can happen in many ways and is hard to capture in generalTo measure a lower bound of the pervasiveness of the problemwe checked whether the hosts in our study (Table 1) had the sameinformation leakage and lifecycle design as reported in Section 33As a result 3 host apps on Android (Wechat Alipay DingTalk) aresusceptible which were all manually confirmed to be exploitable

43 Measurement of ImpactFlaw landscape With the help of Apinat we analyzed 11 highlypopular host apps (Table 1) on Android and iOS and found theyare all vulnerable to APINA flaws (Table 3) Altogether we found 52APINA flaws including 39 System Resource Exposure 10 Sub-windowDeception and 3 hosts vulnerable to Sub-app Lifecycle Hijacking

For System Resource Exposure in total we uncover 39 escaped sub-app APIs associated with 5 categories of exposed system resources4 Android dangerous permissions and 6 iOS entitlements Table 5shows the flaw number for each category of resources (the secondcolumn) and illustrates 8 escaped sub-app APIs with correspondingAndroid permission(s) and iOS entitlement(s) ignored to enforce

10

Table 3 Eleven vulnerable host apps on Android and iOS(A Alipay B Baidu C Chrome D DingTalk F FirefoxJJinRiTouTiao O Opera Q QQ S Safari T TikTok WWechat) NA denotes the flaw does not apply to the OS

Type of APINA Flaw iOS AndroidSystem Resource Exposure A D J Q T W A D J Q T WSub-window Deception A B D W S Q A B C D F W O QSub-app Lifecycle Hijacking NA A W Q

on them All 39 escaped sub-app APIs are listed in our releaseddataset [12] Also Table 6 illustrates 6 Sub-window Deception in non-browser hosts additionally all four browsers we studied (ChromeSafari Firefox Opera) are susceptible to the same Prominent UIattackResource comparison between Android and iOS Althoughfinding the full API-entitlement mapping for iOS is hard we ob-served a few differences between Android and iOS in system re-source protectionbull iOS is less affected than Android Out of 39 escaped sub-app APIs13 are related to iOS which appears to be less affected and harderto be exploited There are two reasons behind the observation asdiscovered in our study First certain iOS APIs return less informa-tion than its Android counterparts (ie those related to Bluetoothsee Section 31) and thus is less susceptible to privacy risk (locationleakage) Hence all 27 Bluetooth related escaped sub-app APIs donot affect iOS (see Table 5) Second WiFi related escaped sub-appAPIs (see Table 5) are much harder to exploit on iOS since Applehas extra protection besides entitlement Specifically right beforethe programmaticWiFi operation an iOS appmust obtain the userrsquosexplicit consent the app must instruct the user to manually openthe WiFi setting page in the Settings app and then return to theiOS app [43] ndash an indicator of user intention for the app to operateWiFibull iOS entitlement fails to communicate risks to the user On Androidwhen the permission ACCESS_FINE_LOCATION is used for protect-ing the operation Wi-Fi scan it indicates a risk that the WiFioperation may leak location a highly private data On iOS how-ever the entitlement for Wi-Fi scan ie Hotspot Helper failsto communicate such a risk Actually to get this entitlement for aniOS app app developers must file a special written request by justi-fying that the app does not have malicious intention Apple reviewsthe request internally and possibly assesses the risks of locationleakage behind the scene However the name of this entitlementand its documentation we could find does not show that Wi-Fiscan needs location protection on iOS This may have been oneof the factors leading to escaped sub-app API wxgetWifiList (seeTable 5) which performs Wi-Fi scan without protectionAttack consequences The system resources exposed by escapedsub-app API and the risks can be identified from the API namesand the permissions they violate (see Table 5) For example unautho-rized sub-apps can use escaped sub-appAPI wxgetRecorderManag-er to record audio (violating Androidrsquos RECORD_AUDIO permission)We summarize the attack consequences in Table 4 Further Sub-window Deception leads to phishing on popular Web services (egFacebook) mobile wallets and sensitive host UIs For exampleWechat has a UI triggered by sub-app API (wxaddPhoneContact)

Table 4 Examples of APINA attack consequences

Flaw Type Consequences (what the adversary is able to do)

SystemResourceExposure

record audio operate camerainfer victimsrsquo geo-location (thus track users)

connect victimrsquos device to arbitrary Wi-Fi (thus manipulatenetwork traffic perform man-in-the-middle (MITM) or phishing)

and steal sensitive QR code etcSub-windowDeception

steal account credentials on Facebook Google Amazon etcsteal mobile wallet passwords contacts etc

Sub-appLifecycleHijacking

steal money (payments in shopping sub-app)steal personal secrets (eg answers tosecurity questions health records etc)

steal business documents (from a document processingand management sub-app published by Microsoft)

steal account credentials of Amazon ICBCCCB HSBC (1st 2nd 7th largest banks in the world)

Airbnb Weibo Starbucks McDonaldrsquos etc

for users to enter contact information (Table 6) attacking this UImay leak contacts which are highly private Last Sub-app LifecycleHijacking affects three hosts (Table 3) and the risks come fromimitating sub-apps supported by these hosts such as sub-apps forAmazon health banking Airbnb etc (see Table 4)Cases Studies We discuss a few other problems we observed inapp-in-app ecosystembull Keeping up with the OS evolution Sub-app API permission policyshould keep up as the OS always evolves newer OS version oftenintroduces more strict protection against sensitive resources Forexample since Android 10 an app that accesses location in the back-ground needs an additional dangerous permission ACCESS_BACKGRO-UND_LOCATION in addition to the regular location permission [82]This protects user location against illicit tracking However sub-app API for accessing location in hosts TikTok and Alipay did notkeep up with such a new protection thus leaving their users at risk

As another example for the WiFi and Bluetooth scan that canleak location Android 9 and 10 require ACCESS_FINE_LOCATIONpermission while Android 81 is less restrictive and ACCESS_COARSE_LOCATION is sufficient (see Table 5) Note that Android uses the firstpermission to control access to precise location (eg GPS data)and uses the second one for coarse-grained positioning (with anaccuracy approximately at the level of a city block [10]) Interest-ingly all hosts we studied only define a general location sub-apppermission to govern location API (eg scopeuserLocation inWechat) but do not differentiate the two levels of accuracybull Too many APIs for one permission APIs of apparently differentfunctionalities should never be governed by the same permissionHowever in the host TikTok (an extremely popular short-videosharing app with more than 500million downloads on Google Play)three sub-appAPIs ttscanCode ttchooseImage and ttchoos-eVideo (for scanning QR code accessing photos and videos) aregoverned by the same permission scopecamera and thus inade-quately protected For example a malicious sub-app that is grantedpermission by the user to scan QR code also behind the scenesilently gets access to API ttchooseImage that accesses user pho-tos posing a serious privacy risk

5 LESSONS AND MITIGATION STRATEGYLessons learned The most important lesson learnt from our re-search is the caution one should take when building a third-party

11

Table 5 Summary of System Resources Exposure flaws (NA means the flaw does not affect the OS)

SystemResourceExposed

of

FlawsExample of Escaped

Sub-app API Dangerous Permission Android API Entitlement iOS Class

Microphone 1 WechatwxgetRecorderManager RECORD_AUDIO mediaMediaRecorder

CaptureRequest Microphone Usage AVAudioRecorder

Camera 3 Alipay myscan CAMERA CameraManageropen-CameraCaptureRequest Camera Usage AVCaptureSession

Wi-Fi 4WeChatwxgetWifiList

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetScanResults Hotspot Helper dagger NEHotspotHelper

JinRiTouTiaoTikTokttgetConnectedWifi

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetConnectionInfo Access WiFi Information dagger CNCopyCurrent-

NetworkInfo

Bluetooth 27

Alipay mystartBluetoothDevicesDiscovery

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan NA NADingTalk

ddgetBluetoothDevicesAlipay

mygetBLEDeviceServices

iBeacon 4 Alipay mygetBeaconsACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan Location Usage CLBeaconRegion

dagger Much harder to exploit on iOS due to the requirement of explicit user approvalDagger Android 9 and 10 require ACCESS_FINE_LOCATION permission while Android 81 requires ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION

Table 6 Examples of Sub-window Deception flaws

Host App Triggering Sub-App API Legitimate (and spoofable)Functionality of the Sub-window

Alipay mytradePay Request password ofAlipay mobile wallet

Baidu swanrequestPolymerPayment Request passwords ofmultiple mobile wallets

DingTalk ddpay Request password ofAlipay mobile wallet

WechatwxaddPhoneContact Enter new contacts

wxrequestPayment Request password ofWechat mobile wallet

QQ new in-app message Display instant messagesand enter a reply

sub-ecosystem on top of the operating system In such a case thethird-party OS-like app strives to provide a secure self-containedenvironment However whether it undermines OS security andbrings in new risks to modern mobile applications need to be eval-uated to identify the security gap between the new sub-ecosystemand the OSes Our measurement study shows that popular host appsare generally susceptible to APINA flaws indicating that the app-in-app system vendors today either fail to identify or are unpreparedfor the new risks

Fundamentally APINA risks come from the limited app-levelcapabilities the host app has in managing OS resources lack ofOS-level support and missing of sub-app API standard Hencedown the road it will require non-trivial joint efforts to fundamen-tally eliminate APINA risks More specifically escaped sub-app APIshows that a third-party host fundamentally lacks the full OS-levelknowledge on system resource protection While such knowledgecan come from different sources eg program analysis on relevantOS modules [35 46] developer documentations technical reportsetc each source only contributes a partial view Hence joint effortsneed to be made in the future to synthesize such knowledge Ourstudy also brings to light that such efforts are by no means trivialndash even the two leading mobile OSes have apparently confusingconflicting security policies Synthesizing such a knowledge base

will not only benefit the app-in-app paradigm but also make theOSrsquo security mechanism more transparent for thorough auditing

Our findings also highlight that prior OS lessons cannot fullyeliminate new risks incurred by the new paradigm which necessi-tates thorough assessment regarding its new attack surfaces Forexample a malicious sub-app a sub-window and a task in Recentsscreen all come as new attack vectors that pose credible new threatsto usersrsquo most sensitive credentials and privacyMitigation strategy Following we propose the short-term miti-gation and discuss the long-term strategybull Escaped Sub-app API Eliminating the risk requires the host tohave full OS-level knowledge about resource control (eg API-permission mapping) which is difficult In the meantime our toolApinat together with our API-permission mapping (released on-line [12]) can help host app vendors identify escaped sub-app APIsNote that since Apinat can identify escaped sub-app API with itsignored permissions with respect to specific OS version (see Sec-tion 43) host vendors may leverage our tool to assess whether theirsub-app API permission policy is always compliant with newly re-leased OS version and thus keep up the pace

Further we envision two possible future directions that couldlead to more viable solutions First as demonstrated by our anal-ysis tool Apinat although it is hard for todayrsquos program analy-sis techniques to derive a complete system API-permission map-ping [35 46] we could significantly improve its accuracy and com-prehensiveness through developer documentation analysis Ourcurrent documentation analysis is rather preliminary but still effec-tive as demonstrated in our study (Section 4) Down the road wecould develop natural language processing (NLP) based techniquesfor deriving more complete knowledge about API permission poli-cies With the techniques an analysis could cover a wider spectrumof literature including iOS documents research papers technicalreports etc which will help derive up-to-date knowledge aboutresource-management policies

Second the app-in-app community should work together tostandardize sub-app APIs and their permission policies as donein the HTML5 community on HTML5 APIs For the time being

12

different app-in-app vendors bring in their own APIs for accessinga wide spectrum of systems resources (see our comparison betweensub-app API and HTML5 API in Table 7 in Appendix) often withoutproper safeguard in place not to mention any effort to standardizethe protectionbull Sub-window deception The risk comes from the UI confusionwhether a window portion in the sub-app window belongs to thesub-app or the host (Figure 3b) To mitigate the risk we envision ahigher degree of UI isolation between the sub-app and the host thesub-apprsquos window should always be separated from that of the hostand the host should never reclaim any window portion from thesub-applsquos window Regarding the Wallet UI confusion (Section 32)for example Wechat should display its wallet UI only in its ownwindow and advertise to users that any UI component inside thesub-app window belongs to the sub-app

A question arises whether a malicious sub-app can fake a crashand then show spoofing content in the sub-app window to resem-ble the host This can be mitigated through additional protectionsupported by the host Specifically the host app could keep mon-itoring the UI of its sub-apps (eg through PixelCopy API onAndroid [71]) to detect whether a UI object in the sub-app is similarto a sub-window or a security-sensitive UI object associated withhost app For performance concern the host app could utilize thestate-of-the-art object detection model (eg Fast Region-based Con-volutional Network based model [61] and YOLO [32 95]) for thereal-time security-sensitive UI object recognition as reported inprior research [95] Fast YOLO yields the performance of 155 framesper second Note that the effectiveness efficiency and deploymentfeasibility of such an approach need to be carefully explored andevaluated which we leave for our future researchbull Sub-app lifecycle hijacking To mitigate this risk a short-termdefense is to place all sub-app resources in the phonersquos internalstorage so our current exploit (leveraging monitoring the phonersquosexternal storage) to track sub-app lifecyle termination (Section 33)can be mitigated However it is always a concern that sub-appsmay deplete the limited space on a phonersquos internal storage Along term solution needs to consider how to make the sub-apptasks dynamically scalable to ensure that the sub-app recycling isno longer traceable and thus the attack surface is fundamentallyeliminated This nonetheless calls for support from modern OSesfor the emerging app-in-app paradigm

6 RELATEDWORKAs mentioned in Section 2 recent years witnessed several tech-niques to support the functionality of app encapsulation (eg Plu-gin frameworks app sandboxing browser extension and PhoneGapapp see Table 2) Accordingly numerous studies have looked intothe flaws in these app encapsulation systems considering the se-curity analysis of Plugin frameworks a set of flaws were revealed[99 111 112] including no permission management and no isola-tion of the virtualized apps Compared with Plugin frameworks theapp-in-app paradigm has a much stronger security model and ourstudy investigates the design challenges and pitfalls in the securitymechanism Meanwhile the security and privacy implications ofbrowser extensions have been extensively studied [48 54 84 98]

Furthermore the current security studies on PhoneGap apps fo-cus on the flaws of PhoneGap frameworkrsquos access control policy[60 90 100 101] For example Song et al [101] revealed that thebridges added by the framework to the browser are not correctlyprotected by the same origin policy Jin et al [86] introduced mul-tiple channels (eg barcode SMS file system Contact) for codeinjection attacks in PhoneGap apps Different from these works wefocus on the unique features of the app-in-app paradigm (Table 2)and reveal multiple new attack surfaces which have never beenstudied before

The closer to our study are the works of Web App and WebViewvulnerability assessment Up to our knowledge only one paper[87] analyzed security issue of Web App in which the securityand privacy risks on HTML5 features in PWA were investigatedIn our attack on Web App we did not focus on HTML5 featuresbut a general UI isolation and management model in app-in-appparadigm Also although WebView technique is used in some ofthe app-in-app systems in sharp contrast to the works on Webviewweaknesses [36 60 88 102 105 109 110] our study explores thesecurity implications and challenges for a third-party app tomanageoperating system resources Another set of works related to ourstudy is the exploitation of mobile UI deception Prior phishingattacks [38 49 53 57 97] mislead victims about the foregroundapp aiming at information theft in spoofing apps Correspondingcountermeasures [49 58 96] emphasize identifying the app of thewhole foreground window and thus cannot thwart Sub-windowDeception due to the inability to identify sub-windows Furtheranother angle of UI deception is clickjacking [59 94] which aredifferent from our mobile-phishing attacks7 CONCLUSIONIn this paper we present the first systematic security analysis on re-source management in high-profile app-in-app systems Our studyshows that such systems are susceptible to a set of serious securityflaws Our measurement study further sheds light on their perva-siveness in the real-world Further our study brings in new insightsinto the fundamental security limitations of this new paradigm andfurther contributes to a better understanding of its mitigation strat-egy an important step towards building a more secure app-in-appecosystem

8 ACKNOWLEDGMENTWe would like to thank our shepherd Yanick Fratantonio and theanonymous reviewers for their insightful comments This work issupported in part by the NSF CNS-1618493 1801432 1838083

REFERENCES[1] 2011 HTML5 Fullscreen API Attack httpsferossorghtml5-fullscreen-api-

attack[2] 2011 The Inception Bar httpsjameshfishercom20190427the-inception-

bar-a-new-phishing-method[3] 2018 Java Runnable httpsdocsoraclecomjavase7docsapijavalang

Runnablehtml[4] 2018 A one year PWA retrospective httpsmediumcompinterest-

engineeringa-one-year-pwa-retrospective-f4a2f4129e05[5] 2018 Wechat 1 million sub-apps httpswwwscmpcomtecharticle2153705

tencents-wechat-now-host-1-million-mini-programs[6] 2018 WeChat reaches 1M sub-apps half the size of Applersquos App Store https

techcrunchcom20181107wechat-mini-apps-200-million-users[7] 2018 Xposed httpsapixposedinforeferencepackageshtml[8] 2019 AdBlock httpsgetadblockcom

13

(a) Real Prominent UI (b) Fake Prominent UI

Figure 3 Safarirsquos Prominent UI confusion on iOS

of a user [37] This attack sub-app successfully passed the vettingof Wechat sub-app store and ran on both iOS and Android versionsof Wechat Note that our attack sub-app has less than 200 lines ofcode which indicates that it is cost-effective for the adversary todevelop APINA flaws malware in the wild Besides we successfullybuilt attack sub-apps in other host apps eg Alipay DingTalk etcand reported the problems to all affected host-app vendors Theyall acknowledged the problem in particular Wechat and Alipayawarded us through bug bounty programs for this flaw

32 Sub-window DeceptionAnother unique app-in-app feature is the functionality-level inter-actions between the host and sub-app For this need the host doesnot fully isolate itself from sub-apps which unwittingly introducesnew attack surfaces and high spoofing risks against host-app UIBrowsersrsquo Prominent UI confusion To bring a native app-likeexperience Safari on iOS and Chrome on Android open each sub-app (ie Web App Progressive Web App or PWA) in an entirededicated window separate from the browser window just like anative app [44 78] ndash without any browser UI such as the addressbar Web App is programmed with JavaScript and HTML but mustmeet certain standards [68] With user confirmation the browsercan install a Web App to the phonersquos home screen (through anAPK [69] package created by Chrome or a Web Clip [44] createdby Safari) Such Web App takes the full screen if ldquostandalone orldquofullscreen is specified in its manifest file EachWeb App is clearlyassociated with specific Web domain when installed When the usernavigates to out-of-scope URL (ie of different origin) in a WebApp the browser displays a Prominent UI ndash a banner at the top ofthe screen (Figure 3a) showing the origin and secure connectionstatus ndash due to the lack of address bar According to Web Appdocumentation [67] users rely on such Prominent UI to be awarewhen they navigate out of scope an important security notice

Based on a study [57] mobile phishing attacks tend to happenwhen users become accustomed to familiar repeated contexts Morespecifically if users frequently encounter legitimate context theywill become conditioned to reflexively respond to it Here the cur-rent design of Web App conditions users to see the Prominent UI inout-of-scope navigation which we found poses a spoofable context

(a) Authentic wallet UI (b) Bogus wallet UI

Figure 4 Mobile wallet UI confusion

Specifically Web App is designed to embrace out-of-scope brows-ing [104] and let users freely navigate to other Web domains forservices such as login through FacebookGoogle (aka SSO [107])payment through PayPal etc The problem is that when a victimuser navigates out of scope eg to Facebook login page a mali-cious Web App can actually navigate to an in-scope phishing pageimitating Facebook showing a bogus Prominent UI (as if shown bythe browser) to misleadingly inform the victim that she is on a realFacebook domain (Figure 3b) In this way the malicious Web Appcan collect victim usersrsquo secrets such as Facebook passwords

We call this problem Sub-window Deception ndash sub-window meanspart of a window Prior phishing attacks in browsers exploredhow a webpage can go full screen and spoof the address bar [12] as another instance of mobile browser UI attacks our attackcomplements the prior understanding by exploiting ProminentUI ndash the counterpart of address bar in the context of native app-like Web App Note that address bar differs from Prominent UIin design based on the Web specification [106] browsers ldquoshouldprovide a means of exiting fullscreen that always works and advertisethis to the user [106] so users can see the real address bar whenthey want (although browsers may not implement this protectionproperly [89]) Web App users however lack practical mechanismsto verify the authenticity of Prominent UI today This attack appliesto general Web App on both iOS and Android we reported it toW3C4 Apple Google Firefox and Opera which all acknowledgedthe importance of the problemMobile Wallet UI confusion Wechat and Alipay both featuremobile wallets which can be leveraged by e-commerce sub-appsto provide users a convenient payment process Amazon sub-appfor example after a user clicks its ldquocheckout with Wechat wal-letrdquo button will invoke a sub-app API (eg wxrequestPaymentin Wechat) to trigger the hostrsquos wallet the host then reclaims acentral portion of the screen from the sub-app to show its walletUI (highlighed in Figure 4a) for the user to enter her wallet pass-word and finish the payment Such a context can condition usersto reflexively provide wallet passwords at checkout and thereforepresents a practical spoofing target Specifically when a victim userclicks the ldquocheck out button in a malicious e-commerce sub-app itcan show a bogus wallet UI (Figure 4b) to collect the userrsquos walletpassword instead of invoking the real wallet

4We do not provide the link to our report for anonymization purpose

6

(a) Real sub-app task (b) Bogus sub-app task

Figure 5 Dedicated task for every sub-app in Recents screen

Up to our knowledge state-of-the-art mobile anti-phishing tech-niques cannot identify our attacks for example [49 58 96] mainlyrely on identifying the app of the whole foreground window so theuser would not expose secrets to the unintended app this cannotidentify a sub-window at the sub-app level ndash whether it belongs toa sub-app or the host app

Our study shows that a bogus sub-window presents a practicalattack vector in app-in-app since a window portion (sub-window)can be used by both the sub- or host- app in accustomed contextswithout differentiation through clear identification From a broadersense we believe the spoofing risk is also high if the OS showsits pop-up atop an app (so malicious app can show a bogus onewhen the OS does not) however in sharp contrast such pop-upis not sub-window (but whole window) and known anti-phishingtechniques (eg [49]) to identify (the owner of) the whole windowcan defeat itAttacks and vendor acknowledgementsWe implemented PoCattacks in Safari on iOS Chrome on Android and Wechat on bothOSes in Safari and Chrome our malicious Web App impersonatesProminent UI to spoof Facebook login page in Wechat our mali-cious sub-app mimics the wallet UI to steal wallet password (seevideo demo online [12]) Our malicious sub-app passed the vettingof Wechatrsquos sub-app store Note that Web App does not have appstores and can be installed after visiting its URL In addition wereported the problems to all affected host vendors who all acknowl-edged that the threats were practical and severe Wechat and Alipayawarded us through their bug bounty programs

33 Sub-app Lifecycle HijackingAs app vendors follow the app-in-app trend by releasing sub-appsit is unclear whether their users remain equally protected as beforeUnfortunately our study shows that even highly credible host appscannot fully eliminate new attack surfaces incurred by app-in-appRecents screen takeover The Recents screen (aka recent task listor recent apps) [64] is a system-owned UI of Android to list recentlyaccessed task (Figure 5a) In particular each launched native appwill have a task in Recents screen similarly a host app creates aseparate task for every launched sub-app which appears in Recentsscreen Limited by the OS each host app can only create a fixednumber of tasks in Recents screen pre-specified as activities inits manifest file In our research we found that host apps all specify

a small magic number (eg 8 in Chrome 5 in Wechat 4 in Alipay3 in JinRiTouTiao) for the task limit

When an additional sub-app will be opened after the task limitis reached the host app silently executes a mandatory recyclingprocess closing the first opened sub-app to recycle its task forlaunching the new one The recycling process is transparent tousers for the possible purpose of not interrupting the user experi-ence Such a mandatory sub-app recycling mechanism introducesa new risk once the recycling is traceable by a malicious appie the adversary knows which sub-app has been recycled and atwhat time it can stealthily insert a phishing task into the Recentsscreen to imitate the silently recycled sub-app For this purposethe adversary needs to acquire the information about a hostrsquos taskrecycling which turns out to be feasible due to the presence ofvarious information-leak avenues that can be hard to eliminate Inour study we found a side channel that enables recycling track-ing in multiple host apps In particular possibly due to the richfunctionalities of sub-apps which require resource files (eg userdata logs icon and image texture) the host app creates a folderin Android external storage [18] to cache sub-app resources Suchexternal storage can be monitored by an Android native app totrack which sub-app is launched and at what time (by monitoringsub-app icon which will be downloaded at launch see PoC attackbelow) Thereby once the number of launched sub-apps reachesthe hostrsquos task limit the sub-app to recycle can be inferred Hencea malicious native app can insert a bogus task in Recents screento mimic the recycled sub-app at this point the bogus task is theonly one in Recents screen that represents the target sub-app thatrsquosspoofed (Figure 5b)

This attack is a kind of mobile task hijacking attacks [52 97]Regarding its root cause the mandatory sub-app recycling opens anew attack surface for app-in-app systems since it makes it possiblefor malicious apps to track a sub-apprsquos lifecycle termination Notethat the attack surface becomes exploitable in the presence of sidechannels eg external storage which itself is a relatively trivialbug Other side channels could also be used for the attack once theyarise (see discussion below) Eliminating this attack surface maynot be trivial in practice since the maximum task number of a hostin Recents screen is not dynamically scalable (statically specifiedin manifest) limited by the OS Although the very recent Androidsupports dynamic task no host app we studied (Table 3) adoptedit possibly for the purpose of supporting older Android versionsgiven the notorious Android version fragmentation [74]Attacks and vendor acknowledgementsWe implemented PoCattacks on Alipay andWechat which cache sub-app resources in theexternal storage and enable recycling tracking Specifically Alipaystores the caches at sdcardalipaymultimedia When a sub-app such as Amazon is launched its icon will be downloaded toit if not already there Our malicious Android app with a commonpermission WRITE_EXTERNAL_STORAGE can remove cached iconsperiodically andmonitor when they reappear to knowwhat specificsub-app is launched and at what time In our attack of Alipay oncethe malicious app infers that five sub-apps have been launched(submit-app task limit of Alipay is 4) it will insert a bogus task inRecents screen to mimic the first sub-app which is recycled Oncethe victim user enters the spoofing task through Recents screenit can lure the user to leak secrets such as passwords Note that

7

our malware successfully passed the vetting of popular app storesincluding Google Play We reported the problem (demo online [12])to Wechat and Alipay which both acknowledged the problem andawarded us through bug bountiesDiscussion on other side channels As mentioned earlier otherside channels once found can also be used for impersonating therecycled sub-app Prior research [113] shows that the operationsof Android apps can be easily tracked through the Android pro-cess file system (procfs) Although Android has been continuouslybeefing up its privacy protection until Android 9 still some globalstatistics under procfs are exposed Particularly we found that theTCP connection status under procnettcp can be accessed byany app without permission on Android 9 and below From the filewe can see the IP addresses of all TCP connections on an Androidphone which are labeled by randomly assigned User IDs Interest-ingly we found that an invoked sub-app makes a sequence of TCPconnections and the endpoints of the connections (domains) canuniquely fingerprint its initiation eg Amazon sub-app connects to4 unique endpoints with 8 consecutive HTTPS requests in the firstfew seconds after it is launched In our research we sampled 8 high-profile sub-apps in Wechat and identified the sequences of theircommunication endpoints as observed when they are triggered (seeTable 8 in Appendix) Through this side channel a malicious nativeapp is able to infer the launch of a specific sub-app so it can waituntil it is terminated for task recycling (eg after 5 other sub-appsare found to be started through the procfs when the magic numberis 5) to create a task to impersonate the sub-app Note that the mali-cious app can resolve the endpoint domains from IP addresses usingAndroid API InetaddressgetCanonicalHostName [81] withoutrequiring any permission which was implemented and confirmedin our study

Until April 2020 84 of the Android devices are still runningAndroid 9 or earlier versions [33] and therefore are vulnerable toour attack On Android 10 which was released in September 2019the procfs used in our attack has been closed by SEAndroid [70 83]and thus the attack is ineffective Seeking a more powerful attackavenue is left to the future research

4 APINA FLAWS IN THEWILDIn this section we report a measurement study that reveals thescope and magnitude of APINA flaws in the wild The study ismade possible by an automatic analysis tool we built called Apinat(short for App-in-app Threat Scanner) which helped us identifyapp-in-app hosts that are susceptible to APINA flaws

41 Identifying System Resource ExposureDesign Apinat aims to find System Resource Exposure flaws byidentifying escaped sub-app API The idea is to find sub-app APIthat is unprotected by sub-app permission while its correspondingsystem API is permission-protected A naive idea is to call eachsub-app API and find out whether the OS checks the permissions ofthe host app eg by looking at permission pop-ups or system logsThis does not work because the permission asked by the OS can berelated to the host apprsquos own rich functionalities not the sub-appAPI To systematically find escaped sub-app API our methodologytracks the system API invocations triggered by a sub-app API via

a dynamic analysis (Step S1 S2) and then utilizes system API-permission maps to derive required permissions of the sub-appAPI (Step S3) which will be compared to the corresponding sub-app permission If a sub-app API is not protected by any sub-apppermission while its corresponding system APIs are guarded by theAndroid dangerous permissions5 or iOS entitlements an escapedsub-app API is found (Step S4) Following we describe how thisdesign works and how it was implemented in our research onAndroid Since sub-app APIs are cross-platform we were able toextend all the findings made by our technique from Android to iOSby simply validating these findings on the Apple platformStep S1 generating test cases To conduct a dynamic analysis wefirst need to generate test cases with valid arguments to invoke eachsub-app API without triggering exceptions For each API we targetthat at least one invocation is successful The argument types ofJavaScript APIs are either primitive or Object [21] To produce testcases for primitive arguments we leveraged Mozillarsquos funfuzz [22]a JavaScript toolkit ForObject arguments we recursively generatedtest cases leveraging funfuzz because an Object includes keyvaluepairs its key is primitive and the value is either primitive or ObjectAll test cases were then used by a sub-app we built to invoke sub-app APIs If all test cases for an API failed we manually inspectedthe API to address the issues such as formatted inputs (eg UUID)stateful calls (an API needs to be invoked before another) etcStep S2 tracking system API As mentioned in Section 21 theexecution of a sub-app API enters the native layer of the hostthrough a dispatcherdispatch function and then its controlflow reaches system APIs (Figure 1) Therefore Step S2 first iden-tifies the dispatcherdispatch function in the host apprsquos nativelayer then tracks its call graph to find the system APIs triggeredby the sub-app API call as elaborated below

(1) Find the dispatcherdispatch function in the native layer Asmentioned earlier Webview and React Native are bridge techniquesto expose dispatcherdispatch to JavaScript layer Note thatthough the object alias (dispatcher) and function name (dispatch)vary across host apps they can be obtained by inspecting functioninvocations in Encapsulation lib (Figure 1) which is a preprocess-ing step in our study Note that the Encapsulation lib usually canbe found in JavaScript files packaged in the host app (eg underassets folder) So all we need is to identify the dispatcher objectin the native layer based on the obtained alias

To this end S2 implements an Xposed [7] (a framework to in-strument Android app execution) module to hook Webview APIaddJavascriptInterface(obj alias) (that exposes Java objectto JavaScript through an alias) and inspect its arguments at run-time if the ldquoalias argumentrsquos value matches the dispatcher aliasdiscovered the ldquoobj is the dispatcher object that we are lookingfor The analysis of React Native bridge is slightly different wehook its API createNativeModules to get its Java objects exposedto JavaScript our Xposed module then calls each exposed objectrsquosgetNamemethod to get its alias ndash if this alias matches the dispatcheralias discovered the object is what we are looking for

5Host apps are typically third-party apps that cannot call privileged system APIs pro-tected by ldquosignature or ldquosignatureOrSystem level permissions [65] or they typicallydo not delegate the access to such APIs through sub-app APIs

8

(2) Track execution of the dispatcherdispatch function Our toolthen tracks the call graph of the dispatch function to find the calledsystem APIs ndash which are called to fulfill the sub-app API call Specif-ically our Xposed module hooks dispatch function and AndroidAPI and inspects their respective call stack traces However wefound that dispatchrsquos thread sometimes does not call Android APIsdirectly it triggers additional thread to call Android APIs likelyfor not to block the dispatch thread This introduces a challengeXposed outputs the above two stack traces by threads ndash one stacktrace with Android API call and the other with dispatch functioncall ndash but cannot correlate two threads if one triggers the otherTherefore we still cannot confirm that the Android APIs are in-voked due to dispatch Hence we developed techniques to deal withthe multi-threading challenge

In our study we found that Handler a typical multi-threadingmechanism of Android is commonly used by dispatchrsquos thread totrigger a new thread Thus we implemented our own thread corre-lation technique based on the Handler mechanism in our Xposedmodule More specifically in the Handlermechanism a triggeringthread that holds a handler instance will submit a runnable to amessage queue via calling the handlerpost(runnable) methodHere the runnable is an instance of Java Runnable [3] with codein its run() method Then the runnable is taken out of the queueby another thread which we name as the handler thread andgets executed in the handler thread Hence as checked in ourXposed module if the executed runnable in a handler thread isthe same instance with one submitted by a triggering thread thenwe correlate the two threads Through such techniques we foundAndroid APIs are indeed called in such handler thread followingthe dispatch threadrsquos triggering ndash this confirms the Android APIcall caused by the dispatcherdispatch functionStep S3 synthesizingAPI-permissionmapping As mentionedin Section 31 system API-permission mappings are incompletewhich can lead to escaped sub-app APIs How to derive a completemapping remains an open question in system security researchand program analysis Here our idea is to supplement recent map-pings [35 46] leveraging documentation analysis we automaticallyextract explicitly declared permissions for system APIs in the devel-oper manuals assuming that explicit specification at least reflectsintended protection of the OS with rare faults Note that certainportion of the documentation (Figure 2) can be misleading to hu-man readers due to incomplete presentation but we observed thatan exhaustive machine-based search on the whole corpus of mobileOSes (eg the entire documentation for all 2497 SDK classes of An-droid API level 27) can help us derive a significantly more completemapping than state-of-the-art mappings [35 46] (see evaluationbelow) For instance after a full scan of Android WifiManager man-ual [75] we were able to flag ACCESS_FINE_LOCATION as a requiredpermission for multiple Wi-Fi scan related APIs (see Figure 8 inAppendix) which has never been included in state-of-the-art map-pings [35 46]

In our implementation we developed a Web crawler to fetchall manuals from Android developer portal [62] and extractedthe description for each public API From the description we ex-tracted the declared permissions based on a few key observations

if the description of an API does not contain a ldquopermission key-word it is very likely that the API does not explicitly requirepermissions otherwise its description usually includes a ldquoper-mission keyword and the exact permission string constants de-fined in Android class androidManifestpermission [77] suchas ACCESS_FINE_LOCATION Based on such observation we per-formed a light-weight string matching to find explicit permissionrequirement of Android APIs (we discuss the sophisticated NLP-based direction in Section 5)

Step S3 also derives a sub-app API-permission map given itsrelatively small size (ie 50 to 172 sub-app APIs in each host com-pared to 35847 public Android APIs found by our Web crawler)we extracted the map by searching ldquopermission related keywordsin sub-app developer manual and manually confirmed the resultStep S4 reporting flaws S4 reports an escaped sub-app API if itis not protected by sub-app permission while its correspondingAndroid API(s) is protected by dangerous permission(s) That is aSystem Resource Exposure flaw is found

For iOS however a comprehensive detection is much more dif-ficult than Android especially because obtaining a system API-entitlement mapping is much more challenging First we are notaware of any work that has produced a mapping on iOS for us tostart with Second we observed that iOS documentation is not asprecise as Android in this regard which describes required enti-tlements for iOS classes but not for individual system API To stillhelp us understand the impact of escaped sub-app API on iOS weextended our findings of escaped sub-app API from Android to iOSif its corresponding iOS API requires an entitlement it is consideredto affect iOS as well This was done by manually searching corre-sponding iOS API for a given escaped sub-app API and checkingwhether any entitlement is asked when the iOS API is invoked inan iOS app we builtEvaluation We evaluated the effectiveness and performance of ouranalysis tool (source code released [12]) on a Google Pixel 2 phoneand iPhone 8 against 11 host apps The evaluation was performedon three Android versions (81 9 10 corresponding to API level 2728 29) and two iOS versions (12 134)bullOverall detection resultsApinat found 39 System Resource Exposureflaws all of them affect Android 81 9 and 10 13 of them affectiOS 12 and 134 We manually validated that all discovered flawsare true in two steps (1) confirming that the sub-app API requiresno sub-app permission through a testing sub-app (2) confirmingthat the corresponding system API(s) has permission protectionthrough a testing native app on Android and iOSbull Evaluating individual steps Step S1 generated test cases for all927 sub-app APIs under test in less than one hour All sub-app APIswere successfully invoked at least once without exception on eachAndroid version In this experiment we did not measure the hostrsquoscode coverage because the host includes implementation of its ownrich functionalities that are unrelated to sub-app API Thus it is notmeaningful to compute the percentage of covered host app code

Step S2 took less than 30 seconds for each sub-app API to reportits corresponding system APIs on each Android version The num-ber of system APIs (protected by dangerous permissions) hookedby S2 is 111 129 145 on the three Android versions respectivelyTo evaluate the correctness of our thread correlation we created

9

a test app which triggered new threads leveraging the Handlermechanism Our test showed that our tool correctly correlated thetriggering and triggered threads on each Android version

Step S3 produced the API-permission mapping including 94public APIs protected by dangerous permissions at API level 27103 APIs at API level 28 and 119 at API level 29 This step took ourapproach three hours to process the descriptions of 35847 42302and 44323 public APIs on the three API versions respectively Tovalidate the correctness of the mapping we constructed a test app toinvoke all the APIs and verify the required permissions at runtimeFor all three Android versions our permission mapping of all except6 APIs are correct Specifically the mapping of 92 APIs out of 94is correct (979 precision) at the API level 27 The two false casesare unprotected APIs hasPermission and requestPermission inclass UsbManager [66] At API 28 the mapping shows a precisionof 971 with one new false case than what was found on API 27(3 cases in total) API 29 shows a precision of 95 with three newcases than API 28 (6 cases in total) Figure 6 and 7 in Appendixlist all six false cases Their descriptions are more complex and weenvision that a natural language processing (NLP) based approachcan further improve our precision (see discussion in Section 5)

To evaluate the coverage of our documentation analysis toolwe randomly selected the documentation of 153 classes 641 APIs(out of 2164 classes) and then manually reviewed and identified52 API-permission mappings as the ground truth Running on theaforementioned documentation our analysis tool shows a precisionof 100 and a recall of 100 to identify API-permission mappingfrom the documentation

We also compared the completeness of our mapping with recentmappings [35 46] They collectively reported 50 public AndroidAPIs that require dangerous permissions on API level 25 (we werenot able to get results of newer Android from the authors) as asignificant improvement our tool was able to find 91 APIs (82more) that require dangerous permissions on the same API versionDiscussion Apinat may not find all escaped sub-app APIs In par-ticular Step S3 cannot derive a complete mapping if the documen-tation is incomplete [56] or too sophisticated to process Apinatonly looks for system resource exposure by public system APIs andundocumented system APIs used by host apps may also lead to theflaw but remain undetected Also Apinat falls short in analyzingobfuscated host apps eg that uses dynamic code loading andimplementations in CC++ Hence Apinat did not scan Web AppAPIs due to the extensive CC++ implementation in browsers Inaddition incorrect documentation (which we assume is rare andindeed our tool did not report any false escaped sub-app API ) mightlead to false alarms if not properly validated

42 Finding UI Deception FlawsDesign To find out the opportunities for Sub-window Deception(Section 32) in a host app Apinat looks for the apprsquos sensitive sub-windows which can be the targets of the attack As discovered inthe wallet UI confusion (Figure 4b) the hostrsquos sub-windows thatare likely to show up in the presence of a sub-app tends to be thosethat can be triggered through sub-app APIs If such a sub-windowalso contains sensitive information our approach then reports it asa potential target for Sub-window Deception

Implementation To detect such sub-windows Apinat monitorsthe change of the host UI in response to each sub-app API callto identify the sub-window triggered by the API call and thendetermines whether it carries sensitive content Specifically ourapproach first constructs a testing sub-app with an empty UI Thenit runs the sub-app API test cases in Section 41 to call each sub-appAPI through the testing sub-app and further inspects the UI screen-shots before and after the call for changes This is done through apixel-to-pixel comparison of two screenshots To capture the screen-shots we developed a screen projection service on Android usingthe Media Projection [63] API Also our screenshot compari-son was implemented using the OpenCV cv2absdiff API [85]For each sub-window identified our approach continues to findthose associated with sensitive information For this purpose itextracts strings from sub-window screenshots using the onlineOCR service [34] From the strings Apinat further utilizes a list of121 sensitive data keywords and the keyword pair list from recentresearch [91] to recognize those carrying sensitive content Notethat like a mobile OS an app-in-app system also provides a set ofsub-app APIs for sub-apps to dynamically generate UI componentssuch as wxcreateCanvasContextdraw() in Wechat To controlfalse positives Apinat omits such sub-app APIs based on the APIcategory in the sub-app API documentation As a result Apinat suc-cessfully detected 6 Sub-window Deception flaws (Section 43) ForiOS we got the same result since sub-app APIs are across-platformthe one triggers a sub-window on one OS also does that on theother (see Section 2)Evaluation Apinat detected 5 sub-app APIs associated with the UIdeception flaw we manually confirmed that all of them trigger sub-windows with sensitive information Also all of them affect bothAndroid (version 81 9 10) and iOS (version 12 134) Performance-wise the screenshot comparison and OCR analysis together tookless than 5 seconds on a desktop with Intel i5 27 GHz CPU and 8GB memoryDiscussion Soundly detecting whether a host app is susceptibleto Sub-app Lifecycle Hijacking (Section 33) is difficult especiallybecause it entails detection of side-channel information leakagewhich can happen in many ways and is hard to capture in generalTo measure a lower bound of the pervasiveness of the problemwe checked whether the hosts in our study (Table 1) had the sameinformation leakage and lifecycle design as reported in Section 33As a result 3 host apps on Android (Wechat Alipay DingTalk) aresusceptible which were all manually confirmed to be exploitable

43 Measurement of ImpactFlaw landscape With the help of Apinat we analyzed 11 highlypopular host apps (Table 1) on Android and iOS and found theyare all vulnerable to APINA flaws (Table 3) Altogether we found 52APINA flaws including 39 System Resource Exposure 10 Sub-windowDeception and 3 hosts vulnerable to Sub-app Lifecycle Hijacking

For System Resource Exposure in total we uncover 39 escaped sub-app APIs associated with 5 categories of exposed system resources4 Android dangerous permissions and 6 iOS entitlements Table 5shows the flaw number for each category of resources (the secondcolumn) and illustrates 8 escaped sub-app APIs with correspondingAndroid permission(s) and iOS entitlement(s) ignored to enforce

10

Table 3 Eleven vulnerable host apps on Android and iOS(A Alipay B Baidu C Chrome D DingTalk F FirefoxJJinRiTouTiao O Opera Q QQ S Safari T TikTok WWechat) NA denotes the flaw does not apply to the OS

Type of APINA Flaw iOS AndroidSystem Resource Exposure A D J Q T W A D J Q T WSub-window Deception A B D W S Q A B C D F W O QSub-app Lifecycle Hijacking NA A W Q

on them All 39 escaped sub-app APIs are listed in our releaseddataset [12] Also Table 6 illustrates 6 Sub-window Deception in non-browser hosts additionally all four browsers we studied (ChromeSafari Firefox Opera) are susceptible to the same Prominent UIattackResource comparison between Android and iOS Althoughfinding the full API-entitlement mapping for iOS is hard we ob-served a few differences between Android and iOS in system re-source protectionbull iOS is less affected than Android Out of 39 escaped sub-app APIs13 are related to iOS which appears to be less affected and harderto be exploited There are two reasons behind the observation asdiscovered in our study First certain iOS APIs return less informa-tion than its Android counterparts (ie those related to Bluetoothsee Section 31) and thus is less susceptible to privacy risk (locationleakage) Hence all 27 Bluetooth related escaped sub-app APIs donot affect iOS (see Table 5) Second WiFi related escaped sub-appAPIs (see Table 5) are much harder to exploit on iOS since Applehas extra protection besides entitlement Specifically right beforethe programmaticWiFi operation an iOS appmust obtain the userrsquosexplicit consent the app must instruct the user to manually openthe WiFi setting page in the Settings app and then return to theiOS app [43] ndash an indicator of user intention for the app to operateWiFibull iOS entitlement fails to communicate risks to the user On Androidwhen the permission ACCESS_FINE_LOCATION is used for protect-ing the operation Wi-Fi scan it indicates a risk that the WiFioperation may leak location a highly private data On iOS how-ever the entitlement for Wi-Fi scan ie Hotspot Helper failsto communicate such a risk Actually to get this entitlement for aniOS app app developers must file a special written request by justi-fying that the app does not have malicious intention Apple reviewsthe request internally and possibly assesses the risks of locationleakage behind the scene However the name of this entitlementand its documentation we could find does not show that Wi-Fiscan needs location protection on iOS This may have been oneof the factors leading to escaped sub-app API wxgetWifiList (seeTable 5) which performs Wi-Fi scan without protectionAttack consequences The system resources exposed by escapedsub-app API and the risks can be identified from the API namesand the permissions they violate (see Table 5) For example unautho-rized sub-apps can use escaped sub-appAPI wxgetRecorderManag-er to record audio (violating Androidrsquos RECORD_AUDIO permission)We summarize the attack consequences in Table 4 Further Sub-window Deception leads to phishing on popular Web services (egFacebook) mobile wallets and sensitive host UIs For exampleWechat has a UI triggered by sub-app API (wxaddPhoneContact)

Table 4 Examples of APINA attack consequences

Flaw Type Consequences (what the adversary is able to do)

SystemResourceExposure

record audio operate camerainfer victimsrsquo geo-location (thus track users)

connect victimrsquos device to arbitrary Wi-Fi (thus manipulatenetwork traffic perform man-in-the-middle (MITM) or phishing)

and steal sensitive QR code etcSub-windowDeception

steal account credentials on Facebook Google Amazon etcsteal mobile wallet passwords contacts etc

Sub-appLifecycleHijacking

steal money (payments in shopping sub-app)steal personal secrets (eg answers tosecurity questions health records etc)

steal business documents (from a document processingand management sub-app published by Microsoft)

steal account credentials of Amazon ICBCCCB HSBC (1st 2nd 7th largest banks in the world)

Airbnb Weibo Starbucks McDonaldrsquos etc

for users to enter contact information (Table 6) attacking this UImay leak contacts which are highly private Last Sub-app LifecycleHijacking affects three hosts (Table 3) and the risks come fromimitating sub-apps supported by these hosts such as sub-apps forAmazon health banking Airbnb etc (see Table 4)Cases Studies We discuss a few other problems we observed inapp-in-app ecosystembull Keeping up with the OS evolution Sub-app API permission policyshould keep up as the OS always evolves newer OS version oftenintroduces more strict protection against sensitive resources Forexample since Android 10 an app that accesses location in the back-ground needs an additional dangerous permission ACCESS_BACKGRO-UND_LOCATION in addition to the regular location permission [82]This protects user location against illicit tracking However sub-app API for accessing location in hosts TikTok and Alipay did notkeep up with such a new protection thus leaving their users at risk

As another example for the WiFi and Bluetooth scan that canleak location Android 9 and 10 require ACCESS_FINE_LOCATIONpermission while Android 81 is less restrictive and ACCESS_COARSE_LOCATION is sufficient (see Table 5) Note that Android uses the firstpermission to control access to precise location (eg GPS data)and uses the second one for coarse-grained positioning (with anaccuracy approximately at the level of a city block [10]) Interest-ingly all hosts we studied only define a general location sub-apppermission to govern location API (eg scopeuserLocation inWechat) but do not differentiate the two levels of accuracybull Too many APIs for one permission APIs of apparently differentfunctionalities should never be governed by the same permissionHowever in the host TikTok (an extremely popular short-videosharing app with more than 500million downloads on Google Play)three sub-appAPIs ttscanCode ttchooseImage and ttchoos-eVideo (for scanning QR code accessing photos and videos) aregoverned by the same permission scopecamera and thus inade-quately protected For example a malicious sub-app that is grantedpermission by the user to scan QR code also behind the scenesilently gets access to API ttchooseImage that accesses user pho-tos posing a serious privacy risk

5 LESSONS AND MITIGATION STRATEGYLessons learned The most important lesson learnt from our re-search is the caution one should take when building a third-party

11

Table 5 Summary of System Resources Exposure flaws (NA means the flaw does not affect the OS)

SystemResourceExposed

of

FlawsExample of Escaped

Sub-app API Dangerous Permission Android API Entitlement iOS Class

Microphone 1 WechatwxgetRecorderManager RECORD_AUDIO mediaMediaRecorder

CaptureRequest Microphone Usage AVAudioRecorder

Camera 3 Alipay myscan CAMERA CameraManageropen-CameraCaptureRequest Camera Usage AVCaptureSession

Wi-Fi 4WeChatwxgetWifiList

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetScanResults Hotspot Helper dagger NEHotspotHelper

JinRiTouTiaoTikTokttgetConnectedWifi

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetConnectionInfo Access WiFi Information dagger CNCopyCurrent-

NetworkInfo

Bluetooth 27

Alipay mystartBluetoothDevicesDiscovery

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan NA NADingTalk

ddgetBluetoothDevicesAlipay

mygetBLEDeviceServices

iBeacon 4 Alipay mygetBeaconsACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan Location Usage CLBeaconRegion

dagger Much harder to exploit on iOS due to the requirement of explicit user approvalDagger Android 9 and 10 require ACCESS_FINE_LOCATION permission while Android 81 requires ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION

Table 6 Examples of Sub-window Deception flaws

Host App Triggering Sub-App API Legitimate (and spoofable)Functionality of the Sub-window

Alipay mytradePay Request password ofAlipay mobile wallet

Baidu swanrequestPolymerPayment Request passwords ofmultiple mobile wallets

DingTalk ddpay Request password ofAlipay mobile wallet

WechatwxaddPhoneContact Enter new contacts

wxrequestPayment Request password ofWechat mobile wallet

QQ new in-app message Display instant messagesand enter a reply

sub-ecosystem on top of the operating system In such a case thethird-party OS-like app strives to provide a secure self-containedenvironment However whether it undermines OS security andbrings in new risks to modern mobile applications need to be eval-uated to identify the security gap between the new sub-ecosystemand the OSes Our measurement study shows that popular host appsare generally susceptible to APINA flaws indicating that the app-in-app system vendors today either fail to identify or are unpreparedfor the new risks

Fundamentally APINA risks come from the limited app-levelcapabilities the host app has in managing OS resources lack ofOS-level support and missing of sub-app API standard Hencedown the road it will require non-trivial joint efforts to fundamen-tally eliminate APINA risks More specifically escaped sub-app APIshows that a third-party host fundamentally lacks the full OS-levelknowledge on system resource protection While such knowledgecan come from different sources eg program analysis on relevantOS modules [35 46] developer documentations technical reportsetc each source only contributes a partial view Hence joint effortsneed to be made in the future to synthesize such knowledge Ourstudy also brings to light that such efforts are by no means trivialndash even the two leading mobile OSes have apparently confusingconflicting security policies Synthesizing such a knowledge base

will not only benefit the app-in-app paradigm but also make theOSrsquo security mechanism more transparent for thorough auditing

Our findings also highlight that prior OS lessons cannot fullyeliminate new risks incurred by the new paradigm which necessi-tates thorough assessment regarding its new attack surfaces Forexample a malicious sub-app a sub-window and a task in Recentsscreen all come as new attack vectors that pose credible new threatsto usersrsquo most sensitive credentials and privacyMitigation strategy Following we propose the short-term miti-gation and discuss the long-term strategybull Escaped Sub-app API Eliminating the risk requires the host tohave full OS-level knowledge about resource control (eg API-permission mapping) which is difficult In the meantime our toolApinat together with our API-permission mapping (released on-line [12]) can help host app vendors identify escaped sub-app APIsNote that since Apinat can identify escaped sub-app API with itsignored permissions with respect to specific OS version (see Sec-tion 43) host vendors may leverage our tool to assess whether theirsub-app API permission policy is always compliant with newly re-leased OS version and thus keep up the pace

Further we envision two possible future directions that couldlead to more viable solutions First as demonstrated by our anal-ysis tool Apinat although it is hard for todayrsquos program analy-sis techniques to derive a complete system API-permission map-ping [35 46] we could significantly improve its accuracy and com-prehensiveness through developer documentation analysis Ourcurrent documentation analysis is rather preliminary but still effec-tive as demonstrated in our study (Section 4) Down the road wecould develop natural language processing (NLP) based techniquesfor deriving more complete knowledge about API permission poli-cies With the techniques an analysis could cover a wider spectrumof literature including iOS documents research papers technicalreports etc which will help derive up-to-date knowledge aboutresource-management policies

Second the app-in-app community should work together tostandardize sub-app APIs and their permission policies as donein the HTML5 community on HTML5 APIs For the time being

12

different app-in-app vendors bring in their own APIs for accessinga wide spectrum of systems resources (see our comparison betweensub-app API and HTML5 API in Table 7 in Appendix) often withoutproper safeguard in place not to mention any effort to standardizethe protectionbull Sub-window deception The risk comes from the UI confusionwhether a window portion in the sub-app window belongs to thesub-app or the host (Figure 3b) To mitigate the risk we envision ahigher degree of UI isolation between the sub-app and the host thesub-apprsquos window should always be separated from that of the hostand the host should never reclaim any window portion from thesub-applsquos window Regarding the Wallet UI confusion (Section 32)for example Wechat should display its wallet UI only in its ownwindow and advertise to users that any UI component inside thesub-app window belongs to the sub-app

A question arises whether a malicious sub-app can fake a crashand then show spoofing content in the sub-app window to resem-ble the host This can be mitigated through additional protectionsupported by the host Specifically the host app could keep mon-itoring the UI of its sub-apps (eg through PixelCopy API onAndroid [71]) to detect whether a UI object in the sub-app is similarto a sub-window or a security-sensitive UI object associated withhost app For performance concern the host app could utilize thestate-of-the-art object detection model (eg Fast Region-based Con-volutional Network based model [61] and YOLO [32 95]) for thereal-time security-sensitive UI object recognition as reported inprior research [95] Fast YOLO yields the performance of 155 framesper second Note that the effectiveness efficiency and deploymentfeasibility of such an approach need to be carefully explored andevaluated which we leave for our future researchbull Sub-app lifecycle hijacking To mitigate this risk a short-termdefense is to place all sub-app resources in the phonersquos internalstorage so our current exploit (leveraging monitoring the phonersquosexternal storage) to track sub-app lifecyle termination (Section 33)can be mitigated However it is always a concern that sub-appsmay deplete the limited space on a phonersquos internal storage Along term solution needs to consider how to make the sub-apptasks dynamically scalable to ensure that the sub-app recycling isno longer traceable and thus the attack surface is fundamentallyeliminated This nonetheless calls for support from modern OSesfor the emerging app-in-app paradigm

6 RELATEDWORKAs mentioned in Section 2 recent years witnessed several tech-niques to support the functionality of app encapsulation (eg Plu-gin frameworks app sandboxing browser extension and PhoneGapapp see Table 2) Accordingly numerous studies have looked intothe flaws in these app encapsulation systems considering the se-curity analysis of Plugin frameworks a set of flaws were revealed[99 111 112] including no permission management and no isola-tion of the virtualized apps Compared with Plugin frameworks theapp-in-app paradigm has a much stronger security model and ourstudy investigates the design challenges and pitfalls in the securitymechanism Meanwhile the security and privacy implications ofbrowser extensions have been extensively studied [48 54 84 98]

Furthermore the current security studies on PhoneGap apps fo-cus on the flaws of PhoneGap frameworkrsquos access control policy[60 90 100 101] For example Song et al [101] revealed that thebridges added by the framework to the browser are not correctlyprotected by the same origin policy Jin et al [86] introduced mul-tiple channels (eg barcode SMS file system Contact) for codeinjection attacks in PhoneGap apps Different from these works wefocus on the unique features of the app-in-app paradigm (Table 2)and reveal multiple new attack surfaces which have never beenstudied before

The closer to our study are the works of Web App and WebViewvulnerability assessment Up to our knowledge only one paper[87] analyzed security issue of Web App in which the securityand privacy risks on HTML5 features in PWA were investigatedIn our attack on Web App we did not focus on HTML5 featuresbut a general UI isolation and management model in app-in-appparadigm Also although WebView technique is used in some ofthe app-in-app systems in sharp contrast to the works on Webviewweaknesses [36 60 88 102 105 109 110] our study explores thesecurity implications and challenges for a third-party app tomanageoperating system resources Another set of works related to ourstudy is the exploitation of mobile UI deception Prior phishingattacks [38 49 53 57 97] mislead victims about the foregroundapp aiming at information theft in spoofing apps Correspondingcountermeasures [49 58 96] emphasize identifying the app of thewhole foreground window and thus cannot thwart Sub-windowDeception due to the inability to identify sub-windows Furtheranother angle of UI deception is clickjacking [59 94] which aredifferent from our mobile-phishing attacks7 CONCLUSIONIn this paper we present the first systematic security analysis on re-source management in high-profile app-in-app systems Our studyshows that such systems are susceptible to a set of serious securityflaws Our measurement study further sheds light on their perva-siveness in the real-world Further our study brings in new insightsinto the fundamental security limitations of this new paradigm andfurther contributes to a better understanding of its mitigation strat-egy an important step towards building a more secure app-in-appecosystem

8 ACKNOWLEDGMENTWe would like to thank our shepherd Yanick Fratantonio and theanonymous reviewers for their insightful comments This work issupported in part by the NSF CNS-1618493 1801432 1838083

REFERENCES[1] 2011 HTML5 Fullscreen API Attack httpsferossorghtml5-fullscreen-api-

attack[2] 2011 The Inception Bar httpsjameshfishercom20190427the-inception-

bar-a-new-phishing-method[3] 2018 Java Runnable httpsdocsoraclecomjavase7docsapijavalang

Runnablehtml[4] 2018 A one year PWA retrospective httpsmediumcompinterest-

engineeringa-one-year-pwa-retrospective-f4a2f4129e05[5] 2018 Wechat 1 million sub-apps httpswwwscmpcomtecharticle2153705

tencents-wechat-now-host-1-million-mini-programs[6] 2018 WeChat reaches 1M sub-apps half the size of Applersquos App Store https

techcrunchcom20181107wechat-mini-apps-200-million-users[7] 2018 Xposed httpsapixposedinforeferencepackageshtml[8] 2019 AdBlock httpsgetadblockcom

13

(a) Real sub-app task (b) Bogus sub-app task

Figure 5 Dedicated task for every sub-app in Recents screen

Up to our knowledge state-of-the-art mobile anti-phishing tech-niques cannot identify our attacks for example [49 58 96] mainlyrely on identifying the app of the whole foreground window so theuser would not expose secrets to the unintended app this cannotidentify a sub-window at the sub-app level ndash whether it belongs toa sub-app or the host app

Our study shows that a bogus sub-window presents a practicalattack vector in app-in-app since a window portion (sub-window)can be used by both the sub- or host- app in accustomed contextswithout differentiation through clear identification From a broadersense we believe the spoofing risk is also high if the OS showsits pop-up atop an app (so malicious app can show a bogus onewhen the OS does not) however in sharp contrast such pop-upis not sub-window (but whole window) and known anti-phishingtechniques (eg [49]) to identify (the owner of) the whole windowcan defeat itAttacks and vendor acknowledgementsWe implemented PoCattacks in Safari on iOS Chrome on Android and Wechat on bothOSes in Safari and Chrome our malicious Web App impersonatesProminent UI to spoof Facebook login page in Wechat our mali-cious sub-app mimics the wallet UI to steal wallet password (seevideo demo online [12]) Our malicious sub-app passed the vettingof Wechatrsquos sub-app store Note that Web App does not have appstores and can be installed after visiting its URL In addition wereported the problems to all affected host vendors who all acknowl-edged that the threats were practical and severe Wechat and Alipayawarded us through their bug bounty programs

33 Sub-app Lifecycle HijackingAs app vendors follow the app-in-app trend by releasing sub-appsit is unclear whether their users remain equally protected as beforeUnfortunately our study shows that even highly credible host appscannot fully eliminate new attack surfaces incurred by app-in-appRecents screen takeover The Recents screen (aka recent task listor recent apps) [64] is a system-owned UI of Android to list recentlyaccessed task (Figure 5a) In particular each launched native appwill have a task in Recents screen similarly a host app creates aseparate task for every launched sub-app which appears in Recentsscreen Limited by the OS each host app can only create a fixednumber of tasks in Recents screen pre-specified as activities inits manifest file In our research we found that host apps all specify

a small magic number (eg 8 in Chrome 5 in Wechat 4 in Alipay3 in JinRiTouTiao) for the task limit

When an additional sub-app will be opened after the task limitis reached the host app silently executes a mandatory recyclingprocess closing the first opened sub-app to recycle its task forlaunching the new one The recycling process is transparent tousers for the possible purpose of not interrupting the user experi-ence Such a mandatory sub-app recycling mechanism introducesa new risk once the recycling is traceable by a malicious appie the adversary knows which sub-app has been recycled and atwhat time it can stealthily insert a phishing task into the Recentsscreen to imitate the silently recycled sub-app For this purposethe adversary needs to acquire the information about a hostrsquos taskrecycling which turns out to be feasible due to the presence ofvarious information-leak avenues that can be hard to eliminate Inour study we found a side channel that enables recycling track-ing in multiple host apps In particular possibly due to the richfunctionalities of sub-apps which require resource files (eg userdata logs icon and image texture) the host app creates a folderin Android external storage [18] to cache sub-app resources Suchexternal storage can be monitored by an Android native app totrack which sub-app is launched and at what time (by monitoringsub-app icon which will be downloaded at launch see PoC attackbelow) Thereby once the number of launched sub-apps reachesthe hostrsquos task limit the sub-app to recycle can be inferred Hencea malicious native app can insert a bogus task in Recents screento mimic the recycled sub-app at this point the bogus task is theonly one in Recents screen that represents the target sub-app thatrsquosspoofed (Figure 5b)

This attack is a kind of mobile task hijacking attacks [52 97]Regarding its root cause the mandatory sub-app recycling opens anew attack surface for app-in-app systems since it makes it possiblefor malicious apps to track a sub-apprsquos lifecycle termination Notethat the attack surface becomes exploitable in the presence of sidechannels eg external storage which itself is a relatively trivialbug Other side channels could also be used for the attack once theyarise (see discussion below) Eliminating this attack surface maynot be trivial in practice since the maximum task number of a hostin Recents screen is not dynamically scalable (statically specifiedin manifest) limited by the OS Although the very recent Androidsupports dynamic task no host app we studied (Table 3) adoptedit possibly for the purpose of supporting older Android versionsgiven the notorious Android version fragmentation [74]Attacks and vendor acknowledgementsWe implemented PoCattacks on Alipay andWechat which cache sub-app resources in theexternal storage and enable recycling tracking Specifically Alipaystores the caches at sdcardalipaymultimedia When a sub-app such as Amazon is launched its icon will be downloaded toit if not already there Our malicious Android app with a commonpermission WRITE_EXTERNAL_STORAGE can remove cached iconsperiodically andmonitor when they reappear to knowwhat specificsub-app is launched and at what time In our attack of Alipay oncethe malicious app infers that five sub-apps have been launched(submit-app task limit of Alipay is 4) it will insert a bogus task inRecents screen to mimic the first sub-app which is recycled Oncethe victim user enters the spoofing task through Recents screenit can lure the user to leak secrets such as passwords Note that

7

our malware successfully passed the vetting of popular app storesincluding Google Play We reported the problem (demo online [12])to Wechat and Alipay which both acknowledged the problem andawarded us through bug bountiesDiscussion on other side channels As mentioned earlier otherside channels once found can also be used for impersonating therecycled sub-app Prior research [113] shows that the operationsof Android apps can be easily tracked through the Android pro-cess file system (procfs) Although Android has been continuouslybeefing up its privacy protection until Android 9 still some globalstatistics under procfs are exposed Particularly we found that theTCP connection status under procnettcp can be accessed byany app without permission on Android 9 and below From the filewe can see the IP addresses of all TCP connections on an Androidphone which are labeled by randomly assigned User IDs Interest-ingly we found that an invoked sub-app makes a sequence of TCPconnections and the endpoints of the connections (domains) canuniquely fingerprint its initiation eg Amazon sub-app connects to4 unique endpoints with 8 consecutive HTTPS requests in the firstfew seconds after it is launched In our research we sampled 8 high-profile sub-apps in Wechat and identified the sequences of theircommunication endpoints as observed when they are triggered (seeTable 8 in Appendix) Through this side channel a malicious nativeapp is able to infer the launch of a specific sub-app so it can waituntil it is terminated for task recycling (eg after 5 other sub-appsare found to be started through the procfs when the magic numberis 5) to create a task to impersonate the sub-app Note that the mali-cious app can resolve the endpoint domains from IP addresses usingAndroid API InetaddressgetCanonicalHostName [81] withoutrequiring any permission which was implemented and confirmedin our study

Until April 2020 84 of the Android devices are still runningAndroid 9 or earlier versions [33] and therefore are vulnerable toour attack On Android 10 which was released in September 2019the procfs used in our attack has been closed by SEAndroid [70 83]and thus the attack is ineffective Seeking a more powerful attackavenue is left to the future research

4 APINA FLAWS IN THEWILDIn this section we report a measurement study that reveals thescope and magnitude of APINA flaws in the wild The study ismade possible by an automatic analysis tool we built called Apinat(short for App-in-app Threat Scanner) which helped us identifyapp-in-app hosts that are susceptible to APINA flaws

41 Identifying System Resource ExposureDesign Apinat aims to find System Resource Exposure flaws byidentifying escaped sub-app API The idea is to find sub-app APIthat is unprotected by sub-app permission while its correspondingsystem API is permission-protected A naive idea is to call eachsub-app API and find out whether the OS checks the permissions ofthe host app eg by looking at permission pop-ups or system logsThis does not work because the permission asked by the OS can berelated to the host apprsquos own rich functionalities not the sub-appAPI To systematically find escaped sub-app API our methodologytracks the system API invocations triggered by a sub-app API via

a dynamic analysis (Step S1 S2) and then utilizes system API-permission maps to derive required permissions of the sub-appAPI (Step S3) which will be compared to the corresponding sub-app permission If a sub-app API is not protected by any sub-apppermission while its corresponding system APIs are guarded by theAndroid dangerous permissions5 or iOS entitlements an escapedsub-app API is found (Step S4) Following we describe how thisdesign works and how it was implemented in our research onAndroid Since sub-app APIs are cross-platform we were able toextend all the findings made by our technique from Android to iOSby simply validating these findings on the Apple platformStep S1 generating test cases To conduct a dynamic analysis wefirst need to generate test cases with valid arguments to invoke eachsub-app API without triggering exceptions For each API we targetthat at least one invocation is successful The argument types ofJavaScript APIs are either primitive or Object [21] To produce testcases for primitive arguments we leveraged Mozillarsquos funfuzz [22]a JavaScript toolkit ForObject arguments we recursively generatedtest cases leveraging funfuzz because an Object includes keyvaluepairs its key is primitive and the value is either primitive or ObjectAll test cases were then used by a sub-app we built to invoke sub-app APIs If all test cases for an API failed we manually inspectedthe API to address the issues such as formatted inputs (eg UUID)stateful calls (an API needs to be invoked before another) etcStep S2 tracking system API As mentioned in Section 21 theexecution of a sub-app API enters the native layer of the hostthrough a dispatcherdispatch function and then its controlflow reaches system APIs (Figure 1) Therefore Step S2 first iden-tifies the dispatcherdispatch function in the host apprsquos nativelayer then tracks its call graph to find the system APIs triggeredby the sub-app API call as elaborated below

(1) Find the dispatcherdispatch function in the native layer Asmentioned earlier Webview and React Native are bridge techniquesto expose dispatcherdispatch to JavaScript layer Note thatthough the object alias (dispatcher) and function name (dispatch)vary across host apps they can be obtained by inspecting functioninvocations in Encapsulation lib (Figure 1) which is a preprocess-ing step in our study Note that the Encapsulation lib usually canbe found in JavaScript files packaged in the host app (eg underassets folder) So all we need is to identify the dispatcher objectin the native layer based on the obtained alias

To this end S2 implements an Xposed [7] (a framework to in-strument Android app execution) module to hook Webview APIaddJavascriptInterface(obj alias) (that exposes Java objectto JavaScript through an alias) and inspect its arguments at run-time if the ldquoalias argumentrsquos value matches the dispatcher aliasdiscovered the ldquoobj is the dispatcher object that we are lookingfor The analysis of React Native bridge is slightly different wehook its API createNativeModules to get its Java objects exposedto JavaScript our Xposed module then calls each exposed objectrsquosgetNamemethod to get its alias ndash if this alias matches the dispatcheralias discovered the object is what we are looking for

5Host apps are typically third-party apps that cannot call privileged system APIs pro-tected by ldquosignature or ldquosignatureOrSystem level permissions [65] or they typicallydo not delegate the access to such APIs through sub-app APIs

8

(2) Track execution of the dispatcherdispatch function Our toolthen tracks the call graph of the dispatch function to find the calledsystem APIs ndash which are called to fulfill the sub-app API call Specif-ically our Xposed module hooks dispatch function and AndroidAPI and inspects their respective call stack traces However wefound that dispatchrsquos thread sometimes does not call Android APIsdirectly it triggers additional thread to call Android APIs likelyfor not to block the dispatch thread This introduces a challengeXposed outputs the above two stack traces by threads ndash one stacktrace with Android API call and the other with dispatch functioncall ndash but cannot correlate two threads if one triggers the otherTherefore we still cannot confirm that the Android APIs are in-voked due to dispatch Hence we developed techniques to deal withthe multi-threading challenge

In our study we found that Handler a typical multi-threadingmechanism of Android is commonly used by dispatchrsquos thread totrigger a new thread Thus we implemented our own thread corre-lation technique based on the Handler mechanism in our Xposedmodule More specifically in the Handlermechanism a triggeringthread that holds a handler instance will submit a runnable to amessage queue via calling the handlerpost(runnable) methodHere the runnable is an instance of Java Runnable [3] with codein its run() method Then the runnable is taken out of the queueby another thread which we name as the handler thread andgets executed in the handler thread Hence as checked in ourXposed module if the executed runnable in a handler thread isthe same instance with one submitted by a triggering thread thenwe correlate the two threads Through such techniques we foundAndroid APIs are indeed called in such handler thread followingthe dispatch threadrsquos triggering ndash this confirms the Android APIcall caused by the dispatcherdispatch functionStep S3 synthesizingAPI-permissionmapping As mentionedin Section 31 system API-permission mappings are incompletewhich can lead to escaped sub-app APIs How to derive a completemapping remains an open question in system security researchand program analysis Here our idea is to supplement recent map-pings [35 46] leveraging documentation analysis we automaticallyextract explicitly declared permissions for system APIs in the devel-oper manuals assuming that explicit specification at least reflectsintended protection of the OS with rare faults Note that certainportion of the documentation (Figure 2) can be misleading to hu-man readers due to incomplete presentation but we observed thatan exhaustive machine-based search on the whole corpus of mobileOSes (eg the entire documentation for all 2497 SDK classes of An-droid API level 27) can help us derive a significantly more completemapping than state-of-the-art mappings [35 46] (see evaluationbelow) For instance after a full scan of Android WifiManager man-ual [75] we were able to flag ACCESS_FINE_LOCATION as a requiredpermission for multiple Wi-Fi scan related APIs (see Figure 8 inAppendix) which has never been included in state-of-the-art map-pings [35 46]

In our implementation we developed a Web crawler to fetchall manuals from Android developer portal [62] and extractedthe description for each public API From the description we ex-tracted the declared permissions based on a few key observations

if the description of an API does not contain a ldquopermission key-word it is very likely that the API does not explicitly requirepermissions otherwise its description usually includes a ldquoper-mission keyword and the exact permission string constants de-fined in Android class androidManifestpermission [77] suchas ACCESS_FINE_LOCATION Based on such observation we per-formed a light-weight string matching to find explicit permissionrequirement of Android APIs (we discuss the sophisticated NLP-based direction in Section 5)

Step S3 also derives a sub-app API-permission map given itsrelatively small size (ie 50 to 172 sub-app APIs in each host com-pared to 35847 public Android APIs found by our Web crawler)we extracted the map by searching ldquopermission related keywordsin sub-app developer manual and manually confirmed the resultStep S4 reporting flaws S4 reports an escaped sub-app API if itis not protected by sub-app permission while its correspondingAndroid API(s) is protected by dangerous permission(s) That is aSystem Resource Exposure flaw is found

For iOS however a comprehensive detection is much more dif-ficult than Android especially because obtaining a system API-entitlement mapping is much more challenging First we are notaware of any work that has produced a mapping on iOS for us tostart with Second we observed that iOS documentation is not asprecise as Android in this regard which describes required enti-tlements for iOS classes but not for individual system API To stillhelp us understand the impact of escaped sub-app API on iOS weextended our findings of escaped sub-app API from Android to iOSif its corresponding iOS API requires an entitlement it is consideredto affect iOS as well This was done by manually searching corre-sponding iOS API for a given escaped sub-app API and checkingwhether any entitlement is asked when the iOS API is invoked inan iOS app we builtEvaluation We evaluated the effectiveness and performance of ouranalysis tool (source code released [12]) on a Google Pixel 2 phoneand iPhone 8 against 11 host apps The evaluation was performedon three Android versions (81 9 10 corresponding to API level 2728 29) and two iOS versions (12 134)bullOverall detection resultsApinat found 39 System Resource Exposureflaws all of them affect Android 81 9 and 10 13 of them affectiOS 12 and 134 We manually validated that all discovered flawsare true in two steps (1) confirming that the sub-app API requiresno sub-app permission through a testing sub-app (2) confirmingthat the corresponding system API(s) has permission protectionthrough a testing native app on Android and iOSbull Evaluating individual steps Step S1 generated test cases for all927 sub-app APIs under test in less than one hour All sub-app APIswere successfully invoked at least once without exception on eachAndroid version In this experiment we did not measure the hostrsquoscode coverage because the host includes implementation of its ownrich functionalities that are unrelated to sub-app API Thus it is notmeaningful to compute the percentage of covered host app code

Step S2 took less than 30 seconds for each sub-app API to reportits corresponding system APIs on each Android version The num-ber of system APIs (protected by dangerous permissions) hookedby S2 is 111 129 145 on the three Android versions respectivelyTo evaluate the correctness of our thread correlation we created

9

a test app which triggered new threads leveraging the Handlermechanism Our test showed that our tool correctly correlated thetriggering and triggered threads on each Android version

Step S3 produced the API-permission mapping including 94public APIs protected by dangerous permissions at API level 27103 APIs at API level 28 and 119 at API level 29 This step took ourapproach three hours to process the descriptions of 35847 42302and 44323 public APIs on the three API versions respectively Tovalidate the correctness of the mapping we constructed a test app toinvoke all the APIs and verify the required permissions at runtimeFor all three Android versions our permission mapping of all except6 APIs are correct Specifically the mapping of 92 APIs out of 94is correct (979 precision) at the API level 27 The two false casesare unprotected APIs hasPermission and requestPermission inclass UsbManager [66] At API 28 the mapping shows a precisionof 971 with one new false case than what was found on API 27(3 cases in total) API 29 shows a precision of 95 with three newcases than API 28 (6 cases in total) Figure 6 and 7 in Appendixlist all six false cases Their descriptions are more complex and weenvision that a natural language processing (NLP) based approachcan further improve our precision (see discussion in Section 5)

To evaluate the coverage of our documentation analysis toolwe randomly selected the documentation of 153 classes 641 APIs(out of 2164 classes) and then manually reviewed and identified52 API-permission mappings as the ground truth Running on theaforementioned documentation our analysis tool shows a precisionof 100 and a recall of 100 to identify API-permission mappingfrom the documentation

We also compared the completeness of our mapping with recentmappings [35 46] They collectively reported 50 public AndroidAPIs that require dangerous permissions on API level 25 (we werenot able to get results of newer Android from the authors) as asignificant improvement our tool was able to find 91 APIs (82more) that require dangerous permissions on the same API versionDiscussion Apinat may not find all escaped sub-app APIs In par-ticular Step S3 cannot derive a complete mapping if the documen-tation is incomplete [56] or too sophisticated to process Apinatonly looks for system resource exposure by public system APIs andundocumented system APIs used by host apps may also lead to theflaw but remain undetected Also Apinat falls short in analyzingobfuscated host apps eg that uses dynamic code loading andimplementations in CC++ Hence Apinat did not scan Web AppAPIs due to the extensive CC++ implementation in browsers Inaddition incorrect documentation (which we assume is rare andindeed our tool did not report any false escaped sub-app API ) mightlead to false alarms if not properly validated

42 Finding UI Deception FlawsDesign To find out the opportunities for Sub-window Deception(Section 32) in a host app Apinat looks for the apprsquos sensitive sub-windows which can be the targets of the attack As discovered inthe wallet UI confusion (Figure 4b) the hostrsquos sub-windows thatare likely to show up in the presence of a sub-app tends to be thosethat can be triggered through sub-app APIs If such a sub-windowalso contains sensitive information our approach then reports it asa potential target for Sub-window Deception

Implementation To detect such sub-windows Apinat monitorsthe change of the host UI in response to each sub-app API callto identify the sub-window triggered by the API call and thendetermines whether it carries sensitive content Specifically ourapproach first constructs a testing sub-app with an empty UI Thenit runs the sub-app API test cases in Section 41 to call each sub-appAPI through the testing sub-app and further inspects the UI screen-shots before and after the call for changes This is done through apixel-to-pixel comparison of two screenshots To capture the screen-shots we developed a screen projection service on Android usingthe Media Projection [63] API Also our screenshot compari-son was implemented using the OpenCV cv2absdiff API [85]For each sub-window identified our approach continues to findthose associated with sensitive information For this purpose itextracts strings from sub-window screenshots using the onlineOCR service [34] From the strings Apinat further utilizes a list of121 sensitive data keywords and the keyword pair list from recentresearch [91] to recognize those carrying sensitive content Notethat like a mobile OS an app-in-app system also provides a set ofsub-app APIs for sub-apps to dynamically generate UI componentssuch as wxcreateCanvasContextdraw() in Wechat To controlfalse positives Apinat omits such sub-app APIs based on the APIcategory in the sub-app API documentation As a result Apinat suc-cessfully detected 6 Sub-window Deception flaws (Section 43) ForiOS we got the same result since sub-app APIs are across-platformthe one triggers a sub-window on one OS also does that on theother (see Section 2)Evaluation Apinat detected 5 sub-app APIs associated with the UIdeception flaw we manually confirmed that all of them trigger sub-windows with sensitive information Also all of them affect bothAndroid (version 81 9 10) and iOS (version 12 134) Performance-wise the screenshot comparison and OCR analysis together tookless than 5 seconds on a desktop with Intel i5 27 GHz CPU and 8GB memoryDiscussion Soundly detecting whether a host app is susceptibleto Sub-app Lifecycle Hijacking (Section 33) is difficult especiallybecause it entails detection of side-channel information leakagewhich can happen in many ways and is hard to capture in generalTo measure a lower bound of the pervasiveness of the problemwe checked whether the hosts in our study (Table 1) had the sameinformation leakage and lifecycle design as reported in Section 33As a result 3 host apps on Android (Wechat Alipay DingTalk) aresusceptible which were all manually confirmed to be exploitable

43 Measurement of ImpactFlaw landscape With the help of Apinat we analyzed 11 highlypopular host apps (Table 1) on Android and iOS and found theyare all vulnerable to APINA flaws (Table 3) Altogether we found 52APINA flaws including 39 System Resource Exposure 10 Sub-windowDeception and 3 hosts vulnerable to Sub-app Lifecycle Hijacking

For System Resource Exposure in total we uncover 39 escaped sub-app APIs associated with 5 categories of exposed system resources4 Android dangerous permissions and 6 iOS entitlements Table 5shows the flaw number for each category of resources (the secondcolumn) and illustrates 8 escaped sub-app APIs with correspondingAndroid permission(s) and iOS entitlement(s) ignored to enforce

10

Table 3 Eleven vulnerable host apps on Android and iOS(A Alipay B Baidu C Chrome D DingTalk F FirefoxJJinRiTouTiao O Opera Q QQ S Safari T TikTok WWechat) NA denotes the flaw does not apply to the OS

Type of APINA Flaw iOS AndroidSystem Resource Exposure A D J Q T W A D J Q T WSub-window Deception A B D W S Q A B C D F W O QSub-app Lifecycle Hijacking NA A W Q

on them All 39 escaped sub-app APIs are listed in our releaseddataset [12] Also Table 6 illustrates 6 Sub-window Deception in non-browser hosts additionally all four browsers we studied (ChromeSafari Firefox Opera) are susceptible to the same Prominent UIattackResource comparison between Android and iOS Althoughfinding the full API-entitlement mapping for iOS is hard we ob-served a few differences between Android and iOS in system re-source protectionbull iOS is less affected than Android Out of 39 escaped sub-app APIs13 are related to iOS which appears to be less affected and harderto be exploited There are two reasons behind the observation asdiscovered in our study First certain iOS APIs return less informa-tion than its Android counterparts (ie those related to Bluetoothsee Section 31) and thus is less susceptible to privacy risk (locationleakage) Hence all 27 Bluetooth related escaped sub-app APIs donot affect iOS (see Table 5) Second WiFi related escaped sub-appAPIs (see Table 5) are much harder to exploit on iOS since Applehas extra protection besides entitlement Specifically right beforethe programmaticWiFi operation an iOS appmust obtain the userrsquosexplicit consent the app must instruct the user to manually openthe WiFi setting page in the Settings app and then return to theiOS app [43] ndash an indicator of user intention for the app to operateWiFibull iOS entitlement fails to communicate risks to the user On Androidwhen the permission ACCESS_FINE_LOCATION is used for protect-ing the operation Wi-Fi scan it indicates a risk that the WiFioperation may leak location a highly private data On iOS how-ever the entitlement for Wi-Fi scan ie Hotspot Helper failsto communicate such a risk Actually to get this entitlement for aniOS app app developers must file a special written request by justi-fying that the app does not have malicious intention Apple reviewsthe request internally and possibly assesses the risks of locationleakage behind the scene However the name of this entitlementand its documentation we could find does not show that Wi-Fiscan needs location protection on iOS This may have been oneof the factors leading to escaped sub-app API wxgetWifiList (seeTable 5) which performs Wi-Fi scan without protectionAttack consequences The system resources exposed by escapedsub-app API and the risks can be identified from the API namesand the permissions they violate (see Table 5) For example unautho-rized sub-apps can use escaped sub-appAPI wxgetRecorderManag-er to record audio (violating Androidrsquos RECORD_AUDIO permission)We summarize the attack consequences in Table 4 Further Sub-window Deception leads to phishing on popular Web services (egFacebook) mobile wallets and sensitive host UIs For exampleWechat has a UI triggered by sub-app API (wxaddPhoneContact)

Table 4 Examples of APINA attack consequences

Flaw Type Consequences (what the adversary is able to do)

SystemResourceExposure

record audio operate camerainfer victimsrsquo geo-location (thus track users)

connect victimrsquos device to arbitrary Wi-Fi (thus manipulatenetwork traffic perform man-in-the-middle (MITM) or phishing)

and steal sensitive QR code etcSub-windowDeception

steal account credentials on Facebook Google Amazon etcsteal mobile wallet passwords contacts etc

Sub-appLifecycleHijacking

steal money (payments in shopping sub-app)steal personal secrets (eg answers tosecurity questions health records etc)

steal business documents (from a document processingand management sub-app published by Microsoft)

steal account credentials of Amazon ICBCCCB HSBC (1st 2nd 7th largest banks in the world)

Airbnb Weibo Starbucks McDonaldrsquos etc

for users to enter contact information (Table 6) attacking this UImay leak contacts which are highly private Last Sub-app LifecycleHijacking affects three hosts (Table 3) and the risks come fromimitating sub-apps supported by these hosts such as sub-apps forAmazon health banking Airbnb etc (see Table 4)Cases Studies We discuss a few other problems we observed inapp-in-app ecosystembull Keeping up with the OS evolution Sub-app API permission policyshould keep up as the OS always evolves newer OS version oftenintroduces more strict protection against sensitive resources Forexample since Android 10 an app that accesses location in the back-ground needs an additional dangerous permission ACCESS_BACKGRO-UND_LOCATION in addition to the regular location permission [82]This protects user location against illicit tracking However sub-app API for accessing location in hosts TikTok and Alipay did notkeep up with such a new protection thus leaving their users at risk

As another example for the WiFi and Bluetooth scan that canleak location Android 9 and 10 require ACCESS_FINE_LOCATIONpermission while Android 81 is less restrictive and ACCESS_COARSE_LOCATION is sufficient (see Table 5) Note that Android uses the firstpermission to control access to precise location (eg GPS data)and uses the second one for coarse-grained positioning (with anaccuracy approximately at the level of a city block [10]) Interest-ingly all hosts we studied only define a general location sub-apppermission to govern location API (eg scopeuserLocation inWechat) but do not differentiate the two levels of accuracybull Too many APIs for one permission APIs of apparently differentfunctionalities should never be governed by the same permissionHowever in the host TikTok (an extremely popular short-videosharing app with more than 500million downloads on Google Play)three sub-appAPIs ttscanCode ttchooseImage and ttchoos-eVideo (for scanning QR code accessing photos and videos) aregoverned by the same permission scopecamera and thus inade-quately protected For example a malicious sub-app that is grantedpermission by the user to scan QR code also behind the scenesilently gets access to API ttchooseImage that accesses user pho-tos posing a serious privacy risk

5 LESSONS AND MITIGATION STRATEGYLessons learned The most important lesson learnt from our re-search is the caution one should take when building a third-party

11

Table 5 Summary of System Resources Exposure flaws (NA means the flaw does not affect the OS)

SystemResourceExposed

of

FlawsExample of Escaped

Sub-app API Dangerous Permission Android API Entitlement iOS Class

Microphone 1 WechatwxgetRecorderManager RECORD_AUDIO mediaMediaRecorder

CaptureRequest Microphone Usage AVAudioRecorder

Camera 3 Alipay myscan CAMERA CameraManageropen-CameraCaptureRequest Camera Usage AVCaptureSession

Wi-Fi 4WeChatwxgetWifiList

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetScanResults Hotspot Helper dagger NEHotspotHelper

JinRiTouTiaoTikTokttgetConnectedWifi

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetConnectionInfo Access WiFi Information dagger CNCopyCurrent-

NetworkInfo

Bluetooth 27

Alipay mystartBluetoothDevicesDiscovery

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan NA NADingTalk

ddgetBluetoothDevicesAlipay

mygetBLEDeviceServices

iBeacon 4 Alipay mygetBeaconsACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan Location Usage CLBeaconRegion

dagger Much harder to exploit on iOS due to the requirement of explicit user approvalDagger Android 9 and 10 require ACCESS_FINE_LOCATION permission while Android 81 requires ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION

Table 6 Examples of Sub-window Deception flaws

Host App Triggering Sub-App API Legitimate (and spoofable)Functionality of the Sub-window

Alipay mytradePay Request password ofAlipay mobile wallet

Baidu swanrequestPolymerPayment Request passwords ofmultiple mobile wallets

DingTalk ddpay Request password ofAlipay mobile wallet

WechatwxaddPhoneContact Enter new contacts

wxrequestPayment Request password ofWechat mobile wallet

QQ new in-app message Display instant messagesand enter a reply

sub-ecosystem on top of the operating system In such a case thethird-party OS-like app strives to provide a secure self-containedenvironment However whether it undermines OS security andbrings in new risks to modern mobile applications need to be eval-uated to identify the security gap between the new sub-ecosystemand the OSes Our measurement study shows that popular host appsare generally susceptible to APINA flaws indicating that the app-in-app system vendors today either fail to identify or are unpreparedfor the new risks

Fundamentally APINA risks come from the limited app-levelcapabilities the host app has in managing OS resources lack ofOS-level support and missing of sub-app API standard Hencedown the road it will require non-trivial joint efforts to fundamen-tally eliminate APINA risks More specifically escaped sub-app APIshows that a third-party host fundamentally lacks the full OS-levelknowledge on system resource protection While such knowledgecan come from different sources eg program analysis on relevantOS modules [35 46] developer documentations technical reportsetc each source only contributes a partial view Hence joint effortsneed to be made in the future to synthesize such knowledge Ourstudy also brings to light that such efforts are by no means trivialndash even the two leading mobile OSes have apparently confusingconflicting security policies Synthesizing such a knowledge base

will not only benefit the app-in-app paradigm but also make theOSrsquo security mechanism more transparent for thorough auditing

Our findings also highlight that prior OS lessons cannot fullyeliminate new risks incurred by the new paradigm which necessi-tates thorough assessment regarding its new attack surfaces Forexample a malicious sub-app a sub-window and a task in Recentsscreen all come as new attack vectors that pose credible new threatsto usersrsquo most sensitive credentials and privacyMitigation strategy Following we propose the short-term miti-gation and discuss the long-term strategybull Escaped Sub-app API Eliminating the risk requires the host tohave full OS-level knowledge about resource control (eg API-permission mapping) which is difficult In the meantime our toolApinat together with our API-permission mapping (released on-line [12]) can help host app vendors identify escaped sub-app APIsNote that since Apinat can identify escaped sub-app API with itsignored permissions with respect to specific OS version (see Sec-tion 43) host vendors may leverage our tool to assess whether theirsub-app API permission policy is always compliant with newly re-leased OS version and thus keep up the pace

Further we envision two possible future directions that couldlead to more viable solutions First as demonstrated by our anal-ysis tool Apinat although it is hard for todayrsquos program analy-sis techniques to derive a complete system API-permission map-ping [35 46] we could significantly improve its accuracy and com-prehensiveness through developer documentation analysis Ourcurrent documentation analysis is rather preliminary but still effec-tive as demonstrated in our study (Section 4) Down the road wecould develop natural language processing (NLP) based techniquesfor deriving more complete knowledge about API permission poli-cies With the techniques an analysis could cover a wider spectrumof literature including iOS documents research papers technicalreports etc which will help derive up-to-date knowledge aboutresource-management policies

Second the app-in-app community should work together tostandardize sub-app APIs and their permission policies as donein the HTML5 community on HTML5 APIs For the time being

12

different app-in-app vendors bring in their own APIs for accessinga wide spectrum of systems resources (see our comparison betweensub-app API and HTML5 API in Table 7 in Appendix) often withoutproper safeguard in place not to mention any effort to standardizethe protectionbull Sub-window deception The risk comes from the UI confusionwhether a window portion in the sub-app window belongs to thesub-app or the host (Figure 3b) To mitigate the risk we envision ahigher degree of UI isolation between the sub-app and the host thesub-apprsquos window should always be separated from that of the hostand the host should never reclaim any window portion from thesub-applsquos window Regarding the Wallet UI confusion (Section 32)for example Wechat should display its wallet UI only in its ownwindow and advertise to users that any UI component inside thesub-app window belongs to the sub-app

A question arises whether a malicious sub-app can fake a crashand then show spoofing content in the sub-app window to resem-ble the host This can be mitigated through additional protectionsupported by the host Specifically the host app could keep mon-itoring the UI of its sub-apps (eg through PixelCopy API onAndroid [71]) to detect whether a UI object in the sub-app is similarto a sub-window or a security-sensitive UI object associated withhost app For performance concern the host app could utilize thestate-of-the-art object detection model (eg Fast Region-based Con-volutional Network based model [61] and YOLO [32 95]) for thereal-time security-sensitive UI object recognition as reported inprior research [95] Fast YOLO yields the performance of 155 framesper second Note that the effectiveness efficiency and deploymentfeasibility of such an approach need to be carefully explored andevaluated which we leave for our future researchbull Sub-app lifecycle hijacking To mitigate this risk a short-termdefense is to place all sub-app resources in the phonersquos internalstorage so our current exploit (leveraging monitoring the phonersquosexternal storage) to track sub-app lifecyle termination (Section 33)can be mitigated However it is always a concern that sub-appsmay deplete the limited space on a phonersquos internal storage Along term solution needs to consider how to make the sub-apptasks dynamically scalable to ensure that the sub-app recycling isno longer traceable and thus the attack surface is fundamentallyeliminated This nonetheless calls for support from modern OSesfor the emerging app-in-app paradigm

6 RELATEDWORKAs mentioned in Section 2 recent years witnessed several tech-niques to support the functionality of app encapsulation (eg Plu-gin frameworks app sandboxing browser extension and PhoneGapapp see Table 2) Accordingly numerous studies have looked intothe flaws in these app encapsulation systems considering the se-curity analysis of Plugin frameworks a set of flaws were revealed[99 111 112] including no permission management and no isola-tion of the virtualized apps Compared with Plugin frameworks theapp-in-app paradigm has a much stronger security model and ourstudy investigates the design challenges and pitfalls in the securitymechanism Meanwhile the security and privacy implications ofbrowser extensions have been extensively studied [48 54 84 98]

Furthermore the current security studies on PhoneGap apps fo-cus on the flaws of PhoneGap frameworkrsquos access control policy[60 90 100 101] For example Song et al [101] revealed that thebridges added by the framework to the browser are not correctlyprotected by the same origin policy Jin et al [86] introduced mul-tiple channels (eg barcode SMS file system Contact) for codeinjection attacks in PhoneGap apps Different from these works wefocus on the unique features of the app-in-app paradigm (Table 2)and reveal multiple new attack surfaces which have never beenstudied before

The closer to our study are the works of Web App and WebViewvulnerability assessment Up to our knowledge only one paper[87] analyzed security issue of Web App in which the securityand privacy risks on HTML5 features in PWA were investigatedIn our attack on Web App we did not focus on HTML5 featuresbut a general UI isolation and management model in app-in-appparadigm Also although WebView technique is used in some ofthe app-in-app systems in sharp contrast to the works on Webviewweaknesses [36 60 88 102 105 109 110] our study explores thesecurity implications and challenges for a third-party app tomanageoperating system resources Another set of works related to ourstudy is the exploitation of mobile UI deception Prior phishingattacks [38 49 53 57 97] mislead victims about the foregroundapp aiming at information theft in spoofing apps Correspondingcountermeasures [49 58 96] emphasize identifying the app of thewhole foreground window and thus cannot thwart Sub-windowDeception due to the inability to identify sub-windows Furtheranother angle of UI deception is clickjacking [59 94] which aredifferent from our mobile-phishing attacks7 CONCLUSIONIn this paper we present the first systematic security analysis on re-source management in high-profile app-in-app systems Our studyshows that such systems are susceptible to a set of serious securityflaws Our measurement study further sheds light on their perva-siveness in the real-world Further our study brings in new insightsinto the fundamental security limitations of this new paradigm andfurther contributes to a better understanding of its mitigation strat-egy an important step towards building a more secure app-in-appecosystem

8 ACKNOWLEDGMENTWe would like to thank our shepherd Yanick Fratantonio and theanonymous reviewers for their insightful comments This work issupported in part by the NSF CNS-1618493 1801432 1838083

REFERENCES[1] 2011 HTML5 Fullscreen API Attack httpsferossorghtml5-fullscreen-api-

attack[2] 2011 The Inception Bar httpsjameshfishercom20190427the-inception-

bar-a-new-phishing-method[3] 2018 Java Runnable httpsdocsoraclecomjavase7docsapijavalang

Runnablehtml[4] 2018 A one year PWA retrospective httpsmediumcompinterest-

engineeringa-one-year-pwa-retrospective-f4a2f4129e05[5] 2018 Wechat 1 million sub-apps httpswwwscmpcomtecharticle2153705

tencents-wechat-now-host-1-million-mini-programs[6] 2018 WeChat reaches 1M sub-apps half the size of Applersquos App Store https

techcrunchcom20181107wechat-mini-apps-200-million-users[7] 2018 Xposed httpsapixposedinforeferencepackageshtml[8] 2019 AdBlock httpsgetadblockcom

13

our malware successfully passed the vetting of popular app storesincluding Google Play We reported the problem (demo online [12])to Wechat and Alipay which both acknowledged the problem andawarded us through bug bountiesDiscussion on other side channels As mentioned earlier otherside channels once found can also be used for impersonating therecycled sub-app Prior research [113] shows that the operationsof Android apps can be easily tracked through the Android pro-cess file system (procfs) Although Android has been continuouslybeefing up its privacy protection until Android 9 still some globalstatistics under procfs are exposed Particularly we found that theTCP connection status under procnettcp can be accessed byany app without permission on Android 9 and below From the filewe can see the IP addresses of all TCP connections on an Androidphone which are labeled by randomly assigned User IDs Interest-ingly we found that an invoked sub-app makes a sequence of TCPconnections and the endpoints of the connections (domains) canuniquely fingerprint its initiation eg Amazon sub-app connects to4 unique endpoints with 8 consecutive HTTPS requests in the firstfew seconds after it is launched In our research we sampled 8 high-profile sub-apps in Wechat and identified the sequences of theircommunication endpoints as observed when they are triggered (seeTable 8 in Appendix) Through this side channel a malicious nativeapp is able to infer the launch of a specific sub-app so it can waituntil it is terminated for task recycling (eg after 5 other sub-appsare found to be started through the procfs when the magic numberis 5) to create a task to impersonate the sub-app Note that the mali-cious app can resolve the endpoint domains from IP addresses usingAndroid API InetaddressgetCanonicalHostName [81] withoutrequiring any permission which was implemented and confirmedin our study

Until April 2020 84 of the Android devices are still runningAndroid 9 or earlier versions [33] and therefore are vulnerable toour attack On Android 10 which was released in September 2019the procfs used in our attack has been closed by SEAndroid [70 83]and thus the attack is ineffective Seeking a more powerful attackavenue is left to the future research

4 APINA FLAWS IN THEWILDIn this section we report a measurement study that reveals thescope and magnitude of APINA flaws in the wild The study ismade possible by an automatic analysis tool we built called Apinat(short for App-in-app Threat Scanner) which helped us identifyapp-in-app hosts that are susceptible to APINA flaws

41 Identifying System Resource ExposureDesign Apinat aims to find System Resource Exposure flaws byidentifying escaped sub-app API The idea is to find sub-app APIthat is unprotected by sub-app permission while its correspondingsystem API is permission-protected A naive idea is to call eachsub-app API and find out whether the OS checks the permissions ofthe host app eg by looking at permission pop-ups or system logsThis does not work because the permission asked by the OS can berelated to the host apprsquos own rich functionalities not the sub-appAPI To systematically find escaped sub-app API our methodologytracks the system API invocations triggered by a sub-app API via

a dynamic analysis (Step S1 S2) and then utilizes system API-permission maps to derive required permissions of the sub-appAPI (Step S3) which will be compared to the corresponding sub-app permission If a sub-app API is not protected by any sub-apppermission while its corresponding system APIs are guarded by theAndroid dangerous permissions5 or iOS entitlements an escapedsub-app API is found (Step S4) Following we describe how thisdesign works and how it was implemented in our research onAndroid Since sub-app APIs are cross-platform we were able toextend all the findings made by our technique from Android to iOSby simply validating these findings on the Apple platformStep S1 generating test cases To conduct a dynamic analysis wefirst need to generate test cases with valid arguments to invoke eachsub-app API without triggering exceptions For each API we targetthat at least one invocation is successful The argument types ofJavaScript APIs are either primitive or Object [21] To produce testcases for primitive arguments we leveraged Mozillarsquos funfuzz [22]a JavaScript toolkit ForObject arguments we recursively generatedtest cases leveraging funfuzz because an Object includes keyvaluepairs its key is primitive and the value is either primitive or ObjectAll test cases were then used by a sub-app we built to invoke sub-app APIs If all test cases for an API failed we manually inspectedthe API to address the issues such as formatted inputs (eg UUID)stateful calls (an API needs to be invoked before another) etcStep S2 tracking system API As mentioned in Section 21 theexecution of a sub-app API enters the native layer of the hostthrough a dispatcherdispatch function and then its controlflow reaches system APIs (Figure 1) Therefore Step S2 first iden-tifies the dispatcherdispatch function in the host apprsquos nativelayer then tracks its call graph to find the system APIs triggeredby the sub-app API call as elaborated below

(1) Find the dispatcherdispatch function in the native layer Asmentioned earlier Webview and React Native are bridge techniquesto expose dispatcherdispatch to JavaScript layer Note thatthough the object alias (dispatcher) and function name (dispatch)vary across host apps they can be obtained by inspecting functioninvocations in Encapsulation lib (Figure 1) which is a preprocess-ing step in our study Note that the Encapsulation lib usually canbe found in JavaScript files packaged in the host app (eg underassets folder) So all we need is to identify the dispatcher objectin the native layer based on the obtained alias

To this end S2 implements an Xposed [7] (a framework to in-strument Android app execution) module to hook Webview APIaddJavascriptInterface(obj alias) (that exposes Java objectto JavaScript through an alias) and inspect its arguments at run-time if the ldquoalias argumentrsquos value matches the dispatcher aliasdiscovered the ldquoobj is the dispatcher object that we are lookingfor The analysis of React Native bridge is slightly different wehook its API createNativeModules to get its Java objects exposedto JavaScript our Xposed module then calls each exposed objectrsquosgetNamemethod to get its alias ndash if this alias matches the dispatcheralias discovered the object is what we are looking for

5Host apps are typically third-party apps that cannot call privileged system APIs pro-tected by ldquosignature or ldquosignatureOrSystem level permissions [65] or they typicallydo not delegate the access to such APIs through sub-app APIs

8

(2) Track execution of the dispatcherdispatch function Our toolthen tracks the call graph of the dispatch function to find the calledsystem APIs ndash which are called to fulfill the sub-app API call Specif-ically our Xposed module hooks dispatch function and AndroidAPI and inspects their respective call stack traces However wefound that dispatchrsquos thread sometimes does not call Android APIsdirectly it triggers additional thread to call Android APIs likelyfor not to block the dispatch thread This introduces a challengeXposed outputs the above two stack traces by threads ndash one stacktrace with Android API call and the other with dispatch functioncall ndash but cannot correlate two threads if one triggers the otherTherefore we still cannot confirm that the Android APIs are in-voked due to dispatch Hence we developed techniques to deal withthe multi-threading challenge

In our study we found that Handler a typical multi-threadingmechanism of Android is commonly used by dispatchrsquos thread totrigger a new thread Thus we implemented our own thread corre-lation technique based on the Handler mechanism in our Xposedmodule More specifically in the Handlermechanism a triggeringthread that holds a handler instance will submit a runnable to amessage queue via calling the handlerpost(runnable) methodHere the runnable is an instance of Java Runnable [3] with codein its run() method Then the runnable is taken out of the queueby another thread which we name as the handler thread andgets executed in the handler thread Hence as checked in ourXposed module if the executed runnable in a handler thread isthe same instance with one submitted by a triggering thread thenwe correlate the two threads Through such techniques we foundAndroid APIs are indeed called in such handler thread followingthe dispatch threadrsquos triggering ndash this confirms the Android APIcall caused by the dispatcherdispatch functionStep S3 synthesizingAPI-permissionmapping As mentionedin Section 31 system API-permission mappings are incompletewhich can lead to escaped sub-app APIs How to derive a completemapping remains an open question in system security researchand program analysis Here our idea is to supplement recent map-pings [35 46] leveraging documentation analysis we automaticallyextract explicitly declared permissions for system APIs in the devel-oper manuals assuming that explicit specification at least reflectsintended protection of the OS with rare faults Note that certainportion of the documentation (Figure 2) can be misleading to hu-man readers due to incomplete presentation but we observed thatan exhaustive machine-based search on the whole corpus of mobileOSes (eg the entire documentation for all 2497 SDK classes of An-droid API level 27) can help us derive a significantly more completemapping than state-of-the-art mappings [35 46] (see evaluationbelow) For instance after a full scan of Android WifiManager man-ual [75] we were able to flag ACCESS_FINE_LOCATION as a requiredpermission for multiple Wi-Fi scan related APIs (see Figure 8 inAppendix) which has never been included in state-of-the-art map-pings [35 46]

In our implementation we developed a Web crawler to fetchall manuals from Android developer portal [62] and extractedthe description for each public API From the description we ex-tracted the declared permissions based on a few key observations

if the description of an API does not contain a ldquopermission key-word it is very likely that the API does not explicitly requirepermissions otherwise its description usually includes a ldquoper-mission keyword and the exact permission string constants de-fined in Android class androidManifestpermission [77] suchas ACCESS_FINE_LOCATION Based on such observation we per-formed a light-weight string matching to find explicit permissionrequirement of Android APIs (we discuss the sophisticated NLP-based direction in Section 5)

Step S3 also derives a sub-app API-permission map given itsrelatively small size (ie 50 to 172 sub-app APIs in each host com-pared to 35847 public Android APIs found by our Web crawler)we extracted the map by searching ldquopermission related keywordsin sub-app developer manual and manually confirmed the resultStep S4 reporting flaws S4 reports an escaped sub-app API if itis not protected by sub-app permission while its correspondingAndroid API(s) is protected by dangerous permission(s) That is aSystem Resource Exposure flaw is found

For iOS however a comprehensive detection is much more dif-ficult than Android especially because obtaining a system API-entitlement mapping is much more challenging First we are notaware of any work that has produced a mapping on iOS for us tostart with Second we observed that iOS documentation is not asprecise as Android in this regard which describes required enti-tlements for iOS classes but not for individual system API To stillhelp us understand the impact of escaped sub-app API on iOS weextended our findings of escaped sub-app API from Android to iOSif its corresponding iOS API requires an entitlement it is consideredto affect iOS as well This was done by manually searching corre-sponding iOS API for a given escaped sub-app API and checkingwhether any entitlement is asked when the iOS API is invoked inan iOS app we builtEvaluation We evaluated the effectiveness and performance of ouranalysis tool (source code released [12]) on a Google Pixel 2 phoneand iPhone 8 against 11 host apps The evaluation was performedon three Android versions (81 9 10 corresponding to API level 2728 29) and two iOS versions (12 134)bullOverall detection resultsApinat found 39 System Resource Exposureflaws all of them affect Android 81 9 and 10 13 of them affectiOS 12 and 134 We manually validated that all discovered flawsare true in two steps (1) confirming that the sub-app API requiresno sub-app permission through a testing sub-app (2) confirmingthat the corresponding system API(s) has permission protectionthrough a testing native app on Android and iOSbull Evaluating individual steps Step S1 generated test cases for all927 sub-app APIs under test in less than one hour All sub-app APIswere successfully invoked at least once without exception on eachAndroid version In this experiment we did not measure the hostrsquoscode coverage because the host includes implementation of its ownrich functionalities that are unrelated to sub-app API Thus it is notmeaningful to compute the percentage of covered host app code

Step S2 took less than 30 seconds for each sub-app API to reportits corresponding system APIs on each Android version The num-ber of system APIs (protected by dangerous permissions) hookedby S2 is 111 129 145 on the three Android versions respectivelyTo evaluate the correctness of our thread correlation we created

9

a test app which triggered new threads leveraging the Handlermechanism Our test showed that our tool correctly correlated thetriggering and triggered threads on each Android version

Step S3 produced the API-permission mapping including 94public APIs protected by dangerous permissions at API level 27103 APIs at API level 28 and 119 at API level 29 This step took ourapproach three hours to process the descriptions of 35847 42302and 44323 public APIs on the three API versions respectively Tovalidate the correctness of the mapping we constructed a test app toinvoke all the APIs and verify the required permissions at runtimeFor all three Android versions our permission mapping of all except6 APIs are correct Specifically the mapping of 92 APIs out of 94is correct (979 precision) at the API level 27 The two false casesare unprotected APIs hasPermission and requestPermission inclass UsbManager [66] At API 28 the mapping shows a precisionof 971 with one new false case than what was found on API 27(3 cases in total) API 29 shows a precision of 95 with three newcases than API 28 (6 cases in total) Figure 6 and 7 in Appendixlist all six false cases Their descriptions are more complex and weenvision that a natural language processing (NLP) based approachcan further improve our precision (see discussion in Section 5)

To evaluate the coverage of our documentation analysis toolwe randomly selected the documentation of 153 classes 641 APIs(out of 2164 classes) and then manually reviewed and identified52 API-permission mappings as the ground truth Running on theaforementioned documentation our analysis tool shows a precisionof 100 and a recall of 100 to identify API-permission mappingfrom the documentation

We also compared the completeness of our mapping with recentmappings [35 46] They collectively reported 50 public AndroidAPIs that require dangerous permissions on API level 25 (we werenot able to get results of newer Android from the authors) as asignificant improvement our tool was able to find 91 APIs (82more) that require dangerous permissions on the same API versionDiscussion Apinat may not find all escaped sub-app APIs In par-ticular Step S3 cannot derive a complete mapping if the documen-tation is incomplete [56] or too sophisticated to process Apinatonly looks for system resource exposure by public system APIs andundocumented system APIs used by host apps may also lead to theflaw but remain undetected Also Apinat falls short in analyzingobfuscated host apps eg that uses dynamic code loading andimplementations in CC++ Hence Apinat did not scan Web AppAPIs due to the extensive CC++ implementation in browsers Inaddition incorrect documentation (which we assume is rare andindeed our tool did not report any false escaped sub-app API ) mightlead to false alarms if not properly validated

42 Finding UI Deception FlawsDesign To find out the opportunities for Sub-window Deception(Section 32) in a host app Apinat looks for the apprsquos sensitive sub-windows which can be the targets of the attack As discovered inthe wallet UI confusion (Figure 4b) the hostrsquos sub-windows thatare likely to show up in the presence of a sub-app tends to be thosethat can be triggered through sub-app APIs If such a sub-windowalso contains sensitive information our approach then reports it asa potential target for Sub-window Deception

Implementation To detect such sub-windows Apinat monitorsthe change of the host UI in response to each sub-app API callto identify the sub-window triggered by the API call and thendetermines whether it carries sensitive content Specifically ourapproach first constructs a testing sub-app with an empty UI Thenit runs the sub-app API test cases in Section 41 to call each sub-appAPI through the testing sub-app and further inspects the UI screen-shots before and after the call for changes This is done through apixel-to-pixel comparison of two screenshots To capture the screen-shots we developed a screen projection service on Android usingthe Media Projection [63] API Also our screenshot compari-son was implemented using the OpenCV cv2absdiff API [85]For each sub-window identified our approach continues to findthose associated with sensitive information For this purpose itextracts strings from sub-window screenshots using the onlineOCR service [34] From the strings Apinat further utilizes a list of121 sensitive data keywords and the keyword pair list from recentresearch [91] to recognize those carrying sensitive content Notethat like a mobile OS an app-in-app system also provides a set ofsub-app APIs for sub-apps to dynamically generate UI componentssuch as wxcreateCanvasContextdraw() in Wechat To controlfalse positives Apinat omits such sub-app APIs based on the APIcategory in the sub-app API documentation As a result Apinat suc-cessfully detected 6 Sub-window Deception flaws (Section 43) ForiOS we got the same result since sub-app APIs are across-platformthe one triggers a sub-window on one OS also does that on theother (see Section 2)Evaluation Apinat detected 5 sub-app APIs associated with the UIdeception flaw we manually confirmed that all of them trigger sub-windows with sensitive information Also all of them affect bothAndroid (version 81 9 10) and iOS (version 12 134) Performance-wise the screenshot comparison and OCR analysis together tookless than 5 seconds on a desktop with Intel i5 27 GHz CPU and 8GB memoryDiscussion Soundly detecting whether a host app is susceptibleto Sub-app Lifecycle Hijacking (Section 33) is difficult especiallybecause it entails detection of side-channel information leakagewhich can happen in many ways and is hard to capture in generalTo measure a lower bound of the pervasiveness of the problemwe checked whether the hosts in our study (Table 1) had the sameinformation leakage and lifecycle design as reported in Section 33As a result 3 host apps on Android (Wechat Alipay DingTalk) aresusceptible which were all manually confirmed to be exploitable

43 Measurement of ImpactFlaw landscape With the help of Apinat we analyzed 11 highlypopular host apps (Table 1) on Android and iOS and found theyare all vulnerable to APINA flaws (Table 3) Altogether we found 52APINA flaws including 39 System Resource Exposure 10 Sub-windowDeception and 3 hosts vulnerable to Sub-app Lifecycle Hijacking

For System Resource Exposure in total we uncover 39 escaped sub-app APIs associated with 5 categories of exposed system resources4 Android dangerous permissions and 6 iOS entitlements Table 5shows the flaw number for each category of resources (the secondcolumn) and illustrates 8 escaped sub-app APIs with correspondingAndroid permission(s) and iOS entitlement(s) ignored to enforce

10

Table 3 Eleven vulnerable host apps on Android and iOS(A Alipay B Baidu C Chrome D DingTalk F FirefoxJJinRiTouTiao O Opera Q QQ S Safari T TikTok WWechat) NA denotes the flaw does not apply to the OS

Type of APINA Flaw iOS AndroidSystem Resource Exposure A D J Q T W A D J Q T WSub-window Deception A B D W S Q A B C D F W O QSub-app Lifecycle Hijacking NA A W Q

on them All 39 escaped sub-app APIs are listed in our releaseddataset [12] Also Table 6 illustrates 6 Sub-window Deception in non-browser hosts additionally all four browsers we studied (ChromeSafari Firefox Opera) are susceptible to the same Prominent UIattackResource comparison between Android and iOS Althoughfinding the full API-entitlement mapping for iOS is hard we ob-served a few differences between Android and iOS in system re-source protectionbull iOS is less affected than Android Out of 39 escaped sub-app APIs13 are related to iOS which appears to be less affected and harderto be exploited There are two reasons behind the observation asdiscovered in our study First certain iOS APIs return less informa-tion than its Android counterparts (ie those related to Bluetoothsee Section 31) and thus is less susceptible to privacy risk (locationleakage) Hence all 27 Bluetooth related escaped sub-app APIs donot affect iOS (see Table 5) Second WiFi related escaped sub-appAPIs (see Table 5) are much harder to exploit on iOS since Applehas extra protection besides entitlement Specifically right beforethe programmaticWiFi operation an iOS appmust obtain the userrsquosexplicit consent the app must instruct the user to manually openthe WiFi setting page in the Settings app and then return to theiOS app [43] ndash an indicator of user intention for the app to operateWiFibull iOS entitlement fails to communicate risks to the user On Androidwhen the permission ACCESS_FINE_LOCATION is used for protect-ing the operation Wi-Fi scan it indicates a risk that the WiFioperation may leak location a highly private data On iOS how-ever the entitlement for Wi-Fi scan ie Hotspot Helper failsto communicate such a risk Actually to get this entitlement for aniOS app app developers must file a special written request by justi-fying that the app does not have malicious intention Apple reviewsthe request internally and possibly assesses the risks of locationleakage behind the scene However the name of this entitlementand its documentation we could find does not show that Wi-Fiscan needs location protection on iOS This may have been oneof the factors leading to escaped sub-app API wxgetWifiList (seeTable 5) which performs Wi-Fi scan without protectionAttack consequences The system resources exposed by escapedsub-app API and the risks can be identified from the API namesand the permissions they violate (see Table 5) For example unautho-rized sub-apps can use escaped sub-appAPI wxgetRecorderManag-er to record audio (violating Androidrsquos RECORD_AUDIO permission)We summarize the attack consequences in Table 4 Further Sub-window Deception leads to phishing on popular Web services (egFacebook) mobile wallets and sensitive host UIs For exampleWechat has a UI triggered by sub-app API (wxaddPhoneContact)

Table 4 Examples of APINA attack consequences

Flaw Type Consequences (what the adversary is able to do)

SystemResourceExposure

record audio operate camerainfer victimsrsquo geo-location (thus track users)

connect victimrsquos device to arbitrary Wi-Fi (thus manipulatenetwork traffic perform man-in-the-middle (MITM) or phishing)

and steal sensitive QR code etcSub-windowDeception

steal account credentials on Facebook Google Amazon etcsteal mobile wallet passwords contacts etc

Sub-appLifecycleHijacking

steal money (payments in shopping sub-app)steal personal secrets (eg answers tosecurity questions health records etc)

steal business documents (from a document processingand management sub-app published by Microsoft)

steal account credentials of Amazon ICBCCCB HSBC (1st 2nd 7th largest banks in the world)

Airbnb Weibo Starbucks McDonaldrsquos etc

for users to enter contact information (Table 6) attacking this UImay leak contacts which are highly private Last Sub-app LifecycleHijacking affects three hosts (Table 3) and the risks come fromimitating sub-apps supported by these hosts such as sub-apps forAmazon health banking Airbnb etc (see Table 4)Cases Studies We discuss a few other problems we observed inapp-in-app ecosystembull Keeping up with the OS evolution Sub-app API permission policyshould keep up as the OS always evolves newer OS version oftenintroduces more strict protection against sensitive resources Forexample since Android 10 an app that accesses location in the back-ground needs an additional dangerous permission ACCESS_BACKGRO-UND_LOCATION in addition to the regular location permission [82]This protects user location against illicit tracking However sub-app API for accessing location in hosts TikTok and Alipay did notkeep up with such a new protection thus leaving their users at risk

As another example for the WiFi and Bluetooth scan that canleak location Android 9 and 10 require ACCESS_FINE_LOCATIONpermission while Android 81 is less restrictive and ACCESS_COARSE_LOCATION is sufficient (see Table 5) Note that Android uses the firstpermission to control access to precise location (eg GPS data)and uses the second one for coarse-grained positioning (with anaccuracy approximately at the level of a city block [10]) Interest-ingly all hosts we studied only define a general location sub-apppermission to govern location API (eg scopeuserLocation inWechat) but do not differentiate the two levels of accuracybull Too many APIs for one permission APIs of apparently differentfunctionalities should never be governed by the same permissionHowever in the host TikTok (an extremely popular short-videosharing app with more than 500million downloads on Google Play)three sub-appAPIs ttscanCode ttchooseImage and ttchoos-eVideo (for scanning QR code accessing photos and videos) aregoverned by the same permission scopecamera and thus inade-quately protected For example a malicious sub-app that is grantedpermission by the user to scan QR code also behind the scenesilently gets access to API ttchooseImage that accesses user pho-tos posing a serious privacy risk

5 LESSONS AND MITIGATION STRATEGYLessons learned The most important lesson learnt from our re-search is the caution one should take when building a third-party

11

Table 5 Summary of System Resources Exposure flaws (NA means the flaw does not affect the OS)

SystemResourceExposed

of

FlawsExample of Escaped

Sub-app API Dangerous Permission Android API Entitlement iOS Class

Microphone 1 WechatwxgetRecorderManager RECORD_AUDIO mediaMediaRecorder

CaptureRequest Microphone Usage AVAudioRecorder

Camera 3 Alipay myscan CAMERA CameraManageropen-CameraCaptureRequest Camera Usage AVCaptureSession

Wi-Fi 4WeChatwxgetWifiList

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetScanResults Hotspot Helper dagger NEHotspotHelper

JinRiTouTiaoTikTokttgetConnectedWifi

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetConnectionInfo Access WiFi Information dagger CNCopyCurrent-

NetworkInfo

Bluetooth 27

Alipay mystartBluetoothDevicesDiscovery

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan NA NADingTalk

ddgetBluetoothDevicesAlipay

mygetBLEDeviceServices

iBeacon 4 Alipay mygetBeaconsACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan Location Usage CLBeaconRegion

dagger Much harder to exploit on iOS due to the requirement of explicit user approvalDagger Android 9 and 10 require ACCESS_FINE_LOCATION permission while Android 81 requires ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION

Table 6 Examples of Sub-window Deception flaws

Host App Triggering Sub-App API Legitimate (and spoofable)Functionality of the Sub-window

Alipay mytradePay Request password ofAlipay mobile wallet

Baidu swanrequestPolymerPayment Request passwords ofmultiple mobile wallets

DingTalk ddpay Request password ofAlipay mobile wallet

WechatwxaddPhoneContact Enter new contacts

wxrequestPayment Request password ofWechat mobile wallet

QQ new in-app message Display instant messagesand enter a reply

sub-ecosystem on top of the operating system In such a case thethird-party OS-like app strives to provide a secure self-containedenvironment However whether it undermines OS security andbrings in new risks to modern mobile applications need to be eval-uated to identify the security gap between the new sub-ecosystemand the OSes Our measurement study shows that popular host appsare generally susceptible to APINA flaws indicating that the app-in-app system vendors today either fail to identify or are unpreparedfor the new risks

Fundamentally APINA risks come from the limited app-levelcapabilities the host app has in managing OS resources lack ofOS-level support and missing of sub-app API standard Hencedown the road it will require non-trivial joint efforts to fundamen-tally eliminate APINA risks More specifically escaped sub-app APIshows that a third-party host fundamentally lacks the full OS-levelknowledge on system resource protection While such knowledgecan come from different sources eg program analysis on relevantOS modules [35 46] developer documentations technical reportsetc each source only contributes a partial view Hence joint effortsneed to be made in the future to synthesize such knowledge Ourstudy also brings to light that such efforts are by no means trivialndash even the two leading mobile OSes have apparently confusingconflicting security policies Synthesizing such a knowledge base

will not only benefit the app-in-app paradigm but also make theOSrsquo security mechanism more transparent for thorough auditing

Our findings also highlight that prior OS lessons cannot fullyeliminate new risks incurred by the new paradigm which necessi-tates thorough assessment regarding its new attack surfaces Forexample a malicious sub-app a sub-window and a task in Recentsscreen all come as new attack vectors that pose credible new threatsto usersrsquo most sensitive credentials and privacyMitigation strategy Following we propose the short-term miti-gation and discuss the long-term strategybull Escaped Sub-app API Eliminating the risk requires the host tohave full OS-level knowledge about resource control (eg API-permission mapping) which is difficult In the meantime our toolApinat together with our API-permission mapping (released on-line [12]) can help host app vendors identify escaped sub-app APIsNote that since Apinat can identify escaped sub-app API with itsignored permissions with respect to specific OS version (see Sec-tion 43) host vendors may leverage our tool to assess whether theirsub-app API permission policy is always compliant with newly re-leased OS version and thus keep up the pace

Further we envision two possible future directions that couldlead to more viable solutions First as demonstrated by our anal-ysis tool Apinat although it is hard for todayrsquos program analy-sis techniques to derive a complete system API-permission map-ping [35 46] we could significantly improve its accuracy and com-prehensiveness through developer documentation analysis Ourcurrent documentation analysis is rather preliminary but still effec-tive as demonstrated in our study (Section 4) Down the road wecould develop natural language processing (NLP) based techniquesfor deriving more complete knowledge about API permission poli-cies With the techniques an analysis could cover a wider spectrumof literature including iOS documents research papers technicalreports etc which will help derive up-to-date knowledge aboutresource-management policies

Second the app-in-app community should work together tostandardize sub-app APIs and their permission policies as donein the HTML5 community on HTML5 APIs For the time being

12

different app-in-app vendors bring in their own APIs for accessinga wide spectrum of systems resources (see our comparison betweensub-app API and HTML5 API in Table 7 in Appendix) often withoutproper safeguard in place not to mention any effort to standardizethe protectionbull Sub-window deception The risk comes from the UI confusionwhether a window portion in the sub-app window belongs to thesub-app or the host (Figure 3b) To mitigate the risk we envision ahigher degree of UI isolation between the sub-app and the host thesub-apprsquos window should always be separated from that of the hostand the host should never reclaim any window portion from thesub-applsquos window Regarding the Wallet UI confusion (Section 32)for example Wechat should display its wallet UI only in its ownwindow and advertise to users that any UI component inside thesub-app window belongs to the sub-app

A question arises whether a malicious sub-app can fake a crashand then show spoofing content in the sub-app window to resem-ble the host This can be mitigated through additional protectionsupported by the host Specifically the host app could keep mon-itoring the UI of its sub-apps (eg through PixelCopy API onAndroid [71]) to detect whether a UI object in the sub-app is similarto a sub-window or a security-sensitive UI object associated withhost app For performance concern the host app could utilize thestate-of-the-art object detection model (eg Fast Region-based Con-volutional Network based model [61] and YOLO [32 95]) for thereal-time security-sensitive UI object recognition as reported inprior research [95] Fast YOLO yields the performance of 155 framesper second Note that the effectiveness efficiency and deploymentfeasibility of such an approach need to be carefully explored andevaluated which we leave for our future researchbull Sub-app lifecycle hijacking To mitigate this risk a short-termdefense is to place all sub-app resources in the phonersquos internalstorage so our current exploit (leveraging monitoring the phonersquosexternal storage) to track sub-app lifecyle termination (Section 33)can be mitigated However it is always a concern that sub-appsmay deplete the limited space on a phonersquos internal storage Along term solution needs to consider how to make the sub-apptasks dynamically scalable to ensure that the sub-app recycling isno longer traceable and thus the attack surface is fundamentallyeliminated This nonetheless calls for support from modern OSesfor the emerging app-in-app paradigm

6 RELATEDWORKAs mentioned in Section 2 recent years witnessed several tech-niques to support the functionality of app encapsulation (eg Plu-gin frameworks app sandboxing browser extension and PhoneGapapp see Table 2) Accordingly numerous studies have looked intothe flaws in these app encapsulation systems considering the se-curity analysis of Plugin frameworks a set of flaws were revealed[99 111 112] including no permission management and no isola-tion of the virtualized apps Compared with Plugin frameworks theapp-in-app paradigm has a much stronger security model and ourstudy investigates the design challenges and pitfalls in the securitymechanism Meanwhile the security and privacy implications ofbrowser extensions have been extensively studied [48 54 84 98]

Furthermore the current security studies on PhoneGap apps fo-cus on the flaws of PhoneGap frameworkrsquos access control policy[60 90 100 101] For example Song et al [101] revealed that thebridges added by the framework to the browser are not correctlyprotected by the same origin policy Jin et al [86] introduced mul-tiple channels (eg barcode SMS file system Contact) for codeinjection attacks in PhoneGap apps Different from these works wefocus on the unique features of the app-in-app paradigm (Table 2)and reveal multiple new attack surfaces which have never beenstudied before

The closer to our study are the works of Web App and WebViewvulnerability assessment Up to our knowledge only one paper[87] analyzed security issue of Web App in which the securityand privacy risks on HTML5 features in PWA were investigatedIn our attack on Web App we did not focus on HTML5 featuresbut a general UI isolation and management model in app-in-appparadigm Also although WebView technique is used in some ofthe app-in-app systems in sharp contrast to the works on Webviewweaknesses [36 60 88 102 105 109 110] our study explores thesecurity implications and challenges for a third-party app tomanageoperating system resources Another set of works related to ourstudy is the exploitation of mobile UI deception Prior phishingattacks [38 49 53 57 97] mislead victims about the foregroundapp aiming at information theft in spoofing apps Correspondingcountermeasures [49 58 96] emphasize identifying the app of thewhole foreground window and thus cannot thwart Sub-windowDeception due to the inability to identify sub-windows Furtheranother angle of UI deception is clickjacking [59 94] which aredifferent from our mobile-phishing attacks7 CONCLUSIONIn this paper we present the first systematic security analysis on re-source management in high-profile app-in-app systems Our studyshows that such systems are susceptible to a set of serious securityflaws Our measurement study further sheds light on their perva-siveness in the real-world Further our study brings in new insightsinto the fundamental security limitations of this new paradigm andfurther contributes to a better understanding of its mitigation strat-egy an important step towards building a more secure app-in-appecosystem

8 ACKNOWLEDGMENTWe would like to thank our shepherd Yanick Fratantonio and theanonymous reviewers for their insightful comments This work issupported in part by the NSF CNS-1618493 1801432 1838083

REFERENCES[1] 2011 HTML5 Fullscreen API Attack httpsferossorghtml5-fullscreen-api-

attack[2] 2011 The Inception Bar httpsjameshfishercom20190427the-inception-

bar-a-new-phishing-method[3] 2018 Java Runnable httpsdocsoraclecomjavase7docsapijavalang

Runnablehtml[4] 2018 A one year PWA retrospective httpsmediumcompinterest-

engineeringa-one-year-pwa-retrospective-f4a2f4129e05[5] 2018 Wechat 1 million sub-apps httpswwwscmpcomtecharticle2153705

tencents-wechat-now-host-1-million-mini-programs[6] 2018 WeChat reaches 1M sub-apps half the size of Applersquos App Store https

techcrunchcom20181107wechat-mini-apps-200-million-users[7] 2018 Xposed httpsapixposedinforeferencepackageshtml[8] 2019 AdBlock httpsgetadblockcom

13

(2) Track execution of the dispatcherdispatch function Our toolthen tracks the call graph of the dispatch function to find the calledsystem APIs ndash which are called to fulfill the sub-app API call Specif-ically our Xposed module hooks dispatch function and AndroidAPI and inspects their respective call stack traces However wefound that dispatchrsquos thread sometimes does not call Android APIsdirectly it triggers additional thread to call Android APIs likelyfor not to block the dispatch thread This introduces a challengeXposed outputs the above two stack traces by threads ndash one stacktrace with Android API call and the other with dispatch functioncall ndash but cannot correlate two threads if one triggers the otherTherefore we still cannot confirm that the Android APIs are in-voked due to dispatch Hence we developed techniques to deal withthe multi-threading challenge

In our study we found that Handler a typical multi-threadingmechanism of Android is commonly used by dispatchrsquos thread totrigger a new thread Thus we implemented our own thread corre-lation technique based on the Handler mechanism in our Xposedmodule More specifically in the Handlermechanism a triggeringthread that holds a handler instance will submit a runnable to amessage queue via calling the handlerpost(runnable) methodHere the runnable is an instance of Java Runnable [3] with codein its run() method Then the runnable is taken out of the queueby another thread which we name as the handler thread andgets executed in the handler thread Hence as checked in ourXposed module if the executed runnable in a handler thread isthe same instance with one submitted by a triggering thread thenwe correlate the two threads Through such techniques we foundAndroid APIs are indeed called in such handler thread followingthe dispatch threadrsquos triggering ndash this confirms the Android APIcall caused by the dispatcherdispatch functionStep S3 synthesizingAPI-permissionmapping As mentionedin Section 31 system API-permission mappings are incompletewhich can lead to escaped sub-app APIs How to derive a completemapping remains an open question in system security researchand program analysis Here our idea is to supplement recent map-pings [35 46] leveraging documentation analysis we automaticallyextract explicitly declared permissions for system APIs in the devel-oper manuals assuming that explicit specification at least reflectsintended protection of the OS with rare faults Note that certainportion of the documentation (Figure 2) can be misleading to hu-man readers due to incomplete presentation but we observed thatan exhaustive machine-based search on the whole corpus of mobileOSes (eg the entire documentation for all 2497 SDK classes of An-droid API level 27) can help us derive a significantly more completemapping than state-of-the-art mappings [35 46] (see evaluationbelow) For instance after a full scan of Android WifiManager man-ual [75] we were able to flag ACCESS_FINE_LOCATION as a requiredpermission for multiple Wi-Fi scan related APIs (see Figure 8 inAppendix) which has never been included in state-of-the-art map-pings [35 46]

In our implementation we developed a Web crawler to fetchall manuals from Android developer portal [62] and extractedthe description for each public API From the description we ex-tracted the declared permissions based on a few key observations

if the description of an API does not contain a ldquopermission key-word it is very likely that the API does not explicitly requirepermissions otherwise its description usually includes a ldquoper-mission keyword and the exact permission string constants de-fined in Android class androidManifestpermission [77] suchas ACCESS_FINE_LOCATION Based on such observation we per-formed a light-weight string matching to find explicit permissionrequirement of Android APIs (we discuss the sophisticated NLP-based direction in Section 5)

Step S3 also derives a sub-app API-permission map given itsrelatively small size (ie 50 to 172 sub-app APIs in each host com-pared to 35847 public Android APIs found by our Web crawler)we extracted the map by searching ldquopermission related keywordsin sub-app developer manual and manually confirmed the resultStep S4 reporting flaws S4 reports an escaped sub-app API if itis not protected by sub-app permission while its correspondingAndroid API(s) is protected by dangerous permission(s) That is aSystem Resource Exposure flaw is found

For iOS however a comprehensive detection is much more dif-ficult than Android especially because obtaining a system API-entitlement mapping is much more challenging First we are notaware of any work that has produced a mapping on iOS for us tostart with Second we observed that iOS documentation is not asprecise as Android in this regard which describes required enti-tlements for iOS classes but not for individual system API To stillhelp us understand the impact of escaped sub-app API on iOS weextended our findings of escaped sub-app API from Android to iOSif its corresponding iOS API requires an entitlement it is consideredto affect iOS as well This was done by manually searching corre-sponding iOS API for a given escaped sub-app API and checkingwhether any entitlement is asked when the iOS API is invoked inan iOS app we builtEvaluation We evaluated the effectiveness and performance of ouranalysis tool (source code released [12]) on a Google Pixel 2 phoneand iPhone 8 against 11 host apps The evaluation was performedon three Android versions (81 9 10 corresponding to API level 2728 29) and two iOS versions (12 134)bullOverall detection resultsApinat found 39 System Resource Exposureflaws all of them affect Android 81 9 and 10 13 of them affectiOS 12 and 134 We manually validated that all discovered flawsare true in two steps (1) confirming that the sub-app API requiresno sub-app permission through a testing sub-app (2) confirmingthat the corresponding system API(s) has permission protectionthrough a testing native app on Android and iOSbull Evaluating individual steps Step S1 generated test cases for all927 sub-app APIs under test in less than one hour All sub-app APIswere successfully invoked at least once without exception on eachAndroid version In this experiment we did not measure the hostrsquoscode coverage because the host includes implementation of its ownrich functionalities that are unrelated to sub-app API Thus it is notmeaningful to compute the percentage of covered host app code

Step S2 took less than 30 seconds for each sub-app API to reportits corresponding system APIs on each Android version The num-ber of system APIs (protected by dangerous permissions) hookedby S2 is 111 129 145 on the three Android versions respectivelyTo evaluate the correctness of our thread correlation we created

9

a test app which triggered new threads leveraging the Handlermechanism Our test showed that our tool correctly correlated thetriggering and triggered threads on each Android version

Step S3 produced the API-permission mapping including 94public APIs protected by dangerous permissions at API level 27103 APIs at API level 28 and 119 at API level 29 This step took ourapproach three hours to process the descriptions of 35847 42302and 44323 public APIs on the three API versions respectively Tovalidate the correctness of the mapping we constructed a test app toinvoke all the APIs and verify the required permissions at runtimeFor all three Android versions our permission mapping of all except6 APIs are correct Specifically the mapping of 92 APIs out of 94is correct (979 precision) at the API level 27 The two false casesare unprotected APIs hasPermission and requestPermission inclass UsbManager [66] At API 28 the mapping shows a precisionof 971 with one new false case than what was found on API 27(3 cases in total) API 29 shows a precision of 95 with three newcases than API 28 (6 cases in total) Figure 6 and 7 in Appendixlist all six false cases Their descriptions are more complex and weenvision that a natural language processing (NLP) based approachcan further improve our precision (see discussion in Section 5)

To evaluate the coverage of our documentation analysis toolwe randomly selected the documentation of 153 classes 641 APIs(out of 2164 classes) and then manually reviewed and identified52 API-permission mappings as the ground truth Running on theaforementioned documentation our analysis tool shows a precisionof 100 and a recall of 100 to identify API-permission mappingfrom the documentation

We also compared the completeness of our mapping with recentmappings [35 46] They collectively reported 50 public AndroidAPIs that require dangerous permissions on API level 25 (we werenot able to get results of newer Android from the authors) as asignificant improvement our tool was able to find 91 APIs (82more) that require dangerous permissions on the same API versionDiscussion Apinat may not find all escaped sub-app APIs In par-ticular Step S3 cannot derive a complete mapping if the documen-tation is incomplete [56] or too sophisticated to process Apinatonly looks for system resource exposure by public system APIs andundocumented system APIs used by host apps may also lead to theflaw but remain undetected Also Apinat falls short in analyzingobfuscated host apps eg that uses dynamic code loading andimplementations in CC++ Hence Apinat did not scan Web AppAPIs due to the extensive CC++ implementation in browsers Inaddition incorrect documentation (which we assume is rare andindeed our tool did not report any false escaped sub-app API ) mightlead to false alarms if not properly validated

42 Finding UI Deception FlawsDesign To find out the opportunities for Sub-window Deception(Section 32) in a host app Apinat looks for the apprsquos sensitive sub-windows which can be the targets of the attack As discovered inthe wallet UI confusion (Figure 4b) the hostrsquos sub-windows thatare likely to show up in the presence of a sub-app tends to be thosethat can be triggered through sub-app APIs If such a sub-windowalso contains sensitive information our approach then reports it asa potential target for Sub-window Deception

Implementation To detect such sub-windows Apinat monitorsthe change of the host UI in response to each sub-app API callto identify the sub-window triggered by the API call and thendetermines whether it carries sensitive content Specifically ourapproach first constructs a testing sub-app with an empty UI Thenit runs the sub-app API test cases in Section 41 to call each sub-appAPI through the testing sub-app and further inspects the UI screen-shots before and after the call for changes This is done through apixel-to-pixel comparison of two screenshots To capture the screen-shots we developed a screen projection service on Android usingthe Media Projection [63] API Also our screenshot compari-son was implemented using the OpenCV cv2absdiff API [85]For each sub-window identified our approach continues to findthose associated with sensitive information For this purpose itextracts strings from sub-window screenshots using the onlineOCR service [34] From the strings Apinat further utilizes a list of121 sensitive data keywords and the keyword pair list from recentresearch [91] to recognize those carrying sensitive content Notethat like a mobile OS an app-in-app system also provides a set ofsub-app APIs for sub-apps to dynamically generate UI componentssuch as wxcreateCanvasContextdraw() in Wechat To controlfalse positives Apinat omits such sub-app APIs based on the APIcategory in the sub-app API documentation As a result Apinat suc-cessfully detected 6 Sub-window Deception flaws (Section 43) ForiOS we got the same result since sub-app APIs are across-platformthe one triggers a sub-window on one OS also does that on theother (see Section 2)Evaluation Apinat detected 5 sub-app APIs associated with the UIdeception flaw we manually confirmed that all of them trigger sub-windows with sensitive information Also all of them affect bothAndroid (version 81 9 10) and iOS (version 12 134) Performance-wise the screenshot comparison and OCR analysis together tookless than 5 seconds on a desktop with Intel i5 27 GHz CPU and 8GB memoryDiscussion Soundly detecting whether a host app is susceptibleto Sub-app Lifecycle Hijacking (Section 33) is difficult especiallybecause it entails detection of side-channel information leakagewhich can happen in many ways and is hard to capture in generalTo measure a lower bound of the pervasiveness of the problemwe checked whether the hosts in our study (Table 1) had the sameinformation leakage and lifecycle design as reported in Section 33As a result 3 host apps on Android (Wechat Alipay DingTalk) aresusceptible which were all manually confirmed to be exploitable

43 Measurement of ImpactFlaw landscape With the help of Apinat we analyzed 11 highlypopular host apps (Table 1) on Android and iOS and found theyare all vulnerable to APINA flaws (Table 3) Altogether we found 52APINA flaws including 39 System Resource Exposure 10 Sub-windowDeception and 3 hosts vulnerable to Sub-app Lifecycle Hijacking

For System Resource Exposure in total we uncover 39 escaped sub-app APIs associated with 5 categories of exposed system resources4 Android dangerous permissions and 6 iOS entitlements Table 5shows the flaw number for each category of resources (the secondcolumn) and illustrates 8 escaped sub-app APIs with correspondingAndroid permission(s) and iOS entitlement(s) ignored to enforce

10

Table 3 Eleven vulnerable host apps on Android and iOS(A Alipay B Baidu C Chrome D DingTalk F FirefoxJJinRiTouTiao O Opera Q QQ S Safari T TikTok WWechat) NA denotes the flaw does not apply to the OS

Type of APINA Flaw iOS AndroidSystem Resource Exposure A D J Q T W A D J Q T WSub-window Deception A B D W S Q A B C D F W O QSub-app Lifecycle Hijacking NA A W Q

on them All 39 escaped sub-app APIs are listed in our releaseddataset [12] Also Table 6 illustrates 6 Sub-window Deception in non-browser hosts additionally all four browsers we studied (ChromeSafari Firefox Opera) are susceptible to the same Prominent UIattackResource comparison between Android and iOS Althoughfinding the full API-entitlement mapping for iOS is hard we ob-served a few differences between Android and iOS in system re-source protectionbull iOS is less affected than Android Out of 39 escaped sub-app APIs13 are related to iOS which appears to be less affected and harderto be exploited There are two reasons behind the observation asdiscovered in our study First certain iOS APIs return less informa-tion than its Android counterparts (ie those related to Bluetoothsee Section 31) and thus is less susceptible to privacy risk (locationleakage) Hence all 27 Bluetooth related escaped sub-app APIs donot affect iOS (see Table 5) Second WiFi related escaped sub-appAPIs (see Table 5) are much harder to exploit on iOS since Applehas extra protection besides entitlement Specifically right beforethe programmaticWiFi operation an iOS appmust obtain the userrsquosexplicit consent the app must instruct the user to manually openthe WiFi setting page in the Settings app and then return to theiOS app [43] ndash an indicator of user intention for the app to operateWiFibull iOS entitlement fails to communicate risks to the user On Androidwhen the permission ACCESS_FINE_LOCATION is used for protect-ing the operation Wi-Fi scan it indicates a risk that the WiFioperation may leak location a highly private data On iOS how-ever the entitlement for Wi-Fi scan ie Hotspot Helper failsto communicate such a risk Actually to get this entitlement for aniOS app app developers must file a special written request by justi-fying that the app does not have malicious intention Apple reviewsthe request internally and possibly assesses the risks of locationleakage behind the scene However the name of this entitlementand its documentation we could find does not show that Wi-Fiscan needs location protection on iOS This may have been oneof the factors leading to escaped sub-app API wxgetWifiList (seeTable 5) which performs Wi-Fi scan without protectionAttack consequences The system resources exposed by escapedsub-app API and the risks can be identified from the API namesand the permissions they violate (see Table 5) For example unautho-rized sub-apps can use escaped sub-appAPI wxgetRecorderManag-er to record audio (violating Androidrsquos RECORD_AUDIO permission)We summarize the attack consequences in Table 4 Further Sub-window Deception leads to phishing on popular Web services (egFacebook) mobile wallets and sensitive host UIs For exampleWechat has a UI triggered by sub-app API (wxaddPhoneContact)

Table 4 Examples of APINA attack consequences

Flaw Type Consequences (what the adversary is able to do)

SystemResourceExposure

record audio operate camerainfer victimsrsquo geo-location (thus track users)

connect victimrsquos device to arbitrary Wi-Fi (thus manipulatenetwork traffic perform man-in-the-middle (MITM) or phishing)

and steal sensitive QR code etcSub-windowDeception

steal account credentials on Facebook Google Amazon etcsteal mobile wallet passwords contacts etc

Sub-appLifecycleHijacking

steal money (payments in shopping sub-app)steal personal secrets (eg answers tosecurity questions health records etc)

steal business documents (from a document processingand management sub-app published by Microsoft)

steal account credentials of Amazon ICBCCCB HSBC (1st 2nd 7th largest banks in the world)

Airbnb Weibo Starbucks McDonaldrsquos etc

for users to enter contact information (Table 6) attacking this UImay leak contacts which are highly private Last Sub-app LifecycleHijacking affects three hosts (Table 3) and the risks come fromimitating sub-apps supported by these hosts such as sub-apps forAmazon health banking Airbnb etc (see Table 4)Cases Studies We discuss a few other problems we observed inapp-in-app ecosystembull Keeping up with the OS evolution Sub-app API permission policyshould keep up as the OS always evolves newer OS version oftenintroduces more strict protection against sensitive resources Forexample since Android 10 an app that accesses location in the back-ground needs an additional dangerous permission ACCESS_BACKGRO-UND_LOCATION in addition to the regular location permission [82]This protects user location against illicit tracking However sub-app API for accessing location in hosts TikTok and Alipay did notkeep up with such a new protection thus leaving their users at risk

As another example for the WiFi and Bluetooth scan that canleak location Android 9 and 10 require ACCESS_FINE_LOCATIONpermission while Android 81 is less restrictive and ACCESS_COARSE_LOCATION is sufficient (see Table 5) Note that Android uses the firstpermission to control access to precise location (eg GPS data)and uses the second one for coarse-grained positioning (with anaccuracy approximately at the level of a city block [10]) Interest-ingly all hosts we studied only define a general location sub-apppermission to govern location API (eg scopeuserLocation inWechat) but do not differentiate the two levels of accuracybull Too many APIs for one permission APIs of apparently differentfunctionalities should never be governed by the same permissionHowever in the host TikTok (an extremely popular short-videosharing app with more than 500million downloads on Google Play)three sub-appAPIs ttscanCode ttchooseImage and ttchoos-eVideo (for scanning QR code accessing photos and videos) aregoverned by the same permission scopecamera and thus inade-quately protected For example a malicious sub-app that is grantedpermission by the user to scan QR code also behind the scenesilently gets access to API ttchooseImage that accesses user pho-tos posing a serious privacy risk

5 LESSONS AND MITIGATION STRATEGYLessons learned The most important lesson learnt from our re-search is the caution one should take when building a third-party

11

Table 5 Summary of System Resources Exposure flaws (NA means the flaw does not affect the OS)

SystemResourceExposed

of

FlawsExample of Escaped

Sub-app API Dangerous Permission Android API Entitlement iOS Class

Microphone 1 WechatwxgetRecorderManager RECORD_AUDIO mediaMediaRecorder

CaptureRequest Microphone Usage AVAudioRecorder

Camera 3 Alipay myscan CAMERA CameraManageropen-CameraCaptureRequest Camera Usage AVCaptureSession

Wi-Fi 4WeChatwxgetWifiList

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetScanResults Hotspot Helper dagger NEHotspotHelper

JinRiTouTiaoTikTokttgetConnectedWifi

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetConnectionInfo Access WiFi Information dagger CNCopyCurrent-

NetworkInfo

Bluetooth 27

Alipay mystartBluetoothDevicesDiscovery

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan NA NADingTalk

ddgetBluetoothDevicesAlipay

mygetBLEDeviceServices

iBeacon 4 Alipay mygetBeaconsACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan Location Usage CLBeaconRegion

dagger Much harder to exploit on iOS due to the requirement of explicit user approvalDagger Android 9 and 10 require ACCESS_FINE_LOCATION permission while Android 81 requires ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION

Table 6 Examples of Sub-window Deception flaws

Host App Triggering Sub-App API Legitimate (and spoofable)Functionality of the Sub-window

Alipay mytradePay Request password ofAlipay mobile wallet

Baidu swanrequestPolymerPayment Request passwords ofmultiple mobile wallets

DingTalk ddpay Request password ofAlipay mobile wallet

WechatwxaddPhoneContact Enter new contacts

wxrequestPayment Request password ofWechat mobile wallet

QQ new in-app message Display instant messagesand enter a reply

sub-ecosystem on top of the operating system In such a case thethird-party OS-like app strives to provide a secure self-containedenvironment However whether it undermines OS security andbrings in new risks to modern mobile applications need to be eval-uated to identify the security gap between the new sub-ecosystemand the OSes Our measurement study shows that popular host appsare generally susceptible to APINA flaws indicating that the app-in-app system vendors today either fail to identify or are unpreparedfor the new risks

Fundamentally APINA risks come from the limited app-levelcapabilities the host app has in managing OS resources lack ofOS-level support and missing of sub-app API standard Hencedown the road it will require non-trivial joint efforts to fundamen-tally eliminate APINA risks More specifically escaped sub-app APIshows that a third-party host fundamentally lacks the full OS-levelknowledge on system resource protection While such knowledgecan come from different sources eg program analysis on relevantOS modules [35 46] developer documentations technical reportsetc each source only contributes a partial view Hence joint effortsneed to be made in the future to synthesize such knowledge Ourstudy also brings to light that such efforts are by no means trivialndash even the two leading mobile OSes have apparently confusingconflicting security policies Synthesizing such a knowledge base

will not only benefit the app-in-app paradigm but also make theOSrsquo security mechanism more transparent for thorough auditing

Our findings also highlight that prior OS lessons cannot fullyeliminate new risks incurred by the new paradigm which necessi-tates thorough assessment regarding its new attack surfaces Forexample a malicious sub-app a sub-window and a task in Recentsscreen all come as new attack vectors that pose credible new threatsto usersrsquo most sensitive credentials and privacyMitigation strategy Following we propose the short-term miti-gation and discuss the long-term strategybull Escaped Sub-app API Eliminating the risk requires the host tohave full OS-level knowledge about resource control (eg API-permission mapping) which is difficult In the meantime our toolApinat together with our API-permission mapping (released on-line [12]) can help host app vendors identify escaped sub-app APIsNote that since Apinat can identify escaped sub-app API with itsignored permissions with respect to specific OS version (see Sec-tion 43) host vendors may leverage our tool to assess whether theirsub-app API permission policy is always compliant with newly re-leased OS version and thus keep up the pace

Further we envision two possible future directions that couldlead to more viable solutions First as demonstrated by our anal-ysis tool Apinat although it is hard for todayrsquos program analy-sis techniques to derive a complete system API-permission map-ping [35 46] we could significantly improve its accuracy and com-prehensiveness through developer documentation analysis Ourcurrent documentation analysis is rather preliminary but still effec-tive as demonstrated in our study (Section 4) Down the road wecould develop natural language processing (NLP) based techniquesfor deriving more complete knowledge about API permission poli-cies With the techniques an analysis could cover a wider spectrumof literature including iOS documents research papers technicalreports etc which will help derive up-to-date knowledge aboutresource-management policies

Second the app-in-app community should work together tostandardize sub-app APIs and their permission policies as donein the HTML5 community on HTML5 APIs For the time being

12

different app-in-app vendors bring in their own APIs for accessinga wide spectrum of systems resources (see our comparison betweensub-app API and HTML5 API in Table 7 in Appendix) often withoutproper safeguard in place not to mention any effort to standardizethe protectionbull Sub-window deception The risk comes from the UI confusionwhether a window portion in the sub-app window belongs to thesub-app or the host (Figure 3b) To mitigate the risk we envision ahigher degree of UI isolation between the sub-app and the host thesub-apprsquos window should always be separated from that of the hostand the host should never reclaim any window portion from thesub-applsquos window Regarding the Wallet UI confusion (Section 32)for example Wechat should display its wallet UI only in its ownwindow and advertise to users that any UI component inside thesub-app window belongs to the sub-app

A question arises whether a malicious sub-app can fake a crashand then show spoofing content in the sub-app window to resem-ble the host This can be mitigated through additional protectionsupported by the host Specifically the host app could keep mon-itoring the UI of its sub-apps (eg through PixelCopy API onAndroid [71]) to detect whether a UI object in the sub-app is similarto a sub-window or a security-sensitive UI object associated withhost app For performance concern the host app could utilize thestate-of-the-art object detection model (eg Fast Region-based Con-volutional Network based model [61] and YOLO [32 95]) for thereal-time security-sensitive UI object recognition as reported inprior research [95] Fast YOLO yields the performance of 155 framesper second Note that the effectiveness efficiency and deploymentfeasibility of such an approach need to be carefully explored andevaluated which we leave for our future researchbull Sub-app lifecycle hijacking To mitigate this risk a short-termdefense is to place all sub-app resources in the phonersquos internalstorage so our current exploit (leveraging monitoring the phonersquosexternal storage) to track sub-app lifecyle termination (Section 33)can be mitigated However it is always a concern that sub-appsmay deplete the limited space on a phonersquos internal storage Along term solution needs to consider how to make the sub-apptasks dynamically scalable to ensure that the sub-app recycling isno longer traceable and thus the attack surface is fundamentallyeliminated This nonetheless calls for support from modern OSesfor the emerging app-in-app paradigm

6 RELATEDWORKAs mentioned in Section 2 recent years witnessed several tech-niques to support the functionality of app encapsulation (eg Plu-gin frameworks app sandboxing browser extension and PhoneGapapp see Table 2) Accordingly numerous studies have looked intothe flaws in these app encapsulation systems considering the se-curity analysis of Plugin frameworks a set of flaws were revealed[99 111 112] including no permission management and no isola-tion of the virtualized apps Compared with Plugin frameworks theapp-in-app paradigm has a much stronger security model and ourstudy investigates the design challenges and pitfalls in the securitymechanism Meanwhile the security and privacy implications ofbrowser extensions have been extensively studied [48 54 84 98]

Furthermore the current security studies on PhoneGap apps fo-cus on the flaws of PhoneGap frameworkrsquos access control policy[60 90 100 101] For example Song et al [101] revealed that thebridges added by the framework to the browser are not correctlyprotected by the same origin policy Jin et al [86] introduced mul-tiple channels (eg barcode SMS file system Contact) for codeinjection attacks in PhoneGap apps Different from these works wefocus on the unique features of the app-in-app paradigm (Table 2)and reveal multiple new attack surfaces which have never beenstudied before

The closer to our study are the works of Web App and WebViewvulnerability assessment Up to our knowledge only one paper[87] analyzed security issue of Web App in which the securityand privacy risks on HTML5 features in PWA were investigatedIn our attack on Web App we did not focus on HTML5 featuresbut a general UI isolation and management model in app-in-appparadigm Also although WebView technique is used in some ofthe app-in-app systems in sharp contrast to the works on Webviewweaknesses [36 60 88 102 105 109 110] our study explores thesecurity implications and challenges for a third-party app tomanageoperating system resources Another set of works related to ourstudy is the exploitation of mobile UI deception Prior phishingattacks [38 49 53 57 97] mislead victims about the foregroundapp aiming at information theft in spoofing apps Correspondingcountermeasures [49 58 96] emphasize identifying the app of thewhole foreground window and thus cannot thwart Sub-windowDeception due to the inability to identify sub-windows Furtheranother angle of UI deception is clickjacking [59 94] which aredifferent from our mobile-phishing attacks7 CONCLUSIONIn this paper we present the first systematic security analysis on re-source management in high-profile app-in-app systems Our studyshows that such systems are susceptible to a set of serious securityflaws Our measurement study further sheds light on their perva-siveness in the real-world Further our study brings in new insightsinto the fundamental security limitations of this new paradigm andfurther contributes to a better understanding of its mitigation strat-egy an important step towards building a more secure app-in-appecosystem

8 ACKNOWLEDGMENTWe would like to thank our shepherd Yanick Fratantonio and theanonymous reviewers for their insightful comments This work issupported in part by the NSF CNS-1618493 1801432 1838083

REFERENCES[1] 2011 HTML5 Fullscreen API Attack httpsferossorghtml5-fullscreen-api-

attack[2] 2011 The Inception Bar httpsjameshfishercom20190427the-inception-

bar-a-new-phishing-method[3] 2018 Java Runnable httpsdocsoraclecomjavase7docsapijavalang

Runnablehtml[4] 2018 A one year PWA retrospective httpsmediumcompinterest-

engineeringa-one-year-pwa-retrospective-f4a2f4129e05[5] 2018 Wechat 1 million sub-apps httpswwwscmpcomtecharticle2153705

tencents-wechat-now-host-1-million-mini-programs[6] 2018 WeChat reaches 1M sub-apps half the size of Applersquos App Store https

techcrunchcom20181107wechat-mini-apps-200-million-users[7] 2018 Xposed httpsapixposedinforeferencepackageshtml[8] 2019 AdBlock httpsgetadblockcom

13

a test app which triggered new threads leveraging the Handlermechanism Our test showed that our tool correctly correlated thetriggering and triggered threads on each Android version

Step S3 produced the API-permission mapping including 94public APIs protected by dangerous permissions at API level 27103 APIs at API level 28 and 119 at API level 29 This step took ourapproach three hours to process the descriptions of 35847 42302and 44323 public APIs on the three API versions respectively Tovalidate the correctness of the mapping we constructed a test app toinvoke all the APIs and verify the required permissions at runtimeFor all three Android versions our permission mapping of all except6 APIs are correct Specifically the mapping of 92 APIs out of 94is correct (979 precision) at the API level 27 The two false casesare unprotected APIs hasPermission and requestPermission inclass UsbManager [66] At API 28 the mapping shows a precisionof 971 with one new false case than what was found on API 27(3 cases in total) API 29 shows a precision of 95 with three newcases than API 28 (6 cases in total) Figure 6 and 7 in Appendixlist all six false cases Their descriptions are more complex and weenvision that a natural language processing (NLP) based approachcan further improve our precision (see discussion in Section 5)

To evaluate the coverage of our documentation analysis toolwe randomly selected the documentation of 153 classes 641 APIs(out of 2164 classes) and then manually reviewed and identified52 API-permission mappings as the ground truth Running on theaforementioned documentation our analysis tool shows a precisionof 100 and a recall of 100 to identify API-permission mappingfrom the documentation

We also compared the completeness of our mapping with recentmappings [35 46] They collectively reported 50 public AndroidAPIs that require dangerous permissions on API level 25 (we werenot able to get results of newer Android from the authors) as asignificant improvement our tool was able to find 91 APIs (82more) that require dangerous permissions on the same API versionDiscussion Apinat may not find all escaped sub-app APIs In par-ticular Step S3 cannot derive a complete mapping if the documen-tation is incomplete [56] or too sophisticated to process Apinatonly looks for system resource exposure by public system APIs andundocumented system APIs used by host apps may also lead to theflaw but remain undetected Also Apinat falls short in analyzingobfuscated host apps eg that uses dynamic code loading andimplementations in CC++ Hence Apinat did not scan Web AppAPIs due to the extensive CC++ implementation in browsers Inaddition incorrect documentation (which we assume is rare andindeed our tool did not report any false escaped sub-app API ) mightlead to false alarms if not properly validated

42 Finding UI Deception FlawsDesign To find out the opportunities for Sub-window Deception(Section 32) in a host app Apinat looks for the apprsquos sensitive sub-windows which can be the targets of the attack As discovered inthe wallet UI confusion (Figure 4b) the hostrsquos sub-windows thatare likely to show up in the presence of a sub-app tends to be thosethat can be triggered through sub-app APIs If such a sub-windowalso contains sensitive information our approach then reports it asa potential target for Sub-window Deception

Implementation To detect such sub-windows Apinat monitorsthe change of the host UI in response to each sub-app API callto identify the sub-window triggered by the API call and thendetermines whether it carries sensitive content Specifically ourapproach first constructs a testing sub-app with an empty UI Thenit runs the sub-app API test cases in Section 41 to call each sub-appAPI through the testing sub-app and further inspects the UI screen-shots before and after the call for changes This is done through apixel-to-pixel comparison of two screenshots To capture the screen-shots we developed a screen projection service on Android usingthe Media Projection [63] API Also our screenshot compari-son was implemented using the OpenCV cv2absdiff API [85]For each sub-window identified our approach continues to findthose associated with sensitive information For this purpose itextracts strings from sub-window screenshots using the onlineOCR service [34] From the strings Apinat further utilizes a list of121 sensitive data keywords and the keyword pair list from recentresearch [91] to recognize those carrying sensitive content Notethat like a mobile OS an app-in-app system also provides a set ofsub-app APIs for sub-apps to dynamically generate UI componentssuch as wxcreateCanvasContextdraw() in Wechat To controlfalse positives Apinat omits such sub-app APIs based on the APIcategory in the sub-app API documentation As a result Apinat suc-cessfully detected 6 Sub-window Deception flaws (Section 43) ForiOS we got the same result since sub-app APIs are across-platformthe one triggers a sub-window on one OS also does that on theother (see Section 2)Evaluation Apinat detected 5 sub-app APIs associated with the UIdeception flaw we manually confirmed that all of them trigger sub-windows with sensitive information Also all of them affect bothAndroid (version 81 9 10) and iOS (version 12 134) Performance-wise the screenshot comparison and OCR analysis together tookless than 5 seconds on a desktop with Intel i5 27 GHz CPU and 8GB memoryDiscussion Soundly detecting whether a host app is susceptibleto Sub-app Lifecycle Hijacking (Section 33) is difficult especiallybecause it entails detection of side-channel information leakagewhich can happen in many ways and is hard to capture in generalTo measure a lower bound of the pervasiveness of the problemwe checked whether the hosts in our study (Table 1) had the sameinformation leakage and lifecycle design as reported in Section 33As a result 3 host apps on Android (Wechat Alipay DingTalk) aresusceptible which were all manually confirmed to be exploitable

43 Measurement of ImpactFlaw landscape With the help of Apinat we analyzed 11 highlypopular host apps (Table 1) on Android and iOS and found theyare all vulnerable to APINA flaws (Table 3) Altogether we found 52APINA flaws including 39 System Resource Exposure 10 Sub-windowDeception and 3 hosts vulnerable to Sub-app Lifecycle Hijacking

For System Resource Exposure in total we uncover 39 escaped sub-app APIs associated with 5 categories of exposed system resources4 Android dangerous permissions and 6 iOS entitlements Table 5shows the flaw number for each category of resources (the secondcolumn) and illustrates 8 escaped sub-app APIs with correspondingAndroid permission(s) and iOS entitlement(s) ignored to enforce

10

Table 3 Eleven vulnerable host apps on Android and iOS(A Alipay B Baidu C Chrome D DingTalk F FirefoxJJinRiTouTiao O Opera Q QQ S Safari T TikTok WWechat) NA denotes the flaw does not apply to the OS

Type of APINA Flaw iOS AndroidSystem Resource Exposure A D J Q T W A D J Q T WSub-window Deception A B D W S Q A B C D F W O QSub-app Lifecycle Hijacking NA A W Q

on them All 39 escaped sub-app APIs are listed in our releaseddataset [12] Also Table 6 illustrates 6 Sub-window Deception in non-browser hosts additionally all four browsers we studied (ChromeSafari Firefox Opera) are susceptible to the same Prominent UIattackResource comparison between Android and iOS Althoughfinding the full API-entitlement mapping for iOS is hard we ob-served a few differences between Android and iOS in system re-source protectionbull iOS is less affected than Android Out of 39 escaped sub-app APIs13 are related to iOS which appears to be less affected and harderto be exploited There are two reasons behind the observation asdiscovered in our study First certain iOS APIs return less informa-tion than its Android counterparts (ie those related to Bluetoothsee Section 31) and thus is less susceptible to privacy risk (locationleakage) Hence all 27 Bluetooth related escaped sub-app APIs donot affect iOS (see Table 5) Second WiFi related escaped sub-appAPIs (see Table 5) are much harder to exploit on iOS since Applehas extra protection besides entitlement Specifically right beforethe programmaticWiFi operation an iOS appmust obtain the userrsquosexplicit consent the app must instruct the user to manually openthe WiFi setting page in the Settings app and then return to theiOS app [43] ndash an indicator of user intention for the app to operateWiFibull iOS entitlement fails to communicate risks to the user On Androidwhen the permission ACCESS_FINE_LOCATION is used for protect-ing the operation Wi-Fi scan it indicates a risk that the WiFioperation may leak location a highly private data On iOS how-ever the entitlement for Wi-Fi scan ie Hotspot Helper failsto communicate such a risk Actually to get this entitlement for aniOS app app developers must file a special written request by justi-fying that the app does not have malicious intention Apple reviewsthe request internally and possibly assesses the risks of locationleakage behind the scene However the name of this entitlementand its documentation we could find does not show that Wi-Fiscan needs location protection on iOS This may have been oneof the factors leading to escaped sub-app API wxgetWifiList (seeTable 5) which performs Wi-Fi scan without protectionAttack consequences The system resources exposed by escapedsub-app API and the risks can be identified from the API namesand the permissions they violate (see Table 5) For example unautho-rized sub-apps can use escaped sub-appAPI wxgetRecorderManag-er to record audio (violating Androidrsquos RECORD_AUDIO permission)We summarize the attack consequences in Table 4 Further Sub-window Deception leads to phishing on popular Web services (egFacebook) mobile wallets and sensitive host UIs For exampleWechat has a UI triggered by sub-app API (wxaddPhoneContact)

Table 4 Examples of APINA attack consequences

Flaw Type Consequences (what the adversary is able to do)

SystemResourceExposure

record audio operate camerainfer victimsrsquo geo-location (thus track users)

connect victimrsquos device to arbitrary Wi-Fi (thus manipulatenetwork traffic perform man-in-the-middle (MITM) or phishing)

and steal sensitive QR code etcSub-windowDeception

steal account credentials on Facebook Google Amazon etcsteal mobile wallet passwords contacts etc

Sub-appLifecycleHijacking

steal money (payments in shopping sub-app)steal personal secrets (eg answers tosecurity questions health records etc)

steal business documents (from a document processingand management sub-app published by Microsoft)

steal account credentials of Amazon ICBCCCB HSBC (1st 2nd 7th largest banks in the world)

Airbnb Weibo Starbucks McDonaldrsquos etc

for users to enter contact information (Table 6) attacking this UImay leak contacts which are highly private Last Sub-app LifecycleHijacking affects three hosts (Table 3) and the risks come fromimitating sub-apps supported by these hosts such as sub-apps forAmazon health banking Airbnb etc (see Table 4)Cases Studies We discuss a few other problems we observed inapp-in-app ecosystembull Keeping up with the OS evolution Sub-app API permission policyshould keep up as the OS always evolves newer OS version oftenintroduces more strict protection against sensitive resources Forexample since Android 10 an app that accesses location in the back-ground needs an additional dangerous permission ACCESS_BACKGRO-UND_LOCATION in addition to the regular location permission [82]This protects user location against illicit tracking However sub-app API for accessing location in hosts TikTok and Alipay did notkeep up with such a new protection thus leaving their users at risk

As another example for the WiFi and Bluetooth scan that canleak location Android 9 and 10 require ACCESS_FINE_LOCATIONpermission while Android 81 is less restrictive and ACCESS_COARSE_LOCATION is sufficient (see Table 5) Note that Android uses the firstpermission to control access to precise location (eg GPS data)and uses the second one for coarse-grained positioning (with anaccuracy approximately at the level of a city block [10]) Interest-ingly all hosts we studied only define a general location sub-apppermission to govern location API (eg scopeuserLocation inWechat) but do not differentiate the two levels of accuracybull Too many APIs for one permission APIs of apparently differentfunctionalities should never be governed by the same permissionHowever in the host TikTok (an extremely popular short-videosharing app with more than 500million downloads on Google Play)three sub-appAPIs ttscanCode ttchooseImage and ttchoos-eVideo (for scanning QR code accessing photos and videos) aregoverned by the same permission scopecamera and thus inade-quately protected For example a malicious sub-app that is grantedpermission by the user to scan QR code also behind the scenesilently gets access to API ttchooseImage that accesses user pho-tos posing a serious privacy risk

5 LESSONS AND MITIGATION STRATEGYLessons learned The most important lesson learnt from our re-search is the caution one should take when building a third-party

11

Table 5 Summary of System Resources Exposure flaws (NA means the flaw does not affect the OS)

SystemResourceExposed

of

FlawsExample of Escaped

Sub-app API Dangerous Permission Android API Entitlement iOS Class

Microphone 1 WechatwxgetRecorderManager RECORD_AUDIO mediaMediaRecorder

CaptureRequest Microphone Usage AVAudioRecorder

Camera 3 Alipay myscan CAMERA CameraManageropen-CameraCaptureRequest Camera Usage AVCaptureSession

Wi-Fi 4WeChatwxgetWifiList

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetScanResults Hotspot Helper dagger NEHotspotHelper

JinRiTouTiaoTikTokttgetConnectedWifi

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetConnectionInfo Access WiFi Information dagger CNCopyCurrent-

NetworkInfo

Bluetooth 27

Alipay mystartBluetoothDevicesDiscovery

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan NA NADingTalk

ddgetBluetoothDevicesAlipay

mygetBLEDeviceServices

iBeacon 4 Alipay mygetBeaconsACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan Location Usage CLBeaconRegion

dagger Much harder to exploit on iOS due to the requirement of explicit user approvalDagger Android 9 and 10 require ACCESS_FINE_LOCATION permission while Android 81 requires ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION

Table 6 Examples of Sub-window Deception flaws

Host App Triggering Sub-App API Legitimate (and spoofable)Functionality of the Sub-window

Alipay mytradePay Request password ofAlipay mobile wallet

Baidu swanrequestPolymerPayment Request passwords ofmultiple mobile wallets

DingTalk ddpay Request password ofAlipay mobile wallet

WechatwxaddPhoneContact Enter new contacts

wxrequestPayment Request password ofWechat mobile wallet

QQ new in-app message Display instant messagesand enter a reply

sub-ecosystem on top of the operating system In such a case thethird-party OS-like app strives to provide a secure self-containedenvironment However whether it undermines OS security andbrings in new risks to modern mobile applications need to be eval-uated to identify the security gap between the new sub-ecosystemand the OSes Our measurement study shows that popular host appsare generally susceptible to APINA flaws indicating that the app-in-app system vendors today either fail to identify or are unpreparedfor the new risks

Fundamentally APINA risks come from the limited app-levelcapabilities the host app has in managing OS resources lack ofOS-level support and missing of sub-app API standard Hencedown the road it will require non-trivial joint efforts to fundamen-tally eliminate APINA risks More specifically escaped sub-app APIshows that a third-party host fundamentally lacks the full OS-levelknowledge on system resource protection While such knowledgecan come from different sources eg program analysis on relevantOS modules [35 46] developer documentations technical reportsetc each source only contributes a partial view Hence joint effortsneed to be made in the future to synthesize such knowledge Ourstudy also brings to light that such efforts are by no means trivialndash even the two leading mobile OSes have apparently confusingconflicting security policies Synthesizing such a knowledge base

will not only benefit the app-in-app paradigm but also make theOSrsquo security mechanism more transparent for thorough auditing

Our findings also highlight that prior OS lessons cannot fullyeliminate new risks incurred by the new paradigm which necessi-tates thorough assessment regarding its new attack surfaces Forexample a malicious sub-app a sub-window and a task in Recentsscreen all come as new attack vectors that pose credible new threatsto usersrsquo most sensitive credentials and privacyMitigation strategy Following we propose the short-term miti-gation and discuss the long-term strategybull Escaped Sub-app API Eliminating the risk requires the host tohave full OS-level knowledge about resource control (eg API-permission mapping) which is difficult In the meantime our toolApinat together with our API-permission mapping (released on-line [12]) can help host app vendors identify escaped sub-app APIsNote that since Apinat can identify escaped sub-app API with itsignored permissions with respect to specific OS version (see Sec-tion 43) host vendors may leverage our tool to assess whether theirsub-app API permission policy is always compliant with newly re-leased OS version and thus keep up the pace

Further we envision two possible future directions that couldlead to more viable solutions First as demonstrated by our anal-ysis tool Apinat although it is hard for todayrsquos program analy-sis techniques to derive a complete system API-permission map-ping [35 46] we could significantly improve its accuracy and com-prehensiveness through developer documentation analysis Ourcurrent documentation analysis is rather preliminary but still effec-tive as demonstrated in our study (Section 4) Down the road wecould develop natural language processing (NLP) based techniquesfor deriving more complete knowledge about API permission poli-cies With the techniques an analysis could cover a wider spectrumof literature including iOS documents research papers technicalreports etc which will help derive up-to-date knowledge aboutresource-management policies

Second the app-in-app community should work together tostandardize sub-app APIs and their permission policies as donein the HTML5 community on HTML5 APIs For the time being

12

different app-in-app vendors bring in their own APIs for accessinga wide spectrum of systems resources (see our comparison betweensub-app API and HTML5 API in Table 7 in Appendix) often withoutproper safeguard in place not to mention any effort to standardizethe protectionbull Sub-window deception The risk comes from the UI confusionwhether a window portion in the sub-app window belongs to thesub-app or the host (Figure 3b) To mitigate the risk we envision ahigher degree of UI isolation between the sub-app and the host thesub-apprsquos window should always be separated from that of the hostand the host should never reclaim any window portion from thesub-applsquos window Regarding the Wallet UI confusion (Section 32)for example Wechat should display its wallet UI only in its ownwindow and advertise to users that any UI component inside thesub-app window belongs to the sub-app

A question arises whether a malicious sub-app can fake a crashand then show spoofing content in the sub-app window to resem-ble the host This can be mitigated through additional protectionsupported by the host Specifically the host app could keep mon-itoring the UI of its sub-apps (eg through PixelCopy API onAndroid [71]) to detect whether a UI object in the sub-app is similarto a sub-window or a security-sensitive UI object associated withhost app For performance concern the host app could utilize thestate-of-the-art object detection model (eg Fast Region-based Con-volutional Network based model [61] and YOLO [32 95]) for thereal-time security-sensitive UI object recognition as reported inprior research [95] Fast YOLO yields the performance of 155 framesper second Note that the effectiveness efficiency and deploymentfeasibility of such an approach need to be carefully explored andevaluated which we leave for our future researchbull Sub-app lifecycle hijacking To mitigate this risk a short-termdefense is to place all sub-app resources in the phonersquos internalstorage so our current exploit (leveraging monitoring the phonersquosexternal storage) to track sub-app lifecyle termination (Section 33)can be mitigated However it is always a concern that sub-appsmay deplete the limited space on a phonersquos internal storage Along term solution needs to consider how to make the sub-apptasks dynamically scalable to ensure that the sub-app recycling isno longer traceable and thus the attack surface is fundamentallyeliminated This nonetheless calls for support from modern OSesfor the emerging app-in-app paradigm

6 RELATEDWORKAs mentioned in Section 2 recent years witnessed several tech-niques to support the functionality of app encapsulation (eg Plu-gin frameworks app sandboxing browser extension and PhoneGapapp see Table 2) Accordingly numerous studies have looked intothe flaws in these app encapsulation systems considering the se-curity analysis of Plugin frameworks a set of flaws were revealed[99 111 112] including no permission management and no isola-tion of the virtualized apps Compared with Plugin frameworks theapp-in-app paradigm has a much stronger security model and ourstudy investigates the design challenges and pitfalls in the securitymechanism Meanwhile the security and privacy implications ofbrowser extensions have been extensively studied [48 54 84 98]

Furthermore the current security studies on PhoneGap apps fo-cus on the flaws of PhoneGap frameworkrsquos access control policy[60 90 100 101] For example Song et al [101] revealed that thebridges added by the framework to the browser are not correctlyprotected by the same origin policy Jin et al [86] introduced mul-tiple channels (eg barcode SMS file system Contact) for codeinjection attacks in PhoneGap apps Different from these works wefocus on the unique features of the app-in-app paradigm (Table 2)and reveal multiple new attack surfaces which have never beenstudied before

The closer to our study are the works of Web App and WebViewvulnerability assessment Up to our knowledge only one paper[87] analyzed security issue of Web App in which the securityand privacy risks on HTML5 features in PWA were investigatedIn our attack on Web App we did not focus on HTML5 featuresbut a general UI isolation and management model in app-in-appparadigm Also although WebView technique is used in some ofthe app-in-app systems in sharp contrast to the works on Webviewweaknesses [36 60 88 102 105 109 110] our study explores thesecurity implications and challenges for a third-party app tomanageoperating system resources Another set of works related to ourstudy is the exploitation of mobile UI deception Prior phishingattacks [38 49 53 57 97] mislead victims about the foregroundapp aiming at information theft in spoofing apps Correspondingcountermeasures [49 58 96] emphasize identifying the app of thewhole foreground window and thus cannot thwart Sub-windowDeception due to the inability to identify sub-windows Furtheranother angle of UI deception is clickjacking [59 94] which aredifferent from our mobile-phishing attacks7 CONCLUSIONIn this paper we present the first systematic security analysis on re-source management in high-profile app-in-app systems Our studyshows that such systems are susceptible to a set of serious securityflaws Our measurement study further sheds light on their perva-siveness in the real-world Further our study brings in new insightsinto the fundamental security limitations of this new paradigm andfurther contributes to a better understanding of its mitigation strat-egy an important step towards building a more secure app-in-appecosystem

8 ACKNOWLEDGMENTWe would like to thank our shepherd Yanick Fratantonio and theanonymous reviewers for their insightful comments This work issupported in part by the NSF CNS-1618493 1801432 1838083

REFERENCES[1] 2011 HTML5 Fullscreen API Attack httpsferossorghtml5-fullscreen-api-

attack[2] 2011 The Inception Bar httpsjameshfishercom20190427the-inception-

bar-a-new-phishing-method[3] 2018 Java Runnable httpsdocsoraclecomjavase7docsapijavalang

Runnablehtml[4] 2018 A one year PWA retrospective httpsmediumcompinterest-

engineeringa-one-year-pwa-retrospective-f4a2f4129e05[5] 2018 Wechat 1 million sub-apps httpswwwscmpcomtecharticle2153705

tencents-wechat-now-host-1-million-mini-programs[6] 2018 WeChat reaches 1M sub-apps half the size of Applersquos App Store https

techcrunchcom20181107wechat-mini-apps-200-million-users[7] 2018 Xposed httpsapixposedinforeferencepackageshtml[8] 2019 AdBlock httpsgetadblockcom

13

Table 3 Eleven vulnerable host apps on Android and iOS(A Alipay B Baidu C Chrome D DingTalk F FirefoxJJinRiTouTiao O Opera Q QQ S Safari T TikTok WWechat) NA denotes the flaw does not apply to the OS

Type of APINA Flaw iOS AndroidSystem Resource Exposure A D J Q T W A D J Q T WSub-window Deception A B D W S Q A B C D F W O QSub-app Lifecycle Hijacking NA A W Q

on them All 39 escaped sub-app APIs are listed in our releaseddataset [12] Also Table 6 illustrates 6 Sub-window Deception in non-browser hosts additionally all four browsers we studied (ChromeSafari Firefox Opera) are susceptible to the same Prominent UIattackResource comparison between Android and iOS Althoughfinding the full API-entitlement mapping for iOS is hard we ob-served a few differences between Android and iOS in system re-source protectionbull iOS is less affected than Android Out of 39 escaped sub-app APIs13 are related to iOS which appears to be less affected and harderto be exploited There are two reasons behind the observation asdiscovered in our study First certain iOS APIs return less informa-tion than its Android counterparts (ie those related to Bluetoothsee Section 31) and thus is less susceptible to privacy risk (locationleakage) Hence all 27 Bluetooth related escaped sub-app APIs donot affect iOS (see Table 5) Second WiFi related escaped sub-appAPIs (see Table 5) are much harder to exploit on iOS since Applehas extra protection besides entitlement Specifically right beforethe programmaticWiFi operation an iOS appmust obtain the userrsquosexplicit consent the app must instruct the user to manually openthe WiFi setting page in the Settings app and then return to theiOS app [43] ndash an indicator of user intention for the app to operateWiFibull iOS entitlement fails to communicate risks to the user On Androidwhen the permission ACCESS_FINE_LOCATION is used for protect-ing the operation Wi-Fi scan it indicates a risk that the WiFioperation may leak location a highly private data On iOS how-ever the entitlement for Wi-Fi scan ie Hotspot Helper failsto communicate such a risk Actually to get this entitlement for aniOS app app developers must file a special written request by justi-fying that the app does not have malicious intention Apple reviewsthe request internally and possibly assesses the risks of locationleakage behind the scene However the name of this entitlementand its documentation we could find does not show that Wi-Fiscan needs location protection on iOS This may have been oneof the factors leading to escaped sub-app API wxgetWifiList (seeTable 5) which performs Wi-Fi scan without protectionAttack consequences The system resources exposed by escapedsub-app API and the risks can be identified from the API namesand the permissions they violate (see Table 5) For example unautho-rized sub-apps can use escaped sub-appAPI wxgetRecorderManag-er to record audio (violating Androidrsquos RECORD_AUDIO permission)We summarize the attack consequences in Table 4 Further Sub-window Deception leads to phishing on popular Web services (egFacebook) mobile wallets and sensitive host UIs For exampleWechat has a UI triggered by sub-app API (wxaddPhoneContact)

Table 4 Examples of APINA attack consequences

Flaw Type Consequences (what the adversary is able to do)

SystemResourceExposure

record audio operate camerainfer victimsrsquo geo-location (thus track users)

connect victimrsquos device to arbitrary Wi-Fi (thus manipulatenetwork traffic perform man-in-the-middle (MITM) or phishing)

and steal sensitive QR code etcSub-windowDeception

steal account credentials on Facebook Google Amazon etcsteal mobile wallet passwords contacts etc

Sub-appLifecycleHijacking

steal money (payments in shopping sub-app)steal personal secrets (eg answers tosecurity questions health records etc)

steal business documents (from a document processingand management sub-app published by Microsoft)

steal account credentials of Amazon ICBCCCB HSBC (1st 2nd 7th largest banks in the world)

Airbnb Weibo Starbucks McDonaldrsquos etc

for users to enter contact information (Table 6) attacking this UImay leak contacts which are highly private Last Sub-app LifecycleHijacking affects three hosts (Table 3) and the risks come fromimitating sub-apps supported by these hosts such as sub-apps forAmazon health banking Airbnb etc (see Table 4)Cases Studies We discuss a few other problems we observed inapp-in-app ecosystembull Keeping up with the OS evolution Sub-app API permission policyshould keep up as the OS always evolves newer OS version oftenintroduces more strict protection against sensitive resources Forexample since Android 10 an app that accesses location in the back-ground needs an additional dangerous permission ACCESS_BACKGRO-UND_LOCATION in addition to the regular location permission [82]This protects user location against illicit tracking However sub-app API for accessing location in hosts TikTok and Alipay did notkeep up with such a new protection thus leaving their users at risk

As another example for the WiFi and Bluetooth scan that canleak location Android 9 and 10 require ACCESS_FINE_LOCATIONpermission while Android 81 is less restrictive and ACCESS_COARSE_LOCATION is sufficient (see Table 5) Note that Android uses the firstpermission to control access to precise location (eg GPS data)and uses the second one for coarse-grained positioning (with anaccuracy approximately at the level of a city block [10]) Interest-ingly all hosts we studied only define a general location sub-apppermission to govern location API (eg scopeuserLocation inWechat) but do not differentiate the two levels of accuracybull Too many APIs for one permission APIs of apparently differentfunctionalities should never be governed by the same permissionHowever in the host TikTok (an extremely popular short-videosharing app with more than 500million downloads on Google Play)three sub-appAPIs ttscanCode ttchooseImage and ttchoos-eVideo (for scanning QR code accessing photos and videos) aregoverned by the same permission scopecamera and thus inade-quately protected For example a malicious sub-app that is grantedpermission by the user to scan QR code also behind the scenesilently gets access to API ttchooseImage that accesses user pho-tos posing a serious privacy risk

5 LESSONS AND MITIGATION STRATEGYLessons learned The most important lesson learnt from our re-search is the caution one should take when building a third-party

11

Table 5 Summary of System Resources Exposure flaws (NA means the flaw does not affect the OS)

SystemResourceExposed

of

FlawsExample of Escaped

Sub-app API Dangerous Permission Android API Entitlement iOS Class

Microphone 1 WechatwxgetRecorderManager RECORD_AUDIO mediaMediaRecorder

CaptureRequest Microphone Usage AVAudioRecorder

Camera 3 Alipay myscan CAMERA CameraManageropen-CameraCaptureRequest Camera Usage AVCaptureSession

Wi-Fi 4WeChatwxgetWifiList

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetScanResults Hotspot Helper dagger NEHotspotHelper

JinRiTouTiaoTikTokttgetConnectedWifi

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetConnectionInfo Access WiFi Information dagger CNCopyCurrent-

NetworkInfo

Bluetooth 27

Alipay mystartBluetoothDevicesDiscovery

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan NA NADingTalk

ddgetBluetoothDevicesAlipay

mygetBLEDeviceServices

iBeacon 4 Alipay mygetBeaconsACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan Location Usage CLBeaconRegion

dagger Much harder to exploit on iOS due to the requirement of explicit user approvalDagger Android 9 and 10 require ACCESS_FINE_LOCATION permission while Android 81 requires ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION

Table 6 Examples of Sub-window Deception flaws

Host App Triggering Sub-App API Legitimate (and spoofable)Functionality of the Sub-window

Alipay mytradePay Request password ofAlipay mobile wallet

Baidu swanrequestPolymerPayment Request passwords ofmultiple mobile wallets

DingTalk ddpay Request password ofAlipay mobile wallet

WechatwxaddPhoneContact Enter new contacts

wxrequestPayment Request password ofWechat mobile wallet

QQ new in-app message Display instant messagesand enter a reply

sub-ecosystem on top of the operating system In such a case thethird-party OS-like app strives to provide a secure self-containedenvironment However whether it undermines OS security andbrings in new risks to modern mobile applications need to be eval-uated to identify the security gap between the new sub-ecosystemand the OSes Our measurement study shows that popular host appsare generally susceptible to APINA flaws indicating that the app-in-app system vendors today either fail to identify or are unpreparedfor the new risks

Fundamentally APINA risks come from the limited app-levelcapabilities the host app has in managing OS resources lack ofOS-level support and missing of sub-app API standard Hencedown the road it will require non-trivial joint efforts to fundamen-tally eliminate APINA risks More specifically escaped sub-app APIshows that a third-party host fundamentally lacks the full OS-levelknowledge on system resource protection While such knowledgecan come from different sources eg program analysis on relevantOS modules [35 46] developer documentations technical reportsetc each source only contributes a partial view Hence joint effortsneed to be made in the future to synthesize such knowledge Ourstudy also brings to light that such efforts are by no means trivialndash even the two leading mobile OSes have apparently confusingconflicting security policies Synthesizing such a knowledge base

will not only benefit the app-in-app paradigm but also make theOSrsquo security mechanism more transparent for thorough auditing

Our findings also highlight that prior OS lessons cannot fullyeliminate new risks incurred by the new paradigm which necessi-tates thorough assessment regarding its new attack surfaces Forexample a malicious sub-app a sub-window and a task in Recentsscreen all come as new attack vectors that pose credible new threatsto usersrsquo most sensitive credentials and privacyMitigation strategy Following we propose the short-term miti-gation and discuss the long-term strategybull Escaped Sub-app API Eliminating the risk requires the host tohave full OS-level knowledge about resource control (eg API-permission mapping) which is difficult In the meantime our toolApinat together with our API-permission mapping (released on-line [12]) can help host app vendors identify escaped sub-app APIsNote that since Apinat can identify escaped sub-app API with itsignored permissions with respect to specific OS version (see Sec-tion 43) host vendors may leverage our tool to assess whether theirsub-app API permission policy is always compliant with newly re-leased OS version and thus keep up the pace

Further we envision two possible future directions that couldlead to more viable solutions First as demonstrated by our anal-ysis tool Apinat although it is hard for todayrsquos program analy-sis techniques to derive a complete system API-permission map-ping [35 46] we could significantly improve its accuracy and com-prehensiveness through developer documentation analysis Ourcurrent documentation analysis is rather preliminary but still effec-tive as demonstrated in our study (Section 4) Down the road wecould develop natural language processing (NLP) based techniquesfor deriving more complete knowledge about API permission poli-cies With the techniques an analysis could cover a wider spectrumof literature including iOS documents research papers technicalreports etc which will help derive up-to-date knowledge aboutresource-management policies

Second the app-in-app community should work together tostandardize sub-app APIs and their permission policies as donein the HTML5 community on HTML5 APIs For the time being

12

different app-in-app vendors bring in their own APIs for accessinga wide spectrum of systems resources (see our comparison betweensub-app API and HTML5 API in Table 7 in Appendix) often withoutproper safeguard in place not to mention any effort to standardizethe protectionbull Sub-window deception The risk comes from the UI confusionwhether a window portion in the sub-app window belongs to thesub-app or the host (Figure 3b) To mitigate the risk we envision ahigher degree of UI isolation between the sub-app and the host thesub-apprsquos window should always be separated from that of the hostand the host should never reclaim any window portion from thesub-applsquos window Regarding the Wallet UI confusion (Section 32)for example Wechat should display its wallet UI only in its ownwindow and advertise to users that any UI component inside thesub-app window belongs to the sub-app

A question arises whether a malicious sub-app can fake a crashand then show spoofing content in the sub-app window to resem-ble the host This can be mitigated through additional protectionsupported by the host Specifically the host app could keep mon-itoring the UI of its sub-apps (eg through PixelCopy API onAndroid [71]) to detect whether a UI object in the sub-app is similarto a sub-window or a security-sensitive UI object associated withhost app For performance concern the host app could utilize thestate-of-the-art object detection model (eg Fast Region-based Con-volutional Network based model [61] and YOLO [32 95]) for thereal-time security-sensitive UI object recognition as reported inprior research [95] Fast YOLO yields the performance of 155 framesper second Note that the effectiveness efficiency and deploymentfeasibility of such an approach need to be carefully explored andevaluated which we leave for our future researchbull Sub-app lifecycle hijacking To mitigate this risk a short-termdefense is to place all sub-app resources in the phonersquos internalstorage so our current exploit (leveraging monitoring the phonersquosexternal storage) to track sub-app lifecyle termination (Section 33)can be mitigated However it is always a concern that sub-appsmay deplete the limited space on a phonersquos internal storage Along term solution needs to consider how to make the sub-apptasks dynamically scalable to ensure that the sub-app recycling isno longer traceable and thus the attack surface is fundamentallyeliminated This nonetheless calls for support from modern OSesfor the emerging app-in-app paradigm

6 RELATEDWORKAs mentioned in Section 2 recent years witnessed several tech-niques to support the functionality of app encapsulation (eg Plu-gin frameworks app sandboxing browser extension and PhoneGapapp see Table 2) Accordingly numerous studies have looked intothe flaws in these app encapsulation systems considering the se-curity analysis of Plugin frameworks a set of flaws were revealed[99 111 112] including no permission management and no isola-tion of the virtualized apps Compared with Plugin frameworks theapp-in-app paradigm has a much stronger security model and ourstudy investigates the design challenges and pitfalls in the securitymechanism Meanwhile the security and privacy implications ofbrowser extensions have been extensively studied [48 54 84 98]

Furthermore the current security studies on PhoneGap apps fo-cus on the flaws of PhoneGap frameworkrsquos access control policy[60 90 100 101] For example Song et al [101] revealed that thebridges added by the framework to the browser are not correctlyprotected by the same origin policy Jin et al [86] introduced mul-tiple channels (eg barcode SMS file system Contact) for codeinjection attacks in PhoneGap apps Different from these works wefocus on the unique features of the app-in-app paradigm (Table 2)and reveal multiple new attack surfaces which have never beenstudied before

The closer to our study are the works of Web App and WebViewvulnerability assessment Up to our knowledge only one paper[87] analyzed security issue of Web App in which the securityand privacy risks on HTML5 features in PWA were investigatedIn our attack on Web App we did not focus on HTML5 featuresbut a general UI isolation and management model in app-in-appparadigm Also although WebView technique is used in some ofthe app-in-app systems in sharp contrast to the works on Webviewweaknesses [36 60 88 102 105 109 110] our study explores thesecurity implications and challenges for a third-party app tomanageoperating system resources Another set of works related to ourstudy is the exploitation of mobile UI deception Prior phishingattacks [38 49 53 57 97] mislead victims about the foregroundapp aiming at information theft in spoofing apps Correspondingcountermeasures [49 58 96] emphasize identifying the app of thewhole foreground window and thus cannot thwart Sub-windowDeception due to the inability to identify sub-windows Furtheranother angle of UI deception is clickjacking [59 94] which aredifferent from our mobile-phishing attacks7 CONCLUSIONIn this paper we present the first systematic security analysis on re-source management in high-profile app-in-app systems Our studyshows that such systems are susceptible to a set of serious securityflaws Our measurement study further sheds light on their perva-siveness in the real-world Further our study brings in new insightsinto the fundamental security limitations of this new paradigm andfurther contributes to a better understanding of its mitigation strat-egy an important step towards building a more secure app-in-appecosystem

8 ACKNOWLEDGMENTWe would like to thank our shepherd Yanick Fratantonio and theanonymous reviewers for their insightful comments This work issupported in part by the NSF CNS-1618493 1801432 1838083

REFERENCES[1] 2011 HTML5 Fullscreen API Attack httpsferossorghtml5-fullscreen-api-

attack[2] 2011 The Inception Bar httpsjameshfishercom20190427the-inception-

bar-a-new-phishing-method[3] 2018 Java Runnable httpsdocsoraclecomjavase7docsapijavalang

Runnablehtml[4] 2018 A one year PWA retrospective httpsmediumcompinterest-

engineeringa-one-year-pwa-retrospective-f4a2f4129e05[5] 2018 Wechat 1 million sub-apps httpswwwscmpcomtecharticle2153705

tencents-wechat-now-host-1-million-mini-programs[6] 2018 WeChat reaches 1M sub-apps half the size of Applersquos App Store https

techcrunchcom20181107wechat-mini-apps-200-million-users[7] 2018 Xposed httpsapixposedinforeferencepackageshtml[8] 2019 AdBlock httpsgetadblockcom

13

Table 5 Summary of System Resources Exposure flaws (NA means the flaw does not affect the OS)

SystemResourceExposed

of

FlawsExample of Escaped

Sub-app API Dangerous Permission Android API Entitlement iOS Class

Microphone 1 WechatwxgetRecorderManager RECORD_AUDIO mediaMediaRecorder

CaptureRequest Microphone Usage AVAudioRecorder

Camera 3 Alipay myscan CAMERA CameraManageropen-CameraCaptureRequest Camera Usage AVCaptureSession

Wi-Fi 4WeChatwxgetWifiList

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetScanResults Hotspot Helper dagger NEHotspotHelper

JinRiTouTiaoTikTokttgetConnectedWifi

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

WifiManagergetConnectionInfo Access WiFi Information dagger CNCopyCurrent-

NetworkInfo

Bluetooth 27

Alipay mystartBluetoothDevicesDiscovery

ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan NA NADingTalk

ddgetBluetoothDevicesAlipay

mygetBLEDeviceServices

iBeacon 4 Alipay mygetBeaconsACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION Dagger

BluetoothLe-ScannerstartScan Location Usage CLBeaconRegion

dagger Much harder to exploit on iOS due to the requirement of explicit user approvalDagger Android 9 and 10 require ACCESS_FINE_LOCATION permission while Android 81 requires ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION

Table 6 Examples of Sub-window Deception flaws

Host App Triggering Sub-App API Legitimate (and spoofable)Functionality of the Sub-window

Alipay mytradePay Request password ofAlipay mobile wallet

Baidu swanrequestPolymerPayment Request passwords ofmultiple mobile wallets

DingTalk ddpay Request password ofAlipay mobile wallet

WechatwxaddPhoneContact Enter new contacts

wxrequestPayment Request password ofWechat mobile wallet

QQ new in-app message Display instant messagesand enter a reply

sub-ecosystem on top of the operating system In such a case thethird-party OS-like app strives to provide a secure self-containedenvironment However whether it undermines OS security andbrings in new risks to modern mobile applications need to be eval-uated to identify the security gap between the new sub-ecosystemand the OSes Our measurement study shows that popular host appsare generally susceptible to APINA flaws indicating that the app-in-app system vendors today either fail to identify or are unpreparedfor the new risks

Fundamentally APINA risks come from the limited app-levelcapabilities the host app has in managing OS resources lack ofOS-level support and missing of sub-app API standard Hencedown the road it will require non-trivial joint efforts to fundamen-tally eliminate APINA risks More specifically escaped sub-app APIshows that a third-party host fundamentally lacks the full OS-levelknowledge on system resource protection While such knowledgecan come from different sources eg program analysis on relevantOS modules [35 46] developer documentations technical reportsetc each source only contributes a partial view Hence joint effortsneed to be made in the future to synthesize such knowledge Ourstudy also brings to light that such efforts are by no means trivialndash even the two leading mobile OSes have apparently confusingconflicting security policies Synthesizing such a knowledge base

will not only benefit the app-in-app paradigm but also make theOSrsquo security mechanism more transparent for thorough auditing

Our findings also highlight that prior OS lessons cannot fullyeliminate new risks incurred by the new paradigm which necessi-tates thorough assessment regarding its new attack surfaces Forexample a malicious sub-app a sub-window and a task in Recentsscreen all come as new attack vectors that pose credible new threatsto usersrsquo most sensitive credentials and privacyMitigation strategy Following we propose the short-term miti-gation and discuss the long-term strategybull Escaped Sub-app API Eliminating the risk requires the host tohave full OS-level knowledge about resource control (eg API-permission mapping) which is difficult In the meantime our toolApinat together with our API-permission mapping (released on-line [12]) can help host app vendors identify escaped sub-app APIsNote that since Apinat can identify escaped sub-app API with itsignored permissions with respect to specific OS version (see Sec-tion 43) host vendors may leverage our tool to assess whether theirsub-app API permission policy is always compliant with newly re-leased OS version and thus keep up the pace

Further we envision two possible future directions that couldlead to more viable solutions First as demonstrated by our anal-ysis tool Apinat although it is hard for todayrsquos program analy-sis techniques to derive a complete system API-permission map-ping [35 46] we could significantly improve its accuracy and com-prehensiveness through developer documentation analysis Ourcurrent documentation analysis is rather preliminary but still effec-tive as demonstrated in our study (Section 4) Down the road wecould develop natural language processing (NLP) based techniquesfor deriving more complete knowledge about API permission poli-cies With the techniques an analysis could cover a wider spectrumof literature including iOS documents research papers technicalreports etc which will help derive up-to-date knowledge aboutresource-management policies

Second the app-in-app community should work together tostandardize sub-app APIs and their permission policies as donein the HTML5 community on HTML5 APIs For the time being

12

different app-in-app vendors bring in their own APIs for accessinga wide spectrum of systems resources (see our comparison betweensub-app API and HTML5 API in Table 7 in Appendix) often withoutproper safeguard in place not to mention any effort to standardizethe protectionbull Sub-window deception The risk comes from the UI confusionwhether a window portion in the sub-app window belongs to thesub-app or the host (Figure 3b) To mitigate the risk we envision ahigher degree of UI isolation between the sub-app and the host thesub-apprsquos window should always be separated from that of the hostand the host should never reclaim any window portion from thesub-applsquos window Regarding the Wallet UI confusion (Section 32)for example Wechat should display its wallet UI only in its ownwindow and advertise to users that any UI component inside thesub-app window belongs to the sub-app

A question arises whether a malicious sub-app can fake a crashand then show spoofing content in the sub-app window to resem-ble the host This can be mitigated through additional protectionsupported by the host Specifically the host app could keep mon-itoring the UI of its sub-apps (eg through PixelCopy API onAndroid [71]) to detect whether a UI object in the sub-app is similarto a sub-window or a security-sensitive UI object associated withhost app For performance concern the host app could utilize thestate-of-the-art object detection model (eg Fast Region-based Con-volutional Network based model [61] and YOLO [32 95]) for thereal-time security-sensitive UI object recognition as reported inprior research [95] Fast YOLO yields the performance of 155 framesper second Note that the effectiveness efficiency and deploymentfeasibility of such an approach need to be carefully explored andevaluated which we leave for our future researchbull Sub-app lifecycle hijacking To mitigate this risk a short-termdefense is to place all sub-app resources in the phonersquos internalstorage so our current exploit (leveraging monitoring the phonersquosexternal storage) to track sub-app lifecyle termination (Section 33)can be mitigated However it is always a concern that sub-appsmay deplete the limited space on a phonersquos internal storage Along term solution needs to consider how to make the sub-apptasks dynamically scalable to ensure that the sub-app recycling isno longer traceable and thus the attack surface is fundamentallyeliminated This nonetheless calls for support from modern OSesfor the emerging app-in-app paradigm

6 RELATEDWORKAs mentioned in Section 2 recent years witnessed several tech-niques to support the functionality of app encapsulation (eg Plu-gin frameworks app sandboxing browser extension and PhoneGapapp see Table 2) Accordingly numerous studies have looked intothe flaws in these app encapsulation systems considering the se-curity analysis of Plugin frameworks a set of flaws were revealed[99 111 112] including no permission management and no isola-tion of the virtualized apps Compared with Plugin frameworks theapp-in-app paradigm has a much stronger security model and ourstudy investigates the design challenges and pitfalls in the securitymechanism Meanwhile the security and privacy implications ofbrowser extensions have been extensively studied [48 54 84 98]

Furthermore the current security studies on PhoneGap apps fo-cus on the flaws of PhoneGap frameworkrsquos access control policy[60 90 100 101] For example Song et al [101] revealed that thebridges added by the framework to the browser are not correctlyprotected by the same origin policy Jin et al [86] introduced mul-tiple channels (eg barcode SMS file system Contact) for codeinjection attacks in PhoneGap apps Different from these works wefocus on the unique features of the app-in-app paradigm (Table 2)and reveal multiple new attack surfaces which have never beenstudied before

The closer to our study are the works of Web App and WebViewvulnerability assessment Up to our knowledge only one paper[87] analyzed security issue of Web App in which the securityand privacy risks on HTML5 features in PWA were investigatedIn our attack on Web App we did not focus on HTML5 featuresbut a general UI isolation and management model in app-in-appparadigm Also although WebView technique is used in some ofthe app-in-app systems in sharp contrast to the works on Webviewweaknesses [36 60 88 102 105 109 110] our study explores thesecurity implications and challenges for a third-party app tomanageoperating system resources Another set of works related to ourstudy is the exploitation of mobile UI deception Prior phishingattacks [38 49 53 57 97] mislead victims about the foregroundapp aiming at information theft in spoofing apps Correspondingcountermeasures [49 58 96] emphasize identifying the app of thewhole foreground window and thus cannot thwart Sub-windowDeception due to the inability to identify sub-windows Furtheranother angle of UI deception is clickjacking [59 94] which aredifferent from our mobile-phishing attacks7 CONCLUSIONIn this paper we present the first systematic security analysis on re-source management in high-profile app-in-app systems Our studyshows that such systems are susceptible to a set of serious securityflaws Our measurement study further sheds light on their perva-siveness in the real-world Further our study brings in new insightsinto the fundamental security limitations of this new paradigm andfurther contributes to a better understanding of its mitigation strat-egy an important step towards building a more secure app-in-appecosystem

8 ACKNOWLEDGMENTWe would like to thank our shepherd Yanick Fratantonio and theanonymous reviewers for their insightful comments This work issupported in part by the NSF CNS-1618493 1801432 1838083

REFERENCES[1] 2011 HTML5 Fullscreen API Attack httpsferossorghtml5-fullscreen-api-

attack[2] 2011 The Inception Bar httpsjameshfishercom20190427the-inception-

bar-a-new-phishing-method[3] 2018 Java Runnable httpsdocsoraclecomjavase7docsapijavalang

Runnablehtml[4] 2018 A one year PWA retrospective httpsmediumcompinterest-

engineeringa-one-year-pwa-retrospective-f4a2f4129e05[5] 2018 Wechat 1 million sub-apps httpswwwscmpcomtecharticle2153705

tencents-wechat-now-host-1-million-mini-programs[6] 2018 WeChat reaches 1M sub-apps half the size of Applersquos App Store https

techcrunchcom20181107wechat-mini-apps-200-million-users[7] 2018 Xposed httpsapixposedinforeferencepackageshtml[8] 2019 AdBlock httpsgetadblockcom

13

different app-in-app vendors bring in their own APIs for accessinga wide spectrum of systems resources (see our comparison betweensub-app API and HTML5 API in Table 7 in Appendix) often withoutproper safeguard in place not to mention any effort to standardizethe protectionbull Sub-window deception The risk comes from the UI confusionwhether a window portion in the sub-app window belongs to thesub-app or the host (Figure 3b) To mitigate the risk we envision ahigher degree of UI isolation between the sub-app and the host thesub-apprsquos window should always be separated from that of the hostand the host should never reclaim any window portion from thesub-applsquos window Regarding the Wallet UI confusion (Section 32)for example Wechat should display its wallet UI only in its ownwindow and advertise to users that any UI component inside thesub-app window belongs to the sub-app

A question arises whether a malicious sub-app can fake a crashand then show spoofing content in the sub-app window to resem-ble the host This can be mitigated through additional protectionsupported by the host Specifically the host app could keep mon-itoring the UI of its sub-apps (eg through PixelCopy API onAndroid [71]) to detect whether a UI object in the sub-app is similarto a sub-window or a security-sensitive UI object associated withhost app For performance concern the host app could utilize thestate-of-the-art object detection model (eg Fast Region-based Con-volutional Network based model [61] and YOLO [32 95]) for thereal-time security-sensitive UI object recognition as reported inprior research [95] Fast YOLO yields the performance of 155 framesper second Note that the effectiveness efficiency and deploymentfeasibility of such an approach need to be carefully explored andevaluated which we leave for our future researchbull Sub-app lifecycle hijacking To mitigate this risk a short-termdefense is to place all sub-app resources in the phonersquos internalstorage so our current exploit (leveraging monitoring the phonersquosexternal storage) to track sub-app lifecyle termination (Section 33)can be mitigated However it is always a concern that sub-appsmay deplete the limited space on a phonersquos internal storage Along term solution needs to consider how to make the sub-apptasks dynamically scalable to ensure that the sub-app recycling isno longer traceable and thus the attack surface is fundamentallyeliminated This nonetheless calls for support from modern OSesfor the emerging app-in-app paradigm

6 RELATEDWORKAs mentioned in Section 2 recent years witnessed several tech-niques to support the functionality of app encapsulation (eg Plu-gin frameworks app sandboxing browser extension and PhoneGapapp see Table 2) Accordingly numerous studies have looked intothe flaws in these app encapsulation systems considering the se-curity analysis of Plugin frameworks a set of flaws were revealed[99 111 112] including no permission management and no isola-tion of the virtualized apps Compared with Plugin frameworks theapp-in-app paradigm has a much stronger security model and ourstudy investigates the design challenges and pitfalls in the securitymechanism Meanwhile the security and privacy implications ofbrowser extensions have been extensively studied [48 54 84 98]

Furthermore the current security studies on PhoneGap apps fo-cus on the flaws of PhoneGap frameworkrsquos access control policy[60 90 100 101] For example Song et al [101] revealed that thebridges added by the framework to the browser are not correctlyprotected by the same origin policy Jin et al [86] introduced mul-tiple channels (eg barcode SMS file system Contact) for codeinjection attacks in PhoneGap apps Different from these works wefocus on the unique features of the app-in-app paradigm (Table 2)and reveal multiple new attack surfaces which have never beenstudied before

The closer to our study are the works of Web App and WebViewvulnerability assessment Up to our knowledge only one paper[87] analyzed security issue of Web App in which the securityand privacy risks on HTML5 features in PWA were investigatedIn our attack on Web App we did not focus on HTML5 featuresbut a general UI isolation and management model in app-in-appparadigm Also although WebView technique is used in some ofthe app-in-app systems in sharp contrast to the works on Webviewweaknesses [36 60 88 102 105 109 110] our study explores thesecurity implications and challenges for a third-party app tomanageoperating system resources Another set of works related to ourstudy is the exploitation of mobile UI deception Prior phishingattacks [38 49 53 57 97] mislead victims about the foregroundapp aiming at information theft in spoofing apps Correspondingcountermeasures [49 58 96] emphasize identifying the app of thewhole foreground window and thus cannot thwart Sub-windowDeception due to the inability to identify sub-windows Furtheranother angle of UI deception is clickjacking [59 94] which aredifferent from our mobile-phishing attacks7 CONCLUSIONIn this paper we present the first systematic security analysis on re-source management in high-profile app-in-app systems Our studyshows that such systems are susceptible to a set of serious securityflaws Our measurement study further sheds light on their perva-siveness in the real-world Further our study brings in new insightsinto the fundamental security limitations of this new paradigm andfurther contributes to a better understanding of its mitigation strat-egy an important step towards building a more secure app-in-appecosystem

8 ACKNOWLEDGMENTWe would like to thank our shepherd Yanick Fratantonio and theanonymous reviewers for their insightful comments This work issupported in part by the NSF CNS-1618493 1801432 1838083

REFERENCES[1] 2011 HTML5 Fullscreen API Attack httpsferossorghtml5-fullscreen-api-

attack[2] 2011 The Inception Bar httpsjameshfishercom20190427the-inception-

bar-a-new-phishing-method[3] 2018 Java Runnable httpsdocsoraclecomjavase7docsapijavalang

Runnablehtml[4] 2018 A one year PWA retrospective httpsmediumcompinterest-

engineeringa-one-year-pwa-retrospective-f4a2f4129e05[5] 2018 Wechat 1 million sub-apps httpswwwscmpcomtecharticle2153705

tencents-wechat-now-host-1-million-mini-programs[6] 2018 WeChat reaches 1M sub-apps half the size of Applersquos App Store https

techcrunchcom20181107wechat-mini-apps-200-million-users[7] 2018 Xposed httpsapixposedinforeferencepackageshtml[8] 2019 AdBlock httpsgetadblockcom

13

[9] 2019 Alibabarsquos alternative to the app store reaches 230M daily users httpstechcrunchcom20190129alibaba-alipay-mini-programs-230m-users

[10] 2019 Android Location permissions httpsdevelopersgooglecommapsdocumentationandroid-sdklocation

[11] 2019 Apache Cordova httpscordovaapacheorg[12] 2019 Apina Supporting Website httpssitesgooglecomviewappinapp[13] 2019 Browser Extension JavaScript APIs httpsdevelopermozillaorgen-US

docsMozillaAdd-onsWebExtensionsBrowser_support_for_JavaScript_APIs[14] 2019 Browser Plug-in httpsdevelopermozillaorgen-USdocsPluginsGuide

Plug-in_BasicsUnderstanding_the_Runtime_Model[15] 2019 Droid Plugin httpdroidpluginteamgithubioDroidPlugin[16] 2019 EditThisCookie httpwwweditthiscookiecom[17] 2019 Entitlements httpsdeveloperapplecomdocumentation

bundleresourcesentitlements[18] 2019 External-Storage httpsdeveloperandroidcomguidetopicsdatadata-

storage[19] 2019 Ionic httpsionicframeworkcom[20] 2019 JavaScript httpsenwikipediaorgwikiJavaScript[21] 2019 JavaScript data types and data structures httpsdevelopermozillaorgen-

USdocsWebJavaScriptData_structures[22] 2019 MorzillaSecurity Funfuzz httpsgithubcomMozillaSecurityfunfuzz

blobmastersrcfunfuzzjssharedrandomjs[23] 2019 Parallel Space App httpparallelspace-appcom[24] 2019 PhoneGap httpsphonegapcom[25] 2019 Pinduoduo httpswwwdigitalcommerce360com20190416why-china-

ecommerce-is-going-crazy-for-wechat-miniE28091programs[26] 2019 Virtual App httpsgithubcomasLodyVirtualApp[27] 2019 WeChat became the 5th most-used app in the world httpswww

dragonsocialnetblogwechat-mini-programs[28] 2019 WeChat Mini-programs and social e-commerce httpswalkthechatcom

wechat-mini-programs-simple-introduction[29] 2019 WeChat Mini Programs The Complete Guide for Business https

topdigitalagencywechat-mini-programs-the-complete-guide-for-business[30] 2019 Wechat sub-app review process httpsdevelopersweixinqqcom

miniprogramenproductrejecthtml[31] 2019 What is a Hybrid Mobile App httpswwwtelerikcomblogswhat-is-a-

hybrid-mobile-app-[32] 2019 YOLOv3 An Incremental Improvement httpspjreddiecommediafiles

papersYOLOv3pdf[33] 2020 Android version distribution httpsgsstatcountercomos-version-

market-shareandroid[34] 2020 OCR SPACE httpsocrspace[35] Yousra Aafer Guanhong Tao Jianjun Huang Xiangyu Zhang and Ninghui

Li 2018 Precise Android API Protection Mapping Derivation and Reason-ing In Proceedings of the 2018 ACM SIGSAC Conference on Computer andCommunications Security ACM 1151ndash1164

[36] Yasemin Acar Michael Backes Sven Bugiel Sascha Fahl Patrick McDaniel andMatthew Smith 2016 Sok Lessons learned from android security research forappified software platforms In 2016 IEEE Symposium on Security and Privacy(SP) IEEE 433ndash451

[37] Jagdish Prasad Achara Mathieu Cunche Vincent Roca and Aureacutelien Francillon2014 Short paper WifiLeaks underestimated privacy implications of the ac-cess_wifi_state android permission In Proceedings of the 2014 ACM conferenceon Security and privacy in wireless amp mobile networks ACM 231ndash236

[38] Simone Aonzo Alessio Merlo Giulio Tavella and Yanick Fratantonio 2018Phishing Attacks on Modern Android In Proceedings of the 2018 ACM SIGSACConference on Computer and Communications Security (CCS rsquo18) ACM NewYork NY USA 1788ndash1801 httpsdoiorg10114532437343243778

[39] Apple 2014 Objective-C httpsdeveloperapplecomlibraryarchivedocumentationCocoaConceptualProgrammingWithObjectiveCIntroductionIntroductionhtml

[40] Apple 2018 Swift httpsdeveloperapplecomswift[41] Apple 2019 Apple Entitlements httpsdeveloperapplecomlibraryarchive

documentationMiscellaneousReferenceEntitlementKeyReferenceChaptersAboutEntitlementshtml

[42] Apple 2019 Microphone Usage Entitlement httpsdeveloperapplecomdocumentationavfoundationavaudiosession1616601-requestrecordpermission

[43] Apple 2019 NEHotspot Requirement httpsdeveloperapplecomlibraryarchiveqaqa1942_indexhtml

[44] Apple 2019 Web Clip httpsdeveloperapplecomlibraryarchivedocumentationAppleApplicationsReferenceSafariWebContentConfiguringWebApplicationsConfiguringWebApplicationshtml

[45] Kathy Wain Yee Au Yi Fan Zhou Zhen Huang and David Lie 2012 Pscoutanalyzing the android permission specification In Proceedings of the 2012 ACMconference on Computer and communications security ACM 217ndash228

[46] Michael Backes Sven Bugiel Erik Derr Patrick D McDaniel Damien Octeauand Sebastian Weisgerber 2016 On Demystifying the Android Application

Framework Re-Visiting Android Permission Specification Analysis In 25thUSENIX Security Symposium 1101ndash1118

[47] Michael Backes Sven Bugiel Christian Hammer Oliver Schranz and Philippvon Styp-Rekowsky 2015 Boxify Full-fledged app sandboxing for stock androidIn 24th USENIX Security Symposium 691ndash706

[48] Sruthi Bandhakavi Nandit Tiku Wyatt Pittman Samuel T King P Mad-husudan and Marianne Winslett 2011 Vetting Browser Extensions for Se-curity Vulnerabilities with VEX Commun ACM 54 9 (Sept 2011) 91ndash99httpsdoiorg10114519953761995398

[49] Antonio Bianchi Jacopo Corbetta Luca Invernizzi Yanick Fratantonio Christo-pher Kruegel and Giovanni Vigna 2015 What the app is that deception andcountermeasures in the android user interface In 2015 IEEE Symposium onSecurity and Privacy IEEE 931ndash948

[50] Antonio Bianchi Yanick Fratantonio Christopher Kruegel and Giovanni Vi-gna 2015 Njas Sandboxing unmodified applications in non-rooted devicesrunning stock android In Proceedings of the 5th Annual ACM CCS Workshopon Security and Privacy in Smartphones and Mobile Devices ACM 27ndash38

[51] ByteDance 2019 Tiktok sub-app review process httpsdevelopertoutiaocomdevcnmini-appoperationagreementagreement

[52] Qi Alfred Chen Zhiyun Qian and Z Morley Mao 2014 Peeking into Your Appwithout Actually Seeing It UI State Inference andNovel Android Attacks In 23rdUSENIX Security Symposium (USENIX Security 14) USENIX Association SanDiego CA 1037ndash1052 httpswwwusenixorgconferenceusenixsecurity14technical-sessionspresentationchen

[53] Qi Alfred Chen Zhiyun Qian and Zhuoqing Morley Mao 2014 Peeking intoYour App without Actually Seeing It UI State Inference and Novel AndroidAttacks In USENIX Security Symposium 1037ndash1052

[54] Vladan Djeric and Ashvin Goel 2009 Securing script-based extensibility inweb browsers University of Toronto

[55] Facebook 2019 React Native httpsfacebookgithubioreact-native[56] Adrienne Porter Felt Erika Chin Steve Hanna Dawn Song and David Wag-

ner 2011 Android permissions demystified In Proceedings of the 18th ACMconference on Computer and communications security ACM 627ndash638

[57] Adrienne Porter Felt and David Wagner 2011 Phishing on mobile devices na[58] Earlence Fernandes Qi Alfred Chen Justin Paupore Georg Essl J Alex Halder-

man Z Morley Mao and Atul Prakash 2016 Android ui deception revisitedAttacks and defenses In International Conference on Financial Cryptographyand Data Security Springer 41ndash59

[59] Yanick Fratantonio Chenxiong Qian Simon P Chung and Wenke Lee 2017Cloak and dagger from two permissions to complete control of the UI feedbackloop In 2017 38th IEEE Symposium on Security and Privacy (SP) IEEE 1041ndash1057

[60] Martin Georgiev Suman Jana and Vitaly Shmatikov 2014 Breaking and fixingorigin-based access control in hybrid webmobile application frameworks InNDSS symposium Vol 2014 NIH Public Access 1

[61] Ross Girshick 2015 Fast r-cnn In Proceedings of the IEEE internationalconference on computer vision 1440ndash1448

[62] Google 2018 Android Developers httpsdeveloperandroidcom[63] Google 2018 Android MediaProjection httpsdeveloperandroidcom

referenceandroidmediaprojectionMediaProjection[64] Google 2018 Android Recents Screen httpsdeveloperandroidcomguide

componentsactivitiesrecents[65] Google 2018 Android Signature Permissions httpsdeveloperandroidcom

guidetopicspermissionsoverviewsignature_permissions[66] Google 2018 Android UsbManager httpsdeveloperandroidcomreference

androidhardwareusbUsbManager[67] Google 2018 Progressive Web App httpsdevelopersgooglecomweb

progressive-web-apps[68] Google 2018 PWA Checklist httpsdevelopersgooglecomwebprogressive-

web-appschecklist[69] Google 2018 PWAWebAPK httpsdevelopersgooglecomwebfundamentals

integrationwebapks[70] Google 2018 Security Enhancements in Android 60 httpssourceandroid

comsecurityenhancementsenhancements60[71] Google 2019 Android PixelCopy API httpsdeveloperandroidcomreference

androidviewPixelCopy[72] Google 2019 Android Record Audio Permission httpsdeveloperandroid

comreferenceandroidManifestpermissionhtmlRECORD_AUDIO[73] Google 2019 Android Requiement of Accquiring Dangerous Level Permission

httpsdeveloperandroidcomguidetopicspermissionsoverview[74] Google 2019 Android Version Fragmentation httpsdeveloperandroidcom

aboutdashboards[75] Google 2019 Android WifiManager Documentation httpsdeveloperandroid

comreferenceandroidnetwifiWifiManager[76] Google 2019 Dangerous Permission Level httpsdeveloperandroidcom

guidetopicspermissionsoverviewdangerous_permissions[77] Google 2019 Manifestpermission httpsdeveloperandroidcomreference

androidManifestpermission

14

[78] Google 2019 Progressive Web Apps httpsdevelopersgooglecomwebfundamentalsapp-install-bannerspromoting-install-mobile

[79] Google 2019 WebView httpsdeveloperandroidcomreferenceandroidwebkitWebView

[80] Google 2020 Android 60 Change httpsdeveloperandroidcomaboutversionsmarshmallowandroid-60-changesbehavior-hardware-id

[81] Google 2020 Android InetAddress API httpsdeveloperandroidcomreferencejavanetInetAddressgetCanonicalHostName()

[82] Google 2020 Privacy changes in Android 10 httpsdeveloperandroidcomaboutversions10privacychanges

[83] Google 2020 Security and Privacy Enhancements in Android 10 httpssourceandroidcomsecurityenhancementsenhancements10filesystem-restrictions

[84] Arjun Guha Matthew Fredrikson Benjamin Livshits and Nikhil Swamy 2011Verified security for browser extensions In 2011 IEEE symposium on securityand privacy IEEE 115ndash130

[85] Itseez 2015 Open Source Computer Vision Library httpsgithubcomitseezopencv

[86] Xing Jin XuchaoHu Kailiang YingWenliangDu Heng Yin andGautamNageshPeri 2014 Code injection attacks on html5-based mobile apps Characterizationdetection and mitigation In Proceedings of the 2014 ACM SIGSAC Conferenceon Computer and Communications Security ACM 66ndash77

[87] Jiyeon Lee Hayeon Kim Junghwan Park Insik Shin and Sooel Son 2018 Prideand Prejudice in Progressive Web Apps Abusing Native App-like Featuresin Web Applications In Proceedings of the 2018 ACM SIGSAC Conference onComputer and Communications Security ACM 1731ndash1746

[88] Tongxin Li Xueqiang Wang Mingming Zha Kai Chen XiaoFeng Wang LuyiXing Xiaolong Bai Nan Zhang and Xinhui Han 2017 Unleashing thewalking dead Understanding cross-app remote infections on mobile web-views In Proceedings of the 2017 ACM SIGSAC Conference on Computer andCommunications Security ACM 829ndash844

[89] Meng Luo Oleksii Starov Nima Honarmand and Nick Nikiforakis 2017 Hind-sight Understanding the evolution of ui vulnerabilities in mobile browsersIn Proceedings of the 2017 ACM SIGSAC Conference on Computer andCommunications Security 149ndash162

[90] Patrick Mutchler Adam Doupeacute John Mitchell Chris Kruegel and GiovanniVigna 2015 A large-scale study of mobile web app security In Proceedings ofthe Mobile Security Technologies Workshop (MoST)

[91] Yuhong Nan Zhemin Yang Xiaofeng Wang Yuan Zhang Donglai Zhu and MinYang 2018 Finding Clues for Your Secrets Semantics-Driven Learning-BasedPrivacy Discovery in Mobile Apps In NDSS

[92] Katarzyna Olejnik Italo Dacosta Joana Soares Machado Keacutevin Huguenin Mo-hammad Emtiyaz Khan and Jean-Pierre Hubaux 2017 SmarPer Context-awareand automatic runtime-permissions formobile devices In 2017 IEEE Symposiumon Security and Privacy (SP) IEEE 1058ndash1076

[93] Olivia Plotnick 2018 How Brands Are Using WeChat Mini Programs httpsmavsocialcomwechat-mini-programs-for-brands

[94] Andrea Possemato Andrea Lanzi Simon Pak Ho Chung Wenke Lee and YanickFratantonio 2018 ClickShield Are You Hiding Something Towards EradicatingClickjacking on Android In Proceedings of the 2018 ACM SIGSAC Conferenceon Computer and Communications Security ACM 1120ndash1136

[95] Joseph Redmon Santosh Divvala Ross Girshick and Ali Farhadi 2016 Youonly look once Unified real-time object detection In Proceedings of the IEEEconference on computer vision and pattern recognition 779ndash788

[96] Chuangang Ren Peng Liu and Sencun Zhu 2017 Windowguard Systematicprotection of gui security in android In Proc of the Annual Symposium onNetwork and Distributed System Security (NDSS)

[97] Chuangang Ren Yulong Zhang Hui Xue Tao Wei and Peng Liu 2015 TowardsDiscovering and Understanding Task Hijacking in Android In 24th USENIXSecurity Symposium (USENIX Security 15) USENIX Association WashingtonDC 945ndash959 httpswwwusenixorgconferenceusenixsecurity15technical-sessionspresentationren-chuangang

[98] Iskander Sanchez-Rola Igor Santos and Davide Balzarotti 2017 ExtensionBreakdown Security Analysis of Browsers Extension Resources Control PoliciesIn 26th USENIX Security Symposium USENIXAssociation Vancouver BC 679ndash694 httpswwwusenixorgconferenceusenixsecurity17technical-sessionspresentationsanchez-rola

[99] Luman Shi Jianming Fu Zhengwei Guo and Jiang Ming 2019 Jekyll andHyde is Risky Shared-Everything Threat Mitigation in Dual-Instance Apps InProceedings of the 17th Annual International Conference on Mobile SystemsApplications and Services ACM 222ndash235

[100] Kapil Singh 2013 Practical context-aware permission control for hybrid mo-bile applications In International Workshop on Recent Advances in IntrusionDetection Springer 307ndash327

[101] Wei Song Qingqing Huang and Jeff Huang 2018 Understanding JavaScriptVulnerabilities in Large Real-World Android Applications IEEE Transactionson Dependable and Secure Computing (2018)

[102] Guliz Seray Tuncay Soteris Demetriou and Carl A Gunter 2016 DracoA system for uniform and fine-grained access control for web code on an-droid In Proceedings of the 2016 ACM SIGSAC Conference on Computer andCommunications Security ACM 104ndash115

[103] W3C 2017 Web App Javascript API Permissions Working Draft httpswwww3orgTRpermissions

[104] W3C 2019 Web App navigation scope httpswwww3orgTRappmanifestnavigation-scope

[105] Rui Wang Luyi Xing XiaoFeng Wang and Shuo Chen 2013 Unauthorizedorigin crossing on mobile platforms Threats and mitigation In Proceedings ofthe 2013 ACM SIGSAC conference on Computer amp communications securityACM 635ndash646

[106] WHATWG 2020 WHATWG Javascript Fullscreen API Living Standard httpsfullscreenspecwhatwgorgsecurity-and-privacy-considerations

[107] Wiki 2019 Single-Sign-On httpsenwikipediaorgwikiSingle_sign-on[108] Luyi Xing Xiaolong Bai Tongxin Li XiaoFeng Wang Kai Chen Xiaojing Liao

Shi-Min Hu and Xinhui Han 2015 Cracking App Isolation on Apple Unautho-rized Cross-App Resource Access on MAC OS X and iOS In Proceedings of the22Nd ACM SIGSAC Conference on Computer and Communications Security(CCS rsquo15) ACM New York NY USA 31ndash43 httpsdoiorg10114528101032813609

[109] Guangliang Yang and Jeff Huang 2018 Automated generation of event-orientedexploits in android hybrid apps In Proc of the Network and Distributed SystemSecurity Symposium (NDSSrsquo18)

[110] Guangliang Yang Jeff Huang Guofei Gu and Abner Mendoza 2018 Study andmitigation of origin stripping vulnerabilities in hybrid-postmessage enabledmobile applications In 2018 IEEE Symposium on Security and Privacy (SP)IEEE 742ndash755

[111] Lei Zhang Zhemin Yang Yuyu He Mingqi Li Sen Yang Min Yang Yuan Zhangand Zhiyun Qian 2019 App in the Middle Demystify Application Virtualizationin Android and Its Security Threats Proc ACM Meas Anal Comput Syst 3 1Article 17 (March 2019) 24 pages httpsdoiorg10114533222053311088

[112] Cong Zheng Tongbo Luo Zhi Xu Wenjun Hu and Xin Ouyang 2018 AndroidPlugin Becomes a Catastrophe to Android Ecosystem In Proceedings of theFirst Workshop on Radical and Experiential Security (RESEC rsquo18) ACM NewYork NY USA 61ndash64 httpsdoiorg10114532034223203425

[113] Xiaoyong Zhou Soteris Demetriou Dongjing He Muhammad Naveed Xi-aorui Pan XiaoFeng Wang Carl A Gunter and Klara Nahrstedt 2013 Iden-tity location disease and more Inferring your secrets from android publicresources In Proceedings of the 2013 ACM SIGSAC conference on Computeramp communications security ACM 1017ndash1028

15

(a) MediaStoresetRequireOriginal

(b) WebSettingssetGeolocationEnabled

(c) RequestsetDestinationUri

Figure 6 Descriptions of Android APIs that Apinat failed togenerate permission mapping (Part1)

(a) UsbManagerrequestPermission

(b) UsbManagerhasPermission

(c) WifiManageraddNetworkSuggestions

Figure 7 Descriptions of Android APIs that Apinat failed togenerate permission mapping (Part2)

16

(a) WifiManagergetScanResults

(b) WifiManagergetConfiguredNetworks

Figure 8 The identified documentation associated with AC-CESS_FINE_LOCATION permission

Table 7 Examples of system resources accessed by sub-appAPIs in real-world app-in-app systems which aremissing instandardized HTML5

CapabilitiesResources Related Sub-app APIAuthenticationUser Identification 4Background Audio Playback 24Bluetooth Scan 3Contacts 3Clipboard 8iBeacon 5Make Phone Call 4mDns 10Phone Number 2NFC ReadWrite 10Wifi Scan 9Total 82

Table 8 Examples of popular sub-apps in Wechat and corre-sponding endpoint-request sequences 119899 means 119899 continu-ous requests

Sub-app Catergory Endpoint-request sequence

Google Technologynq2kp0q0apilncldnet

drawtogethergoogleminiappscnnq2kp0q0apilncldnet2

SEPHORA Beauty

beacon-mptingyuncomfp-itfengkongcloudcom

apisephoracn5mpsephoracn

sensorsephoracnexperimentappadhoccom

ssl1sephorastaticcnzhlsqqcom

imgsephorastaticcn

Amazon Shopping

api-cslp-emtamazoncnwwwamazoncn

images-cnssl-images-amazoncom2api-cslp-emtamazoncn2

images-cnssl-images-amazoncom2miniappamazoncn

Walmart Retailer

mapighsmpwalmartcomcdnghsmpwalmartcom2

zhlsqqcom2btraceqqcom

statisticghsmpwalmartcom2

McDonaldrsquos Catering

jicefw4me4apiminiappmcdonaldscomcn2

cdnjaxcxcomtrackingmcdonaldscomcn4cdnminiappmcdonaldscomcn

KFC Catering

trackingprdhwwt8comorderskfccomcn

imgorderkfccomcn6fphwwt8com

Airbnb Travel

z1muscachecnapiairbnbcn2

z1muscachecn2wwwairbnbcnz1muscachecnapiairbnbcn3

BMW Automotive

cdnbmwwechatcndcsbmwcomcn

cdnbmwwechatcnappletbmwwechatcncdnbmwwechatcn2

appletbmwwechatcn3cdnbmwwechatcn3

Nike Shopping

analyticsnikecom3makecellapinikecom24insightsnikecom22unitenikecom 29wwwnikecom4

Lofter Blog

hubbleneteasecom4miniloftercom

sentryyuedu163comyaoluyuedu163com

Mongo TV Streaming

0imghitvcom41imghitvcom42imghitvcom43imghitvcom44imghitvcom4

d-weixin-v0logmgtvcom2i5hitvcom

httpmobilesobzmgtvcomstbzmgtvcom

thirdpartapimgtvcom2

17

(a) WifiManagergetScanResults

(b) WifiManagergetConfiguredNetworks

Figure 8 The identified documentation associated with AC-CESS_FINE_LOCATION permission

Table 7 Examples of system resources accessed by sub-appAPIs in real-world app-in-app systems which aremissing instandardized HTML5

CapabilitiesResources Related Sub-app APIAuthenticationUser Identification 4Background Audio Playback 24Bluetooth Scan 3Contacts 3Clipboard 8iBeacon 5Make Phone Call 4mDns 10Phone Number 2NFC ReadWrite 10Wifi Scan 9Total 82

Table 8 Examples of popular sub-apps in Wechat and corre-sponding endpoint-request sequences 119899 means 119899 continu-ous requests

Sub-app Catergory Endpoint-request sequence

Google Technologynq2kp0q0apilncldnet

drawtogethergoogleminiappscnnq2kp0q0apilncldnet2

SEPHORA Beauty

beacon-mptingyuncomfp-itfengkongcloudcom

apisephoracn5mpsephoracn

sensorsephoracnexperimentappadhoccom

ssl1sephorastaticcnzhlsqqcom

imgsephorastaticcn

Amazon Shopping

api-cslp-emtamazoncnwwwamazoncn

images-cnssl-images-amazoncom2api-cslp-emtamazoncn2

images-cnssl-images-amazoncom2miniappamazoncn

Walmart Retailer

mapighsmpwalmartcomcdnghsmpwalmartcom2

zhlsqqcom2btraceqqcom

statisticghsmpwalmartcom2

McDonaldrsquos Catering

jicefw4me4apiminiappmcdonaldscomcn2

cdnjaxcxcomtrackingmcdonaldscomcn4cdnminiappmcdonaldscomcn

KFC Catering

trackingprdhwwt8comorderskfccomcn

imgorderkfccomcn6fphwwt8com

Airbnb Travel

z1muscachecnapiairbnbcn2

z1muscachecn2wwwairbnbcnz1muscachecnapiairbnbcn3

BMW Automotive

cdnbmwwechatcndcsbmwcomcn

cdnbmwwechatcnappletbmwwechatcncdnbmwwechatcn2

appletbmwwechatcn3cdnbmwwechatcn3

Nike Shopping

analyticsnikecom3makecellapinikecom24insightsnikecom22unitenikecom 29wwwnikecom4

Lofter Blog

hubbleneteasecom4miniloftercom

sentryyuedu163comyaoluyuedu163com

Mongo TV Streaming

0imghitvcom41imghitvcom42imghitvcom43imghitvcom44imghitvcom4

d-weixin-v0logmgtvcom2i5hitvcom

httpmobilesobzmgtvcomstbzmgtvcom

thirdpartapimgtvcom2

17

Table 10 Examples of popular sub-apps and correspondinghost apps

Sub-app Category Host AppGoogle Technology WechatMicrosoft Technology WechatSEPHORA Beauty WechatAmazon Shopping WechatDell Manufacturer WechatWalmart Retailer Chrome WechatMcDonaldrsquos Catering Alipay WechatKFC Catering WechatAirbnb Travel WechatGIORGIO ARMANI Luxury WechatBookings Travel Alipay Baidu WechatStarbucks Catering Alipay WechatHSBC Banking Alipay Wechat ChromeHuawei Electronics Alipay WechatSamsung Electronics WechatBMW Automotive Chrome WechatICBC Banking Wechat

18

Table 9 Android dangerous permissions and iOS entitlements requested by vulnerable host apps when first launched andwhen the host appslsquo own functionalities are triggered

Host App Android Permissions When Launched Other Android Permissions iOS Entitlements When Launched Other iOS Entitlements

Alipay

READ_PHONE_STATEWRITE_EXTERNAL_STORAGEREAD_EXTERNAL_STORAGE

CAMERAACCESS_COARSE_LOCATIONACCESS_FINE_LOCATION

RECORD_AUDIOGET_ACCOUNTSREAD_CONTACTSWRITE_CONTACTS

Push NotificationCameraLocation

Photo LibraryContacts

Microphone Usage

Baidu

READ_PHONE_STATEWRITE_EXTERNAL_STORAGEREAD_EXTERNAL_STORAGEACCESS_COARSE_LOCATIONACCESS_FINE_LOCATION

CAMERAGET_ACCOUNTSREAD_CONTACTSWRITE_CONTACTSRECORD_AUDIO

Push NotificationLocation

CameraMicrophone UsagePhoto Library

DingTalkREAD_PHONE_STATE

WRITE_EXTERNAL_STORAGEREAD_EXTERNAL_STORAGE

READ_CALENDARWRITE_CALENDAR

CAMERAGET_ACCOUNTSREAD_CONTACTSWRITE_CONTACTS

ACCESS_COARSE_LOCATIONACCESS_FINE_LOCATION

RECORD_AUDIO

Push NotificationContacts

CalendarsCamera

Microphone UsagePhoto Library

Location

QQREAD_PHONE_STATE

WRITE_EXTERNAL_STORAGEREAD_EXTERNAL_STORAGE

CAMERAGET_ACCOUNTSREAD_CONTACTSWRITE_CONTACTS

ACCESS_COARSE_LOCATIONACCESS_FINE_LOCATION

RECORD_AUDIOREAD_CALENDARWRITE_CALENDAR

Push NotificationContacts

CameraMicrophone UsagePhoto Library

Location

WechatREAD_PHONE_STATE

WRITE_EXTERNAL_STORAGEREAD_EXTERNAL_STORAGE

CAMERAGET_ACCOUNTSREAD_CONTACTSWRITE_CONTACTS

ACCESS_COARSE_LOCATIONACCESS_FINE_LOCATION

RECORD_AUDIOBODY_SENSORS

Push NotificationCameraContacts

Montion amp Fitness

Photo LibraryMicrophone Usage

Location

19

• Abstract
• 1 Introduction
• 2 Mobile App-in-app Systems
• • 21 Architecture
  • 22 Security Model in Resource Management
  • 23 Comparison with Existing App Encapsulation Systems
  • 24 Adversary Model
  • • 3 Design Challenges and Pitfalls
    • • 31 System Resource Exposure
      • 32 Sub-window Deception
      • 33 Sub-app Lifecycle Hijacking
      • • 4 APINA Flaws in the Wild
        • • 41 Identifying System Resource Exposure
          • 42 Finding UI Deception Flaws
          • 43 Measurement of Impact
          • • 5 Lessons and Mitigation Strategy
            • 6 Related Work
            • 7 Conclusion
            • 8 Acknowledgment
            • References

Table 9 Android dangerous permissions and iOS entitlements requested by vulnerable host apps when first launched andwhen the host appslsquo own functionalities are triggered

Host App Android Permissions When Launched Other Android Permissions iOS Entitlements When Launched Other iOS Entitlements

Alipay

READ_PHONE_STATEWRITE_EXTERNAL_STORAGEREAD_EXTERNAL_STORAGE

CAMERAACCESS_COARSE_LOCATIONACCESS_FINE_LOCATION

RECORD_AUDIOGET_ACCOUNTSREAD_CONTACTSWRITE_CONTACTS

Push NotificationCameraLocation

Photo LibraryContacts

Microphone Usage

Baidu

READ_PHONE_STATEWRITE_EXTERNAL_STORAGEREAD_EXTERNAL_STORAGEACCESS_COARSE_LOCATIONACCESS_FINE_LOCATION

CAMERAGET_ACCOUNTSREAD_CONTACTSWRITE_CONTACTSRECORD_AUDIO

Push NotificationLocation

CameraMicrophone UsagePhoto Library

DingTalkREAD_PHONE_STATE

WRITE_EXTERNAL_STORAGEREAD_EXTERNAL_STORAGE

READ_CALENDARWRITE_CALENDAR

CAMERAGET_ACCOUNTSREAD_CONTACTSWRITE_CONTACTS

ACCESS_COARSE_LOCATIONACCESS_FINE_LOCATION

RECORD_AUDIO

Push NotificationContacts

CalendarsCamera

Microphone UsagePhoto Library

Location

QQREAD_PHONE_STATE

WRITE_EXTERNAL_STORAGEREAD_EXTERNAL_STORAGE

CAMERAGET_ACCOUNTSREAD_CONTACTSWRITE_CONTACTS

ACCESS_COARSE_LOCATIONACCESS_FINE_LOCATION

RECORD_AUDIOREAD_CALENDARWRITE_CALENDAR

Push NotificationContacts

CameraMicrophone UsagePhoto Library

Location

WechatREAD_PHONE_STATE

WRITE_EXTERNAL_STORAGEREAD_EXTERNAL_STORAGE

CAMERAGET_ACCOUNTSREAD_CONTACTSWRITE_CONTACTS

ACCESS_COARSE_LOCATIONACCESS_FINE_LOCATION

RECORD_AUDIOBODY_SENSORS

Push NotificationCameraContacts

Montion amp Fitness

Photo LibraryMicrophone Usage

Location

19

• Abstract
• 1 Introduction
• 2 Mobile App-in-app Systems
• • 21 Architecture
  • 22 Security Model in Resource Management
  • 23 Comparison with Existing App Encapsulation Systems
  • 24 Adversary Model
  • • 3 Design Challenges and Pitfalls
    • • 31 System Resource Exposure
      • 32 Sub-window Deception
      • 33 Sub-app Lifecycle Hijacking
      • • 4 APINA Flaws in the Wild
        • • 41 Identifying System Resource Exposure
          • 42 Finding UI Deception Flaws
          • 43 Measurement of Impact
          • • 5 Lessons and Mitigation Strategy
            • 6 Related Work
            • 7 Conclusion
            • 8 Acknowledgment
            • References