What's in Your Dongle and Bank Account? Mandatory and Discretionary Protection of Android External Resources

Abstract

The pervasiveness of security-critical external resources (e.g accessories, online services) poses new challenges to Android security. In prior research we revealed that given the BLUETOOTH and BLUETOOTH_ADMIN permissions, a malicious app on an authorized phone gains unfettered access to any Bluetooth device (e.g., Blood Glucose meter, etc.). Here we further show that sensitive text messages from online banking services and social networks (account balance, password reset links, etc.) are completely exposed to any app with either the RECEIVE_SMS or the READ_SMS permission. Similar security risks are present in other channels (Internet, Audio and NFC) extensively used to connect the phone to assorted external devices or services. Fundamentally, the current permission-based Discretionary Access Control (DAC) and SEAndroid-based Mandatory Access Control (MAC) are too coarse-grained to protect those resources: whoever gets the permission to use a channel is automatically allowed to access all resources attached to it. * The two lead authors are ordered alphabetically. Permission to freely reproduce all or part of this paper for noncommercial purposes is granted provided that copies bear this notice and the full citation on the first page. Reproduction for commercial purposes is strictly prohibited without the prior written consent of the Internet Society, the first-named author (for reproduction of an entire paper only), and the author's employer if the paper was prepared within the scope of employment.

ContexIoT: Towards Providing Contextual Integrity to Appified IoT Platforms

“…Abusing permission: malicious app logic abuses the privilege granted to the app [39], [31], [51] Exploiting weakness of general system design: generic system mechanisms such as IPC [63], [23] Exploiting weakness of platform specific features: techniques specific to platform, e.g., native code [19], [20], [49], [47] Exploiting system vulnerability: security flaws and bugs in the system e.g., root exploits [59], [71], [43], [65], [18] N/A Shadow payload: disguise malicious payload using obfuscation or encryption techniques [74], [55] Side channel: carry out malicious payload using covert channel [32], [70], [72], [29] Malicious payload…”

“…Remote control: Taking control of user's device with C&C servers [74], [46] Spyware: Aiming to gather information from the victims without their knowledge [39], [31], [51], [72], [48] Adware: Downloading and displaying unwanted ads on the user's device [58], [46], [42] Ransomware: Installed covertly to DoS the device and demands a ransom payment to restore it [45], [43] Privilege escalation: Exploiting a bug or design flaw of the system to gain elevated access [59], [65], [73], [47] N/A to achieve maximum benefit; (2) evade detection to prolong their life-time. Guided by these principles various adversary techniques are used that we categorize into 6 classes shown in Table II.…”

Detecting (absent) app-to-app authentication on cross-device short-distance channels

“…Previous work highlighted the problems existing in Android device-to-device communications [11,20]. In particular, Demetriou et al [11] studied several channels of communication in Android (such as Bluetooth, SMS, Internet and audio) showing that the security model of Android does not offer adequate measures for protecting certain secrets. To address this problem, they build a security system, called SEACAT, to enforce fine-grained protection on the above resources.…”

“…Several solutions exist for securing cross-device communication. In the Android environment, they allow authentication of devices and communication channels [11,20]. However, these solutions are not sufficient to protect the entire communication flow.…”

“…However, these solutions are not sufficient to protect the entire communication flow. Specifically, the proposed protection system in [11] restricts apps' access to external resources, such as Bluetooth, SMS and NFC, by defining new SEAndroid types to represent the resources based upon their identities observed from their channels. The policies bind an app to a particular device on a specific channel.…”