Research

Android Mobile Application Security – Understanding Your Exposure

Researchers:

Mark Rose

At the time of writing there are approximately 2.6 million applications available on the Google play store and it should be no surprise that these apps enhance the overall user experience. From disabling your alarm to controlling your smart home devices, or checking the weather, apps have become part of our daily routine. However, because of their often-trivial nature, it can be easy to overlook potential security issues.

Both organisations, and recreational developers, aim to provide users with accessible and convenient functionality through apps. However, many developers do not fully understand their applications attack surface and may, therefore, pose a security risk to end-users.

To understand the attack surface of an application, we first need to understand the structure of an Android application:

Activities – activities allow users to interact with the application by providing a user interface. An application can consist of many activities tied together to perform the desired functionality.
Services – services can be described as the worker of the application; they ensure processes continue to function when the user navigates to other activities or applications. Additionally, if an action were to take a prolonged duration of time, a service would be used.
Broadcast Receivers – broadcast receivers enable the system to send events to the application out with the regular user flow resulting in a system wide announcement. These can be delivered to the application even if it is not running.
Content Providers – content providers help manage data that can be stored on the devices file system, within an SQLite database, or on the web.
Manifest File – the manifest file is where all application components are listed, permissions are stated, aliases set, secret codes created, and determine what actions can be performed.

(Further information regarding these can be found from the official Android documentation)

We now need to understand what risk each component, if misconfigured, could introduce.

Example Misconfigurations

A threat actor would start by carrying out an analysis of the applications Manifest file. By performing this simple action, an understanding of the attack surface would be obtained. Whilst carrying out this, threat actors would be looking for misconfigurations such as, but not limited to:

Secret Codes – string values that can be entered via the dial pad to launch activities.
Exported Components – components can either be implicitly or explicitly exported. Exported components enable interaction from other applications and can be launched to bypass restrictions.
Aliases – aliases, as they sound, give another name to activities. These can be used opposed to the official activity name and are defined within the <activity> tag.
Debug Prevention – a specific element placed in the <application> tag to prevent debugging.
Backup – another element within the <application> tag that can be used to allow, or prevent, users from backing up the application and the data associated.

Exported Components will be the focal point here and to demonstrate the risk, a vulnerable application, Sieve, will be used alongside Drozer to exploit misconfigurations.

Sieve behaves as a password manager and is deliberately misconfigured. These deliberate misconfigurations help demonstrate attack vectors a threat actor would use to exploit your application.

Drozer allows threat actors to impersonate an android application allowing interactions with the target application. This would replicate a malicious application on the user’s device, targeting your legitimate app. Further functionality is provided by Drozer such as executing custom payloads, or utilising pre-written exploit scripts, however, this will be outside the scope of this post.

Identification of Components

The first step in a threat actors’ methodology would be to start the enumeration process. Enumeration of the application would include identifying directories where data is written, application permissions and components exported.

Drozer can be leveraged to achieve this information with relative ease. The attack surface can be obtained by issuing the following command:

				
					dz> run app.package.attacksurface com.mwr.example.sieve

Once executed, the attack surface would be revealed:

Figure 1 – Sieve attack surface revealed via Drozer

Sieve contained 3 activities, 2 content providers and 2 services that were exported. Additionally, it was possible to debug the application.

This can be verified by analysing the Manifest.xml file. Illustrated below was the debug and backup misconfiguration:

Figure 2 – Debug and Backup Misconfiguration

The exported components could be identified via the following lines contained within the Manifest.xml. Highlighted below are the component name, and their status set as exported.

– Explicitly Exported Activities

.FileSelectActivity

.PWList

.FileBackUpProvider

Despite listing 3 exported components within Figure 1 – Sieve attack surface revealed via Drozer, only two are a concern as the applications MainActivity will always be exported to enable the successful launch.

– Exported Content Providers

.DBContentProvider

– Exported Services

.AuthService

.CryptoService

An understanding of the attack surface has now been obtained detailing the exact components a malicious application, or threat actor, would target.

This knowledge would lead a threat actor into attempting to leverage the exploited components. This will determine what unauthorised actions could be performed and what confidential information could be obtained.

Exploitation

When launching Sieve, the MainActivity will be launched. The MainActivity would present the following user interface:

Figure 3 – Sieve Application

The application was, as mentioned, a place for users to store passwords. It appeared as if the application was used prior to launching as there were no register function and was only asking for the user’s password.

So, what can be done now, is it possible to bypass this activity?

Although a hurdle, in the form of authentication, it may be possible to bypass the login prompt. To do so, exported components may be used.

A threat actor would review the data collated and start targeting the components using Drozer.

Following a review of the data, an activity of interest will be identified. The .PWList activity was exported, meaning any application on the device can launch it. Using Drozer, mimicking a malicious application, the activity could be launched by using the following command:

Once issued, Drozer would instruct the activity to be launched, this would result in authentication bypass. By negating application logic, and navigating past the MainActivity, access to the user’s password vault would be possible.

Figure 4 – Password vault data

From here, passwords could be copied into the clipboard and exfiltrated. Successful exfiltration would result in a complete loss of confidentiality which could result in unauthorised access to accounts and impersonation of the user. This information could also be used to restrict access to accounts, further impacting the availability.

But what if the activity wasn’t exported, your application would be secure, right?

No, the attack surface would be reduced, however, it would still be possible to exploit other exported components.

Content Providers were also exported when initial enumeration of the application occurred. To assess these further, Drozer allows for information to be obtained when using the following command:

The response would reveal the exported content providers and potential paths of interest:

Figure 5 – Sieve Content Providers

Out of both providers exported, one would prove more lucrative than the other. The provider of interest would be .DBContentProvider as the path appears to reveal that user keys may be stored insecurely.

Cross checking with the initial enumeration it appeared as if this provider was in fact exported meaning interaction would be possible. Threat actors would then start their interrogation process to determine what information could be obtained.

Drozer contains a scanner that can automatically look for further paths used by providers and feedbacks whether they could be queried:

The following paths were identified along with their query status:

Figure 6 – Content Provider Query Paths

Enumeration of Accessible Content URIs would be carried out to see if any confidential data was stored. Systematically these would be worked through starting with /Keys/ path:

This content provider would be queried, and a response would be obtained as such:

Figure 7 – Content Provider /Keys/

Passwords and Pins were stored within the content provider, so could these be used to authenticate into the application. After using the password revealed from the content provider, in the MainActivity, authentication was successful.

This information leakage resulted in a loss of confidentiality, as not only was the master password revealed, the account information contained within was also accessible. If used to access the accounts stored within the password vault, integrity of data would be hindered and account availability may be impacted negatively.

Further paths within the .DBContentProvider were also accessible. Following the same process outlined above, but this time querying Passwords, further information was accessible:

Figure 8 – Content Provider /Passwords/

This query resulted in the records stored within the password vault revealing their confidential information. A determined threat actor would be able to use this to obtain cleartext passwords or carry out targeted phishing attacks due to their increase in knowledge of email addresses and services adopted by the user.

Content providers not only allow threat actors to query data, but further attacks such as SQL injection and data exfiltration would be possible. Examples of these include, but are not limited to, adding new, or amending existing, records in the database used by the content providers or exfiltrating a local copy of the database to query offline. Some of which are automated which will increase the trivial nature.

So, we have now dealt with exported activities and content providers, our application security must be sound?

Services also allow threat actors to obtain confidential information, as a result, these should also not be exported, but what can be done with these?

Exploitation of services requires a bit more skill, and as such, would be harder to exploit. This is a result of threat actors needing to understand Java coding language as analysis of the codebase would be required. Success of this would also be increased if the applications codebase would not to be obfuscated. In this instance, Sieve did not have encrypted code allowing for easier interpretation.

If these skills were present, a threat actor could look to take leverage of available services in order to perform actions without appropriate authorisation.

Two exported services were available, .AuthService and .CryptoService. Focus will be placed on .AuthService to demonstrate risk.

To send a message, 3 arguments are always required, once the service requirements are satisfied random values could be supplied. If the arguments were not met, the service message would not be executed, and nothing would be performed.

Analysis of .AuthService was carried out.

Codes were defined at the top of the service code as such:

Figure 9 – .AuthService Message Codes

The service would need to contain a msg.what within the handleMessage method. A quick way to identify this would be to perform a search on the service.

An instance was located within the service meaning sensitive information may be attainable.

Assessment of this would be carried out to gain an understanding of the functionality and requirements that would need to be satisfied.

The code has functionality for threat actors to abuse that would result in passwords being leaked. Exploitation, as mentioned before, would require the correct codes, these were obtained in the figure above. We are particularly interested in the MSG_CHECK code, 2354, and the TYPE_PIN code, 9234.

At a high level, the method would return the users password upon receiving the correct pin code, the relevant code could be seen circled in the figure below. The inverse could be performed as well; however, the focus will be on obtaining the password.

Figure 10 – .AuthService Exported Service Code

Following the understanding, interaction with the service could be carried out:

Highlighted are the codes previously identified.

This would result in the user’s password being returned:

Figure 11 – Exported Service Exposing Password

If an invalid code was specified, it would be echoed back within the Extras field:

Figure 12 – Exported Service Incorrect PIN

A threat actor could carry out an automated attack to identify PIN codes that reveal legitimate user passwords. By abusing the exported service, it was possible, once more, to compromise the confidentiality.

Surely, our application attack surface must be limited now.

There are many other attack vectors that impact Android applications that were not discussed here. A basic understanding of Android application security has been outlined and some exploit vectors demonstrated. These vectors are things that a threat actor, and penetration test, would identify.

By carrying out a penetration test, these would be identified prior to threat actor exploitation, preventing reputational damage, or depending on application functionality, loss of confidential personally identifiable information, credential sets or sensitive information.

Rounding back to the initial point, how confident are you with your application’s security posture, do you believe that the best, and most secure, version of it is being presented to your clients, and are you aware of the available attack surface? If the answer is no to any of these, then undertaking a security assessment will certainly help improve your application’s security posture and demonstrate a mature approach to security.