Android Applications Basics
Android Security Model
There are two layers:
The OS, which keeps installed applications isolated from one another.
The application itself, which allows developers to expose certain functionalities and configures application capabilities.
UID Separation
Each application is assigned a specific User ID. This is done during the installation of the app so the app can only interact with files owned by its User ID or shared files. Therefore, only the app itself, certain components of the OS and the root user can access the apps data.
UID Sharing
Two applications can be configured to use the same UID. This can be useful to share information, but if one of them is compromised the data of both applications will be compromised. This is why this behaviour is discourage.
To share the same UID, applications must define the same android:sharedUserId value in their manifests.
Sandboxing
The Android Application Sandbox allows to run each application as a separate process under a separate user ID. Each process has its own virtual machine, so an app’s code runs in isolation from other apps. From Android 5.0(L) SELinux is enforced. Basically, SELinux denied all process interactions and then created policies to allow only the expected interactions between them.
Permissions
When you installs an app and it ask for permissions, the app is asking for the permissions configured in the uses-permission elements in the AndroidManifest.xml file. The uses-permission element indicates the name of the requested permission inside the name attribute. It also has the maxSdkVersion attribute which stops asking for permissions on versions higher than the one specified.
Note that android applications don't need to ask for all the permissions at the beginning, they can also ask for permissions dynamically but all the permissions must be declared in the manifest.
When an app exposes functionality it can limit the access to only apps that have a specified permission. A permission element has three attributes:
The name of the permission
The permission-group attribute, which allows for grouping related permissions.
The protection-level which indicates how the permissions are granted. There are four types:
Normal: Used when there are no known threats to the app. The user is not required to approve it.
Dangerous: Indicates the permission grants the requesting application some elevated access. Users are requested to approve them.
Signature: Only apps signed by the same certificate as the one exporting the component can be granted permission. This is the strongest type of protection.
SignatureOrSystem: Only apps signed by the same certificate as the one exporting the component or apps running with system-level access can be granted permissions
Pre-Installed Applications
These apps are generally found in the /system/app or /system/priv-app directories and some of them are optimised (you may not even find the classes.dex file). Theses applications are worth checking because some times they are running with too many permissions (as root).
The ones shipped with the AOSP (Android OpenSource Project) ROM
Added by the device manufacturer
Added by the cell phone provider (if purchased from them)
Rooting
In order to obtain root access into a physical android device you generally need to exploit 1 or 2 vulnerabilities which use to be specific for the device and version.
Once the exploit has worked, usually the Linux su binary is copied into a location specified in the user's PATH env variable like /system/xbin.
Once the su binary is configured, another Android app is used to interface with the su binary and process requests for root access like Superuser and SuperSU (available in Google Play store).
Note that the rooting process is very dangerous and can damage severely the device
ROMs
It's possible to replace the OS installing a custom firmware. Doing this it's possible to extend the usefulness of an old device, bypass software restrictions or gain access to the latest Android code. OmniROM and LineageOS are two of the most popular firmwares to use.
Note that not always is necessary to root the device to install a custom firmware. Some manufacturers allow the unlocking of their bootloaders in a well-documented and safe manner.
Implications
Once a device is rooted, any app could request access as root. If a malicious application gets it, it can will have access to almost everything and it will be able to damage the phone.
Android Application Fundamentals
Fundamentals Review
Android applications are in the APK file format. APK is basically a ZIP file. (You can rename the file extension to .zip and use unzip to open and see its contents.)
APK Contents (Not exhaustive)
AndroidManifest.xml
resources.arsc/strings.xml
resources.arsc: a file containing precompiled resources, such as binary XML for example.
res/xml/files_paths.xml
META-INF/
Certificate lives here!
classes.dex
Dalvik bytecode for application in the DEX file format. This is the Java (or Kotlin) code compiled that the application will run by default.
lib/
Native libraries for the application, by default, live here! Under the lib/ directory, there are the cpu-specific directories.
armeabi: compiled code for all ARM based processors onlyarmeabi-v7a: compiled code for all ARMv7 and above based processors onlyx86: compiled code for X86mips: compiled code for MIPS processors only
assets/
Any other files that may be needed by the app.
Additional native libraries or DEX files may be included here. This can happen especially when malware authors want to try and “hide” additional code, native or Dalvik, by not including it in the default locations.
res/
the directory containing resources not compiled into resources.arsc
Dalvik & Smali
Most Android applications are written in Java. Kotlin is also supported and interoperable with Java. For ease, for the rest of this workshop, when I refer to “Java”, you can assume that I mean “Java or Kotlin”. Instead of the Java code being run in Java Virtual Machine (JVM) like desktop applications, in Android, the Java is compiled to the Dalvik Executable (DEX) bytecode format. For earlier versions of Android, the bytecode was translated by the Dalvik virtual machine. For more recent versions of Android, the Android Runtime (ART) is used. If developers, write in Java and the code is compiled to DEX bytecode, to reverse engineer, we work the opposite direction.
Smali is the human readable version of Dalvik bytecode. Technically, Smali and baksmali are the name of the tools (assembler and disassembler, respectively), but in Android, we often use the term “Smali” to refer to instructions. If you’ve done reverse engineering or computer architecture on compiled C/C++ code. SMALI is like the assembly language: between the higher level source code and the bytecode.
Intents
Intents are the primary means by which Android apps communicate between their components or with other apps. These message objects can also carry data between apps or component, similar to how GET/POST requests are used in HTTP communications.
So an Intent is basically a message that is passed between components. Intents can be directed to specific components or apps, or can be sent without a specific recipient. To be simple Intent can be used:
To start an Activity, typically opening a user interface for an app
As broadcasts to inform the system and apps of changes
To start, stop, and communicate with a background service
To access data via ContentProviders
As callbacks to handle events
Improper implementation could result in data leakage, restricted functions being called and program flow being manipulated.
Intent-Filter
An Intent Filter specify the types of Intent that an activity, service, or Broadcast Receiver can respond to. It specifies what an activity or service can do and what types of broadcasts a Receiver can handle. It allows the corresponding component to receive Intents of the declared type. Intent Filters are typically defined via the AndroidManifest.xml file. For Broadcast Receiver it is also possible to define them in coding. An Intent Filter is defined by its category, action and data filters. It can also contain additional metadata.
In Android, an activity/service/content provider/broadcast receiver is public when exported is set to true but a component is also public if the manifest specifies an Intent filter for it. However,
developers can explicitly make components private (regardless of any intent filters)
by setting the exported attribute to false for each component in the manifest file.
Developers can also set the permission attribute to require a certain permission to access the component, thereby restricting access to the component.
Implicit Intents
Intents are programatically created using an Intent constructor:
The Action of the previously declared intent is ACTION_SEND and the Extra is a mailto Uri (the Extra if the extra information the intent is expecting).
This intent should be declared inside the manifest as in the following example:
An intent-filter needs to match the action, data and category to receive a message.
The "Intent resolution" process determine which app should receive each message. This process considers the priority attribute, which can be set in the intent-filter declaration, and the one with the higher priority will be selected. This priority can be set between -1000 and 1000 and applications can use the SYSTEM_HIGH_PRIORITY value. If a conflict arises, a "choser" Window appears so the user can decide.
Explicit Intents
An explicit intent specifies the class name it's targeting:
In other applications in order to access to the previously declared intent you can use:
Pending Intents
These allow other applications to take actions on behalf of your application, using your app's identity and permissions. Constructing a Pending Intent it should be specified an intent and the action to perform. If the declared intent isn't Explicit (doesn't declare which intent can call it) a malicious application could perform the declared action on behalf of the victim app. Moreover, if an action ins't specified, the malicious app will be able to do any action on behalf the victim.
Broadcast Intents
Unlike the previous intents, which are only received by one app, broadcast intents can be received by multiple apps. However, from API version 14, it's possible to specify the app that should receive the message using Intent.set Package.
Alternatively it's also possible to specify a permission when sending the broadcast. The receiver app will need to have that permission.
There are two types of Broadcasts: Normal (asynchronous) and Ordered (synchronous). The order is base on the configured priority within the receiver element. Each app can process, relay or drop the Broadcast.
It's possible to send a broadcast using the function sendBroadcast(intent, receiverPermission) from the Context class.
You could also use the function sendBroadcast from the LocalBroadCastManager ensures the message never leaves the app. Using this you won't even need to export a receiver component.
Sticky Broadcasts
This kind of Broadcasts can be accessed long after they were sent. These were deprecated in API level 21 and it's recommended to not use them. They allow any application to sniff the data, but also to modify it.
If you find functions containing the word "sticky" like sendStickyBroadcast or sendStickyBroadcastAsUser, check the impact and try to remove them.
Deep links / URL schemes
Deep links allow to trigger an Intent via URL. An application can declare an URL schema inside and activity so every time the Android device try to access an address using that schema the applications activity will be called:
In this case the scheme in myapp:// (note also the category BROWSABLE)
If inside the intent-filteryou find something like this:
Then, it's expecting something like http://www.example.com/gizmos
If you find something like this:
It will mean that it's expecting a URL starting by example://gizmos
In this case you could try to abuse the functionality creating a web with the following payloads. It will try to navigate to arbitrary pages and try to execute JS:
In order to find the code that will be executed in the App, go to the activity called by the deeplink and search the function onNewIntent.
AIDL - Android Interface Definition Language
The Android Interface Definition Language (AIDL) allows you to define the programming interface that both the client and service agree upon in order to communicate with each other using interprocess communication (IPC). On Android, one process cannot normally access the memory of another process. So to talk, they need to decompose their objects into primitives that the operating system can understand, and marshall the objects across that boundary for you. The code to do that marshalling is tedious to write, so Android handles it for you with AIDL.).
Services using AIDL are referred to as Bound Services. In the Service's class you will find the onBind method. This is where the interaction begins so it's initial part of the code to review looking for potential vulnerabilities.
A bound service is the server in a client-server interface. It allows components (such as activities) to bind to the service, send requests, receive responses, and perform interprocess communication (IPC). A bound service typically lives only while it serves another application component and does not run in the background indefinitely.
Messenger
A Messenger is another type of IPC mechanism. Since the Messenger is also a "Bound Service", the data passed from the client app is also processed through the onBind method. So, the code review should start on this method and you should look for the invocation of sensitive functionality or unsafe handling of data.
Binder
Components
These include: Activities, Services, Broadcast Receivers and Providers.
Launcher Activity and other activities
An Android activity is one screen of the Android app's user interface. In that way an Android activity is very similar to windows in a desktop application. An Android app may contain one or more activities, meaning one or more screens.
The launcher activity is what most people think of as the entry point to an Android application. The launcher activity is the activity that is started when a user clicks on the icon for an application. You can determine the launcher activity by looking at the application’s manifest. The launcher activity will have the following MAIN and LAUNCHER intents listed.
Keep in mind that not every application will have a launcher activity, especially apps without a UI. Examples of applications without a UI (and thus a launcher activity) are pre-installed applications that perform services in the background, such as voicemail.
Activities can be exported allowing other processes on the device to launch the activity. By default, they aren't exported but you can export them setting:
Note that the ability to bypass activity protections isn't always a vulnerability, you need to check to which data you have obtained access.
Also, some activities returns data to a caller. In these scenarios you need to search for the setResult method and check the data that is passed into the Intent parameter. If it's sensitive data you may have an information leakage vulnerability and it's exploitable with apps capable of communicating with the Activity.
The code of an activity starts with the onCreate method.
Application Subclass
If the attachBaseContext method is defined in the Application subclass, it is called first, before the onCreate method.
Services
There is a myriad of ways that they can be started and thus are an entry point for applications. The default way that a service can be started as an entry point to an application is through Intents.
When the startService method is called to start a Service, the onStart method in the Service is executed. It will run indefinitely until the stopService method is called. If the service is only needed as long as the client is connected, the client should "bind" to it using the bindService method.
For a bound service (see previous section), the data will be passed to the onBind method.
For example, a service might play music in the background while the user is in a different application, or it might fetch data over the network without blocking user interaction with an activity.
A service can be exported which allows other processes on the device to start the service. By default services aren't exported but it can be configured in the Manifest:
Broadcast Receivers
Broadcasts can be thought of a messaging system and broadcast receivers are the listeners. If an application has registered a receiver for a specific broadcast, the code in that receiver is executed when the system sends the broadcast. Note that in this case several apps can receive the same message.
There are 2 ways that an app can register a receiver: in the app’s Manifest or dynamically registered in the app’s code using the registerReceiver API call. In the manifest you can limit the broadcasts you accept through the use of permissions within the receiver element. When dynamically defined you can pass the permission to the registerReceiver method.
In both cases, to register the receiver, the intent filters for the receiver are set. These intent filters are the broadcasts that should trigger the receiver.
When the specific broadcasts are sent that the receiver is registered for are sent, onReceive in the BroadcastReceiver class is executed.
An application may register a receiver for the low battery message for example, and change its behaviour based on that information.
Broadcast can be asynchronous (every receiver receives it) or synchronous (the broadcast is received in an ordered manner based on the priority set to receive it).
Note that any application can set itself as top priority to receive a Broadcast.
To examine the code implemented into a Broadcast Receiver you need to search for the onReceive method of the class of the receiver.
Note that Ordered Broadcasts can drop the Intent received or even modify it using one of the setter methods. Therefore, the receivers should validate the data.
Content Provider
Content Providers are the way apps share structured data, such as relational databases. Therefore, it's very important to use permissions and set the appropriate protection level to protect them.
Content Providers can use the readPermission and writePermission attributes to specify which permissions an app must have. These permissions take precedence over the permission attribute.
Moreover, they can also allow temporary exceptions by setting the grantUriPermission to true and then configuring the appropriate parameters in the grant-uri-permission element within the provider element inside the manifest file.
The grant-uri-permission has three attributes: path, pathPrefix and pathPattern:
path: Allows to specify the entire path to exclude
pathPrefix: Allows to specify the beginning of the path
pathPattern: Allows the use of wildcards and symbolic replacements to gain more granular control.
It's important to validate and sanitise the received input to avoid potential vulnerabilities like SQL injection.
Content Provider features:
Content Provider component supplies data from one application to others on request.
You can store the data in the file system, an SQLite database, on the web, or any other persistent storage location your app can access.
Through the content provider, other apps can query or even modify the data (if the content provider allows it).
Content Provider is useful in cases when an app want to share data with another app.
It is much similar like databases and has four methods.
insert()
update()
delete()
query()
FileProvider
This is a type of Content Provider that will share files from a folder. You can declare a file provider like this:
Note the android:exported attribute because if it's true external applications will be able to access the shared folders.
Note that the configuration android:resource="@xml/filepaths" is indicating that the file res/xml/filepaths.xml contains the configuration of which folders this FileProvider is going to share. This is an example of how to indicate to share a folder in that file:
Sharing something like path="." could be dangerous even if the provider isn't exported if there is other vulnerability in some part of the code that tried to access this provider.
You could access an image inside that folder with content://com.example.myapp.fileprovider/myimages/default_image.jpg
WebViews
WebViews are effectively web browsers embedded into Android Apps. WebViews content can be pulled from remote sites or can be files included in the app. WebViews are vulnerable to the same vulnerabilities affecting any web browsers. However there are some configurations that can be useful to limit the attack surface.
There are two types of WebViews in Android:
The WebViewClient, best suited for simpleHTML rendering. This won't run the JS alert function. So, XSS tests using that function will be invalid.
The WebChrome client, is a Chrome browser.
Note that WebView browsers doesn't have access to the native browser's cookies.
To load a URL or file it's possible to use the functions loadUrl, loadData or loadDataWithBaseURL. It's important to only access sanitised URLs.
The WebView security can be configured through the WebSettings object.
For example, JS code execution can be disabled using the setJavaScriptEnabled method with the false value. This will remove the possibility of a XSS and other JS related vulnerabilities.
The JavaScript "Bridge" functionality inject Java objects into a WebView making them accessible to JS. From Android 4.2 methods must be annotated with @JavascriptInterface in order to be accessible to JavaScript.
If true is passed to setAllowContentAccess, WebViews will be able to access Content Providers via content:// scheme. This obviously poses a security risk. Note that if this access is given, it's very important to ensure that the content:// URL is safe.
By default, local files can be accessed by WebViews via file:// URLs, but there are several ways to prevent this behaviour:
Passing
falsetosetAllowFileAccess, prevents the access to the filesystem with the exception of assets viafile:///android_assetandfile:///android_res. These paths should be used only for non-sensitive data (like images) so this should be safe.The method
setAllowFileAccessindicates if a path from afile://URL should be able to access the content from other file scheme URLs.The method
setAllowUniversalAccessFromFileURLsindicates if a path from afile://URL should be able to access content from any origin.
Other App components
Application Signing
Android requires that all apps be digitally signed with a certificate before they can be installed. Android uses this certificate to identify the author of an app.
To run application on the device, it should be signed.When application is installed on to a device the package manager verifies that whether the application has been properly signed with the certificate in the apk file or not.
Application can be self signed or can be signed through CA.
Application signing ensures that one application can’t access any other application except through well-defined IPC and also that it is passed unmodified to the device.
Application Verification
Android 4.2 and later support application verification. Users can choose to enable “Verify Apps” and have applications evaluated by an application verifier prior to installation.
App verification can alert the user if they try to install an app that might be harmful; if an application is especially bad, it can block installation.
Mobile Device Management
MDM or Mobile Device Management are software suits that are used to ensure a control and security requirements over mobile devices. These suites use the features referred as Device Administration API and require an Android app to be installed.
Generally the MDM solutions perform functions like enforcing password policies, forcing the encryption of storage and enable remote wiping of device data.
Last updated
Was this helpful?
