Assessing the security features of android 5 x

ASSESSING THE SECURITY FEATURES OF ANDROID 5.X WHICH INFLUENCES BRING YOUR OWN DEVICE (BYOD) POLICY

BY

DANIEL DE JAGER

1.

CONTENTS

1. CONTENTS ....................................................................................................... 2 2. LIST OF TABLES .............................................................................................. 3 3. LIST OF FIGURES ............................................................................................ 3 1. Introduction ........................................................................................................ 4 2. Overview of the Android Architecture ................................................................ 4 3. The Security Model and Android 5.x Security Enhancements ........................... 5 3.1

Application Sandboxing ............................................................................... 6

3.2

Permissions................................................................................................. 6

3.3

Interprocess Communication....................................................................... 7

3.4

Code Signing and Platform Keys ................................................................ 7

3.5

Multi-User Support ...................................................................................... 8

3.6

SELinux ....................................................................................................... 8

3.7

System Updates .......................................................................................... 8

3.4.

Verified Boot................................................................................................ 9

3.5

Encryption ................................................................................................... 9

3.6

Smart Lock Features ................................................................................... 9

3.7

Address Space Randomisation ................................................................. 10

4. Known Android 5.x Security Vulnerabilities and Exploits ................................. 10 5. How Android 5.x Security Features Influences BYOD Policy .......................... 11 6. Conclusion and Recommendations ................................................................. 13 7. REFERENCES ................................................................................................ 14

2

2.

LIST OF TABLES

Table 1 Known Vulnerabilities for Android 5.x ........................................................ 11

3.

LIST OF FIGURES

Figure 1 Android Security Architecture, Android (2015)………………………………….…..…6

3

1. Introduction Information Security is the counterbalance of Risk. At the core, it is concerned about the Confidentiality, Integrity and Availability of Assets, as well as Accountability, Authentication and Authorisation in support of the mission of the Enterprise.

Fundamentally, BYOD presents a paradigm shift in the approach towards managing risk, driven by the consumerisation of Information Technology, transforming the way in which employees conduct activities and tasks at work.

Enterprises are now faced with the challenge of sharing risk between the organisation and the employee, as the employee owns the asset which stores and transmits organisational information connected to the Enterprise Infrastructure. It is therefore necessary to enforce Enterprise Policy

on

the usage of mobile devices, enforce process and standards, and to mitigate threats associated with mobile device usage at work.

This paper examines Android version 5.x and how it influences the BYOD policy. We review the architecture and security model of the Android Platform. We then

analyse known vulnerabilities and their associated

risk. Lastly we take a view of all

these features and determine how they

would influence a typical BYOD

Security Policy. A conclusion is

then

presented with recommendations.

2.

Overview of the Android Architecture Android (2015) shows the Android Architecture as layered. At the bottom of the stack is the Linux Kernel on which Android is based. It contains the necessary drivers for communication with the phones hardware.

4

Elenkov (2015) describes Linux as a multi-user system which implements user resource and process isolation. Permissions are the

mechanism

enforced to provide permission to explicitly access

resources from other

users. He continues on to describe that users are

not physical, but are

applications instead and forms the foundation for

Android’s

application

Sandboxing. This is the implementation of the principle of Least Privilege, in that each application can only access its own resources.

The second layer contains the libraries as well as the Android Runtime, which

is

Framework

based

on

the

Dalvik

Virtual

Machine.

The

Application

follows and then lastly the most upper layer is the

Application Layer.

Each component assumes that the components below are properly secured.

With the exception of a small amount of Android OS code running as root, all code above the Linux Kernel is restricted by the Application Sandbox (Android, 2015).

Redmond Pie (2013) shows a poster of Android flavors in the form of a timeline. Most notably is how more APIs are now exposed for use in the newer versions, and security improved over the last 7 years. Drake et al.

(2014) shows a similar timeline, but concerning is the adoption rate of new versions that he indicates and explains that it takes approximately 365 days to get a new version of Android on 90% of devices. From a malicious point of view this is certainly good news.

3.

The Security Model and Android 5.x Security Enhancements

5

3.1

Application Sandboxing Android shares Linux’s UID/group ID paradigm, but does not have traditional passwd and group files for its source of users and group credentials (Drake et al, 2014). Instead it utilises Application ID’s. This is a good technique to separate applications and their resources from other applications. Each application would have its own space in memory rather than sharing this with others, which might be malicious.

Figure 1 Android Security Architecture, Source: Android (2015)

3.2

Permissions

6

Even when applications are mutually exclusive, some requirements must allow for applications to share resources. The mechanism which can provide access to data or resources is called Permissions. Permissions can be requested and they can be provided. For example, and application that requires internet access would require permission to do so. It would request permission by using XML based tags to indicate it requires internet usage.

The flipside of Permissions, if not implemented correctly, i.e. if your application is not implementing least privilege; it might lead to unauthorized use of protected resources.

3.3

Interprocess Communication Interprocess Communication is achieved through the Kernel. These messages passed from one process to another are referred to as Intents.

Android leaves it up to the callee to decide who can call it (Tomescu, 2011).

This again, presents an issue when it comes to the developer having to make a decision in terms of allowable callers. The developer must understand processes and their UIDs. Only trusted processes are to be allowed to be the

3.4

calling party.

Code Signing and Platform Keys All Applications are signed by their authors. This ensures that updates on applications can be verified. Platform keys can be used to sign applications that require sharing of resources and run inside the same process (Elenkov, 2015). This is an excellent feature. It supports non-repudiation at the Core of Information Security.

7

3.5

Multi-User Support Android supports multi-users on the same device(s), and ensures that data is kept separately by managing the physical user and the applications they install and use. Android 5.x supports guest users which cannot access data of authorized users. This creates a possible issue around, who is accountable for which actions on a corporate network as the device is being shared. Central Mobile Device Management Solutions must be multi-user aware to implement the concept of accountability i.e. who is doing what?

3.6

SELinux Elenkov (2015) describes that Security Enhanced Linux (SELinux) is a Mandatory Access Control implementation for the Linux kernel and that it is from version 4.4, that SE Linux is deployed in enforcing mode, limited to system daemons. Applications run in permissive mode, and violations of policy do not cause runtime errors. Although Android (2015) indicates that enforcing mode is an enhanced feature of the Android 5.x platform, it has already been implemented since version 4.4.

3.7

System Updates System updates are particularly useful when software vulnerabilities have been discovered and can be rectified by an OTA patch. OTA is an acronym for Over-the-Air. OTA update are performed by download an OTA package files which contains a small script file to be interpreted by the recovery, and rebooting the device in recovery mode (Elenkov, 2015). Android (2015) says Webview can now be updated independent of OTA for Android 5.0. Webview allows a developer to add internet content without using a browser in his or her application.

8

3.4.

Verified Boot According to Android (2015), verified boot is an experimental feature implemented from Android 4.4. They further explain the use of hashing to ensure block states of the file system. It is a mechanism to prevent rooting the system through the use of a key burned into the device by the manufacturer. This is a good feature to use, since File Integrity is important as it pertains to sensitive information.

If a malicious agent successfully

changes the state or integrity of key system files, this functionality would be a detective control.

3.5

Encryption Android 5.x is encrypted by default according to Android (2015). Full disk encryption is enabled and the key is bound to the hardware keystore (Android, 2015). It also supports TLSv.1.2 and TLSv1.1. Android (2015) indicates Forward Secrecy is now preferred and AES-GCM is enabled with weak cipher suites disabled. Although this feature will not be a preventative measure, it would make it more difficult to copy data if a device is stolen. It might also alleviate remote wipe, as risk is less when encryption is applied.

However, this might be a predicament for forensics if a device is used to conduct illegal activities within the Enterprise.

3.6

Smart Lock Features From version 5.x, a device can be unlocked by trusted devices. Android (2015) even states that facial recognition can be used for device unlocking.

These are known as trust agents (Elenkov, 2015). This can be an advantage

9

for the Enterprise in that when a device must be accessed by security incident personnel, that it can be unlocked by a “master” device. MDM technology can benefit from this feature for centralised management.

However, this also means that trusted devices which do not form part of the mobile device ecosystem may unlock a device and gain access to classified information.

3.7

Address Space Randomisation Operating Systems can implement software assurance. One of these features is Address Space Randomisation. In order for malware and memory exploits to be successful, the threat agent must be able to accurately identify and determine the memory address where a specific process or function will be loaded. Android 5.x supports ASR. Android (2015) also requires that DLE’s must support Position-Independent-Executables.

4.

Known Android 5.x Security Vulnerabilities and Exploits Android 5.0 includes fixes for older versions of Android. But as we know, software is not 100% secure. According to Kovacs (2015), a Chinese Researcher discovered two major vulnerabilities in Android version 5.0 and earlier. Android 5.0 and earlier suffers from a data handling error in the GraphicBuffer::unflatten

function

in

platform/frameworks/native/libs/ui/GraphicBuffer.cpp which leads to heap corruption.

According to NIST (2015), it has been assigned CVE-2015-1474 with CVSS base score of 10 and vector (AV:N/AC:L/Au:N/C:C/I:C/A:C) which indicates that a complete compromise of Confidentiality, Integrity and Availability is

10

achieved and is trivial to perform. In essence this describes a Denial of Service Threat.

A second vulnerability that was disclosed by the same researcher, referenced as CVE-2015-1530, with the same base score and vector, according to Kovacs (2015) but no NVD record exists. However, Seclists (2015) describe an integer overflow in Android 5.0 and older, on March the 12th 2015.

A fix for the vulnerabilities has been provided. These are provided in Lollipop 5.1. Table 2 shows a list of known vulnerabilities and exploits.

Platform

Android 5.0

Android 5.0

CVE

Discovery Date

CVE2015 11/03/2015 1530 CVE2015 15/02/ 2015 1474

Exploit

Exploit Source

POC Only

http://seclists.org/fulldi sclosure/2015/Mar/67

POC Only

http://seclists.org/fulldi sclosure/2015/Mar/68

Table 1 Known Vulnerabilities for Android 5.x

5.

How Android 5.x Security Features Influences BYOD Policy We seek guidance from guidelines and standards such as NIST and ISO27001/2 on BYOD Policies, Processes and Standards. NIST publication SP800-124, Guidelines for Managing the Security of Mobile Devices in the Enterprise refers to SP800-53, Security Controls and Publications, as a supporting control framework for BYOD. ISO27001 follows a risk management approach and Enterprise Policies would reflect the appetite of risk for each organisation. Technical Controls would then be derived from ISO27002.

11

Full Disk Encryption as default setting provides a hurdle for Forensic Investigators. Enterprise BYOD policies would make statements that the Organisation would have the right to seize and examine any Smart Device for Forensic Investigation. However, encryption would satisfy Confidentiality Requirements of Security Policy. It would then make sense that the MDM Solution caters to support the Organisations Forensics requirements by having access to the hard key.

Given the scope and severity of vulnerabilities described, BYOD policy must refer to Patch Management, and which specific Android OS version is acceptable, and therefore BYOD Policy would have to speak to Configuration Management. A Standard of N-1 on Android 5.x will not suffice as a serious flaw exists in version 5.0.

The organisation would also then have to allow OTA to enable software upgrades. This then creates the question of responsibility of compliance.

One approach to enforce compliancy would be if a smart device is found to be non-compliant do not allow access to the corporate network. The alternative is to place the device on a guest network with limited access to corporate data.

This places the and shifts the risk to

responsibility solely on the owner of the smart device, the owner, a transfer of risk by the organisation.

However, one must consider accessibility of broadband, especially in developing countries, in that some countries might not be able to cater, therefore the organisation plays a pivotal role in assisting upgrading of software through corporate infrastructure.

12

Even though Applications are digitally signed by their authors to enforce nonrepudiation, it would make sense that BYOD Policy refer to control in terms of whitelisting or blacklisting certain applications from Google Play.

Developers are still human, and will introduce flaws during the development lifecycle. Some examples of flaws, would be allowing incorrect Permissions, allowing unauthorized applications to harvest data. However, this capability requires one to have the capability to

authorize the installation of third

party applications, being aware of the vulnerabilities being introduce onto the smart device, and how it can impact the organisation. Again, one can utilise MDM technology to support the process of authorisation if supported.

Smart unlock might pose a threat in terms of devices being able to unlock one another especially from an Enterprise point of view. Consider the scenario where a family member’s smart phone is trusted and can be used to unlock another device, the latter being a BYOD device. From an Enterprise point of view, the family member would be an unauthorized individual now having access to corporate data.

6.

Conclusion and Recommendations Android relies heavily on the security of SELinux for its security, and implements the concepts well. Given the security features implemented and the risks associated, it means that a BYOD policy needs to cater for these changes as some features may impact information security.

It is recommended that a Vulnerability Management Program also includes the scanning of Android Smart Devices, in order to calculate the risk and exposure for the organisation and that processes from Vulnerability Management then interacts with Configuration Management. The latest 13

vulnerabilities as indicated in this report show that zero days exist in the operating system libraries. It tells a similar story to that of OpenSSL (Codenomicon, 2014), that these vulnerabilities where shipped since 2008.

Smart lock is a feature which can aid the user away from the corporate office, but it can pose a risk for the organisation if unauthorised individuals might also be able to unlock a smart device. It is therefore recommended that consideration is given to enablement of this feature.

7.

REFERENCES

[1]

Android (2015). [Online]. [Accessed 2 March 2015]. Available from: http://www.android.com/history/

[2]

Android (2015), Secure Boot [Online]. [Accessed 4 March 2015].

Available

from: https://source.android.com/devices/tech/security/secureboot/index.html

[3]

Codenomicon (2015), Heartbleed Bug, [Online]. [Accessed 13 March 2015].

Available from: Heartbleed.com

[4]

CVE Details (2015), the Ultimate Security Vulnerability Data source [Online].

[Accessed

6-15

March

2015].

Available

from:

http://www.cvedetails.com/product-list/vendor_id-1224/Google.html

[5]

Drake, J., For a, P., Lanier, Z., Mulliner, C. Ridley, A, Wicherski, G. (2014), Android Security Design and Architecture. In: Shimonski, R. ed., Android Hacker’s Handbook. Indianapolis: John Wiley & Sons, Inc.,pp.25-56

14

[6]

Elenkov, N. (2015), Androids Security Model. In: McGarvey, G. ed., N., Android Security Internals an in-depth guide to Android’s security architecture. San Francisco: No Starch Press Inc, pp. 1-19

[7]

Elenkov, N. (2015), Android Explorations [Online]. [Accessed 7 March 2015].

Available from : http://nelenkov.blogspot.com

[8]

IsecT Ltd. 2012 [Online]. [Accessed 13 February 2015]. Available from: https:// www.iso27001security.com/ISO27k_Model_policy_on_BYOD_security.pdf

[9]

Kovacs, E. (2015), Security Week [Online]. [Accessed 12 March 2015].

Available

from:

http://www.securityweek.com/google-fixes-priviledge-

escalation-vulnerability-android-51.lollipop

[10]

National Institute of Standards and Technology, NIST Special Publication 800-124 Revision 1 (2013), Guidelines for Managing the Security of Mobile Devices in the Enterprise, pp.1-30

[11]

National Institute of Standards and Technology, NIST Special Publication 800-53, Security and Privacy Controls for Federal Information Systems Revision 4.

[12]

NVD (2015), National Vulnerability Database [Online]. [Accessed 6-15 March 2025]. Available from:https://web.nvd.nist.gov

[13]

Redmond Pie. 2013. [Online]. [Accessed 15 February 2015]. Available from http://www.redmondpie.com/android-version-history-guide-v1.0-to-v4.1-jellybean-infographic/

15

[14]

Tomescu, A. (2011), Android Security Model [Online]. [Accessed 2 March 2015]. Available from: http://www.cs.stonybrook.edu/~rob/teaching/cse409fa11/

16