Security of Android and iOS devices

Motives and statistics of attacks

Smart devices have become the central information hub in many people's personal and even professional lives. Hence, an attacker who gains access to a smart device can: get access to data stored on the device: personal information, stored passwords, credit card numbers, photos, e-mails, etc. In addition, it is possible to take over the identity of the device's owner by using the services that are automatically logged in on the device or by making phone calls or sending messages. It may also be possible to deny the device owner's access to his/her device and demand ransom for granting the access.

A research paper “Dissecting Android Malware: Characterization and Evolution” published in 2012 analysed 1260 different malicious Android apps that were discovered between August 2010 and October 2011:

86% of the analysed apps were repacked versions of some other apps, i.e. they just added a malicious payload;
36.7% of the apps were granted administrator access on the device;
90% made the device join a botnet
45.3% sent messages or called paid numbers;
51.1% of the apps gathered information about the device user;
the best antivirus app at the time recognised 79.6% of these apps as malware;
the worst antivirus recognised only 20.2% of the apps.

Mobile threat reports from F-Secure

(up) Android malware, categorised by the app store.

F-Secure, the developer of popular antivirus software, periodically publishes reports on (mobile) threats. According to its report on the second half of 2013 (pdf), 97% of the new mobile malware targeted the Android platform and the rest 3% Symbian. It means that no known malware was detected on iOS, Windows Phone, or Blackberry platforms during this period.

In the second half of 2013, F-Secure collected a total of 180,000 examples of potential malware apps. The image to the right shows from which Android app stores these examples originated and how many were deemed malware by F-Secure. As shown, only 0.1% of the samples from Google's official Google Play store were malware.

As seen from the threat report for the second half of 2014 (pdf), there are also some malicious apps targeting iOS. However, it is still much less than for Android.

Mobile malware in H2 2014.

Since getting one's malicious app accepted in Apple's App Store has proven difficult, attackers have found alternative ways to get malware on iOS devices. For example, in 2014, there was a class of malware that infected an iOS device when it was connected to an already infected computer by a USB cable. According to the F-Secure's Threat Report 2015, there have been instances where instead of an end-user, an app developer's computer is attacked. By infecting the developer's computer, the malicious code is copied into the app when it is built, without the developer knowing it.

Top 10 Android malware, F-Secure Threat Report 2015.

Newer info can be found from a report by Skycure: Mobile Threat Intelligence Report Q1 2017.

Security policies for smart devices

A security policy of an enterprise should also cover smart devices. It should include which devices and how they can be used for work-related tasks. An example of such policy can be seen here: Sample Mobile Device Security Policy.

There are three common usage policies for (smart) devices:

Bring Your Own Device (BYOD)
Choose Your Own Device (CYOD)
Corporate Owned, Personally Enabled (COPE)

Next, we give a short overview of each and more information can be found here:

BYOD allows employees to use their own devices for work. Hence, it is the cheapest solution and suits a small business without a strict security policy. The problem is that the employer has no control over the devices. There are many different types of devices, so the security manager has no overview of the security of the devices used.

CYOD allows employees to use their own device only if it is approved by the employer. Hence, the employer can approve a shortlist of devices that it considers most secure. For example, a security manager can allow only newer iOS and Google Nexus smart devices as iOS devices are considered more secure, and Google Nexus devices are the first to get security updates. This usage policy is more expensive for the enterprise but gives a better security level without restricting employees' freedom too much.

COPE allows employees only to use a device owned by the employer and is under its control. The employer can choose which apps are allowed on the device and how and for what the device may be used. This is the most expensive usage policy and suits only companies that need a high-security level or greater control over their employees.

Dilbert comic (source)

Physical security of mobile devices

What could happen when an attacker can briefly access the device? In case the attacker has physical access to an unlocked device, it may be possible (depending on the configuration) to:

read / copy / erase information on the device
impersonate the owner of the device - send messages, emails, photos, etc.
get access to the logged-in accounts
use the credit card number that is connected to the device
install malware
access the second authentication factor that is integrated into the device
access the cloud services used by the owner of the device
make expensive phone calls, buy items via SMS messages

Thus, physical access should be prevented to an unlocked device. To prevent the previously mentioned malicious activities, the device should be configured to lock itself automatically. However, the screen lock only fulfils its goal when it is nontrivial to unlock. Thus, simple patterns and common PIN codes do not provide sufficient protection. The screen lock on its own can not protect the data stored on the device. Fortunately, modern Android and iOS devices automatically enable encryption when a strong screen lock is used.

Screen lock

What can a person do who gains temporary access to your smartphone/tablet? He/she can:

read, copy or delete personal information as usually your e-mails are synced to your device;
act as the device owner, send messages, e-mails, upload photos;
gain access to all services where the device owner is logged in;
use device owner's credit card (if this information is saved);
install malware, for example, to grant later access;
use the device for two-factor authentication.

It is important that an unauthorized person cannot gain access to your smart device. To mitigate this risk, a screen lock with a non-trivial pattern, PIN-code or password must be enabled. Even a brief moment with your smart device gives an attacker a large attack surface, and therefore the device should be locked whenever you are not using it.

1. Pattern lock

The easiest way to lock an Android device is to use a pattern lock. To unlock the device, a right pattern must be drawn on (usually) a 3x3 grid. With pattern lock, an attacker may guess the correct pattern by just trying or by studying the fingerprints on the screen (see the paper "Smudge Attacks on Smartphone Touch Screens"). An attacker has 20 tries before the device is locked and can be opened only with a Google account password.

Pattern lock on Android (source)

2. PIN-code

Both Android and iOS support screen locks that are based on PIN codes. On Android, the PIN-code is limited to 4..16 digits, whereas iOS supports either a PIN-code of exactly 4 digits ("simple passcode") or a password.

It is possible to have five incorrect PIN-code entries in Android before a 30-second delay is introduced. So, if it takes 10 seconds to enter five incorrect PIN codes, then with this additional delay, it makes a total of 40 seconds for every five tries. In one hour, there are 3,600 seconds, so with this speed, it is possible to try about 90 codes in an hour. It would take up to 111 hours (and 55.5 hours on average) to brute force a 4 digit PIN code in this way. iOS allows automatically deleting all data on the device after 10 (or on some devices 6) unsuccessful tries.

PIN-code protected lock screen on Android (left) and iOS (right, source).

3. Password

Both Android and iOS also support locking the screen by using a password. The password must be at least 4 characters long in both Android and iOS, but in Android, at most, 16 characters are allowed compared to 37 on iOS. The repercussions of entering a wrong password are the same as with PIN codes.

Password entry on an Android device.

4. Fingerprint reader

Newer versions of both iOS (iPhone 5s or later, iPad Air 2, or iPad mini 3 or later, source) and Android devices support unlocking the device by using a fingerprint scanner. In iOS, it's called Touch ID. On both systems (all iOS devices and newer Android devices), fingerprint data is stored only locally in a secure hardware element.

There have been successful attempts on bypassing the Touch ID-based lock by using a lifted fingerprint of the device owner: "Hackers claim to have defeated Apple's Touch ID print sensor".

5. Face recognition

Some Android devices include the possibility to unlock a device by using face recognition. When the feature is activated, then it is required to add a fallback method that is used in case face recognition fails. The fallback method can be either a PIN code or a password. The fallback method is used with most biometric mechanisms, including fingerprint sensors.

Face recognition on Android.

It is fairly easy to use a photo to bypass face recognition, so it should be considered a convenience feature rather than a true security measure. To overcome the simple photo hack, the Android developers have added a "liveness check" to verify that the device's camera is seeing a real person. It forces the user to blink his/her eyes in order to unlock the screen. However, this can also be fooled quite easily:

Encryption

A screen lock itself does not protect the data on the device. In order to protect the data, encryption should be used. Encryption helps in case the device is stolen or in the case when the attacker has enough time to copy files from the device. Additionally, remote wiping should be enabled in order to protect the data in case the device is stolen. There is a chance that the attacker may bypass the screen lock, but it is also possible that the attacker could access the files directly if the device is not encrypted.

On Android, device encryption has been supported since version 2.3.4, although it might differ for different manufacturers. To encrypt all data on the device, go to Settings -> Security -> Encrypt.... Full-device encryption is turned on by default starting from Android 7.

Keep in mind that:

After encrypting the device, a PIN code or a password has to be entered after each reboot, and in addition, it has to be used to unlock the screen.
Encryption is only as strong as the password, so choose a strong password. This does not apply if the device is encrypted by default.
Encrypting the whole device might take a long time. It is advisable to keep the device battery charged during this process, as interruptions may cause data loss.
There is no way to restore data if the encryption password is lost.
If your device has a separate SD card, make sure it is also encrypted. Some devices require encrypting it separately.

A detailed overview of Android device encryption can be found here: Revisiting Android disk encryption.

On iOS devices starting from iPhone 3GS, iPod Touch 3 gen. and all iPad models using a screen lock automatically enables device encryption. Starting from iOS 8, even Apple cannot access the data on the device without the encryption key, i.e. the key is stored in a special security enclave in the device, and Apple does not have a backup key (backdoor).

Locating a lost phone

Both Android and iOS have an option that allows to start tracking the device through a web application. If the device is lost, then it is possible to see its location on the map and make it sound an alarm so it can be easily found. If the device is stolen, these services allow to remotely enable a screen lock with a strong(er) password or to wipe the whole device.

This feature requires that the device periodically sends its own location info to the service provider (Google or Apple), so GPS and mobile internet or WiFi must be enabled.

On Android, the tracking service is called Google Find My Device.

Android Device Manager (previous name for the service) showing a device on a map.

To enable it:

Go to Google Find My Device
Accept that your device's location is sent to Google
Locate your device on the map
1. If this does not work, verify that the device has an internet connection
2. If that does not work, verify that location services are enabled on the device:
  1. Settings -> Location access -> Access to my location
  2. Settings -> Location access -> GPS satellites
  3. Settings -> Location access -> Wi-Fi & mobile network location

On iOS, the tracking feature has been available since iOS 5 and is called "Find My" (it was called "Find My iPhone" before iOS 13).

Find my iPhone showing an iOS device.

To enable this service, go to: Settings -> Apple ID -> Find My on your device. Also, you have to have an Apple iCloud account.

To use the service, go to https://www.icloud.com/, log in with your Apple ID and click on the "Find my iPhone" icon. You have to enter your Apple ID password once again, and then a map is shown with the user's devices.

More information about it can be found on Apple's web page http://support.apple.com/kb/PH2696 or from an unofficial tutorial on Youtube: https://www.youtube.com/watch?v=XvvIyhgMnLI.

Activation lock

Starting from iOS 7, Apple's devices also have an activation lock that ties a device with a specific Apple ID. Without entering the account's password, it is not possible to reset the device and start using it as a new user. Activation lock is part of "Find my iPhone", and it makes stealing iOS devices pointless.

Android

Android logo (source)

Permission model

Android policy used to require that apps include a list of permissions that they might need. These permissions are listed in the Google Play store when installing an app and can also be seen on the device for apps that are already installed. It is essential to study which permissions (and combinations of permissions) an app requires before the choice is made to install the app. For example, a game should not be able to make phone calls or send SMS messages. If an app asks for too many illogical permissions, it might be malware. Also, it is important to consider that many free apps need network communication access just to show advertisements.

Unfortunately, with this policy, it is not possible to install an app by granting it only a subset of the permissions that it asks for. A user must either accept all of the required permissions or cannot install the app at all. Granting a subset of required permissions is enabled in CyanogenMod, though.

A list of possible app permissions: https://developer.android.com/reference/android/Manifest.permission.html
A list of app permissions with explanations on Android developer forum: http://forum.xda-developers.com/showthread.php?t=2341839

Of course, it is possible to see the list of permissions granted for each app. Android provides a way to do it one app at a time, but there are also special apps that give a better overview, e.g. PermissionDog.

Exercise. Use Google Play store to study a list of required permissions for an app.

A thorough overview of the current security model in Android is given in "Android Security, Pitfalls, Lessons Learned and BYOD".

Starting from version Android 6 (Marshmallow), Android adopted a more granular permission model, where a user is asked for the permissions when the permission is first used. For example, in a supported app, a user should give permission when the app would like to access potentially privacy-critical information, e.g. access photos, device location, use the microphone, etc.

More granular app permissions in Android Marshmallow (source).

Threats and problems

Attack vectors

Repackaging or imitating existing apps and redistributing them in alternative app stores.
Adding a self-update feature to an application to download the malicious payload after the app has been installed.
Drive-by download

Pirate copies of apps

With pirated apps, there is no guarantee that the app is tested or free of malware. On the contrary, pirate copies of apps are a convenient way to distribute malware. Many users would like to access a priced functionality for free and thus do not care much about the security risks. It may be difficult to ascertain if a pirated copy is modified just to get it working for free or it is also infected with malware. Moreover, pirated apps usually do not have a community that reviews and rates the apps.

Problems with updating

Android is open-source software, and also some of its bug tracking sites are public. This means that attackers may get enough published information about the currently available vulnerabilities. Hence, bugs should be fixed quickly, but in reality, it may take months before a fix reaches the end-users. The problem is that distributing bug fixes (patches) is expensive for device manufacturers, and there are a lot of manufacturers creating Android devices. Updated firmware must be thoroughly tested, and updated devices must be recertified for the mobile network operators. Certification is expensive and can take months. Therefore, many Android users do not get updates and are not able to use the new Android versions. This is illustrated by the following screenshot that shows the distribution of Android versions:

Distribution of Android versions. (source: screenshot from StatCounter)

Researchers in Cambridge studied information that was collected from 20400 Android devices and found out that most of the devices are vulnerable as the software has not been updated. You can read more about the study from the article: Security Metrics for the Android Ecosystem. Similar findings are depicted on the following graph.

Vulnerable Android devices (source).

A good overview of the problems related to updating Android is given in "Android Security, Pitfalls, Lessons Learned and BYOD". This report also gives a good overview of how some of the operating system customizations done by device manufacturers have weakened the Android security model and opened up new attack vectors.

Project Treble (source)

Google tries to tackle these problems with project Treble that separates vendor-specific customizations from the operating system core functionality. As a result, vendors are able to ship Android operating system updates (including security patches) directly to end-users without the need to re-apply their customizations. Project Treble is available for all new Android devices shipped with Android O (Oreo). Read more from the Android Developer's blog.

Security recommendations

Enable screen lock (pattern, PIN-code, password, face recognition or fingerprint scanner).
Use only official or well-known app stores
- Google Play
- Amazon Appstore
Before installing an app, look at its popularity, rating and comments.
An app should only have the permissions it really needs.
Think before giving an app access to your personal information.
Do not keep private information on a removable memory card. App-specific access rights do not work there so that every app can access all the data stored on removable memory cards.
Pirated apps may contain malware that is hard to notice.
Encrypt your device.
Disable USB debugging in the settings (unless you are a developer).
If you do not have Bluetooth enabled accessories, disable Bluetooth.
Do not root your device unless it is really needed.

Additional content

An overview of the architecture and security of Android is given by the MIT course 6.858 Computer Systems Security. The following video lecture is made available through the MIT OpenCourseWare program. It is not compulsory to watch the video; it is an extra material for the students who would like to get more information about Android. We advise you to read the following article before watching the video lecture: Understanding Android Security.