Combating Android Security Issues: The Case for Hardening Android

How Secure Is Android?

As a company that specializes in embedded Android customization, we often work with OEMs who are looking at adopting Android but are concerned about security; they question whether Android is ‘safe enough’ for their product. Some would argue that if Android is so widely deployed in phones, it must be secure, so this concern is unfounded. Unfortunately, that philosophy is not correct. Why? Most smartphones deal mainly with personal data. You have your address book, your pictures, your social networking data and possibly even your passwords in some crypto vault. This is important data, no doubt, and pilferage would range from a mere impediment to complete disaster for you depending on the circumstances. But now take the case for an Android IP Business phone. Such a phone will be wired into your enterprise LAN, which means that if your device is compromised, the theft (and liability as a result of it) could go far beyond you as a single person. Corporate servers could be subsequently compromised, critical data stolen. This would result in significant financial loss to the company.

Let’s look at another example: Android based Class I or Class II medical devices. These are typically FDA regulated, and for good reason. Errors and/or compromises could lead to life threatening situations for the patient. So naturally the concerns for security are more stringent here, especially if they are ‘connected devices’ compared to a standalone, personal phone.

Let’s go back to the basic question at hand: is Android secure enough for different verticals? The simple answer is that it depends on the use-case. The longer answer is that the stock AOSP Android image is not security optimized, but with modifications to the kernel, device management integration and possibly even migrating to SE-Android/Linux, the system can be made very secure.

Of course, in security, there is never a 100% assurance. Security is a multi-layered concept, with each layer adding more security – but it can never be fully complete.

The good news is Android can be customized to be more secure than many existing Linux based phones in the market today.  Not because a pure Linux based phone can’t be hardened, it can. It’s just that Android has received so much market focus that incredible effort has been put in to combat security holes or potential areas of exploitation. But there’s still more that can be done.

When it comes to working out how to harden Android, there are two major things to consider.

Hardening AOSP

AOSP (Android Open Source Project) is the stock Android source code that an OEM looking to build their own device first downloads. AOSP contains both the Android Middleware and the Androidized Linux kernel provided by Google. Typically, the OEM starts with this image and adds specific drivers required for support in their target platform (the latter is usually provided by the OEM’s hardware partner). It is surprising to see how many OEMs choose not to make AOSP more secure when they easily could do so. Most OEMs primarily focus on a locked down home screen (i.e. if they are making a specialized system that does not need a generic Android home screen) and quicker boot time, but pay less attention to patching security holes.

So how do you harden AOSP? There are several things you can do (not all of these may be applicable to your device):

• Eliminate Android network-enabled processes that start up on Android boot that you don’t need. For example, there are a bunch of applications that Android starts up that you may have no need for in your devices. They open up network connections that could potentially be used for compromising your system. Examples of such process include: Backup Transport, SCP, Market feedback Agent, Contacts Sync, SSH and others.

• In the same vein, eliminate applications that may not be needed. For example, there’s no need for Google Play in a medical device – get rid of it.

• Disable accessories unless you really need them. It’s better to remove them at compile time rather than run time because if you disable at runtime, they can be enabled again.
  • Bluetooth, NFC – channels for data pilferage, specific to Bluetooth, remote buffer overflow exploits keep surfacing.
  • SDCard & USB interface – you really don’t want people copying data to small untraceable cards in an enterprise deployment.
  • GPS, Accelerometer

• Harden device connectivity rules.
  • Specify routing permissions at the IPTables level to dictate what sort of traffic and connections are accepted going in and out of your system. You can also specify specific network interfaces which will have access to particular ports – this is very useful when say, you need to enable SSH access, but only want to authorize it when connected to your enterprise LAN via Ethernet and not over WiFi.
  • Encrypt network traffic – it is possible in Android to ensure all network connections be encrypted, say via OpenVPN and authorized to only work with a specific VPN gateway. In general, it’s a good idea to ensure no network data is transmitted without encryption and if it is, there needs to be a very good reason why.

• Harden custom applications – if you are developing custom applications that come along with the OS, ensure that in addition to following good security principles (such as not storing critical user data in the SD card), you also use Proguard and Dexguard to obfuscate your code. They make reverse engineering harder. On a related note, these tools are also very useful to remove Logs from your applications that often give out more information than you’d like to an infiltrator.

• SQLite – while this could have been bundled into the point above, it’s worthy of having its own mention. If you are creating custom policies/rules/applications that need to store data, consider using SQL Cipher instead of SQLite.

• ADB – The Android Debug Bridge is a standard mechanism that allows developers to debug applications on their device. It allows a host computer to connect either via TCP or USB to the target device and run commands on it, including installing new applications/removing apps/downloading data. This is often a much-abused interface. We’ve worked with vendors where multiple ADB strategies have been used:
  • Completely disabling ABD and implementing a proprietary device control interface secured with necessary authentication
  • Relocating ADB to another port and implementing custom authentication before one can access it

• Integrating device management solutions – it is important to integrate powerful device management solutions into enterprise solutions. In addition to just integrating MDM apps, we find it is best to actually integrate and embed them together as a ROM – that way it’s harder to disable by malicious attacks.

There are plenty of other areas that can be optimized and made more secure; these are just a few pointers. Hopefully, they’ve given you plenty to think about.

With respect to security, another interesting development is migrating your system to SE-Android instead of starting with standard Android.

SEAndroid (Security Enhancements for Android)

First up, let’s briefly touch on how security works in Android. At a very abstract level, Android’s security policy is UID and GUID based. Remember how in Linux where every user is mapped to a unique uid (with uid==0 is root) and group ids are used to provide access to more than one user? Well, Android is pretty much based on these same rules – except instead of mapping every ‘user’ to a unique uid, it maps every single process to a unique uid. Yes, that’s right. Every process that is installed in Android has a different uid. Furthermore, Android’s default policy is to deny access to applications unless the user (the person using the device) says otherwise.

So theoretically, you would think that this is a great model. And it is actually quite good. But the problem is that users often make mistakes. When they install new applications, they are often asked for permission and without thinking they may allow the application access to too many privileges. Once they do, the application can install malware, download harmful data and more. Therefore, there is a need for a better security policy framework that allows for the inspection of resource usage and patterns that go beyond user permissions.

Enter SE-Android. SE-Android consists of two parts:

SELinux

SELinux has been around for a while. It’s a hardened form of the standard Linux distribution. The key thing it adds is something called the MAC (Mandatory Access Control) layer, which goes beyond the user-enforced security model discussed earlier (also referred to as DAC or Discretionary Access Control) and offers a centralized security policy that can be customized and allows security policies to be enforced on a per process, per object as well as per operation basis. Simply put, what this means is that even privileged apps (with uid==0) can be restricted from certain operations. One key concept of this is that you can associate security tags with different resources, and write a centralized policy that dictates which processes have access to which resources, irrespective of the uid of the processes.

SEAndroid

SEAndroid is a more recent introduction, brought to you by the fine folks at (none other than) SEAndroid. While SELinux has been around for a while, its security policy framework needs to be exposed to the Android level as well. Remember that Android applications run inside their own Dalvik Virtual Machine (DVM) instances. It ties into SE-Linux and also brings with it a MAC policy layer at Android called the MMAC (Middleware Mandatory Access Control) that provides granular security policy enforcements at the Android level. (Technically, SEAndroid could also just be SELinux in enforcing mode, but we think the MMAC is an important part of the framework and hence have included it as part of our definition of SEAndroid)

Linux users may be aware that migrating from standard Linux to SELinux is not very hard. In fact, many distributions like Ubuntu and Debian have rather straightforward mechanisms to migrate to SELinux. Unfortunately, it’s a much harder problem to migrate Android to SEAndroid unless it already includes SELinux. Smalley et. al published a paperon the efforts involved in this, and they are not straightforward. But fortunately for us, since Android 4.3, SELinux has actually been included as part of the Android distribution – just not in enforcing mode. Essentially, this means that while SELinux was a part of the image, its security policies were not really being used for anything except logging access.

Starting with release 4.4 (Kitkat) of Android, SELinux was actually put into enforcing mode and it is now possible to configure the MAC for security policies. In other words, starting with version 4.4 you can actually use the SELinux MAC layer to configure granular policies. Note however that in 4.4, MAC policies have been applied only to a select set of Linux process. Even so, the fact that MAC was enabled and in operation means that this layer can be extended – great news for OEMs building devices! For example, this paper gives a good example of how this helps – it describes an exploit, where a buffer overflow would exploit a well-known uid=0 process (void) and launch a root shell. Using SELinux MAC, one could easily write a policy which would deny command line shell access to void making this exploit fail. The same paper cites many other interesting examples where the SELinux MAC would help thwart other exploits based on uid, and further justify the need for SELinux.

So what does the proposed Android MMAC bring on top of SELinux?

SELinux only works at the Linux process level. The entire Android middleware is then open to exploit. This includes third party Android applications that may be performing unauthorized operations at the Android level (above DVM). Many of these operations may not be visible to the Linux layer and/or may look just like regular IPC calls (becauSEAndroid uses binders for a lot of inter process communications).

Finally, as discussed earlier, the Android security policy is user-based and once the user grants permissions there is no clean way to enforce operation-based security. Given that Android and Linux are really separate layers, it’s not clean to mix Android and Linux permissions together. Therefore, it is necessary to somewhat mimic the Linux MAC at the Android level. And this is exactly what the MMAC does.
Unfortunately, as of today the MMAC layer is very limited (almost absent) in Android mainline. While the folks behind SELinux have made good contributions to the MMAC, it has yet to show up in mainstream Android. Until it does, it is left to OEMs to do this on their own.

Conclusion

When building your next great device using Android, the impact of security issues needs to be assessed based on your vertical. Securing Android is a multi-pronged approach, so you should not only look at hardening your existing kernel/middleware but also look at the viability of basing your product on SEAndroid. While the SEAndroid effort from an MMAC perspective is still not fully integrated into the mainstream Android code, it would benefit new device makers to adopt the SELinux enabled 4.4 and above code branches of Android and build from there. Irrespective of whether you choose to go with SEAndroid or not, for now, you should definitely look at hardening your Android code. The tips provided above should give you enough food for thought to get started.

(Do you find this article interesting? You may want to check out our Embedded Android pages to read more about what we do in this space.)