Aware: Controlling App Access to I/O Devices on Mobile Platforms
Giuseppe Petracca, Ahmad Atamli, Yuqiong Sun, Jens Grossklags, Trent Jaeger
aa r X i v : . [ c s . O S ] A p r Aware : Controlling App Access to I/O Devices on Mobile Platforms
Giuseppe Petracca ⋆ [email protected] Ahmad Atamli ∗ [email protected] Yuqiong Sun ⋆ [email protected] Jens Grossklags ⋆ [email protected] Trent Jaeger ⋆ [email protected] ⋆ The Pennsylvania State University ∗ University of Oxford
Abstract
Smartphones’ cameras, microphones, anddevice displays enable users to capture and view memo-rable moments of their lives. However, adversaries cantrick users into authorizing malicious apps that exploitweaknesses in current mobile platforms to misuse suchon-board I/O devices to stealthily capture photos, videos,and screen content without the users’ consent. Contem-porary mobile operating systems fail to prevent such mis-use of I/O devices by authorized apps due to lack of bind-ing between users’ interactions and accesses to I/O de-vices performed by these apps. In this paper, we pro-pose
Aware , a security framework for authorizing apprequests to perform operations using I/O devices, whichbinds app requests with user intentions to make all usesof certain I/O devices explicit. We evaluate our defensemechanisms through laboratory-based experimentationand a user study, involving 74 human subjects, whoseability to identify undesired operations targeting I/O de-vices increased significantly. Without
Aware , only 18%of the participants were able to identify attacks fromtested RAT apps.
Aware systematically blocks all theattacks in absence of user consent and supports usersin identifying 82% of social-engineering attacks testedto hijack approved requests, including some more so-phisticated forms of social engineering not yet presentin available RATs.
Aware introduces only 4.79% max-imum performance overhead over operations targetingI/O devices.
Aware shows that a combination of systemdefenses and user interface can significantly strengthendefenses for controlling the use of on-board I/O devices.
Nowadays, mobile platforms are equipped with cameras,microphones and wide screens, which enable a varietyof popular functions, ranging from audio/video record-ing to displaying information to users. Many apps nowutilize these functions to provide services that leverageon-board Input/Output (I/O) devices. For example, manyapps now support voice and video messages, as well as photo/video shooting and editing. Even insurance orbanking apps now utilize mobile platforms’ cameras tocollect sensitive information to expedite claim process-ing or check depositing [15, 17]. Apps able to record thescreen content are also available for remote screen shar-ing or tutorial editing.However, uncontrolled access to on-board I/O devicescan enable malicious apps, with access to these devices,to exfiltrate sensitive information. Adversaries have builtmalware apps, referred to as
Remote Access Trojans (RATs), that abuse authorized access to such devices toextract audio, video, screen content, and more, from mo-bile platforms, such as smartphones and tablets. Mal-ware in the wild both surreptitiously records data froma variety of mobile devices [3, 1, 13], but also performsdirected attacks, such as constructing three-dimensionalmodels of indoor environments [22] and extracting creditcard numbers and PIN numbers [23] from screenshotsor keyboards’ tones. Furthermore, uncontrolled accessesto on-board cameras and microphone can become sen-sitive if apps can stealthily take photos or videos andrecord audio by running a service in background . Addi-tionally, RAT apps can also use social-engineering tech-niques [16] to hijack user-requested activities, such asshowing a soft-button on screen that supposedly allowsthe user to take a picture when in reality the user actionwill trigger voice recording instead through the smart-phone’s microphone.Current defenses do not prevent malicious apps thathappen to be granted access to I/O devices from ex-filtrating sensitive data. Android, iOS, and WindowsPhone OS all require users to authorize apps for accessto I/O devices, such as the camera and microphone, atinstall time or at first use. In many cases, users mayassume that the use of such devices will be important,if not fundamental, for the effective operation of suchapps. Should the user authorize an app, the app can
75% of operations requiring permissions are performed when thescreen is off or apps are running in background as services [36] hen choose when to use the device. In addition, ac-cess to screen content is not even mediated by any ofthe mobile operating systems. More restrictive securitymodels, such as SE Android [29], cannot control appsaccess to such devices further, as they mainly protectthe lower level Android system. Some research systemsaim to prevent unauthorized access to resources, such asthese devices, by empowering apps to assist in the deci-sion making [25, 30, 31]. However, since apps may bemalicious, attacks cannot be prevented by this method.Alternatively, researchers have explored auditing the useof such devices [34] and providing visible indication ofapp behaviors [28], but the former only detects attacksretroactively after the data has been exfiltrated, whereasuser notification alone requires users to pay attention toeach operation’s security status, continuously, to avoidmissing attacks.In this work, we propose the
Aware framework for au-thorizing app requests to perform operations using I/Odevices, which binds app requests with user intentionsto make all uses of I/O devices explicit. To do this, wetake the following steps. First, app requests for oper-ations using I/O devices are intercepted by the
Aware -enabled services to mediate all security-sensitive oper-ations. Second,
Aware makes each app request visibleto the user, independently from the app, to enable usersto express their intents without being spoofed. Third,
Aware makes ongoing operations, targeting I/O devices,visible to users, so they may choose to terminate the op-eration. As opposed to previous solutions,
Aware doesnot depend on apps to govern users, but rather
Aware links app requests and user input. Also,
Aware maintainsthe security status of ongoing operations, so user actionsare only necessary at operation initiation and completion,rather than requiring ongoing user monitoring [28].We have implemented
Aware on Android OS(android-6.0.1 r5 version) and found it to perform effec-tively, by adding a maximum overhead of 4.79% (mini-mum 2.19%). We have performed a user study, involv-ing 74 human subject. Without
Aware , only 18% ofthe study participants were able to identify attacks fromtested RAT apps.
Aware systematically blocks all the at-tacks in absence of user consent and enabled study par-ticipants to identify 82% of social-engineering attackstested to hijack approved requests, including some moresophisticated forms of social engineering not yet presentin available RATs. This paper makes the following con-tributions:• We reverse-engineer two real-world RAT apps andtwo proof-of-concept RAT apps to systematicallystudy and categorize the different techniques usedby adversaries in mounting attacks targeting on-board I/O devices. We identify five security prop-erties that must be satisfied in order to ensure pro- tection against stealthy operations from maliciousapps targeting on-board I/O devices.• We propose
Aware , a security framework, that in-troduces defense mechanisms for enforcing thesefive security properties by mediating app requeststo I/O devices and matching those requests to userconsent, which blocks all unapproved requests andmaintains the security status of ongoing requests tothe user to enable prevention of social-engineeringattacks.• We conduct an extensive user study involving 74human subjects to evaluate: (1) users’ awarenessof RAT attacks targeting I/O devices, (2) effective-ness of RAT attacks targeting on-board I/O devices,and (3) effectiveness of our proposed defense mech-anisms in increasing users’ awareness and controlover sensitive operations targeting I/O devices.• We evaluate our approach on five RAT apps andeight widely-used apps, to show that it is possibleto prevent against attacks from RAT apps withoutcompromising functionality or introducing signifi-cant performance overhead.
In this section, we describe Remote Access Trojans(RATs) to demonstrate attacks that exploit use of I/O de-vices. We then examine the state-of-the-art in permis-sion granting for mobile platforms to understand whysuch malware apps are capable of exploiting I/O deviceson smartphones. We then outline the challenges for de-fenses capable of blocking such attacks.
On smartphones,
Remote Access Trojans (RATs) are ma-licious apps users may be tricked into installing on theirsmartphones that aim to violate users’ privacy and dataconfidentiality. RATs collect security-sensitive informa-tion through on-board I/O devices, such as cameras, mi-crophones, and screen buffers using authorized app per-missions to perform stealthy, malicious operations in-cluding taking photos and videos, recording audio, orcapturing screenshots.Researchers have designed and developed mobileRATs to demonstrate limitations of current access con-trol models adopted in mobile OSs. Examples include:
PlaceRaider [22], which uses the camera and other sen-sors to construct rich, three-dimensional, models of in-door environments; and
Soundcomber [23], which exfil-trates sensitive data, such as credit card and PIN num-bers, from both tones and speech-based interaction withphone menu systems. Real-world RATs are also avail-able online for purchase. Two popular ones, widely dis-cussed in security blogs and anti-virus companies, are:2 endroid [1], which takes photos using the phone’s cam-era, records audio and video, downloads existing photos,records calls, sends texts, etc. and
Krysanec [3], whichtakes photos, records audio through the microphone, lo-cates victims via devices’ GPS, views victims’ contactlist, and intercepts and sends text messages.We reverse engineered and statically analyzed theseRATs. The two real-world RATs were leaked on-line, whereas the two proof-of-concept RATs have beenshared by researchers. From the analysis, we obtaineddetails on how RATs work. We found out that: (1) all analyzed RATs require a specific set of permissions toaccess on-board I/O devices, except when accessing thescreen buffers; (2) all of them run a background servicethat stealthily performs malicious operations to abusepermissions granted at install time or first use; (3) none of their activities is shown on screen; (4) all of them needaccess to the Internet to leak security-sensitive data col-lected; and (5) their stealthy operations are never associ-ated with any user interaction with the smartphone.
Mobile OSes currently support two default mechanismsto grant apps permission to access on-board I/O devices.First, in Android OS, users grant apps permission toaccess I/O devices at install time . Apps receiving per-mission at install time can then access I/O devices at anytime , without further user approval, so users are unableto track how and when sensitive on-board I/O devices areaccessed by apps at runtime. Table 1 summarizes thepermission sets required by the analyzed RAT apps toperform stealthy operations. We found out that: (1) all permissions used by RAT apps to perform stealthy oper-ations are classified as dangerous by the official AndroidOS documentation [4]; (2) users are never notified aboutaccesses to security-sensitive on-board I/O devices atruntime, via on-screen prompts, or notifications; and (3)the same sets of permissions are used by well-known be-nign apps downloaded by millions of users worldwide.We performed an extensive analysis of permission setsused by apps by randomly selecting 74 apps from third-party app stores [11, 10] and 329 apps from the officialGoogle Play [8]. The results cause concern: 83.89% ofapps from the official Google Play store could potentiallytake stealthy screenshots, whereas 25.68% of apps fromthird-party app stores could potentially take stealthy pho-tos (complete analysis results are reported in AppendixA).Second, starting from Android OS 6.0 (Marshmal-low) and in other mobile operating systems, such as Ap-ple iOS and Windows Phone OS, users are prompted Users could notice the Wi-Fi or cellular network icon on the phonescreen status bar, but they do not know what app is responsible for thenetwork traffic, and what data is flowing out through the network.
Table 1: Android Permissions used by RAT apps
Permissions requiredto perform Operation ProtectionLevels UserNotifiedStealthy Photo
CAMERAWRITE EXTERNAL STORAGE
Dangerous NoStealthy Video
RECORD AUDIO, CAMERAWRITE EXTERNAL STORAGE
Dangerous NoStealthy Audio
RECORD AUDIOWRITE EXTERNAL STORAGE
Dangerous NoStealthy Screenshot
WRITE EXTERNAL STORAGE
Dangerous NoRemote Data Transfer
INTERNET
Dangerous No with access requests the first time apps request access toI/O devices. Researchers have shown that, while theseprompts attempt to verify users’ intent, in practice, theycreate an excessive burden on users, which leads to usersignoring these prompts eventually . In addition, thesemobile operating systems allow users to manage permis-sion grants at runtime by accessing a per app or per I/Odevice permission control panel. This feature allows forbetter flexibility in permission granting, since it is nowpossible to revoke, at runtime, permissions granted toapps at install time or first use.Unfortunately, neither of these mechanisms ensurethat sensitive operations targeting on-board I/O devicesare performed only in response to users’ interaction withrunning apps, which must unmistakeably bind the user’sconsent with specific security-sensitive operations tar-geting an I/O devices . In the absence of such binding,malicious apps are free to leverage I/O devices, evenwhile running as background services, once they cantrick users into granting them permissions as shown inFigure 1.Figure 1: Effect of the lack of binding between users’interaction and operations performed by running apps Researchers have identified several attacks targeting on-board I/O devices [22, 23], and proposed various defensemechanisms [25, 26, 29, 5]. Unfortunately, significantattacks are still capable of circumventing proposed de-fenses. Furthermore, most anti-malware tools availablefor smartphones are not able to identify apps behaving asRATs, especially if not advertised and commercialized as Prompts are disruptive and cause excessive fatigue, conditioninguser to simply accept any prompt query, resulting in undermining theusefulness of the prompts [24, 19, 36]. . Similarly, current static analy-sis tools [12, 32, 33, 14] designed to analyze apps’ sourcecode to identify malice are often not able to find stealthyoperations targeting I/O devices .On one hand, several attempts have been made, in thepast, to include users or surrounding environments inthe access control decision mechanism. Unfortunately,User-Driver Access Control (UDAC) [25] is subject tosocial-engineering attacks [28], whereas World-DrivenAccess Control (WDAC) [26] limits the objects that maybe recorded, but does not enable users to control whenapps use I/O devices for recording. However, solutionsto prevent social-engineering attacks [28] currently re-quire users to pay attention to the security status of anoperation throughout its execution, rather than just at thebeginning and end. On the other hand, researchers havealso proposed methods to augment contemporary accesscontrol models based on the Android Permission mech-anism [4, 24] and SE Android [29, 5]. Android Secu-rity Modules (ASM) [30] enable apps to assist in se-curity decision-making, but unfortunately the apps per-forming operations are the adversary we must control;whereas Android Security Framework (ASF) [31], whichoperates at the kernel level, does not have the neces-sary information about higher level events required to de-tect security-sensitive operations performed by processesrunning apps. Additionally, solutions that leverage hard-ware support for app isolation, such as Samsung Knox[18], would prevent apps in one domain from stealingsensitive data from apps in other domains, but RAT appscan still perform stealthy operations within their own do-main.Despite the various efforts above, several open chal-lenges remain to be addressed:• Once apps obtain permission, at install time or at first use , they may stealthily access sensitive I/O de-vices at any time .• Mobile operating systems lack a method to connectuser interactions with security-sensitive operations targeting on-board I/O devices for controlling ac-cess to such operations.• Apps may use social-engineering techniques [16,27, 28] to hijacking user-intended activities andtrick users in authorizing undesired operations.In addition, any effectitve solution to these problemsmust only require user input and attention consistent withnormal application use. We have tested the 15 most popular Android anti-malware tools,complete results are reported in Appendix B. We have tested 2 static and 2 dynamic analysis tools currentlyadopted by researchers and the general mobile app community. Com-plete results are reported in Appendix C.
In this paper, we focus our attention on Android OS dueto its open-source nature, availability, and popularity [2].Similar considerations hold true for other mobile operat-ing systems, such as Apple iOS and Windows Phone OS.In the following subsections, we provide background in-formation useful to understand the mechanisms proposedin this paper.
We briefly describe how processes obtain access to on-board I/O devices in Android OS. For performance andsecurity reasons, only the Linux kernel has direct ac-cess to on-board I/O device drivers. The Hardware Ab-straction Layer (HAL) implements an interface that al-lows system services (privileged Android processes) toindirectly access on-board I/O devices via well-definedAPIs. SE Linux for Android guarantees that only sys-tem services can access on-board I/O devices at run-time. Thus, apps must communicate with system ser-vices, through the Binder mechanism [4], to request ex-ecution of specific operations targeting on-board I/O de-vices. The system services designed to handle requestsfrom apps would then execute the operations on be-half of processes running apps, if and only if, the nec-essary permissions have been granted to the request-ing apps by the user or operating system. Permis-sions are validated by the
Package Manager , part ofAndroid OS, each time apps request to perform oper-ations targeting I/O devices. For instance, for opera-tions targeting the microphone, the
Package Manager checks the apps
AndroidManifest.xml files to verifyif the RECORD AUDIO permission has been granted tothe requesting app. If the required permissions are notgranted to apps, the
Package Manager fires up a securityexception to communicate the operation abortion. An-droid services do not require a permission check for appsto access the screen buffer.
The Android User Interface is composed by three maingraphical elements, as depicted in Figure 2 (A). Differentmanufacturers may different layouts, but all distributionsof the Android OS have the same three main elements.The
Status Bar shows the device’s state, such as bat-tery level and network connectivity. The
Navigation Bar includes three navigation buttons to interact with all cur-rently running apps and the home screen. The
ActivityWindow is the only portion of the screen that processesrunning apps can draw graphical elements on, such as
Activities and
Views inside activities. All activities cre-ated by apps are drawn in the system-managed
ActivityWindow . Activities are organized in a stack managed bythe
ActivityManager system service, the only process al-4
A) (B)
Figure 2: Android User Interface Graphical Elementsand Gestures to bring back the Navigation and StatusBars into view when apps are in full screen modelowed to manage these three main graphical elements.The only activity shown to the user is the one on topof the stack, even though, previously displayed activi-ties might be visible if the new activity on top is onlypartially covering the
Activity Window .The
Activity Window becomes the only graphical el-ement visible on screen when apps go in
Full Screen mode. Starting from version 4.4, the Android OS of-fers apps two approaches to go full screen:
Lean Back and Immersive . In both approaches, all persistent sys-tem bars are hidden. The difference between them is howthe user brings the bars back into view, as shown in Fig-ure 2 (B). In Lean Back mode, users can bring back thebars by simply touching the screen anywhere. Whereas,in
Immersive mode, they can just swipe from any edgewhere a system bar is hidden. This gestures are easy andintuitive, an explanatory message appears on screen thefirst time the app goes full screen.
When designing
Aware , we focus on defending againstany process running an app that has permissions to ac-cess security-sensitive, on-board I/O devices (e.g., cam-era, microphone, and touch screen) based on the follow-ing threat model.We assume that adversaries have no control over theoperating system (e.g., Linux kernel and Android OS)or Android system apps (e.g., SystemUI) and services(e.g., Binder, AudioSystem, MediaServer, SensorMan-ager, InputManager and WindowManager). Next, we as-sume that SEAndroid enforces mandatory access controlover access to on-board I/O devices, preventing unautho-rized access from apps containing native code. There-fore, we assume that only system services can accesson-board I/O devices indirectly through the use of theJava Native Interface (JNI) [7] to the Linux kernel. Fur- Used when users won’t be interacting heavily with the screen whileconsuming content, like while watching a video. Mainly intended for apps in which the user will be heavily inter-acting with the full screen as part of the primary experience, like whileplaying games, viewing images in a gallery, or reading a book. ther, we assume apps can access I/O devices only throughAPIs provided by the standard Android SDK [4]. Finally,we assume that Android system services can enforce ac-cess control policies that are applied at the time that datawould be collected from an I/O device only. We aim tocontrol whether apps can receive data produced by on-board I/O devices, but do not provide any guarantee afterthe app is granted access to the data itself.Adversaries in control of apps may cause threats byexecuting the following operations. First, adversarialapps request use of security-sensitive operations on on-board I/O devices, including accessing devices’ camerato take picture or video recording, devices’ microphonesto record users’ voices or surrounding environments, anddevices’ screens to steal security sensitive informationdisplayed to users. Additionally, adversarial apps mayalter the display to launch social-engineering attacks totrick users into consenting to operations they do not wantby overlaying a frame buffer over another apps’ or sys-tem component’s display or displaying a request for oneoperation then performing a different operation. Aware
Design Overview5.1
Aware
Operation
An overview of the
Aware design is shown in Figure 3.In the overview description, we use Android OS as refer-ence, similar considerations hold for other mobile oper-ating systems available on the market. Typically, a pro-cess
Prc , running an Android app, sends a request to per-form an operation
Opr using a specific I/O device
Dev (step 1 ). An example could be a request from an app(
Prc ) to access the front camera (
Dev ) and take a photo(
Opr ). The request is received by a system service
Srv (e.g., the MediaServer for the camera), one of the privi-leged processes in charge of authorizing and processingaccess requests to system resources. At first, the conven-tional access control mechanisms are activated (step 2 ).For instance, in Android OS, the Android permissionsand the SE Android access control policy checks are ac-tivated. If the result of the conventional access controlenforcement is a denial, then the system service
Srv isnotified of the security exception, which in turn notifiesthe requesting process
Prc of the access denial (step 3 ).Otherwise, if the result of the conventional access controlenforcement is a grant,
Aware is activated in order to im-plement its additional access control conditional checks.The
Aware
Conditional Engine collects informationabout the process
Prc requesting a certain operation
Opr over a target device
Dev (step 4 ) through the systemservice
Srv . Based on this information, the
Aware
Con-ditional Engine then identifies and selects, from the Con-ditional Rule Store, the set of conditional rules
Cnds thatmust be satisfied to allow operation
Opr to be performed5igure 3: Overview of the
Aware
Designon behalf of process
Prc , over the target device
Dev , bythe system service
Srv (step 5 ). Subsequently,
Aware collects the measurements necessary to evaluate if the se-lected conditional rules are satisfied (step 6 ). Measure-ments can involve readings from on-board I/O devicesand sensors, or system events necessary to verify specificenvironmental conditions. If and only if all the selectedconditional rules
Cnds are satisfied, then
Aware gener-ates an authorized session during which the system ser-vice
Srv is authorized to perform the security-sensitiveoperation
Opr , over the target device
Dev , on behalfof process
Prc (step 7 ). During authorized sessions,
Aware verifies that all conditional rules remain satisfiedduring the entire session and notifies users about ongoingoperations (step 8 ). Whenever any of the selected con-ditional rules is not satisfied,
Aware abort the operation
Opr and notifies the service
Srv about the set of unsatis-fied conditional rules via a denial message (step 9 ).
Aware
Conditional Engine
Aware
Conditional Engine uses conditional rules to au-thorize app requests to I/O devices and maintain securitystate during any authorized sessions. To verify the sat-isfaction of conditional rules,
Aware is designed to col-lect inputs from I/O devices, sensors and system servicesat run-time, by using additional hooks placed inside theAndroid framework.
Aware conditional rules are of threetypes: (1)
Preconditions that must be satisfied before anoperation targeting I/O devices is authorized; (2)
Ongo-ing Conditions that must be satisfied while the authorizedoperations targeting I/O devices are being performed, un-til their completion; and (3)
Exit Conditions that must beall satisfied once authorized operations terminate due tousers’ actions or runtime exceptions.
Aware
Preconditions ensure two security properties.
SP1
All app requests to perform security-sensitive oper- ations targeting on-board I/O devices must be authorized.This security property prevents processes from perform-ing such operations stealthly.
SP2
Security-sensitive op-erations performed using on-board I/O devices match ausers’ consenting action. This property ensures that ev-ery such operation is initiated by a user action.
Aware
Ongoing Conditions ensure two additional security prop-erties.
SP3
Ongoing security-sensitive operations target-ing I/O devices are always visible to users. This secu-rity property enables users to check that the authorizedoperation is what they expected, reducing the possibil-ity of undetected social-engineering attacks.
SP4
On-going security-sensitive operations targeting I/O devicesare always logged. Such logging enables users to exam-ine the progress of ongoing security-sensitive operations,which may enable termination of an ongoing operationdeemed suspicious or retrospective analysis of past oper-ations.
Aware
Exit Conditions ensure one more securityproperty.
SP5
All ongoing security-sensitive operationstargeting I/O devices are visible to the user as long asthey run. This property ensures that apps cannot keepoperations running after user terminates them and theuser interface correctly removes only terminated oper-ations from the display. The conditional rules and secu-rity properties above mentioned are summarized, for fu-ture reference, in Table 2. To express
Aware conditionalrules, the Usage Control (UCON) model [20] could beadopted. Aware
Design
We present the
Aware design in terms of four mecha-nisms necessary to fulfill the five security properties.
Complete mediation of all requests to access I/O devicesfrom processes running apps and matching each requestto a user input corresponding to the app request is neces-sary to ensure that only authorized app requests are run,guaranteeing
SP1 . Mediation involves several systemservices, such as services controlling gestures on screen,or handling requests from running processes, when tar-geting on-board I/O devices and sensors. Users’ interac-tion events have to be aggregated and mapped to requestsinstantiated by processes running apps. The SE Androidreference monitor must be extended to ensure completemediation of all security-sensitive operations targetingI/O devices [21]. Identifying the right locations whereto place additional hooks, to mediate every access to I/Odevices, is challenging.Mainly, complete mediation of accesses to I/O devicescan be achieved in two ways: (1) by placing hooks insidethe Android framework and libraries, or (2) by placinghooks inside the Linux kernel and I/O device drivers. Toachieve complete mediation of accesses to I/O devices,which are low-level system resources, the kernel and de-6able 2:
Aware
Conditional Rules and Security Properties
Preconditions Security PropertiesP1 User interacts with process
Prc to request operation
Opr targeting device
Dev
P2 Process
Prc requests Service
Srv to perform operation
Opr over device
Dev
P3 User is aware of what operation
Opr , targeting device
Dev , is going to beperformed by Service
Srv on behalf of process
Prc
P4 User approves operation
Opr on behalf of process
Prc targeting device
Dev
SP1
All app requests to perform security-sensitive operations targetingon-board I/O devices must be authorized
SP2
Security-sensitive operations performed using on-board I/O devicesmatch a users’ consenting actionOngoing ConditionsO1 User has continuous visibility of operation
Opr performedon behalf of process
Prc over device
Dev
O2 The authorized session
Ses , for process
Prc to execute operation
Opr over device
Dev , is logged to allow retroactive actions
SP3
Ongoing security-sensitive operations targeting I/O devices are alwaysvisible to users
SP4
Ongoing security-sensitive operations targeting I/O devices are alwaysloggedExit ConditionsE1 The authorized session
Ses , relative to process
Prc , terminatesE2 Termination of session
Ses is loggedE3 User has visibility that session
Ses has been terminated
SP5
All on-going security-sensitive operations targeting I/O devicesare visible to the user as long as they run vice drivers seem to be the most appropriate place whereto add mediation hooks. However, two main issues arisefrom this approach: (1) low level hooks would not havethe required level of information to map requests to pro-cesses running apps, due to the fact that requests arealways handled by system services on behalf of the re-questing processes; (2) mobile platforms are equippedwith different I/O devices, which would require the op-erating system to be able to support customized hooksdefined for different drivers by driver vendors.In
Aware , hooks are placed at the Android frameworkand libraries level, to avoid the above mentioned issues.
Aware
Hooks provide complete mediation, because sys-tem services are the only path through which processes,running apps, can access I/O devices and sensors, dueto Android framework architecture and MAC rules en-forced by SE Android [5]. We have dynamically ana-lyzed the Android framework and libraries code, rela-tive to SDK APIs handling accesses to I/O devices andsensors, to validate complete mediation, and check thatevery access to the I/O devices and sensors is capturedby one of the 18 hooks introduced. Retaining such log-ging could be used to detect errors, if any exist. Call-backs from hooks inform the
Aware
Conditional Engineabout users interacting with processes running apps, andrequesting operations over I/O devices. These callbacksare used to validate precondition P1 . Aware
Hooks also capture resources acquisition and release by systemservices operating on behalf of processes running apps.Callbacks from these hooks are used to validate precon-dition P2 and exit condition E1 . Satisfying theseconditions is sufficient to reliably bind users interactionwith apps requests to operate over I/O devices, thereforeguaranteeing SP1 . Secure display of operations targeting I/O devices whenthey are requested, when they are ongoing, and whenthey are terminated is necessary to fulfill multiple guar-antees. First, by maintaining visibility of operations after they are authorized, users may identify undesired oper-ations approved by mistake to guarantee
SP3 . Further-more, ensuring that operations are visible to users as longas they run guarantees that there are no stealthy operationon I/O devices ongoing
SP5 . Visibility over accessesto I/O devices from running apps may be provided tousers in four different ways: (1) via notification lights,similar to those used for cameras on laptops or externalUSB cameras; (2) by playing a distinctive sound, simi-lar to the shutter sound produced when taking a photo;(3) by displaying notification icons, similar to the loca-tion icon shown on the status bar; and (4) by visualiz-ing alert messages on screen. Unfortunately, notificationlights, sounds, or notification icons can only alert usersabout accesses to sensitive I/O devices, but cannot con-vey exact information about operations performed, targetdevices, and processes responsible for such operations.Furthermore, the sounds might not be audible in silentor vibrate mode. A better way to convey complete infor-mation about operations performed over I/O devices, byrunning processes, is by displaying on screen alert mes-sages to users.Solutions that make use of the
Activity Window portionof the screen, to display access notifications or alert mes-sages, are subject to user deception attacks, were screenoverlays are used by malicious apps to surreptitiously re-place, or mimic, the GUI of other apps and mount social-engineering attacks, or else mislead the user perceptionof ongoing operations.
Aware avoids this problem by displays
Security Mes-sages to users on the
Status Bar , a reserved portion ofthe screen drawable only by the
WindowManager sys-tem service, a privileged process part of the Android OS.A similar approach has been adopted by Bianchi et al. [28], where the
Navigation Bar has been used to host asecurity indicator as solution against User Interface (UI)deception. However, Bianchi’s solution, as it is, can-not be adopted to provide visibility to users about op-erations targeting I/O devices or to automatically preventoperation programmatically initiated by processes run-7
A) Pending Operation (B) Ongoing Operation
Figure 4: Security Messages displayed on the Status Barning apps, without users interaction. In fact, Bianchi’ssolution does not provide the necessary mechanisms tobind users interaction to access requests for I/O devicesfrom processes running apps.
Aware uses
Security Messages displayed on the
StatusBar to convey, to users, two types of events: (1) pend-ing operations initiated by users; and (2) status feedbackabout ongoing operations authorized by users. A
Secu-rity Message includes the app identifier (e.g., app icon orname) and a text message specifying the target operation.The first type of message makes users aware of the opera-tion resulting from the interaction with a soft-button dis-played by an app on screen. For example, in Figure 4 (A),if the user presses the button depicting a camera, the
Se-curity Message specifies that the Instagram app will takea photo using the smartphone front camera . The secondtype of message informs users about ongoing authorizedsessions targeting on-board I/O devices. As example, inFigure 4 (B), a Security Message is used to inform theuser that the Google Voice Search app is using the mi-crophone to listen to the user voice for commands. Ifmultiple operations are simultaneously targeting differ-ent I/O devices, the
Security Message alternate messagesto make users aware of all the ongoing operations.
Security Messages are used to validate precondition P3 , ongoing condition O1 and exit condition E3 . Sat-isfying these conditions is sufficient to reliably providevisibility to users over sensitive operations targeting I/Odevices, therefore guaranteeing SP3 and
SP5 . Aware
Security Messages are always visible to userseven if apps are in full screen mode. Upon use-initiatedoperations targeting I/O devices (i.e., press soft-button totake a photo),
Aware systematically reactivates the
StatusBar to display a
Security Message specifying the pendingoperation. Thus, any attempt by malicious apps to draw afake
Status Bar with a fake
Security Message would fail,since the original
Status Bar is always drawn on screen. (F) used to indicate front camera and (B) indicate back camera. Figure 5: State Transition Diagram for Security Mes-sages based on User-Initiated Interactions
The requirement for users to approve or abort pendingapp requests for operations on I/O devices by providinguser input through GUI elements, guarantees
SP2 . On-screen prompts could be used to request approval, ev-ery time I/O devices are accessed by a process runningan app, in response to user-initiated interactions. How-ever, while prompts attempt to verify users’ intention,in practice, they create an excessive burden on users,which leads to users ignoring these prompts eventually .Therefore, prompting users every time I/O devices areaccessed seems unreasonable.To avoid excessive burden on users and, at the sametime, enforce a per-access approval, Aware uses a
Ges-ture Identification mechanism to identifying specific se-quence of gestures, by users, on smartphones’ screen.Gestures are intercepted and analyzed, in real-time, to in-fer users’ intention when interacting with apps. Capturedgestures on screen are mapped with undergoing opera-tions performed by apps running in foreground. User-initiated interactions are combined with
Security Mes-sage on screen, as depicted in the state machine diagramin Figure 5. With
Aware , operations targeting I/O devicescan only be initiated by user, pressing and holding downa soft-button on screen. Upon user-initiated operations,
Aware displays the pending operation on a
Security Mes-sage , for a preset time period, after which the operationis abort in absence of user interaction . After looking atthe Security Message users can confirm the operation bysimply releasing the soft-button, or aborting the pendingoperation by sliding their finger out from the soft-buttonarea, as shown in Figure 6 (A).We could have designed
Aware in order to have twodifferent areas of the screen where users could place theirfinger to either deny or allow operations, as shown infigure 6 (B). This solution would have been subject tosocial-engineering attacks because the two areas wouldappear in the
Activity Window , allowing malicious appsto overlay fake messages, and swap the deny area withthe allow area to trick the user into allowing an operation.The
Aware
Gesture Identification mechanism alsosupport an alternative method that makes use of the fin-gerprint scanner to authenticate users interacting with On average, there are 8 requests per minute by processes runningapps to request permission to access sensitive resources [36]. The timer is used to support apps that require users to keep press-ing down a button to perform the operation (i.e., record a video). A) (B) (C)
Figure 6: Alternative Approaches to retrieve Users InputsmartphonesUsers scan their finger to confirm pendingoperations displayed on
Security Messages , as illustratedon the right side of Figure 6 (C).
Aware interprets theabsence of specific sequences of gestures, from users,how operations not matching users’ intention and vo-lition, therefore, blocks and logs attempts from mali-cious apps trying to programmatically activate security-sensitive operations targeting on-board I/O device. The
Gesture Identification mechanism is used to validate pre-condition P4 , which in conjunction with P1 , P2 and P3 are sufficient to guarantee that operations performedover on-board I/O devices match users’ intention and vo-lition, therefore guaranteeing SP2 .For users willing to lower the security of their mobileplatforms,
Aware allows to disable the
Gesture Identifi-cation mechanism per-app or when a remote controller(i.e., Bluetooth selfie stick) is used. However, we dis-courage white listing apps, even after a certain period ofusage, because apps can dynamically change their behav-ior during time, due to automatic, periodic, software up-dates. Furthermore, apps could ask another apps to per-form specific operations targeting I/O devices, throughthe intent mechanism. Thus, a white listed app could betricked in serving a request coming from a malicious app.
The requirement to log actions occurring during the ex-ecution of operations targeting I/O devices, guarantees
SP4 . To support retroactive actions by users,
Aware generates three type of access logs for security-sensitiveoperation targeting on-board I/O devices. First,
Aware logs any failed attempt by running processes in access-ing I/O devices, due to lack of necessary conditions re-quired to allow requested operations. These logs are ac-cessible in the
Blocked Accesses section, shown in Fig-ure 7, and allow users to identify apps that attemptsto perform stealthy operations while running as back-ground services. Second,
Aware logs any operation de-nied by users though the
Gesture Identification mecha-nism. These logs are accessible in the
Denied Accesses section, shown in Figure 7, and allow users to identify apps using social-engineering techniques to trick themin authorizing undesired operations. Third,
Aware logany operation performed over I/O devices, authorized byusers though the
Gesture Identification mechanism, al-lowing users to track authorized operations.To better catch users’ attention, attempted access vi-olations are signaled by
Aware by producing a soundand showing a
Security Message communicating unde-sired behaviors from running apps. The
Aware
Logs canbe accessed by users anytime, from the app menu or bytapping on the
Security Message displayed on the
StatusBar . Each access log entry reports information regardingapps ID, date, time and operations performed by apps, asshown in Figure 7.Figure 7: On-Board I/O Devices Access Logs
Aware
Logs allow users to perform two retrospectiveactions: (1) uninstall apps identified as malicious, and(2) revoke granted permissions to prevent future unde-sired accesses . Retrospective actions can be taken byusers either immediately, when the I/O devices is still be-ing used by apps to block undesired operations, or afterreviewing what apps are doing over time.The Aware
Log mechanism is used to validate Ongo-ing Condition O2 and Exit Condition E2 . Satisfyingthese conditions is sufficient to allow users to performretrospective actions over sensitive operations targetingI/O devices, therefore guaranteeing SP4 . We have implemented a prototype of
Aware by modify-ing a recent release of standard Android OS (versionandroid-6.0.1 r5) available through the Android OpenSource Project (AOSP) [6]. The Aware prototype in-cludes new components and modifies some pre-existingsystem services, libraries and the SystemUI app. Theirfootprint is about 325 LOC in C, 680 LOC in C++ and This mechanism supports the Android AppOps mechanism rein-troduced starting from Android OS 6.0 Marshmallow [4], which allowsto revoke permissions granted at install time, to running apps. A script to automatically integrate
Aware on top of previous ver-sions of Android framework components and libraries is also available.
Aware source code will be made available on github.com.
982 LOC in Java. We tested the
Aware prototype on aNexus 5 and Nexus 5X smartphones. In the follow-ing paragraphs, we briefly describe the new and modified Aware components.
Aware
Hooks are placed inside the original
AudioSys-tem, MediaServer and
SensorManager system servicesto capture the acquisition and release of I/O devices andthe reading of sensor data. Other hooks are placed in-side the original
InputManager and
GestureDetector tocapture users’ input events. Hooks retrieve the PID ofthe calling processes, operations requested
Opr and tar-get devices
Dev , which are then passed as a parametersin a call back to the
Aware
Conditional Engine.
Aware
Security Messages are implemented by modi-fying the
SurfaceManager, SurfaceFlinger, WindowMan-ager and the
SystemUI . In particular, an ImageView hasbeen added to the Status Bar to display app IDs. Fur-thermore, a TextView has been added to display ongoingoperations, and the service handling the status bar hasbeen modified to receive and handle intent actions sentby the
Aware
Conditional Engine .The
Aware
Conditional Engine is a new componentadded to the original Android framework. It includes:(1) the
Callback Handler in charge of processing call-backs from
Aware hooks, (2) the
Verification Service , incharge of validating preconditions, ongoing conditions,and exit conditions based on the information retrievedfrom callbacks by
Aware
Hook ; and (3) the
ConditionalRule Store , designed to store and retrieve conditionalrules used to enforce control over I/O devices.The
Aware
Gesture Identification module is imple-mented by modifying the
InputManager, NativeInput-Manager, FingerprintManager, InputFlinger and
Ges-tureDetector , to translate raw input data into higher-levelevents (key press, gesture, and such), and then propa-gates them to the
Conditional Engine through callbacks.
We performed a comprehensive laboratory-based survey,user study, and system experiments with the followingfive objectives. First, we survey users’ privacy and se-curity attitudes as they pertain to the malicious use ofI/O devices, and investigate users’ awareness about RATattacks. Second, we observe users’ vigilance during aseries of interactive tasks, while RAT attacks targetingon-board I/O devices are deployed and the
Aware de-fense mechanisms are not active. Third, we investigatethe effectiveness of
Aware from two perspectives. Ini-tially, during another series of interactive tasks, we ob-serve whether users notice and can adequately respondto customized social-engineering attacks, when those can Equipped with a fingerprint scanner. be thwarted with the user interface components of
Aware .We then debrief users about their experience with
Aware .Fourth, we measure whether
Aware effectively and sys-tematically shields users from practically deployed RATattacks, while they perform the second series of interac-tion tasks. Fifth, we measure the performance overhead
Aware incurs on the critical paths of processing app re-quests.
The study has three survey components, two interactiveuser task sequences, and one group of measured tasks.We obtained IRB approval at our institution.
Surveys:
Individuals completed an initial question-naire with demographic questions and questions abouttheir usage of mobile platforms. A second survey de-briefed participants about the first series of interactivetasks, performed using an of-the-shelf Android smart-phone and investigated their privacy and security atti-tudes. A third survey debriefed participants about thesecond series of interaction tasks, performed using asmartphone running
Aware , and their perceptions about
Aware . The surveys included standard Likert-type psy-chometric scale questions (e.g., to measure attitudes) aswell as open-ended question formats (e.g., to solicit par-ticipants’ experiences during the interactive tasks). Sur-veys were implemented on Qualtrics and executed on alab computer.
Interactive Tasks:
In the first series of interactivetasks, we studied participants’ potential reactions topractically deployed RAT attacks. Participants wereasked to interact with a Nexus 5 smartphone, runninga vanilla version of the Android OS (6.0.1 r25), and toperform 9 tasks ranging from taking a picture with thesmartphone’s camera to sending an email. The first 5tasks (T1-T5), summarized in Table 3, were not associ-ated with any RAT attacks. Tasks T6-T10 were associ-ated with 4 different, visibly noticeable attacks (A1-A4),also summarized in Table 3. These attacks were care-fully triggered by the experimenter, while participantsengaged in the interactive tasks. The attacks varied inthe degree to which they are perceivable, as highlightedin Table 3. Please note that individuals were not explic-itly instructed about the presence of RAT attacks beforethe tasks, however we asked them to report unusual be-haviors verbally and in the survey.Before the second series of interactive tasks, subjectswere debriefed about the previously experienced attacks.We further familiarized them with the
Aware systemthrough instructional materials and by allowing them toinspect the
Aware user interface on a Nexus 5X smart-phone. As before, the participants were engaged in sev-eral interactive tasks. First, participants engaged in tasksT1-T5 and T10, which did not present any noticeable
Task ID Task Description App Used Attack Source Attack Description Perceivable Detection Rate
T1 Take a picture Instagram (B) None N/A N/A N/AT2 Take a video Fideo (B) None N/A N/A N/AT3 Record a voice message Messenger (B) None N/A N/A N/AT4 Record a video message Skype (B) None N/A N/A N/AT5 Record the device screen Rec. (B) None N/A N/A N/AT6-A1 Navigate Internet Chrome (B) Krysanec (M) Stealthy Photo Camera Shutter Sound 18%T7-A2 Watch a Video YouTube (B) Soundcomber (M) Stealthy Voice Recording None 0%T8-A3 Add a new contact Contacts (B) Dendroid (M) Stealthy Video Recording UI Slow Down 1%T9-A4 Send email Gmail (B) PlaceRaider (M) Stealthy Photos UI Slow Down 0%T10 Take a screenshot None* None N/A N/A N/AT11-A5 Record a video SimpleFilters † SimpleFilters † Stealthy Screenshot Security Message Mismatch 82%T12-A6 Take a photo SimpleFilters † SimpleFilters † Stealthy Voice Record Security Message Mismatch 76%T13 Analyze
Aware
Logs
Aware
Logs (B) None N/A N/A N/A(B) Benign App (M) Malicious App * Performed by pressing the power and volume-down physical buttons at the same time† SimpleFilters appears as a benign app, but includes functionality to run additional I/O operations beyond those consented by users
RAT behaviors. Then, in tasks T11 and T12, we useda test RAT app to investigate users’ responses to attackswhere the user consented to one action, but the app per-formed additional, unapproved actions. These social-engineering attacks (A5 and A6) aimed to trick usersinto executing unwanted I/O operations, such as record-ing voice when they consented to the app taking a photo.Using the
Aware security message and gesture mecha-nism, we investigated whether participants could noticeand thwart the attacks. The series of tasks concludedwith T13, which did not include any attacks. We didnot brief individuals about which tasks were associatedwith attacks or which I/O devices would be targeted. Wesummarize the 9 tasks and associated attacks in Table 3.We recorded participants’ interactive behaviors, andtheir survey responses. In addition, we applied a think-aloud protocol by encouraging participants to speak outabout their experiences while being engaged in the tasks.
Measured Evaluation:
During the second series oftasks, participants were still exposed to attacks program-matically and persistently triggered from the four RATapps used in our study (i.e., Krysanec, Soundcomber,Dendroid, and PlaceRaider). The
Aware system was ex-pected to shield the user from these attacks, and thereforeno noticeable effects should have been observable by theparticipants. As such, the purpose of the measurementtask is to evaluate whether
Aware effectively and auto-matically shields the participants while they engage inrealistic user interaction behaviors .All participants completed the entire set of study com-ponents in about 25-35 minutes and were compensatedwith a $10 gift card.
Demographics and Mobile Platforms Usage:
In total,74 participants completed the whole set of surveys andtasks. The majority of the sample were between 20-29years old (76%). We recruited predominantly undergrad-uate and graduate students; the majority having an inter-national background (70%), and fields of study different from computer science (75%). Most participants activelyused smartphones (99%) and additional devices associ-ated with third-party apps such as tablets (54%), and to alesser extent smart watches and fitness bands (10%).
Privacy Attitudes:
We asked participants how con-cerned they are about threats to their personal privacywhen using smartphones, and found that 43% were mod-erately or extremely concerned. Participants were evenmore concerned about privacy and security aspects asthey related to third-party apps (57%). Most importantto our study, concern levels were high for the misuse ofsmartphones’ camera (62%) and microphone (55%).
RAT Awareness and Security Behaviors:
The major-ity of the participants stated that they were aware thatapps could access the camera (56%) and the microphone(56%) of their smartphones at any time without repeat-edly asking for consent. However, participants had littleknowledge of specific RATs that exploit smartphones’I/O devices, such as Dendroid and SoundComber (4%each), and Krysanec and PlaceRaider (3% each). A smallnumber of participants (8%) were able to articulate howmalicious apps apply social-engineering techniques tomisled users into taking an action. Only 24% of theparticipants use a mobile anti-malware product, whereas78% of subjects stated that they avoid downloading appsfrom unofficial app stores.
Identification of Threats without
Aware : The attacksin the first series of interaction tasks varied in the de-gree to which risk signals in the vanilla Android systemare perceivable by a user. A1 was associated with thecamera shutter sound when the Krysanec malware took astealthy photo, while participants were browsing the In-ternet. Only 18% correctly noticed that a camera shuttersound was audible. 8% incorrectly thought that a screen-shot was taken. 4% merely noticed a sound. Not a sin-gle participant stated any suspicion in the survey or thethink-aloud comments that malware or a security prob-lem could be responsible for the sound. Two participantsquestioned whether “something” or “someone was tak-ing a screenshot”. Only one participant noticed the UI11low-down (i.e., a perceived glitch in the UI) in task T8-A3 when a stealthy voice recording was initiated by theSoundComber app. None of the participants identifiedany suspicious activity when being involved in attacktasks T7-A2 and T9-A4. An overview of the detectionrates for the RAT attacks is available in Table 3.In summary, audible risk signals (associated with thebuilt-in camera in A1) are noticed by at least some partic-ipants, but their interpretation of the risk, ability to iden-tify the cause or at least to question the cause of the un-expected behavior is highly limited. State-of-the-art mal-ware apps engaging in stealthy voice and video record-ings remained almost entirely unnoticed. PlaceRaider(A4) which also takes stealthy pictures and sidesteps au-dible risk signals was not noticed by any participant.
Interaction of Users with
Aware : Using
Aware sub-stantially simplifies the problem space of unwanted I/Oaccess in two ways. First, any access to an I/O devicewhich is not associated with a user interaction will beautomatically blocked. Thereby, attacks that participantswere encountering in the first series of interactive taskswould be automatically thwarted. We will verify this as-pect of
Aware ’s effectiveness in the subsequent measure-ment results subsection. Second, only user-intended in-teractions which explicitly trigger an I/O device will beallowed to proceed. Note, however, that malicious appscould nevertheless try to hijack these user-intended ac-tivities.
Aware also aims to thwart attacks that coincidewith such user-intended I/O interactions. For this pur-pose,
Aware provides user interface features (i.e.,
Aware security messages and gesture identification) that helpto notice and to block such attacks. In addition, userscan inspect the
Aware log to verify which wanted or un-wanted I/O operations have taken place.To investigate the effectiveness of
Aware when usersencounter such sophisticated attacks (which exploit the context of users’ interactions), we have customized asimple photographic filter app called SimpleFilters. Theapp is modified to attempt to take a screenshot (A5) anda voice recording (A6) stealthily when users intention-ally engage in a different type of I/O interaction. Using
Aware , 82% of the participants noticed the attack whileperforming task T11-A5, and 76% noticed the attackwhile performing task T12-A6. In contrast to the firstseries of user interactions, these participants were alsoable to clearly articulate what attacks took place. A typi-cal debriefing message for attack A5 was: “It was takinga screenshot, while I asked it to take a video”, whereasfor attack A6, messages were a variations of: “
Aware message said the microphone was being accessed”.Inspecting the system logs, we were also able to deter-mine how often participants used the
Aware gestures to block the attacks that they noticed. For A5, all of the 82%of the participants who noticed the attack successfully used the gestures to abort the task. Similarly, all partic-ipants who noticed attack A6 succeeded in blocking theattempt to record audio instead of taking a picture. In thefinal task (T13), we asked individuals to inspect
Aware
Logs to evaluate which I/O access operations had takenplace during the second series of interactions. 88% ofall participants found
Aware
Logs helpful in identifyingsuspicious activities from running apps, and they wereclearly able to articulate what attacks had taken place.After the interaction tasks, we solicited further feed-back from the participants. 90% of the participants found
Aware more secure than the vanilla Android OS, and80% found it as (or more) usable compared to the vanillaAndroid OS. These are encouraging results since ad-ditional security mechanisms often meet with user re-sistance, for example, because they may distract fromthe user’s primary task. Further, 57% of the partici-pants said they would prefer the
Aware notice and ges-ture mechanism compared to other notification options.For example, only 21% of the participants preferred to beprompted with a permission dialog at every access. Fur-ther, only 10% of them stated that they would prefer tobe asked for permission at install time, and 8% of themat first use. Most importantly, 99% of the participantswould like
Aware integrated in their current mobile OS.
Measurements to Evaluate
Aware : To evaluate the ef-fectiveness of
Aware in the presence of realistic user in-teractions, we allowed the 4 RAT apps used in the firstseries of user interaction tasks to also be active during thesecond series of interaction tasks. We also tested whetheractivities from the customized SimpleFilters app wouldbe blocked if they did not coincide with the users’ inter-actions with the I/O devices (i.e., in T11 and T12). In or-der to monitor whether any of the malicious activities ofthese RAT apps were successful, we used logcat [4], theAndroid logging system, which provides a mechanismfor collecting system debug output about activities fromvarious apps and system services. For the 74 sessions in-volving participants, we found that RAT apps attempted1080 times to perform stealthy operations targeting I/Odevices, but they never succeeded in accessing the on-board camera, microphone or screen content, as result ofsystematically validating preconditions P1 and P4 . Inother words, the absence of users’ interaction and con-sent prevented RAT apps from succeeding in performingstealthy operations while running services in the back-ground. Furthermore, based on the logs, there were norun-time exceptions, triggered by the
Aware components,which could have caused any of the 9 well-known legiti-mate apps to crash or unexpectedly terminate.
Summary : Aware prevented all attempts from RATapps to perform stealthy operations that did not coin- See Appendix D for a summary of selected results.
Aware
Performance Overhead in m s. Numbersgive the mean value and corresponding standard devia-tion after 10,000 runs. Vanilla Android OS
Aware
Nexus 5 Nexus 5X Nexus 5 Nexus 5X Max (Min)OverheadFront Camera 15.90 ± ± ± ± ± ± ± ± ± ± ± ± ± ± ± ± cide with users’ intended I/O access operations and con-siderably reduced the success rate of social-engineeringattacks, without breaking any apps’ logic. Therefore, Aware significantly raises the bar compared to the detec-tion rate of state-of-the-art static/dynamic analysis tools,and anti-malware tools, available to users to identify ma-licious apps running on smartphones . We anticipatethat with additional experience users will become evenmore proficient with the Aware security messages andthe gesture mechanism, which would further reduce theeffectiveness of social-engineering techniques. However,the achieved results are very impressive given the sophis-ticated nature of the attacks tested with the SimpleFiltersapp . Aware automatically blocks all attacks whichare not carefully socially-engineered and significantly re-duces the attention burden placed on users, thereby, re-duces habituation and notice fatigue [38].
We have measured the overhead introduced by
Aware while handling each access request for operating on-board I/O devices, such as the camera to take photosand video, the microphone to record audio, and thescreen to capture screenshots. Due to lack of publiclyavailable benchmarks for Android OS, we only pro-vide microbenchmark analysis of such operations for twophones, a Nexus 5 and a Nexus 5X running Android OS(version android-6.0.1 r5). The overhead is calculatedby measuring the time interval from the time the requestis made by the process running the app to the time theoperation is granted/denied by
Aware . Table 4 reportsthe average time over 10,000 requests, the standard devi-ation and the maximum recorded overhead introduced by
Aware . Overall,
Aware introduces a negligible overheadof the order of 1 m s per access. The maximum recordedoverhead is 4.79% while accessing the screen buffers. User-Driven Access Control (UDAC) [25] attempts to in-clude users in the access control decision loop. Applica-tion level access control gadgets (ACGs) are used to ver- Detailed analysis results reported in Appendices B and C. Research on carefully crafted Phishing attacks shows that, evenwith repeated security training, a significant share of users will fall forsuch attacks [37]. ify that actions requested by apps genuinely comes fromusers. However, UDAC is subject to social-engineeringattacks [28, 27, 16], such as draw on top and appswitch , because ACGs are displayed in a portion of thescreen accessible to apps.SemaDroid [34] is a privacy-aware sensor manage-ment framework for smartphones that allows users tomonitor sensors usage by installed apps, and control thedisclosure of sensed data. However, users are supportedin identifying undesired accesses only after apps have al-ready performed operations targeting I/O device.Petracca et al. [35] propose AuDroid, an extension tothe SELinux reference monitor integrated into the An-droid OS, to enforce lattice policies over the dynami-cally changing use of system audio resources (e.g. mi-crophone and speaker). However, AuDroid only dealswith accesses to microphone and speaker from third-party apps and does not provide a solid and general solu-tion for other on-board I/O devices and sensors.Bianchi et al. [28] address the problem of maliciousapps surreptitiously replacing or mimicking the GUI ofother apps to mount phishing and click-jacking attacks.However, Bianchi’s solution cannot systematically pre-vent operations programmatically initiated by processesrunning apps, without users’ interaction, because it doesnot provide the necessary mechanisms to bind users’ in-teraction to access requests for I/O devices from pro-cesses running apps. Moreover, Bianchi’s use visibilityto transfer more responsibility to users when attack sce-narios have to be identified, whereas visibility should beused to support users in making decision only when it isnot possible to prevent attacks systematically.
10 Conclusion
In this paper, we presented
Aware , a security frame-work for authorizing app requests to perform sensitiveoperations using I/O devices, which binds app requestswith user intentions to make all uses of certain I/O de-vices explicit. We evaluated the proposed defense mech-anisms through laboratory-based experimentation and auser study, involving 74 human subjects, whose abil-ity to identify undesired operations targeting I/O devicesincreased significantly. Without
Aware , only 18% ofthe participants were able to identify attacks from testedRAT apps.
Aware systematically blocked all the attacks,in absence of user-initiated interaction, and supportedusers in identifying 82% of more sophisticated attacks,which used social-engineering techniques to hijack user-initiated operations.
Aware introduced only 4.79% max-imum performance overhead over operations targetingI/O devices. Drawing of graphical elements over other apps. Malicious app replaces the legitimate top Activity with one of itsown. eferences AppendicesA Android Permission Set Analysis
The analysis of 74 apps from third-party app stores[11, 10] and 329 apps from the official Google Play [8],shows concerning results, summarized in Table 5. In par-ticular, many of the analyzed apps could potentially be-have as RAT, since they have the necessary permissionsto perform stealthy operations targeting on-board I/O de-vices. For example, from the Google Play, 83.89% ofapps could potentially take stealthy screenshots. Further-more, 25.68% of apps from third-party app stores couldpotentially take stealthy photos. In each cell of Table 5,the first value represents the number, the second valuethe percentage of apps, among all the app analyzed inthe same category, that have the permissions required toperform the stealthy operation specified in the first col-umn. We are not aware if these apps are actually mis-using their permission, but we want to point out that it ispossible for these apps to misuse their permissions to per-form stealthy operations, and by statically analyzing theset of Android permissions used by apps, it is by no meansufficient to distinguish between purely benign apps andmalicious apps.
B Anti-Malware Tools Detection Analysis
The analysis results relative to RAT detection by the 15most popular anti-malware apps, available on GooglePlay [8] and used on smartphones by millions of user14able 5: Market Apps that potentially could behave as RATs and perform stealthy operations
Potential Feature \ Category Game Business Book Comics Commu-nication Edu-cation Enterta-inement TotalThird-Party App StoresStealthy Screenshots 18 (90.00%) 11 (68.75%) 1 (100.00%) 2 (100.00%) 20 (95.24%) 0 (0.00%) 9 (69.23%) 61 (82.43%)Stealthy Photos 0 (0.00%) 4 (25.00%) 0 (0.00%) 1 (50.00%) 13 (61.90%) 0 (0.00%) 1 (7.69%) 19 (25.68%)Stealthy Videos 0 (0.00%) 0 (0.00%) 0 (0.00%) 0 (0.00%) 12 (57.14%) 0 (0.00%) 0 (0.00%) 12 (16.22%)Stealthy Audio 2 (10.00%) 0 (0.00%) 0 (0.00%) 0 (0.00%) 12 (57.14%) 0 (0.00%) 4 (30.77%) 18 (24.32%)Number of Apps 20 16 1 2 21 1 13 74Google Play StoreStealthy Screenshots 38 (95.00%) 33 (91.67%) 25 (83.33%) 30 (90.91%) 61 (87.14%) 52 (67.53%) 37 (86.05%) 276 (83.89%)Stealthy Photos 3 (7.50%) 9 (25.00%) 2 (6.67%) 4 (12.12%) 32 (45.71%) 4 (5.12%) 7 (16.28%) 61 (18.54%)Stealthy Videos 0 (0.00%) 2 (5.56%) 1 (3.33%) 1 (3.03%) 27 (38.57%) 1 (1.30%) 3 (6.98%) 35 (10.64%)Stealthy Audio 0 (0.00%) 3 (8.33%) 2 (6.67%) 3 (9.09%) 30 (42.96%) 6 (7.79%) 4 (9.30%) 48 (14.59%)Number of Apps 40 36 30 33 70 77 43 329 around the world, are summarized in Table 6. The
In-stalls column indicates the number of installs performedby users on their smartphones. The
Reviews columnspecifies how many people gave a personal review and ascore for the anti-malware app on Google Play. Finally,the
Score column reports the average score received bythe app over a scale of 5 by user reviewing the app itself.All the anti-malware apps have been updated with themost recent malware database before starting the scan,indeed 3 anti-malware apps (marked with ⋆ in Table 5)have detected the Stagefright vulnerability [9] that wouldallow malicious code to send fraudulent MMS, only re-cently discovered. The analysis results are based ona first scan before malware installation, and a secondscan during the execution of the malware, when the anti-malware has been kept actively scanning for 10 minutes.Subsequently, three consecutive scans have been per-formed, after malware installation. After the first scan,the anti-malware has been configured to actively keepscanning. We made sure to select full/deep scan fromthe scanning options. The three successive scans havebeen manually activated to force the anti-malware to res-can the entire system. At each new malware installationthe smartphone has been flashed again with a clean copyof the OS and anti-malware software installation.The analysis revealed that most anti-malware toolsare able to detect well-known RATs (e.g., Dendroidand Krysanec). We believe that this is due to thefact that well-known RATs have been classified anda signature has been generated and distributed on theWeb. On the other hand, proof-of-concept RATs (e.g.,PlaceRaider, SoundComber and StealthyStalker) are un-known and gone undetected by anti-malware tools eventhough they use similar techniques used by well-knownRATs. Exceptionally, the AVAST Mobile Security Anti-Malware identifies some malice in both PlaceRaider andStealthyStalker.On the Android OS side, an interesting finding wasthat, at install time, an alert was triggered to block the installation of Krysanec. At the second attempt, the An-droid OS asked the user if to proceed with the installa-tion anyhow. Additionally, while uninstalling the app,Krysanec attacked the operating system by exploitingprivilege escalation. C Static and Dynamic Analysis Tools
The analysis results relative to RAT detection by fourstate-of-the-art static and dynamic analysis tools are re-ported in Table 6.
VirusTotal [12], originally developed by Hispasec andnow own by Google, is a free service that analyzes sus-picious files and URLs and facilitates the quick detec-tion of viruses, worms, trojans, and all kinds of malware.It uses 56 different anti-malware products and 61 onlinescan engines to check for viruses. VirusTotal was se-lected by PC World as one of the best 100 products of2007. As shown in Table 6, VirusTotal detects well-knowRATs (e.g., Dendroid and Krysanec). The two RATs areidentified as malicious with a score of respectively 22/56and 20/56. The nominator in the score fractions refers tothe number of tools that identify the app as potentiallymalicious, the denominator indicates the total number oftools that have analyzed the app.
MassVet [32] compares a submitted app with apps al-ready on a market, focusing on the difference betweenthose sharing a similar UI structure (indicating a possi-ble repackaging relation), and the commonality amongthose seemingly unrelated. MassVet uses a “DiffCom”analysis on top of an efficient similarity comparison al-gorithm, which maps features of an app’s UI structure ora method’s control-flow graph to a value for a fast com-parison. As shown in Table 6, MassVet detects maliciouscode in 3 of the 5 RATs analyzed.
Google Bouncer [14] is a codename used by Google,for a security service introduced early in 2012, to keepmalicious apps off the official Google Play . Bouncer According to Google, Bouncer was responsible for a 40% drop inthe number of malicious apps in its app store.
Legend: ✓ Malware Detected ✗ Malware Undetected ◦ Malware Detected as Privacy Violation ⊗ Anti-malware crashed during Scan P l ace R a i d e r S ound c o m b e r S t ea lt hy S t a l k e r D e nd r o i d K r y s a n ec I n s t a ll s R e v i e w s S c o r e ( S ca l e o f )
360 Security Antivirus Boost ⋆ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ⋆ ✗ ✗ ✗ ✓ ✓ ✗ ✗ ✗ ✓ ✓ ⋆ ✗ ✗ ✗ ◦ ✓ ✗ ✗ ✗ ✓ ✓ ✗ ✗ ✗ ✓ ✓ ✗ ✗ ✗ ✓ ✓ ✗ ✗ ✗ ✓ ✓ ✗ ✗ ✗ ⊗ ✓ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✓ ✓ ✗ ✗ ✗ ✗ ✗ Table 7: RAT Detection via Static and Dynamic Analysis
Static Analysis Dynamic AnalysisVirusTotal MassVet GoogleBouncer CopperDroidPlaceRaider ✗ ✗
N/A N/ASoundComber ✗ ✓
N/A N/AStealthyStalker ✗ ✓ ✗
N/ADendroid ✓ ✗
N/A N/AKrysanec ✓ ✓
N/A N/A
Legend: ✓ Malware Detected ✗ Malware UndetectedN/A Data Not Available quietly and automatically scans apps (both new andpreviously uploaded ones) and developer accounts inGoogle Play with its reputation engine and cloud in-frastructure. To test the effectiveness of Bouncer, indetecting RAT apps, we have implemented a proof-of-concept testing app, called
StealthyStalker , able to takestealthy photos, videos, screenshots, record audio and hi-jack user-initiated operations. To release an app throughGoogle Play, a third-party developer has to participate inAndroid developer program and submit to Google for re-view. The app is signed and published by Google onlyafter it passes the review process. As shown in Table6 and Figure 8, the StealthyStalker app (submitted forpublication with the fake name of SimpleFilter) success-fully passed the Google Play (Bouncer) review and pub-lished, after a couple of hours, despite the hidden ma-licious code. This means that Google Bouncer did notfind any potential harm in the app. Following the ethicalhacking practice, we immediately removed the app fromGoogle Play before any user could actually download it,as proved by the download statistic provided by Google.Results for the other 4 RATs are not available due to thefact that we are not authorized to submit code written byother researchers or malicious developers. Submitted to Google Play under the name of
SimpleFilters
Figure 8: StealthyStalker RAT app published on GooglePlay under the name of SimpleFilters
CopperDroid [33] is a tool to perform dynamic anal-ysis over Android apps to characterize the behavior ofAndroid malware. It automatically analyzes low-levelOS-specific and high-lelvel Android-specific behaviorsof Android malware by observing and analyzing systemcall invocations, including IPC and RPC interactions,carried out as system calls. Although CopperDroid isa powerful tool that dynamically analyzes Android apps,analysis results do not provide any hint on the malicious-ness of a given sample. Indeed, by manually analyzingthe logs files generated by CopperDroid (e.g, syscalls,pcap, logcat and basicbinder), we were not able to iden-tify evidence of malice for the analyzed software.16
Summary of selected Results from our User Study and Aware Evaluation