Android Exploitation Bypassing Android Permission Model

Android Security and Bypassing Android Permission Model

Android Exploitation using Android Permission Model

The permissions in the Android devices are basically designed to guarantee that the Android Applications installed in the device are not able to do or modify anything where they are not supposed to . The permission model controls the access to various resources by an Android Application .In this post we will see how android malware developers target android permission model for Android Exploitation .

How Android Permission Model Works

An Android app can access limited system resources. To access sensitive APIs, the app must declare permissions required in AndroidManiflest.XML file. These sensitive APIs include camera function, location data (GPS), Bluetooth and telephony functions, SMS/MMS functions and network/data connections and so on … the list continues .

Once an app is installed, the App Installer shows the declared permissions to the user who either accepts or refuses them.

The user has full information on what permissions an Android application is asking for at the time of application Installation . If a user chooses to grant the permissions, these permissions are applied to the application so long as it is installed. During runtime, the system will no longer notify the user when sensitive APIs are being accessed again. Declining these permissions, on the other hand, aborts the app installation.

Once an app attempts to use a protected feature but failed to declare the required permission, the runtime system typically throws a security exception, which then terminates the app.

This basically crashes the application . One important point to note here is ,

Android applications are executed in DVM(Dalvick Virtual Machine) . This ensures complete abstraction of applications from each other and also ensures that if one Application crashes , others are not affected .

Now as we have just seen that an Application will crash if it tries to go out of the scope and access a resource which it fails to mention on the Manifest.xml file . Hence the chances of a malicious application to succeed in accessing the protected resource is very less .Till now we have seen and believed that an Application can only access the resource that it declears at the installation time . However some Android security researchers have succeeded to craft applications that tend to abuse this security meassure .

Misusing the Default Browser to Upload Information

Now if you remmember we just came to know that android applications run in DVM which are basically light weight Virtual Machines to avoid the crashing of one application crash the other . But if an application needs to use the component of another application , it can launch the component of another application by using a feature called intent . These intents can be used for Android exploitation .

Intent is an abstract data structure that describes the operation to be executed .  Each intent consists of action (the action to be performed) and data required to execute the action. When an app sends out an intent, the mobile OS chooses the appropriate app to handle it.

An intent with action Intent.ACTION_VIEW, for example, paired with data Uri.parse(“http://www.google.com”)indicates that the app wants to view the Google webpage. If this intent is sent out, the mobile OS determines the best choice to launch the browser.

With this in mind, a shady developer can develop an app with an intent to open a browser and upload any stolen data to the desired server.

Since the browser opens the URL, the malicious app does not need to declare android.permission.INTERNETbecause this was already acquired by the browser app

Logcat: Using Loging for Android Exploitation

Logcat is a logging system provided by the Android framework and can be used to collect, view, and filter system and app debug output. A set of APIs are also provided for application writers to write debug log into the buffer. Another way to abuse permissions is through the misuse of Logcat

To read the logs, an app will only need to request android.permission.READ_LOG, which appears to be harmless for an ordinary user to be aware of.

Developers may write any information into Logcat, which in most cases are debug information. While some of this information are sensitive in nature (e.g. login credentials, credit card numbers), careless developers may forget to remove these when releasing their products. This can be problematic, as malicious apps may read these information from the log message poll and may use these information in their next attack.

Similarly, the OS also log certain information, which a potential attacker can use to his/her advantage.

For example, in some versions of Android, when opening a website using the default browser, Logcat logs the URL being opened. Though this act may seem harmless, a malicious app can monitor the log to get URLs and determine user’s preference. This monitoring then enables an attacker to choose the phishing version of the users’ most-visited site. Should users browse the site again, the app may stop the loading site and instead ask the browser to load the phishing version instead.

Another example is GPS. When using the GPS service provided by system, some apps will log the current GPS data. A malicious app may get updated location information just by auditing the log, to track user.

Abusing Unprotected Components for Android Exploitation 

Android apps typically have four components: activity, service, content provider, and broadcast receiver. Because of this, an application may be invoked via multiple entry points. To protect these components from being invoked by arbitrary apps, Android implemented the permissions system.

Contacts information is provided by system through the use of a content provider and to successfully query data from that content provider, the calling app should acquire android.permission.READ_CONTACTS. Similarly, to install another app, the app need to declare android.permission.INSTALL_PACKAGES. Apart from system pre-defined permissions, apps can also register their own permissions.Whichever permissions are declared by an app, the calling app should acquire those permissions to call the desired app.

However, there are still too many apps that do not require permissions. This is typical of components designed to be used inside the app. Unwary developers may think that since these are private, no other app (or possible attackers) will know the existence of these components.

Unfortunately, this gives malicious app writers an opportunity to make their move. A developer may intentionally look for all hidden and private components along with the intent to invoke them by decompiling the targeted app.

This becomes a grave concern if the flawed app is a system app. Pre-installed system apps usually have powerful capabilities such as installing app, reading sensitive information and even wiping all data stored in the device. Users also cannot uninstall system apps, unless their devices are rooted.