Android Attacks in a Nutshell (Part III)

3  Permission Re-delegation Attack

3.1  What is Permission Re-delegation?

Browsers and smartphone operating systems, however, have shifted from associating privilages to their user accounts to a fundamentally new model where applications are treated as potentially malicious and mutually distrusting. Principals receive few privileges by default and are isolated from one another except for communication through explicit IPC channels. Inter Process Communication (IPC) in a system with per-application permissions leads to the threat of permission re-delegation. Permission re-delegation occurs when an application with a usercontrolled permission makes an API call on behalf of a less privileged application without user involvement. The privileged application is referred to as a deputy, handling authority on behalf of the user. According to Porter et. al, More than a third of the 872 surveyed Android applications in their study had requested permissions for sensitive resources and also had exposed public interfaces; i.e. they are therefore at risk of facilitating permission re-delegation. Moreover, the paper claims that 15 permission redelegation vulnerabilities in 5 core system applications were found. The permission re-delegation process is as follows: the deputy defines a public interface that exposes some of its functionality. After that, a malicious requester application lacks the permission that the deputy has. The requester invokes the deputy’s interface, causing the deputy to issue a system API call. The system will approve and execute the deputy’s API call because the deputy has the required permission. The requester has succeeded in causing the execution of an API call that it could not have directly invoked (Figure 1).

 

Figure 2: Permission re-delegation attack: The requester does not have the text message permission, but the deputy does. The deputy also defines a public interface with a Notify method, which makes an API call requesting to send a text message. When the requester calls the deputy’s Notify method, the system API will send the text message because the deputy has the necessary permissions. Consequently, the attack succeeds. [1]

3.2  Implementated Applications for Attacks

Porter et. al, built attacks using 5 of the 16 system applications. All of the attacks succeed in the background with no visible indication to the user. The filtered 5 applications provided 15 paths to 13 interfaces with permissions, one of which was SignatureOrSystem and nine of which were Dangerous permissions. Two example application in order to create permission redelegation attacks were also presented:

•     Settings serves as the phone’s primary control panel. When a user presses certain buttons, Settings’ user interface sends a message to a Settings BroadcastReceiver that turns WiFi, Bluetooth, and GPS location tracking on or off. However, Settings’ BroadcastReceiver accepts Intents from any application. An unprivileged application can therefore ask the Settings application to toggle the state of devices by sending its BroadcastReceiver the same Intents that it expects from its user interface. Turning these devices on or off is supposed to require Dangerous permissions (CHANGE_WIFI_STATE, BLUETOOTH_ADMIN,and ACCESS _FINE _LOCATION, respectively).

•     Desk Clock provides time and alarm functionality. One of its public Services accepts directions for playing alarms. If an unprivileged application sends an Intent requesting an alarm with no end time, then Desk Clock will indefinitely vibrate the phone, play an alarm, and prevent the phone from sleeping. The alarm will continue until until the user kills the Desk Clock process. Playing sound with a wake lock requires the Dangerous WAKE_LOCK permission, and vibrating the phone requires the Normal VIBRATE permission.

Concrete vulnerabilities were found with implementing the two previously mentioned applications in 5 of the 16 applications, which is equal to half of the 11 system applications identified as at-risk. Unfortunately, the authors did not disclose the code and therefore we cannot go further. Finally, Porter et. al discussed that to prevent permission re-delegation attacks, an IPC Inspection mechanism were presented, in which each deputy will accept Intents from the applications that already share the common permissions which is needed for the execution of that Intent. IPC inspection mechanism resides on top of already stack-inspection-enabled JVM and CLR. Since this topic is not in the scope of this report, for more details see [1].

4  Conclusion

This report is an introduction to Android OS security. While there exists a range of taxonomies of android attacks [2], their impact and possibility of occurance differs. We presented an XSS vulnerability on default web engine of Android, i.e. WebKit, after that a description of one of Android’s permission re-delegation attacks was presented and its implemented applications were discussed.

References

[1] Adrienne Porter Felt et. al. Proceedings of the 11th usenix conference on security. In Permission Re-Delegation: Attacks and Defenses.

[2] Asaf Shabtai et. al. Google android: A comprehensive security assessment. 2010.

[3] Sebastian Gerling Michael Backes and Philipp von Styp-Rekowsky. A local cross-site scripting attack against android phones. Technical report, Information Security and Cryptography Group, Saarland University.

[4] Patrick McDaniel William Enck, Damien Octeau and Swarat Chaudhuri. A study on android security. In Proceeding of 20th USENIX Security Symposium.