Android is an open source mobile platform that includes an operating system, middleware and applications. Android has revolutionized the mobile world in a big way. Android, which started as an alternative to Apple’s iOS, is now slowly eating into the market share of Apple and is of primary concern to the company. Let’s have a brief introduction about android and then look into the security concerns and vulnerabilities that need to be focused on.
Android was developed by Android Inc., which was purchased by Google in 2005. Due to the iPhone effect, Google has strategically formed an Open Handset Alliance (OHA) to counter the dominance of Apple. Open Handset Alliance is a consortium of telecommunication, hardware and software companies which are dedicated to provide open standards for mobile devices. Google released Android in 2007 along with the founding of OHA. The fact that android is open source, which can be modified freely by anyone, made it a sudden and huge success. The first android phone later came into market in 2008. Just like the Apple’s App Store, Google has launched Google Play from where you can download the android apps. More than 7 billion apps are estimated to be present in the store today. Android has great number of features available and it provides an easy development environment.
Why think about ‘Android Security’?
Security has become a central and crucial aspect that determines the success or failure of any platform or for that matter, any new feature. Along with the functionalities, the overall security aspect determines the strength of a platform. With the exponential increase in hacking related activities, users are primarily concerned about the strength of security that a product offers. Android is based on Linux kernel and is typically programmed with java language. Android boasts of several security features to protect the user data and resources. Some of these include robust security through Linux kernel, permissions model, application signing, and sandbox approach for all applications. These features are certainly necessary but not sufficient enough to secure the platform.
Android – Security Perspective:
This article aims to project security concerns with android implementations and the associated risks at code level. In this process we will also touch upon the underlying security concepts implemented by android. Android has built in security mechanisms at the operating system level which reduce problems with application security issues. The following are some of the security features with risks that need attention. For a more in depth look into these security issues, check out the web application security training course offered by the InfoSec Institute.
The Permission Model:
When installing new software, users need to approve the permissions that an application has. These permissions are expressed in AndroidManifest.xml file. Permissions might include sending SMS, accessing camera, accessing contact list etc. So the user can sense some malicious activity if a gaming application asks access to your contact list. In some cases to support dangerous permissions like accessing internet etc., android also modifies the underlying Linux kernel. For example to support internet the applications require membership to inet group. So these permissions are enforced in the OS rather than in the VM level. So even if the VM is compromised, android still maintains its security. As a developer, you need to minimize the permissions an application uses because that would make the user feel more secure when installing the software. By default, an android application has no permissions.
To access any protected feature, permissions must be declare in AndroidManifest.xml file. The code snippet below is taken from an android developer site which helps you better understand how permissions work.
The problem here is even though the permission model is well designed many users ignore this entirely while installing an application. Users need to look out carefully for those applications which would require dangerous permissions while installing. The android:protectionLevel parameter has provides an idea about the risk involved in the permission. It can hold any of the following values:
Normal – This is the default value. It’s a lower-risk permission that gives applications access to isolated application-level features, with minimal risk to other applications, the system, or the user. This type of permission is granted automatically by the system to the requesting application at installation, without asking for the user’s permission. The user does have the chance to review these, though.
Dangerous – A higher-risk permission that would give a requesting application access to private user data or control over the device that can negatively impact the user. This permission is not granted automatically because of the risk associated with it. For example, any dangerous permissions requested by an application may be displayed to the user and require confirmation before proceeding, or some other approach may be taken to avoid the user automatically allowing the use of such facilities.
Signature – A permission that the system grants only if the requesting application is signed with the same certificate as the application that declared the permission. If the certificates match, the system automatically grants the permission without notifying the user or asking for the user’s explicit approval.
SignatureOrSystem – This permission is granted by the system only to applications that are in the Android system image or that are signed with the same certificate as the application that declared the permission. This permission is used for certain special situations where multiple vendors have applications built into a system image and need to share specific features explicitly because they are being built together.
There are also a few services available in the market which rate the applications based on different factors. Examples for these sites include https://viaforensics.com/appwatchdog/ and http://www.appoozle.com/Home/Android where you can see the trustworthiness of an application before installing it. For instance, below is one such screenshot taken from the above mentioned site.
Also there are apps which tell the permission and threat level of all the apps installed on the device. PermissionDog is once such app which lists all the applications installed on the phone and their corresponding permissions, as well as the threats associated with them.
Handling Intents & Activities in a secure way:
Intents – They are used to start an activity from your application. For example, the application may want to dial a number or open a web page. They can be used to send broadcasts, to start or stop background services, etc. They are the core of Android’s inter process communication.
Intent myIntent=new Intent();
Activity – is something that a user can do. So you can start a new activity using intent.
Intents can be used to start activities and the activity to be started is decided by Android’s Activity Manager. For all the activities, intent filters are registered. The activity manager checks the past intent against the intent filters registered for the activities and finds the match. The important thing here is intent filters are not a security mechanism (i.e. they don’t validate the incoming intent). Categories can be added to intents to make the system more selective about the code the intent handles. You can also add categories to intent filters declaring restrictions on the category. Adding categories to intent enhances the security.
Activities allow applications to communicate with each other, reuse each other’s features, etc. However, activities cannot depend on intent filters because callers can always pass badly configured intents. So it’s important to make the activities safe by confirming any changes or actions with the user. In simple words, intents received by an activity are untrusted inputs and must be validated. If you do not want your activities to be used by any other application, you do not have to define an intent filter at all. Another security aspect while starting activities is for you not to include any data into the intent which is of interest to an attacker. This is because a malware could register an intent filter and get hold of sensitive information sent to its activity. These are the issues to be looked out for even during a penetration test.
Validating and properly handling user data:
Files and Preferences:
Android maintains Unix style permissions for file systems like root file system. Each application has its own UID and has its own file system that it owns. So you can create files, edit them and save them. You need to consider certain important aspects while trying to do so. Executable codes like configuration files and scripts should be allowed with write preferences. Similarly, database files and logs should not have world readability. Other questions with respect to sensitivity of the file, unexpected changes to the file etc. are to be addressed well in advance.
Unsecure Storage in SD card:
Android provides several storage options such as internal storage, external storage, SQLite databases, shared preferences, and more. To save the files and data you can use either internal storage or external storage (SD card) depending on the purpose and size of the data. By default, the files saved to internal storage are private to the application. Due to the limited amount of memory in the internal storage, you might need to use the external storage option. Storing the data here is of some issue. To move the data faster across different locations, the format of these cards is VFAT which does not support the Linux controls. In other words, data stored in SD cards is world readable and can be accessed by any program on the device. Android clearly mentions that no security is enforced on the files stored in external storage. Because external storage can be removed at any time by the user; sensitive files should not be stored on here. If you need to store any confidential data, you need to encrypt it.
Securing the Content Providers:
Content provider mechanism allows applications to share raw data. You can share sql data, sounds, and images. SQL backend is also provided for the same. So using content provider applications can expose the private data to the outside world. If you don’t intend to share any of your data, you don’t have to develop a provider. The ‘provider’ tag present in AndroidManifest.xml registers it and defines permissions for accessing it. There can be separate read and write permissions for reading and writing on a provider. It is said that holding only write permissions does not mean you can read the data. But this is not always true because update and delete queries have a where clause which results in generation of a sql statement. Attackers can exploit this scenario through use of blind sql injection, where they insert queries after a where clause. For better security, it’s important to declare read and write permission directly in AndroidManifest.xml file’s provider tag.
Loading the code dynamically:
Android does not encourage developers to load the code outside of the application APK. This is because dynamic loading of code increases the chances of code injection or code tampering. It also increases the overall complexity of the application and makes it difficult for application testers. When the application loads code from insecure locations or from locations such as external storage, there is every chance that the content can be modified (either on the device or on the transit). If your application has to load code it has to come from a verifiable source. And another important thing is the code runs with same security permissions as the APK.
No other version available yet.