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

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.

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.

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:

• How to formulate an effective smartphone security policy
• BYOD vs CYOD: Bring or choose your own device?

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.

---

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.

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 may 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.

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.

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.

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.

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.

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:

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.

To enable it:

1. Go to Google Find My Device
2. Accept that your device's location is sent to Google
3. 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).

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.

iOS 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.

---

Operating system level security

The major security features of Android devices and iOS devices are provided by the underlying operating system. For example, among other things, the operating system provides encryption, sandboxes the applications from each other, checks its integrity, manages system level cryptographic keys, enforces security policies for external interfaces. The ways how the security measures are implemented differ between iOS and Android. We won't go into the details in this course as the goal is to give an overview of the basics. However, we provide links with more detailed information for the students who are interested in reading the specifics.

Android

The underlying philosophy

Android is open-source. Android allows users to modify their software. For example, Android users can get apps from different app stores and even install them manually.

The official application store is Google Play store. However, an Android device may also come with other app stores. Compared to iOS App Store there are fewer restrictions in Google Play store, which makes it is easier for developers to distribute their apps. The details about app distribution are written in the Developer Distribution Agreement.

Android apps are digitally signed by the developers before the apps are uploaded to the Play Store. The application stores distribute applications that are digitally signed by the developers. Thus, in theory it is possible for end users to verify the signature to ensure that they received the correct application (although it is difficult to validate this in practice).

The downside of Android's open architecture is the ease to distribute malicious applications. As there is no central location for distributing applications it is difficult to ensure quality and security.

It is also possible to root Android devices (get administrative permissions). By rooting the device it is possible to modify the functionalities of the operating system, replace the operating system (e.g. install GrapheneOS), uninstall apps bundled by the device manufacturer or carrier, disable carrier lock. However, by rooting the device and getting administrative permissions, the security level is weakened as malicious applications can cause much more harm by using the elevated permissions.

Encryption in Android

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.... Device encryption is turned on by default starting from Android 7.

Android versions from 5 to 9 supported full-disk encryption where the whole device was encrypted with a single key (connected to user's password). While this is simple and provides good protection level, it also means that no device's functionality is available until user has provided the password. This affects, for example, receiving phone calls, alarms, etc. Starting from Android version 7, file-based encryption is supported that encrypts parts of device storage with different keys. So some of the phone's functionality is available even before entering user password. File-based encryption is enforced from Android version 10. Read about full-disk and file-based encryption from Android documentation.

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

When enabling encryption 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 PIN / password, so choose a strong PIN / 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. This is not relevant for newer devices that are already encrypted by default.
• There is no way to restore data if the encryption password is lost and there is no backup.
• If your device has a separate SD card, make sure it is also encrypted. Some devices require encrypting it separately.

Problems with updating

Android is open-source, 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.

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:

In 2015 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 had 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.

A good overview of the problems related to updating Android is given in "Android Security, Pitfalls, Lessons Learned and BYOD" (2013). 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.

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 (PIN-code is recommended).
• Use only official or well-known app stores, e.g., Google Play and 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.

iOS and iPadOS

iOS uses a closed ecosystem. Apple is the sole manufacturer of both iOS and the hardware on which iOS runs. In addition, Apple only allows iOS applications to be distributed via the official App Store, which is owned by Apple. There are quite strict requirements for getting applications to the App Store. Apple provides guidelines for developer to ease the process. Apps in the App Store are tested according to the requirements and for malware. Still, sometimes it is possible for a malicious app to bypass these tests: iOS malware can sneak through Apple's approval process, researchers show (2013). Such cases have been found also more recently.

iOS apps are digitally signed by the developers before the apps are uploaded to the App Store. However, the developers have to register themselves to get the signing certificate, which allows them to digitally sign the application. Thus, only the developers approved by Apple can upload applications to the App Store. Still, it is easy to register as a developer. Unlike Android, iOS App Store encrypts the application to enforce DRM. However, as encrypting the application modified the application and thereby invalidates the signature, Apple has to issue a new signature for the iOS apps before they are distributed via App Store. Similarly to Android, iOS apps are also sandboxed, i.e., isolated from other applications.

By applying strict rules and limiting what the user can do, Apple iOS provides more security to the end-user. It is not possible to install applications from unofficial application stores unless the device has been rooted/jailbroken. Apple does not provide means for the user to get administrative permissions. Rooting is not allowed to ensure that the users are protected by the security policy of iOS. To get administrative permissions the device has to be jailbroken, which means that someone has to find a vulnerability and distribute an exploit that allows to use administrative permissions.

Jailbreaking makes it possible to overcome some of the restrictions posed by the operating system. For example, on a jailbroken device, it is possible to access the file system of the device directly. On the other hand, jailbreaking also makes it easier to attack the device as the security model has been broken and malware can also use administrative permission.

The iOS source code is not available, which has made it more difficult for security researchers and cyber criminals to identify its inner workings. However, being closed source does not prevent vulnerabilities from being discovered. Given sufficient amount of resources, it is still possible to find vulnerabilities, but it takes more time as source code is not available. This has also been validated in practice, given the amount of vulnerabilities found from iOS during the recent years.

Encryption in iOS

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).

Security recommendations

• Enable screen lock
• Do not jailbreak your device.
• Do not install pirated apps as they may contain malware that is hard to detect.
• Be careful with uploading data to iCloud. In case of a legal dispute Apple can use a decryption key, which can be used to access part of the information that has been uploaded to iCloud.
• Consider turning on Locdown Mode if you want to significantly increase the security level of your iOS device.

iOS additional content

For the people who are more interested in the security of iOS devices, it might be interesting to read the security documentation created by Apple: Apple Platform Security.

---

Application level security

Android 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.

Attack vectors

Here are some attack vectors:

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

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.

iOS application permissions

iOS does not ask the user to grant an app the necessary permissions when it is installed. Their approach comes from the security model differences between Android and iOS. Android (before version 6, Marshmallow) leaves the decision making up to the user, while iOS apps are generally more thoroughly tested and are in turn granted permissions automatically. Nevertheless, each time an app wants to access some potentially private information for the first time, a user is prompted to grant the access. Such information includes access to device location, user's calendar, contacts, photos or social networking information.

• User cannot see the rights that an app has in the device

Apps can be browsed by a special program (App Store on-device or iTunes on a computer)

• Some apps can be browsed from the web: App Store.

Threats related to pirate copies of applications

If an iOS device is jailbroken, it is possible to install apps not only from App Store but also from elsewhere. However, like with pirated apps on Android, it is not recommended to install those. The main reason is that it is not known if an app is modified to work for free or if it is modified to add a malicious payload.

---

End-to-end encrypted communication

Even if traditional instant messenger software claims to be secure, it usually means that only the connection with the service's central server is encrypted (e.g. Skype, Google Hangouts). The service provider can still read and modify users' messages as they are waiting to be delivered. Fortunately, there are also some messaging and calling apps that use end-to-end encryption, e.g. the communication is secured between two end-devices.

Signal is probably the most popular end-to-end encrypted messaging and calling app for both iOS and Android devices. It is free and open-source. WhatsApp, Facebook Messenger, and Skype have also integrated (or are integrating) the Signal protocol into their apps to enable end-to-end encryption. However, in addition to Signal itself, end-to-end encryption is only enabled by default in WhatsApp. In contrast to the other aforementioned messaging applications, Signal is developed by a nonprofit organisation. Thus, there is no financial motivation to build trackers into the application.

It is also worth mentioning that the Apple iMessage protocol used by the Messages applications on both macOS and iOS also provides end-to-end encryption and is widely used as it comes built-in with Apple's devices. However, the protocol description is not published, and the user keys are managed by Apple central servers. More on the shortcomings of the protocol here: Attack of the Week: Apple iMessage.

---

Further reading

• Reports
  • F-Secure, Mobile Threat Report Q1 2014 (2014)
  • F-Secure Threat Report 2015 (2015)
  • Defending mobile devices for high level officials and decision-makers (2015)
  • Mobile Threat Intelligence Report Q1 2017 (2017)
  • F-Secure State of Cyber Security 2017
  • Data Security on Mobile Devices: Current State of the Art, Open Problems, and Proposed Solutions (2021)
• Malware for smart devices
  • A Survey of Mobile Malware in the Wild (2011)
  • Dissecting Android Malware: Characterization and Evolution (2012)
  • AndroidVulnerabilities.org (2015)
  • 234 Android Applications Are Currently Using Ultrasonic Beacons to Track Users (2017)
  • Report Finds Rate of iOS Malware Increasing Faster than Android Malware at iPhone Ten Year Anniversary (2017)
  • Yet Another Android Malware Infects Over 4.2 Million Google Play Store Users (2017)
  • So You Think You Can Secure Your Mobile Phone With a Fingerprint? (2017)
• Miscellaneous articles
  • Managing smart phone security risks (2010)
  • Permission Re-Delegation: Attacks and Defenses (2011)
  • The iPhone Has Passed a Key Security Threshold (2012)
  • Is Apple Picking a Fight With the U.S. Government? (2014)
  • The FBI spent $1.3M to crack the iPhone — this hacker spent just $100 (2016)
  • The bumpy road towards iPhone 5c NAND mirroring (2016)
  • MAC randomization: A massive failure that leaves iPhones, Android mobes open to tracking (2017)
  • Secret chips in replacement parts can completely hijack your phone’s security (2017)
• Android security model
  • "Android Security, Pitfalls, Lessons Learned and BYOD" (2013)
  • ABS: Android security underpinnings
  • Forum topic: Android permissions explained, security tips, and avoiding malware
  • Revisiting Android disk encryption (2014)
  • Security Metrics for the Android Ecosystem (2015)
  • The limitations of Android N Encryption (2016)
  • Here comes Treble: A modular base for Android (2017)
• Overview of secure messaging applications (among other things)
  • EFF surveillance self-defence