Security of smart devices

Motives and statistics of attacks

Why are smart devices attacked?

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.;
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;
deny device owner's access to his/her own device and demand ransom for granting the access.

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

86% of the analyzed 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 recognized 79.6% of these apps as malware;
the worst antivirus recognized only 20.2% of the apps.

Mobile threat reports from F-Secure

(up) Android malware, categorized by app store.

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

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 from and how many were actually deemed as malware by F-Secure. As shown, only 0.1% of the examples from the Google's official Google Play store were really malware.

As seen from the threat report for the second half of 2014 (pdf), there are also some malicious apps targeting iOS. However, it it 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 computed 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.

An open or a closed platform

Why are there so much more malicious apps on Android than on iOS? The main reason here is that Android and iOS (iPhone, iPad) use different method for distributing their apps. Apple uses a closed system and allows users to download apps from a single source - the App Store. Google uses an open system that enables users to get apps from different app stores and even install them manually.

The closed system of Apple iOS:

A single source for apps - the App Store
- All distributed apps are digitally signed by Apple itself
- Jailbraking the device allows to install apps from other sources
Strict requirements for accepting an app in App Store
- Developer guidelines: https://developer.apple.com/appstore/guidelines.html
Apps can be browsed by a special program (App Store on device or iTunes on computer)
- Some apps can be browsed from the web: App Store.
Apps in the App Store are tested for following the requirements and for malware
- Still, sometimes it is possible for a malicious app to bypass these tests: http://www.theguardian.com/technology/appsblog/2013/aug/19/ios-malware-apple-iphone-ipad-jekyll
Apps are run in a sandbox
- User cannot see the rights that an app has in the device
- iOS is closed source

The open system of Google Android:

Possible to use different app stores
- For example, Amazon app store: http://www.amazon.com/gp/mas/get/android
Google Play store has fewer restrictions than Apple App Store, so it is easier for developers to distribute their apps
- Developer Distribution Agreement: https://play.google.com/about/developer-distribution-agreement.html
- Google Play: https://play.google.com/store?hl=en
Each app has a set of permissions showing what it can do in a system
- This changed starting from Android version 6 (see below)
Apps are signed by developers
Most malicious apps are discovered by community
Android is open sourced
- https://source.android.com/

Hence, we can say that with its strict rules Apple iOS provides more security to the end user. However, both iOS and Android devices can be rooted to overcome some of the restrictions posed by the operating system. For example, on a rooted device, it is possible to access the file system of the device directly. On the other hand, rooting also makes it easier to attack the device. On iOS, rooting is called jailbreaking.

Rooting allows to:

Android
- install another operating system, e.g. GrapheneOS
- uninstall apps bundled by device manufacturer or carrier
- tune some apps to make them run faster
- disable carrier lock
iOS
- install apps from alternative sources
- get file system level access
- disable carrier lock

Security policy for smart devices

A security policy of an enterprise should also cover smart devices. It should include which devices and how 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 that does not need a strict security policy. The problem is that the employer has no control over the devices. There are many different types of devices and so the security manager has no overview about 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 short list of devices that it considers most secure. For example, a security manager can decide to 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 the freedom of employees too much.

COPE allows employees to only use a device that is 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

Screen lock

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

read, copy or delete personal information, usually your e-mails are synced to your device;
act as 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 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 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 each 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 to automatically delete 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 is 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 as 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 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 is 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.
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 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 device without the encryption key, i.e. the key is stored in 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 could be easily found. If the device is stolen, these services allow to remotely enable a screen lock with 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, tracking service is called Android Device Manager.

Android Device Manager showing a device on a map.

To enable it:

Go to Android Device Manager
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 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, tracking feature is called "Find My iPhone" and is supported since iOS 5.

Find my iPhone showing an iOS device.

To enable this service, go to: Settings -> Location Services (On) -> Find My iPhone (On) 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 Google Play store when installing an app and can be seen also on the device for apps that are already installed. Is it very important 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. 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 the 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 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 is it also infected with malware. Moreover, pirated apps usually do not have the community that reviews and rates the apps.

Problems with updating

Android is an 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 graph that shows the popularity of older Android versions (4.1-4.3 Jelly Bean, 4.4 KitKat, 5 Lollipop, 6 Marshmallow, ...):

Distribution of Android versions. Original caption: "Data collected during a 7-day period ending on May 7, 2019.

Any versions with less than 0.1% distribution are not shown." (image source).

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 with updating Android is given in "Android Security, Pitfalls, Lessons Learned and BYOD". This report also gives a good overview on 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 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 it.
Do not root your device unless it is really needed.

Additional materials

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.