Anexo 2: Parental Stress Index Short-Form

We evaluated USB-Droid and it’s effectiveness via two types of testing - negative testing and positive testing. In negative testing, we ran our system on popular and trusted apps. This test was aimed at identifying how our system would behave with general day applications. This would also help us understand the False Positives picked up by the system. In positive testing, we implemented colluding malware from [25], [26], [27] and [28]. In addition we also implemented colluding malware using the ideas from the above papers on other channels.

6.4.1 Negative Testing

We evaluated USB-Droid using 100 different apps. Around 70 apps came prein- stalled in the factory image of Nexus 5 device and the rest of them (30) were installed from Google Play Store. These apps were chosen from the top 3 in ten different cat-

egories. For our evaluation, we built a test bed of system apps, third party apps and malware. All apps were sanity tested in the course of the normal day operations. During our testing, we observed that there were no false positives on the system. This is because benign apps generally use overt channels for communication. Covert channels are generally used by stealthy malware. Hence, not having false positives is expected in this scenario.

6.4.2 Positive Testing

We evaluted USB-Droid against colluding malware built based on reports from [25], [26], [27] and [28]. We built colluding malware based on their report of how they executed their attacks. However, not all colluding channels were covered by the afore-referrenced work. Hence, we implemented similar malware logic on the uncovered channels so as to ensure a complete evaluation of our system across all covert channels. The entire list of malware that we developed are as below.

1. An application to steal user contacts by writing them into the system logs 2. An application to steal user identity and location by using the /proc, /sys

channel

3. An application to steal user location via the single/multiple changes to system settings

4. An application to send custom sensitive information via changes to vibration settings. Custom information was stored in an app’s private storage. Since the malware was packaged with the app, we could access that information.

6. Two malware applications that communicate via discovery of UNIX sockets. 7. Two malware applications that communicate via changes in disk free space. 8. Two malware applications that communicate via periodic broadcast intents for

gradual discharge of battery.

9. Two malware applications that communicate via the last placed call.

We now discuss a few policies that we developed during our evaluation in tables 6.2, 6.3 to flag these malware.

6.4.2.1 Policy To Detect Leakage Of User Identity And Contacts Info In this example, an app which has access to the user’s contact information colludes with a weather app which has permission to access the Internet. The two apps collude via the logs channel. The sender app writes sensitive contact information to the logs and the weather app can read that info from the logs. To prevent this communication, we defined the following policy.

Entity Permissions

android.permission.READ CONTACTS android.permission.GET ACCOUNTS

Receiver

android.permission.INTERNET

android.permission.ACCESS NETWORK STATE android.permission.ACCESS WIFI STATE

android.permission.READ LOGS Channel LOGS

Table 6.2: Policy to identify communication via LOGS channel - Contact Stealer malware communicates with Weather application to steal user contacts [11]. Similar policies exist for other covert channels

6.4.2.2 Policy To Detect Leakage Of User location, Health Related Info In this section, we discuss how we detect the theft of user location via an app that does not use any permissions. The attack vector is as follows: The attacker app ‘A’ uses the /proc and /sys channels to gather information about app’s operations. An example would be accessing the Internet usage history. This information is world readable on Android phones. Once the history is accessed, the app uses predefined fingerprints to identify which app is being used and what functionality of the app is being exercised. Once the apps are identified, the authors use other external tools (such as Twitter APIs) to ascertain the user identity.

We defined the following policy to detect this threat. It can be seen that the sender does not have any permissions but we’re still able to detect the colluding transactions. This is because we monitor the covert channels and track their usage. When an app colludes maliciously, our system will identify the misuse and flag it. In this case, the covert channels are used extensively and our system correctly identifies them. In addition, we see that the receiver app has sensitive permissions that allow it to send data to an offline server. Since our policy captures that, we’re able to identify such misuse with ease.

Sender No permissions Receiver

android.permission.INTERNET

android.permission.ACCESS NETWORK STATE android.permission.ACCESS WIFI STATE

Channel PROC SYS

Table 6.3: Policy to identify zero permission app stealing user location, identity and personal medical info

In our evaluation, we conducted two separate trials that show the effectiveness of our system. In the first trial, we override our system to allow all Binder transactions irrespective of the policy matching results. We used the phone under this setting for about a day - sending messages via the default app, sending texts via messaging apps, watching videos on YouTube, sending emails via the GMail, Yahoo Mail apps, check- ing on weather via Yahoo Weather app and listening to music via music streaming apps. Due to our light-weight solution, the evaluator would not notice any difference with the addition of USB-Droid. In another trial, we override our system to deny all transactions irrespective of the policy matching results. This rendered the phone useless as the phone would get stuck during the boot process. Since there are a lot of Binder transactions during the boot time, any failure to complete them raises an exception and thereby hangs the boot process. Thus, it can be seen that operating on the Binder layer is indeed very effective for providing security mechanisms.