Android Permissions

The strongest protection against malicious apps, is to simply not export any components. But the attribute android:exported="false" is not the only way to protect components such as activities or services.

Android Permissions are used to protect your app against attackers.

There are different kinds of permissions. First is the permissions that your app needs to functiona properly. Which you define in manifest file and ask user to grant that permission. e.g.

<uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>
<uses-permission android:name="android.permission.READ_CONTACTS"/>
<uses-permission android:name="android.permission.WRITE_CONTACTS"/>
<uses-permission android:name="android.permission.INTERNET"/>

Note: In latest android you don't get the permission by just declaring in manifest file you have to request it deynamically too to ask for permission.

In above example some permissions are normal that are granted without any user interactions i.e. Internet access.

While permissions like reading contacts, post notifications will require user interaction and user will have to allow this permission.

This phenomenon is called android permission protection level, there can be different levels raning from normal, dangerous, signature, knownSigner, signatureOrSystem . Each group hash different kind of permissions assigned you can read more here:

<permission>  |  Android DevelopersAndroid Developers

For every android core versions we have this manifest file with all possible permissions in android and their protection level decided for them . read more: https://android.googlesource.com/platform/frameworks/base.git/+/refs/heads/main/core/res/AndroidManifest.xml

e.g. write permission to contacts is protection level dangerous and user will have to consent to grant this permission.

permission android:name="android.permission.WRITE_CONTACTS"
        android:permissionGroup="android.permission-group.UNDEFINED"
        android:label="@string/permlab_writeContacts"
        android:description="@string/permdesc_writeContacts"
      android:protectionLevel="dangerous" />

our poc app should request less permission that target app and exploit that target app to escalate our privilege.

Second is Protecting Components with Permissions

when target app protects itself with required permissions, meaning to call target app components target app enforces that calling app should have this permission beforehand otherwise they can't intercat with target app components.

e.g.

<service android:name="com.example.weather.WeatherService" 
         android:permission="android.permission.ACCESS_FINE_LOCATION"
         android:exported="true">
</service>

Tis means even though this service is exported but to interact with this service from our poc app we need to have android.permission.ACCESS_FINE_LOCATION permission beforehand and user must grant your app location access. which defeats the purpose if you are just requesting a higher privilege permission.

there are certain system level permissions that we can't even request and if an compoenent is protected is protected by that pemrission we can't do anything. this can be checked by checking android core manifest file by reading baout the target pemrission or try to request in android studion and it will error out. sometimes there can be misconfiguration when vendors build their own versions of android and they might forget to enforce system level pemrissions and user might actually request it so try doing that also.

Discovering vendor-specific vulnerabilities in AndroidNews, Techniques & Guides

Two weeks of securing Samsung devices: Part 2News, Techniques & Guides

custom permissions

Besides using system permissions, applications can also create their own permissions in their AndroidManifest.xml. Termux for example declares a dangerous permission that can be used to execute arbitrary code by exporting a service which enforces this custom android:permission

<permission android:label="@string/permission_run_command_label"
    android:icon="@mipmap/ic_launcher"
    android:name="com.termux.permission.RUN_COMMAND"
    android:protectionLevel="dangerous"
    android:description="@string/permission_run_command_description"/>

If another app wants to use Termux to run code, it has to request the RUN_COMMAND permission, which triggers an explicit consent dialog.

Hoever if this custom permission was declared as normal then it will become an issue as we just have to declare it and os will grant us this permission without any user consent.

Common mistakes when using permissions in AndroidNews, Techniques & Guides

Protected Broadcast

Besides the permissions, the Android core AndroidManifest.xml also contains lots of protected broadcasts. No regular app is allowed to send these broadcasts to other apps.

// [...]
<protected-broadcast android:name="android.intent.action.BOOT_COMPLETED" />
<protected-broadcast android:name="android.intent.action.PACKAGE_INSTALL" />
<protected-broadcast android:name="android.intent.action.PACKAGE_ADDED" />
<protected-broadcast android:name="android.intent.action.PACKAGE_REPLACED" />
// [...]

Pro Tip: you can also use the Android Code Search to look for any log message or exception reason, to learn more about the implementation details of certain Android features.