Exploring

Android Permissions, Misuse and Leak

noras noras |

Tags: #Android

After the release of Android 6.0, we have to distinguish between normal and dangerous permissions, according to the developer guide from Android . We will explain what different permission groups and how it is possible for a developer to enforce his own permissions.

In this context “normal” permissions will be used, when the application needs to access information outside of its own sandbox. Examples could be accessing the clock to change the time zone or setting up a new wallpaper for the phone. When the developer uses such a permission inside his/her Android application, the permission will automatically be granted without a notification to the user.

Dangerous” permission on the other hand, are permissions that grant a function to access information outside its sandbox, that are privacy sensitive, like having read and write access to the contacts or activating the camera.

When an application uses a dangerous permission, the user will be alerted and has to accept to grant the permission to the applicaion first.

Requesting Permissions

An easy way to do that is as following:


/*CALL THE METHOD IN THE MAIN ACTIVITY*/

/*In Marshmallow we should ask for the "Critical/Dangerous" permissions*/
if (android.os.Build.VERSION.SDK_INT >= 23) {
    if (checkAndRequestPermissions()) {
        // carry on the normal flow, as the case of permissions granted.
    }else {
        //Otherwise we should degrade the functionality
    }
}

Let’s say that we want to request the use of the camera and message sending and want to want to ask for these permissions in one call, then checkAndRequestPermissions method will look like this:


/*This part is Marshmallow specific as we have to ask for the permission on real-time*/
private boolean checkAndRequestPermissions() {
    int permissionSendMessage = ActivityCompat.checkSelfPermission(this, Manifest.permission.SEND_SMS);
    int cameraPermission = ActivityCompat.checkSelfPermission(this, Manifest.permission.CAMERA);
    //---------------------------------------------------
    List<String> listPermissionsNeeded = new ArrayList<>();
    //---------------------------------------------

    if (cameraPermission != PackageManager.PERMISSION_GRANTED) {
        listPermissionsNeeded.add(Manifest.permission.CAMERA);
    }
    if (permissionSendMessage != PackageManager.PERMISSION_GRANTED) {
        listPermissionsNeeded.add(Manifest.permission.SEND_SMS);
    }
    //---------------------------------
    if (!listPermissionsNeeded.isEmpty()) {
        ActivityCompat.requestPermissions(this, listPermissionsNeeded.toArray(new String[listPermissionsNeeded.size()]), 2);
        return false;
    }
    return true;
}

Note that this means you can ask for all the permission at once, and in case the user accept and grant the permission he will never be asked for them again in most cases.

The broken permission system

For all Android versions before Android 6.0 (Marshmallow), “Android users were given an all or nothing choice: either give an app permission to do whatever it requested, or don’t install the app.”[#]. The old permission model restricted the choice of users with respect to security reasons weather to download and use an application or not. However, an article  shows how only half of the users have chosen to not install an application based on its permission. That means that the other half of user will install an application that they want or need without bothering about their privacy.

Even Though the previously mentioned mechanics of separating the applications from each other and dividing the different permissions into normal and dangerous groups in the latest version of android “Marshmallow”, could work as a basic defense, there a still a lot more ways to actually circumvent these mechanics by finding ways to misuse the permission handling. To emphasize this even more, we would like to reference to the OWASP Mobile Top 10 , which puts the improper platform usage, in the first place of its list.

Misusing Android’s permissions

As mentioned before, when a user installs a new application, he will be noticed on which permission will be used and he has to explicitly accept these permissions in order for the application to run. Google suggestion on this topic is to, minimize the number of permissions that your app requests. The advantage is, that the user and the developer, have a clear overview over the used permissions. But with this approach, after every update and if the application requests new permissions, the user has to manually accept the new permissions again. This could be described as a minor inconvenience for the user. For that account, major companies like Facebook or Microsoft, will ask for the acceptance of every permission for their application. This raises big privacy concerns, because once the user accept all the permissions, the app has almost full control over the phone itself. For example, the Facebook application can read personal messages stored on the phone and use the found information as an advertisement vector. This principle aims at lessen the burden on the user, but creates a major security vulnerability.

Once the attacker has passed this obstacle, he can basically do want he wants. Trendmicro.com has enumerated the twelve most abused application permissions . They are: Network-based Location, GPS location, View Network State, View Wi-Fi State, Retrieve running apps, Full internet access, Read phone state identity, automatically start at boot, control vibrator, prevent from sleeping, modify/delete SD Card contents and send SMS messages.

No permissions applications leaks

Android applications can leak and send information to the attacker even without asking for any permissions. One of the most criticized no permission property in Android  is that the application can access the Linux layer and execute shell commands from the application layer simply by using the code shown in figure 1. This can be very useful for some applications, however this property can leak resource information .

Some examples of this information are available memory information using the command cat /proc/meminfo, cup consumptions using the command cat /proc/cpuinfo and network information using the command cat /proc/net/arp. At the end of this section we will show a small scenario of how the network information leak can determine the user’s location.

 

android_p1_code_systemcall

 

The information gathered has no value for the attacker if the attacker cannot observe them. One of the simplest ways is to transfer them to the attacker’s website. This can be done without any permission and this is possible because any application can start a new activity. The figure 2 shows the simple code to do that by starting the default browser activity passing the URL. However, the user can see that the browser activity being opened.

 

Figure 2: Code to open the default browser.

 

Now, to demonstrate a no permission application scenario we will use both the previous no permission properties and opening the default browser activity. First the application executes the shell command cat /proc/net/arp that gives an output similar to the output shown in figure 3. In case the user is connected to a Wi-Fi access point, it will show its MAC address also known as BSSID (Basic Service Set Identification). The BSSID can be used to geographically locate the access point using a free web service, for example, https://wigle.net/ .The next step is to set the output to the info variable in figure 2 and just starting the browser activity. By doing that the adversary has now the geographic location of the user.

 

Figure 3: The output of the command cat /proc/net/arp

 

This was a very simple scenario for a no permission application leak. Of Course more information can be leaked, and some applications have been discovered to leak information .

Finally..

Once an application is installed it is there, it may send any kind of data in the background and there are no restrictions that prevents that but the permissions. In Android Marshmallow and above, the applications has to ask for the permissions on run time. And if the user grant the permission to an application he will not be asked again. Which leaves us with the same problem.

Executing a shell command from the application can be done with no special permission. This leads to different kind of information leaks that the system require permission for at the first place. Moreover, this may be used to execute certain binary files (again with no permissions), so the question here is: Why do android have read and write permissions and no execute permission?


About the author

noras

"Senior Software Engineer. MSc in Computer systems and Networks with big interest in security. Loves to play with Android code and does security research for fun and profit. Speaks 4 languages and codes in much more."

Related articles

Tags: #Android




Copyright © 2019 - nindoda.com