A study on a feasible no-root approach on Android

2.1. ADB

ADB is a debug system for Android that allows developers to connect development computers and Android devices (or emulators). Developers can debug Android devices on separate development computers equipped with other operating systems via ADB. As shown in Figure 1, ADB includes three components, i.e., ADB client, ADB server, and ADB daemon. In practice, ADB server is implemented in the same binary as ADB client. A developer issues an ADB command via the ADB client on a development computer. The ADB server on the development computer, passes the command from ADB client to the ADB daemon which runs on a target Android device. When the response of the ADB command is ready, it passes back to the developer along the same route. Before debugging, there is a switch to be enabled in the Settings→Developer options.

OPEN IN VIEWER

Fig. 1.

The ADB architecture.

Taking security into consideration, the debugging connection is performed with RSA authentication since Android 4.2.2. On these new versions, an Android device authenticates a development computer it is connected to by verifying the RSA signature of the development computer. In addition to the authentication, ADB connection requires a manual confirmation. Each time a development computer requests to connect, there’s a pop-up dialog on the connected Android device showing the MD5 hash of the RSA public key of the development computer which the user can use to confirm the approval of debugging from this development computer. The confirmation is to make sure that the debugger indeed has the access to the target device, capable of unlocking the device and responding to the pop-up dialog correctly. The confirmation dialog could be also waived, once “Always allow from this computer” has been checked during the confirmation of the connection from this computer.

ADB capability can be categorized into two parts: ADB commands and shell commands. ADB commands fulfil the functionalities for debugging purpose, such as device connection, app (un)installing, data transfer, and shell starting. Shell commands can be used after the shell starting, when a shell user, whose UID is 2000 on Android, is born with shell permissions. The permissions for the shell user are listed in Table 7 in Appendix. The majority of shell permissions have protection levels higher than “dangerous.” Any permissions at “signature” level or “signatureOrSystem” level are either hidden or not for use by third-party apps, and such permissions account for more than half (43 out of 65) of the shell permissions. High-level shell permissions are necessary for debugging as debugging requires close inspection and precise control of system status and resources. It is because of ADB’s powerful debugging functionalities and high-level permissions that we need to make sure that ADB is not misused for malicious purposes.

ADB is commonly adopted by existing no-root apps during their preprocessing [1,13,25–27]. The preprocessing usually includes two manual operations. The first is to connect the Android device to a development computer and switch on the debug mode in the Settings→Developer options. The second is to run a provisioned enabler on the development computer which has been downloaded separately from a no-root app’s website. To understand the purpose of using an enabler, we introduce a typical enabler script, which is shown in Listing 1. In Listing 1, “nservice” denotes the native service that performs a target task which requires certain high-level permissions. The executable of this service is pushed to the Android device using a command “adb push” (Line 2), and its access permission is changed to “executable” for all users (Line 3). Then, the service is started by ADB shell (Line 4) so that it inherits the shell permissions for exercising some privileged functionalities such as screen shot. After that, the no-root app which directly interacts with users, is able to work by delegating some of its tasks to the running service through sockets.

3.1. ADB loopback

An Android device from API level 15 to 22 can debug another Android device, because these new versions have introduced the ADB components, which are originally on development computers, to Android systems, i.e., ADB client and ADB server (shown as the dashed ADB Binary in Figure 2). In addition, the connection mode is not limited to using USB cable. A TCP mode newly added since version 4.0 allows a development computer using TCP links to connect to the target Android device (shown as the dashed TCP connection between the development computer and the Android device in Figure 2). However, an inconspicuous side consequence is that an Android device gains the capability of debugging itself by connecting its ADB server to its local ADB daemon (shown as the dashed ADB loopback in Figure 2). Based on such ADB loopback, we propose a feasible no-root approach.

OPEN IN VIEWER

Fig. 2.

ADB loopback.

Similar to existing no-root approaches, this approach takes a preprocessing. What a user needs to do in this preprocessing is to run a script which we name as “Looper” on a development computer connected to the target Android device via a USB cable. Looper can work on any platform that supports Android ADB. Listing 22

After ADB loopback is established, a no-root app with the permission to connect to local TCP ports can play the role of a debugger. The permissions of ADB that are intended for remote development computers are now available on stand-alone Android devices for such apps. As a result, by using ADB loopback, no-root apps can perform privileged tasks as long as they can connect to local TCP ports.

No-root has always been a double-edged sword.3

Recall on Android, permission control is the basic security mechanism. Sensitive resources and system functions are all protected by permissions. Apps request for permissions explicitly during installation. The grant procedure varies according to the protection levels of requested permissions. There are four protection levels for permissions, which are “normal”, “dangerous”, “signature”, and “signatureOrSystem.” The normal level permissions are automatically granted as they are considered harmless. The permissions listed on screen during installation are mostly at dangerous level, which should be approved by users explicitly. The signature level permissions are granted only if the requesting app is signed with the same certificate as the app that declares the permissions. Specifically, for the permissions defined by Android system, the certificate of the app that declares the permissions is the system certificate. The signatureOrSystem level permissions are granted either the requesting app satisfies the grant condition of signature level permissions or the app is built in the Android system image. Hence, the permissions requested by an app represent the app’s capability. There are already many solutions proposed to model an app’s capability through permission analysis, based on which advanced security mechanisms can be developed [6,9,35].

A “permission explosion” happens when an Android app plays the role of a debugger and attains shell privileges by ADB loopback. The only permission needed is “android.permission.INTERNET”, which is the permission needed for connecting to the local ports so as to establish the ADB loopback. On an Android device that has adopted the no-root approach via ADB loopback, an app can act as a debugger to issue ADB or shell commands by invoking ADB client on the device. The commands are passed to ADB daemon via the TCP connection. It is the ADB daemon (adbd), which runs in shell UID, that truly performs the privileged operations. Therefore, when Android checks whether the process performing privileged operations has certain permission, the check is enforced on ADB daemon instead of the calling app without that permission. In this case, an app only with the internet permission can obtain all capabilities under the protection of shell permissions including the permissions at the signature level and signatureOrSystem level. The permission declaration in AndroidManifest.xml no longer reflects the whole capability of any app with the internet permission. Consequently, any existing analysis and protection mechanisms based on app permissions would be in vain.

It is known that the shell privileges are just part of the total control of Android. What permission explosion makes things worse is, however, the capability of misusing the package (un)installation permission which could (un)install APK files silently even when “Unknown sources” is disabled. This would enable malwares to settle down on target devices. With this capability, there is no need for a malware to request for all necessary but suspicious permissions since it can install more malwares silently and conclude with them in attacks. Collusion with sound job division [8] is hard to detect based on analysing app individually [18]. In addition, this capability makes it possible to replace a benign app with a malicious one displaying similar icon and UI in app phishing [11], which may steal users’ input such as account credentials without users’ awareness.

The no-root approach we propose is easy to implement, and it meets the user’s requirement for no-root. We need to ensure that this no-root approach is not misused, since an app using this no-root approach may come to market at any time. Thus, it is necessary to estimate the potential threats to other existing apps from such no-root approach.

4.1. Adversary model & experiment setup

The scenario of our investigation is that a user has a device which is not rooted. (S)he has installed a no-root app that adopts our no-root approach on his/her Android device for the purpose of enjoying privileged functions without rooting the device. We investigate the potential threats from a malicious app only with the internet permission, i.e., how much the other installed apps on the same device would suffer from the malicious one in terms of security and privacy.

After identifying the threats, we test the vulnerabilities causing the threats on a recently collected dataset to find out how prevalent the exploits are among real-world apps. Table 1 shows about 100,000 apps we collected between June and December 2014 from Google Play and four third-party app markets from United States (US) and China (CN), including Android Freeware (US), Anzhi Market (CN), Eoe Market (CN), and Slide Me (US).

Two Android devices without root privilege, i.e., Nexus 4 and Nexus 5, which have been preprocessed by Looper, are used in our experiments. It is verified that this new no-root approach works on the Android versions ranging from 4.0.4 to 5.1.1.

Android provides a logging system for collecting and inspecting debugging outputs. The access to log messages is regulated by callers’ UIDs. Normal users, i.e., third-party apps without root privilege, can only access the logs related to themselves, whereas the shell user is not limited by such restriction. Therefore, when an app attains the shell privileges via the no-root approach we propose, it can get all system-wide logs using logcat which is the official tool for dumping log messages.

Since the system-wide logs are readable, we investigate whether a malicious app can obtain any sensitive information from the logs of other apps. In fact, Android documents suggest that logs should be managed according to their types. The logs of verbose type should never be compiled into an app except during development, and the logs of debug type can be compiled in but should be stripped at runtime [3]. The negligence of logging informative data has also been pointed out previously [17]. If there is no sensitive data being logged, a malicious app can get nothing even with the capability of dumping log messages. We are interested to know what the situation is in app markets nowadays. Do app developers remove their logs as required? The answer is “no” according to our investigation.

We need to clarify in this case what information is sensitive. We classify the sensitive information on mobile devices into four categories, i.e., device parameters, app account information, user interaction indications, and others. The first category is the device parameters which reflect the characteristics of devices, including Android version, device model, manufacturer, root status, and SIM card related information such as phone number, IMEI, and IMSI. The second category, i.e., app account information, is on the application level, which includes account ID, account credential, and personal profile. The third category is the user interaction indications, which indicate the operations a user performs at different time, such as opening an activity and inputting a password. In addition, geographic information (e.g., location, latitude/longitude, and country code) and network status (e.g., SSID, gateway IP, and network quality) are classified into the last category along with other information.

To evaluate the risk of leaking sensitive information against the privacy leakage exploit, we select top 10 account-sensitive apps from the top free list from Google Play and Anzhi Market, respectively. We run these 20 target apps on our experiment device, and test them manually according to their functionalities. The observation on the messages logged by these apps begins from the time when they are launched, and lasts the entire runtime till there’s no further operation. Experimental results show that 11 of the 20 top-ranked apps log some sensitive data. The apps with respect to their logged sensitive information are shown in Table 2. According to the location of logging code (i.e., the code generating logs), we categorize the logs of sensitive information into two types.

The first type is logged by apps themselves. One example of such app is “com.sinovatech.unicom.ui” which is the service app of China Unicom.4

The second type of logs is from third-party SDKs. For example, Snapchat [29] and Vine [31] both use Flurry [12] SDK to help their developers to know how the apps are used by users according to accurate usage data analytics. Flurry defines log APIs, including FlurryAgent.setLogEnabled() and FlurryAgent.setLogLevel(), for developers to monitor the runtime behaviours of apps during developing and debugging. It is observed that due to the developers’ improper use of FlurryAgent, it logs some of the user operations when a user interacts with an activity shown on screen. One of such cases, which happens during registration, is demonstrated in Listing 3. It can be inferred from its logs that Snapchat first focuses on the email field (Line 2), and then the edit on this filed begins (Line 3). After that, it focuses on the password filed waiting for inputs (Line 4). Once a user starts inputting his/her password, it immediately outputs the corresponding log (Line 5). Even though there’s no direct leakage of email or password, the information about focusing and editing can be used by a malicious app to know the accurate time of entering usernames and passwords, and such accurate time is important for launching other attacks such as keylogger attacks.

On Android, a third-party app stores private data in its private folder, the access to which by other third-party apps is prohibited so as to avoid account takeover. A private folder is thus only accessible to Android system and its owner app. Even the shell privileges cannot access such data directly. We show that however, there is an alternative way to achieve account takeover without knowing any account credentials.

ADB backup is an ADB mechanism which performs the backup and restore task on Android. It can be used to back up all the data files in an app’s private data folder, including databases and shared preferences, to a single file.5

Account credentials are rarely stored in plain text locally, thus it is of little use to obtain the data in apps’ private folders. Nevertheless, when restored on a different device, an app’s account login status could be kept the same as they were on the former device. Hence, a malicious app can take over other apps’ private data protected in the account circuitously by backing up target apps and then restoring them on a fully-controlled device. In such case, even the attacker does not know the account credential, (s)he can perform any operation to the target app with a logged-in account on the restored device. To avoid becoming a victim, an app should detect any new runtime device and protect its private data accordingly, e.g., logging out of the account if a different runtime device is detected. In the following, we investigate how many real-world apps in our collected dataset allow backup, and whether some most popular apps enforce any protection on their private data when restored on a different device.

In the first part of our investigation, we focus on the usage of “allowBackup” in the dataset we collected from multiple markets (Table 1). The results are shown in Table 3. We observe that most apps do not set “false” explicitly to the backup attribute either by intention or ignorance, which means that they are potential victims of the above-mentioned account takeover exploit. A small portion of apps set “allowBackup” to “false”, which accounts for 6.95% in Google Play dataset. This proportion is lower in alternative market datasets; the lowest proportion is 0.01% in Anzhi Market. It is both reasonable to set “allowBackup” to either “true” or “false.” However, it is critical for an app with true (or default) value in “allowBackup” to enforce some necessary protection on the backup data.

In the second part of our investigation, we focus on whether some popular apps that allow backup would lead to account takeover. Unlike the first investigation which can be performed in a large scale, this investigation requires a manual analysis of a small number of apps so as to verify account takeover. In this investigation, we choose two categories of apps for which it is important to protect users’ data against account takeover (i.e., mail apps and browser apps), and the most popular apps in these categories (i.e., top 5 apps). Specifically, we target at the top 5 free mail apps (i.e., K-9 Mail, myMail, Microsoft Outlook, Yahoo Mail, and Mail.Ru) and top 5 free browser apps (i.e., Chrome Browser, Opera browser for Android, UC Browser, Dolphin Browser for Android, and Firefox Browser for Android) in Google Play. The values of the backup attribute show that all of the 10 apps can be backed up.

The mail apps are used for handling emails, such as logging in, sending/receiving mails and saving drafts. We inspect into account login status, inbox/outbox mails, and draft content after restoring a user’s account data to a different device. Table 4 shows that three out of five mail apps keep their accounts logged in on the different device to which they are restored as they were logged in on the original device. In such case, the whole account data is accessible and arbitrary mailing operations can be performed on the restored device, which leads to the takeover of their mail accounts. In contrast, the other two apps have adopted certain protections, both of which require re-login after being restored on a different device. A minor difference is that Yahoo Mail needs both username and password to complete the re-login, whereas myMail prompts the username as a hint and requests the password only.

For browser apps, we care about the data related to user privacy and account safety, including browser account login status, saved passwords (for other websites), history, bookmarks, and downloads. Table 5 shows whether the above-mentioned data is accessible by an attacker after restoring a user’s account data to a different Android device. History data and bookmarks are accessible for all five browser apps on the different device. Although no downloaded file is available, because the “Downloads” folder, which is the recommended location to store downloaded files on Android, is not within the browsers’ backup scale (i.e., private data folders), two of the five browsers still leak valuable information about users’ downloads by either filenames or URLs. Except Chrome, all tested browsers that support account login fail in detecting the change of runtime device, and keep their accounts logged in on the restored device. A more serious problem is that some browsers provide the choice of saving login credentials for users. Such browsers can fill in the login forms of visited websites with saved usernames and passwords. In our testing, four browsers (i.e., Chrome Browser, Opera browser for Android, Dolphin Browser for Android, and Firefox Browser for Android) provide this functionality. Except for Dolphin Browser (i.e., mobi.mgeek.TunnyBrowser), the other three browsers fill in web forms on the different device to which they are restored with the account information saved on the original device. It is worth noting that the auto-fill of saved passwords in Chrome still works, although Chrome has detected the different runtime device and logged out of its account.

The application attribute “debuggable” defines whether an app can be debugged, even when running on a device in user mode. During the app development, “debuggable” needs to be explicitly set to “true”; however, sometimes it fails to be set back to “false” when the release version is produced. Any app with true “debuggable” attribute value registers itself to ADB daemon by connecting to the local socket @jdwp-control which is opened by ADB daemon. When a debugger requests for a connection to a debuggable app, the ADB daemon is responsible for establishing such connection. This connection is based on standard Java Debug Wire Protocol (JDWP), which is designed to be used in debugging by the debugger to control the debuggable app and execute necessary testing code in the context of the debuggable app. When a malicious app takes the role of the debugger on a stand-alone device, which is the exact situation in the no-root environment with ADB loopback, it attains the full control of the debuggable app and can run arbitrary code in the debuggable context with the same UID as the debuggable app. In other words, the malicious debugger can exercise the debuggable app’s permissions and access its sensitive data. As a result, Android access control based on UID is not effective in this setting.

To mitigate this threat, it is prohibited to publish apps with the true “debuggable” value on Google Play since late 2013. Unfortunately, according to our evaluation, the third-party markets still put apps on shelves without enforcing any restriction on the debuggable attribute.

We investigate how many apps in our dataset (see Table 1) collected from Google Play and four third-party app markets are subject to UID abuse by examining whether the “debuggable” attribute in AndroidManifest.xml holds a true value. The usage of “debuggable” attribute in these apps is shown in Table 6. It is discovered that Google Play still hosts a small portion of its published apps being debuggable (1.67%). Even though Google Play’s prohibition of publishing debuggable apps is effective since late 2013, the debuggable apps uploaded before that and never updated afterwards are still on shelf. In the four third-party markets, the situation is not very optimistic. For example, 13.75% apps are debuggable in Anzhi Market.

User input inference is a way to capture user private information such as account credential. Previous research targets on user input inference from various channels such as device sensors [7,19], the clipboard [10,33], sound from voice response systems [24], screen captures [16], and indirect shoulder surfing [23]. While the existing inference approaches can still work in no-root environment, a malicious app in no-root environment can obtain more accurate information about user’s input, including the input characters and the time of the input.

Inference of Input Characters. The characters that a user inputs on a touch-screen can be inferred from knowing both the touch position on screen and the software keyboard layout.

First, let us consider the inference of touch positions. In Android, a touch screen registers the absolute position of each click in its coordinates, i.e., ABS_MT_POSITION_X and ABS_MT_POSITION_Y. There’s only one activity shown on screen each time. The dispatch destination of each click position is supposed to be the app running on screen only. However, the no-root approach we propose makes it feasible for another app on the same device to access directly to the touch coordinates using the shell command getevent no matter it is running on screen or not. We set up an app running in background which gets the coordinates of user clicks via getevent. Listing 4 shows the raw events obtained by this app when a user neatly presses letter “a” using the English (US) Google Keyboard with “QWERTY” layout on Nexus 5, where /dev/input/event1 represents the touch screen, and the three hex numbers following a colon represent type, code, and value, respectively. For example, in Lines 2 and 3, type ‘0003’ denotes an absolute event, followed by codes ‘0035’ and ‘0036’ denoting X coordinate and Y coordinate, respectively, and followed by the coordinate value. It ensures accurate inference of user input by parsing these raw events directly as the Android system does for the app running on screen.

Second, let us consider the inference of keyboard layout, whose varieties are introduced by different vendors. Even for the input methods that endorse the same “QWERTY” layout, the position of each key is slightly different due to the appearance adjustment by vendors. The information about the input method (e.g., its name and whether it is invoked) is available using dumpsys which is another shell command that becomes available to apps with the internet permission in no-root environment. As a result, a malicious app obtains the combination of user click positions and the keyboard layout and thus the input characters.

Good Timing of Credential Input. From an attacker’s point of view, it is important to determine the good timing at which a user is ready to input his/her account credentials to an app so as to capture the user’s input of such information. This is because a screen touch happens frequently, but not every time it means a valuable input to a malicious app. Detecting the good timing of user credential input would enable a malicious app to know when to start inferring the input characters for user credentials.

Algorithm 1 illustrates our good timing detection algorithm in pseudo code. The good timing is a logical variable which is detected to be true when the login activity of a target app is shown and an input keyboard is invoked. The goodTiming being true indicates that the user is ready for inputting his/her account credentials.

OPEN IN VIEWER

Algorithm 1

Good timing detection

Login activities share a common pattern which can be used to detect them. A login activity normally consists of at least two EditText fields for inputting a username and a password, respectively. Among the two, the second EditText field conceals the password content by representing each input character in a black dot or asterisk, as attribute inputType (one of the attributes of EditText) is set to password-related by developers. Therefore, a login activity can be detected by seeing this pattern. A malicious app in no-root environment can obtain the activity layout in XML using the shell command uiautomator which is usually used in user interface tests. The layout describes an activity hierarchy composed of a variety of layout widgets, each of which has its type (e.g., EditText) and many attributes of this type (e.g., inputType). This activity layout, along with the information of whether any input method is invoked which can be obtained using the shell command dumpsys, provides a malicious app with all parameters used in Algorithm 1.

We test our good timing detection algorithm with the top 20 finance apps in Google Play. The protection of users’ credentials is critical for these apps since any leakage may lead to financial loss. These target apps are installed on the test device on which our good timing detection algorithm runs in the background. Volunteers are recruited to operate on the device at will, e.g., playing games, browsing websites, and logging in the target apps with provided accounts. For demonstration purpose, we add one more component to the good timing detection service to take a screenshot using shell command screencap when any good timing is detected for the input of users’ credentials. The screenshots are stored with the filenames which are named according to the corresponding good timing timestamps. If our detection algorithm is accurate, there should be a screenshot showing a login form with an input keyboard invoked if and only if a volunteer is about to input an account credential in a target app. During the experiment, all of the 20 apps have been invoked by volunteers. We obtain 15 apps’ screenshots in the end. According to our further inspection, the other five apps do not support user login. It proves that the good timing detection works perfectly for all 15 apps which support user login.

5.1. Permission-based solution

Once the ADB loopback is set up, a benign no-root app can access the ADB client (one of the ADB components introduced in Section 2.1) to meet users’ requirements. However, malicious apps may abuse ADB client, which helps them to access the resources beyond their granted permissions. The ADB client cannot distinguish whether the calls are from benign no-root apps or malicious apps. All of the exploits presented in this paper rely on unauthorised calls to ADB client from malicious third-party apps. Consequently, the exploits can be mitigated by thwarting unauthorised calls to ADB client.

A preferred solution should mitigate the ADB loopback exploits while still making it work for benign no-root apps. It is thus not an optimal choice to shut down the ADB loopback on Android. One possible solution is to extend the existing Android permission mechanism properly without introducing too much modification to it.6

In Android frameworks, a wide variety of permissions is defined to control the access to critical resources such as equipped hardware resources, system API functions, and file systems. An app cannot access any protected resources unless it has the required permissions. The enforcement of permission checking is located at two different layers, including Framework layer and Linux kernel layer. The checkpoints at the Framework layer mainly deal with the Android API callings to some sensitive resources such as contacts. Other checkpoints in Linux kernel are responsible for checking file system and network related permissions. Android assigns a unique Group ID (GID) to each type of permissions that are checked in Linux kernel. If any permission is granted to an app, this app will include the corresponding GID to its GIDs field which is a set of GIDs for each app maintained by system. When the app requests to access any protected resource, the checkpoint in Linux kernel checks whether the app has the required GID.

Since ADB is an open-sourced protocol, a third-party app can implement it and communicate with ADB server as ADB client does. Previous research [14] suggests to verify whether the entity communicating with ADB server is truly the system ADB client. It requires that only ADB client can communicate with ADB server. In our solution, we focus more on how to protect the ADB client.

To prevent unauthorized calls to ADB client, we propose to add one extra permission to the current permission system. In particular, we add android.permission.DEBUG_ADB to the permission group DEVELOPMENT_TOOLS. To make this permission work, we need to declare it first as shown in Listing 5. Due to the fact that ADB is not managed by any Android service manager, the checkpoint of this permission should be located at the Linux kernel layer. It thus requires a unique GID for permission checking in Linux kernel. In Listing 6, we show how to map this new permission to a GID named adb_debug. After that, we need to assign a GID number to the ADB debug permission in Listing 7. Till now, the new permission for ADB debug is declared, and it has its own GID which can be used during the enforcement of permission.

Having defined the new permission, we need to specify the constraint related to this permission for ADB client. We add a permission check function at the beginning of ADB source code so that the DEBUG_ADB permission is checked whenever the ADB client is called. We check whether the calling process has the DEBUG_ADB permission. As mentioned previously, the permission check in Linux layer depends on the GIDs of the calling process, which should include the AID_ DEBUG_ADB for the DEBUG_ADB permission. In order to obtain the GIDs of the calling process, we read the /proc/ pid /status file indexed by pid and get the Groups field. The Groups field is a set of integers each of which indicates a group the process includes, i.e., a permission of the process. If there is no “3009”, the GID number of AID_DEBUG_ADB, in the calling app’s Groups field, the access request is denied. However, if Groups field shows that the calling process indeed has the ADB debug permission, we do not allow it to access ADB immediately. A skilful malicious app without the ADB debug permission may call the ADB client by circuitously invoking function system(cmd) or issuing command sh -c cmd. In this situation, the calling process of ADB client is the bash that directly launches ADB client, rather than the app itself. Therefore, our permission check function is applied to all the parent processes along the call chain till zygote which is the parent process that spawns all apps on Android, or reaching the process with parent process ID 0 without passing by zygote which means the calling is directly from shell or system. If any process along the call chain does not have the ADB debug permission, the permission check for the ADB debug permission is terminated and the call is denied.

We also need to maintain the original usage of ADB for shell user. We declare the use of DEBUG_ADB permission for shell user in its manifest file /platform/frameworks/base/packages/Shell/AndroidManifest.xml, so that shell can get this permission and face no security exception when debugging. Similarly, this permission is also granted to the system user and the root user. It is worth noting that this solution modifies neither definitions nor enforcement of any other permissions; therefore, it affects no apps but the ones accessing ADB client.

Once the above permission-based solution takes effect, any app which requires access to ADB client should require for android.permission.DEBUG_ADB in its manifest file. An app cannot invoke ADB client on an Android device unless the user of the device explicitly grants the permission during the app’s installation. An app which positions itself as a benign no-root app or development tool must convince the user to grant the ADB debug permission to it. The mitigation solution introduces insignificant change to the current Android system. It prevents any app without the DEBUG_ADB permission from invoking the ADB client, and thus mitigates the dark-side exploits of the no-root approach based on ADB loopback by thwarting unauthorized access to the ADB client.

Besides the permission-based solution which can be enforced on the Android side, we also give some suggestions for app developers and app markets based on our observation that the negligence from both sides may lead to exploits.

On the app developers’ side, proper coding and configuration would help protect apps against some malicious exploits. It is common that app developers sometimes insert logging code or use logging APIs from SDKs in their apps in the development phase for testing purposes. Probably due to negligence, some of them leave the logging code without change when they release their final products. In the no-root environment with ADB loopback, such apps are subject to the privacy leakage exploit. This exploit can be mitigated by cleaning the logging code before releasing their apps. Besides cleaning unnecessary logging code, app developers need to check for the configuration of the application attribute “allowBackup.” It is reasonable to set the value either to “true” or “false”. If it is set to “true” (explicitly or by default), necessary protection must be enforced on the backup data, e.g., logging out of account once the app is restored on a different device; otherwise, the app is subject to the account takeover exploit. Lastly, app developers should check for the misconfiguration of application attribute “debuggable.” If it is set to “true” in the development phase, it should be set to “false” in the released version so as to mitigate the application UID abuse exploit.

On the app markets’ side, it is suggested that app markets enforce effective vetting processes. Google Play has set up an example of using its bouncer [5], which checks for malicious operations and certain vulnerabilities in each app submitted to Google Play and suggests whether or not Google Play should accept the app. One of the jobs that bouncer do is to ensure that debuggable apps should not appear in the market since late 2013. This would help mitigate the application UID abuse exploit due to the permission explosion. On the other hand, we discover that several popular third-party markets, including Android Freeware, Anzhi Market, Eoe Market, and Slide Me, still host a considerable portion of apps that can be debugged. They may consider to improve their vetting systems to catch up with Google Play in prohibiting the debuggable apps. Besides blocking debuggable apps, we suggest that Android markets should check for the apps with debug or verbose logging code so as to avoid leaking sensitive information in logs.

5.3. Discussion

Impact of SEAndroid. Since Android version 4.4, SEAndroid is enforced by default. Our no-root approach may not trigger the existing constraints from SEAndroid unless specific SEAndroid rules are defined so as to restrict the use of TCP-mode connections and debugging capabilities. The reason is that our no-root approach leverages on a side effect of combining two legitimate features introduced in Android 4.0 and later versions, including the connection channel via TCP mode and the debugging capability of mobile system. After the establishment of ADB loopback, an application can serve as a legitimate debugger and use the normal ADB functions. It is verified that our no-root approach works on Nexus 5, Android 5.1 with SEAndroid enforced. To prevent the exploits of our no-root approach, SEAndroid rules should be defined to distinguish regular use from misuse of ADB. However, this is challenging since it may not be always possible to distinguish between benign no-root apps and untrusted third-party apps by Android platform provider or device manufacturers. Note that SEAndroid policies are defined by Android platform provider, which can be modified and extended by device manufacturers.

Users’ Security Awareness. The security awareness of users is always a key to the security of digital systems. A no-root user may not fully understand the purpose and consequence of the preprocessing steps. In this case, an attacker may entice users to push malicious executables into their devices. For example, an attacker may pretend to be a no-root application and instruct users to push an ADB binary to mobile devices in the preprocessing steps. Using this ADB binary, the attacker can bypass our permission-based solution and exploit the dark side analysed in this paper. Therefore, it is helpful to educate users to understand the purpose and consequence of the operations they perform on their devices. On the other hand, smartphone manufacturers may leverage on SELinux/SEAndroid to prevent such breach by defining access policies to restrict the execution of untrusted executable files pushed in by ADB shell. Under the premise that users are willing to adopt the no-root approach, the best protection is to ensure that the no-root approach is indeed used by the no-root app instead of any other apps.

Google’s Solution. After we verify that the no-root approach can work on Android versions from 4.0.4 to 5.1.1, which is the latest version at that time, we reported to Google about the feasible no-root approach along with its dark side in August 2015. Google admitted soon that the no-root approach can work as intended, and so do the exploits on its dark side. Later in October 2015, Google removed the ADB client and ADB server from the release of Android 6.0. These two components are responsible for accepting debug commands and communicating with the ADB daemon, respectively. Therefore, an Android device cannot be used to debug other Android devices. In contrast, the permission-based solution we propose in Section 5.1 prevents ADB client from being misused while keeping the debugger functionality, which could be more desirable in practice.