The technology supporting mobile devices moves pretty quickly. To keep you up to date with developments in the mobile security field, we have developed this interim update to accompany your SANS SEC575 course materials.

Joshua Wright [email protected]

@joswr1ght

1/31/2018 New in iOS 11

With iOS 11 we have several new security features and support for new hardware. Specifically, iOS 11 is the major software release to support the iPhone 8, 8+, and X (pronounced "ten"). iOS 11 supports several new features as well:

• Native Screen Recording: iOS 11 supports native screen recording functionality, accessible from a control center option, and as a programmatic API in the ReplayKit library (RPScreenRecorder.startCapture()). When a screen recording is active, iOS places a red banner at the top of the screen that the user can tap on to stop the recording. When the recording is finished, it is saved to the Camera Roll. This feature could be used to record visible screen contents outside of the standard application functionality, but would only be accessible to the malicious application if it also has the Camera Roll privilege.

• Offload Unused Apps: iOS 11 can also automatically remove applications that are not used from the device as a storage-saving measure. When the application is invoked again, the device downloads it on-demand from the iTunes app store. When an app is removed automatically, the data itself is retained on the device until the app is reinstalled and uninstalled manually.

• App Password Autofill: Mobile Safari has had iCloud synchronization for login credentials since iOS 9, but this password autofill functionality has been limited to Mobile Safari. With iOS 11, password autofill is also extended to any application that designed to use this functionality (as shown on this page for the Twitter application, having obtained the password from iCloud storage following a visit to Twitter with Mobile Safari). When the user chooses to populate a password with autofill, they must authenticate to the device using Touch ID or Face ID. App password autofill is not limited to iCloud synchronization; password managers such as OnePass or 1Password can also be extended to take advantage of this functionality as a credential provider instead of only getting password from iCloud storage. Face ID Bypass

With the loss of a home button on the iPhone X, Apple introduced Face ID as a new biometric authentication option. Face ID uses infrared light to illuminate a subject's face, comparing observed subdermal facial geometry with movement to stored biometric information. Apple indicates that Face ID is also motion aware, requiring the user or produce other facial movements that would not be available in a still subject (https://www.forbes.com/sites/quora/2017/09/13/how-does-apples-new-face-id-technology-work).

Shortly after the release of the iPhone X, several YouTube videos started gaining popularity where identical twins could unlock each other's iPhone X devices, as well as close relatives (a mother and son pair demonstrate an unlock event at https://www.youtube.com/watch?v=dUMH6DVYskc). However, the iPhone X Face ID feature "learns" with each subsequent unlock (to allow for changes in a face over time, such as growing a beard) so it is not clear if these unlock events are shortcomings in Face ID or intended functionality with trained devices.

In November 2017, Ngo Tuan Anh, Vice President of Bkav a computer security firm in Vietnam demonstrated to reporters that he was able to produce a mask capable of evading Face ID. Anh built the mask from paper tape, a silicon node, and paper eyes along with a framework designed on a 3D printer for $150. Anh indicated that the mask took a week to build such that it would bypass Face ID recognition and unlock a device (Image source: https://www.reuters.com/article/us-apple-vietnam-hack/vietnamese-researcher-shows-iphone-x-face-id- hack-idUSKBN1DE1TH). In practice, it is unlikely that Face ID bypass will be a practical attack technique for an adversary. Apple limits attempts to unlock an iPhone X with Face ID to 5; after 5 failed attempts, the device will require the user to enter the secondary authentication credential (a password or a PIN). While media reports indicate that Face ID bypass is possible, a targeted attack (where you intend to unlock a specific device) is unlikely to be successful with this 5 attempt limitation. Emergency SOS iOS 11 introduces a new feature called Emergency SOS where the user can disable biometric authentication and get a shortcut to place an emergency call (or immediately place an emergency call if configured to do so) by pressing the power button 5 times rapidly on the iPhone 7/7+ and earlier or by pressing and holding the side button while holding volume up or down on the iPhone 8, 8+, or X.

When the user activates emergency SOS, even if an emergency call is not placed, the iOS device will disable biometric authentication access, requiring the user to enter the secondary authentication credential to unlock the device. This could be seen as a tiny snub to US law enforcement agencies and courts that say that biometric data is not protected by the US Constitution 5th amendment (the 5th amendment of the US Constitution is part of the Bill of Rights that protects individuals from being compelled to be witnesses against themselves in criminal cases). Essentially, lower courts in the US have ruled that biometric information is not protected, and a suspect can be forced to unlock an iOS device using a fingerprint or face scan. An individual about to be apprehended could trigger the emergency SOS feature, preventing the device from unlocking using biometric information. Intelligent Tracking Prevention (ITP) iOS 11 also takes steps to defend against cookie tracking using Intelligent Tracking Prevention (ITP). To understand ITP, we have to first differentiate the concept of first-party and third-party cookies.

A first-party cookie is set when a user visits a website (either through a browser or app with a WebView) and the server returns a Set-Cookie response header. A third-party cookie is set when a user visits a website (browser or WebView), and the linked content generates additional requests to new websites (such as when you browse to cnn.com, and cnn.com links to an image on facebook.com). If the subsequent requests are returned with Set-Cookie headers, the cookies are known as third-party.

With ITP, iOS applies different policies to cookies whether they are first-party or third-party. A third-party cookie is disabled after 24 hours if it is intended for user tracking purposes (the nature of the intent is not clear in the Apple documentation). First-party cookies are purged if the website that issued the cookie has not been visited within 30 days.

Following this feature announcement from Apple, advertisers expressed discontent with the change, indicating that the change would hamper their ability to deliver a positive user experience that supplies desirable advertising to users (https://www.pmxagency.com/blog/2017/09/ios-11-intelligent-tracking-prevention-means- marketers). Many advertisers quickly responded to the change by refactoring how cookies are delivered. For example, Analytics' __gac cookie was formerly delivered by googleadservices.com (a third-party for most users), but has been changed such that it is delivered from the first-party site instead to "accurately understand attribution and campaign performance" (https://www.pmxagency.com/blog/2017/09/ios-11- intelligent-tracking-prevention-means-marketers/). iOS 11 Location Services Permission Change

Prior to iOS 11, an app could dictate how the location privilege prompt is displayed to users, limiting the choice for users to allow or deny access to location services (shown on the left of the image on this page). iOS has supported a third option for privilege services, "only while using the app", but that option was not always accessible depending on how the developer write the app.

With iOS 11, Apple will display the three location services options when the app attempts to access location services without the developer's ability to suppress the "while using" option. This change provides the user with more flexibility is how they grant location access to applications. App

Also new in iOS 11 is a native file management app. Though long eschewed by Apple, Android feature parity warranted the introduction of a file manager that replaces the former iCloud Drive app, allowing the user to manage files from native and third-party cloud storage providers, as well as limited local storage (primarily the photo reel and deleted items folders).

Third-party apps can leverage the Files app API set to read files from other cloud storage providers through the Files app. This creates the possibility for the app to read files belonging to another third-party app stored in Dropbox or any other cloud storage provider. Instead of using a permission restriction to indicate which apps can read what files, the iOS 11 platform requires that all access to files is user-gated (that is, the user must choose the files they wish to share after initiating a Browse action as shown on this page). Apps are not allows to silently access data stored in cloud providers accessible to the Files app. iOS 11 SSL/TLS Changes iOS 11 also introduces new SSL/TLS changes that will affect developers and hosting providers while improving network transport security for end-users. With iOS 11, TLSv1.2 is the default preferred crypto capability negotiated in all secure HTTP requests (when the URLSession, URL, URLRequest, and NSURLConnection libraries are used; other third-party libraries may not also enforce this same crypto requirement). Further, 3DES, SHA1 and RSA keys with a bit length less than 2048 are no longer accepted for TLS connections. iOS 11 also introduces preliminary support for TLSv1.3 while dropping SSLv3 support from the platform. This is partially in compliance with the upcoming requirements changes for the Payment Card Industry Data Security Standard 3.1 (PCI DSS), though iOS 11 continues to support TLSv1.0 which is not permitted in PCI DSS 3.1.

As with prior versions of iOS, HTTP connections are not allowed in third-party apps unless a domain exception is designated in the app Info.plist file.

The sample code on this page demonstrates a simple secure HTTP request using the Swift language for iOS. In this example, an iOS 11 device would negotiate a secure connection using TLSv1.2 by default, falling back to TLSv1.1 or TLSv1.0 if the server didn't support TLSv1.2. Certificate validation is on by default for all URL library connection requests, unless otherwise overridden (not shown here). iOS Backup Password Reset Now Possible

A potential reduction in security in iOS 11 is the ability for users to reset a password associated with a backup, allowing a user to generate new, password-less backups.

With iOS 8-10, the user has the option to select a backup password in iTunes. When the password is entered, it is stored on the iOS device and the data is encrypted prior to delivery to the host system for storage in iTunes. To restore the backup, the backup password must be entered to decrypt the contents. Further, removal of a password was only possible by entering the password and generating a new, unencrypted backup, or by performing a full device reset (losing all data on the device).

In iOS 11, this behavior has changed. Password are still an option to protect the confidentiality of iTunes backups, but unlike earlier versions of iOS, the requirement to use a password for a backup has been removed. With iOS 11, the user can navigate to Settings | General | Reset and tap Reset All Settings to remove the iTunes backup password requirement.

For end-users, this could be seen as a positive change, since prior to iOS 11 if the user forgets their iTunes password they can't restore backups or create new unencrypted backups (e.g. they can't turn off the password required to restore the backup). However, this also opens up a new opportunity for forensic analysis of an iOS device.

Consider a case where the user has an iOS 10 device with a backup password. If apprehended by law enforcement in the US, the officer could use TouchID or FaceID to unlock a device and access data from the device itself. However, a logical forensic acquisition (e.g. an iTunes backup) is not possible since the iOS device will not create new, unencrypted backups without the prior iTunes backup password (which the suspect could "forget", or otherwise not turn over to LEA). With iOS 11, this limitation for LEA is removed, and an apprehended iOS device could be unlocked and a logical forensic acquisition could be applied to recover all data after navigating to the Reset All Settings option. https://support.apple.com/en-us/HT205220

On your iOS device, go to Settings > General > Reset.

Tap Reset All Settings and enter your iOS passcode.

Follow the steps to reset your settings. This won’t affect your user data or passwords, but it will reset settings like display brightness, Home screen layout, and wallpaper. It also removes your encrypted backup password.

Connect your device to iTunes again and create a new encrypted backup.

This change reduces the effective security of iOS, allowing for logical acquisition of iOS data through iTunes when the device is unlocked. IOS Security Guide

Apple publishes the iOS Security guide at the URL shown on this page. This document highlights many of the strengths of the iOS platform, and should be considered mandatory reading for any information security professionals working with iOS devices. New in (Android 8, API 26, 27)

Next we'll look at what is new from a security perspective in Android Oreo (sometimes referred to Android 8 or Android 8.1, also using API 26 and API 27 development version indicators). We'll use the convention Android Oreo to denote these platforms, unless referring to something specific in a later version of the development API.

Android Oreo introduces new granularity in how applications enumerate and discover account usernames registered with other applications. Prior to Android Oreo, any app with the permission GET_ACCOUNTS is able to enumerate a list of account usernames registered with other applications on the system. With and later, this privilege is associated with the NORMAL permission group, and does not raise a permission request dialog when used. With Android Oreo, third-party apps can supply a policy that indicates whether or not the account information is revealed to other applications. The device user has no influence over this control, but apps can opt out of the account enumeration results.

Android Oreo also offers new Mobile Device Management (MDM) controls, including the ability to disable Bluetooth file transfer, the ability to deploy proxy settings for Wi-Fi networks, and the ability to grant or deny Android backup access. These controls have always been available locally to the Android user, but can also be controlled with MDM tools in Android Oreo.

One benefit Android offers users that iOS lacks is the ability to downgrade the version of the OS. If the user updates Android and is unhappy with the change they can revert the platform to the prior version (in most cases; this can be a complex operation beyond the means of some users). This feature has a negative side-effect though, in that an attacker could downgrade the version of Android to one that includes a vulnerability that could be used to bypass platform security. To address this shortcoming, Android Oreo includes a default-on feature called Rollback Prevention that stops OS downgrades. This effectively stops the downgrade attack to bypass security, but can also be disabled by an end-user, should they wish to downgrade the platform for their own use.

Another security-related feature in Android Oreo is the introduction of enhanced SECCOMP filters, which limit app access to privileged syscalls. The Android team evaluated the syscall access used by applications, eliminating access to dangerous syscalls that have been used previously to bypass platform security (such as the OS swapon an swapoff syscalls). More information on the permitted and denied syscalls is available on the Android developer blog site at https://android-developers.googleblog.com/2017/07/seccomp-filter-in-android- o.html. Protect

One of the advertised security benefits of Android Oreo is Google Play Protect. Google Play Protect is essentially a new marketing term used to describe several features that have long existed in one way or another in prior Android releases including Google Play Store scanning for malicious apps (formerly Google Bouncer), on-device app scanning (formerly Verify Apps), remote location/lock/wipe features (formerly Android Device Manager) and new intelligence for warning about malicious sites (formerly Chrome Safe Browsing).

Though these features have previously been available in , Google Play Protect is integrated into the base Android Oreo release. This has the added benefit of being available to other non- Google uses of Android (such as the Kindle) in the future, if adopted by OEMs. Google SafetyNet

Google SafetyNet is a new feature in Android Oreo that provides a set of services and developer APIs to evaluate the "fitness" of an Android device for different security-sensitive uses. For example, using SafetyNet, a bank could evaluate the security of the Android device to determine if it meets the requirements for secure operation prior to allowing a user to leverage the device for banking transactions.

SafetyNet comes in four forms:

SafetyNet Attestation API: verifies device integrity (boot loader, root access, etc.) Can also be used to identify the calling application that invoked the APK (e.g. if a third-party called your app, or if it was launched by the end-user directly).

SafetyNet Verify Apps API: identifies installation of potentially harmful apps. Can also determine if the user has disabled the Google Verify Apps feature.

SafetyNet reCAPTCHA API: prevent bots from using your app by using the reCAPTCHA service. If the API believes the app is being used by a bot instead of a human, a CAPTCHA is presented that must be solved before continued use.

SafetyNet Safe Browsing API: checks URLs for known threats. Will likely be implemented by systems where arbitrary URLs are entered by the end user or another outside source (such as advertiser syndicates).

Developers can choose to use various components of the SafetyNet API and change the applications behavior as a result. For example, a banking application may choose not to run if the Verify Apps API indicates that malware is installed on the platform. Further, developers can choose to hide their apps in Google Play based on device SafetyNet status as well (through the Attestation or Verify Apps APIs). More information on the Google SafetyNet feature is available on the Android developer website at https://developer.android.com/training/safetynet/.

Interesting analysis of the SafetyNet and the implication to people who root Android devices: https://android.gadgethacks.com/how-to/safetynet-explained-why-safetynet-shows-google-actually-cares-about- android-root-0177638. Oreo WebView Enhancements

Every app has built-in internet access on Android devices, and many apps will leverage some sort of WebView to load and display external content to the end-user. The WebView is essentially a small web browser that retrieves and renders HTML content using the open source WebKit library. Unfortunately, the WebKit library has suffered from several flaws that could be used as a remote exploit vector. Prior to Android Oreo, the WebKit rendering process in the WebView runs with the same permissions of the parent application in the same process space. If WebKit is successfully exploited, an attacker would gain access to all the data and process information (memory contents, file system data, etc.) as the associated application.

With Android Oreo, WebView objects are moved to a new process that is isolated from the parent application. This change significantly limits the exposure to the user in the event of a WebKit vulnerability, preventing WebKit exploits from accessing application data. Further, the WebKit object also has limited privileges, suppressing the ability to write to disk and operating in a sandbox that limits read data access. These restrictions further limit the exposure from WebKit vulnerabilities. SSL/TLS Changes

Android Oreo drops support for SSLv3, partially meeting the updated PCI DSS 3.1 requirements. Like iOS 11, Android Oreo continues to support TLSv1.0 which is not permitted in the PCI DSS.

In earlier versions of Android, the HttpsURLConnection library is vulnerable to a MITM attack technique where an attacker could force the client to use an older, less secure version of TLS through the manipulation of the TLS protocol negotiation and the TLS fallback protocol (https://android- developers.googleblog.com/2017/04/android-o-to-drop-insecure-tls-version.html). In Android Oreo, TLS fallback is disabled following a TLS handshake failure, preventing an attacker from forcing a downgrade of the TLS security. Note that this change is featured in the HttpsURLConnection library offered for TLS connection establishment, but is not available in other common TLS libraries used on the Android platform including OkHttpClient, Picasso, Volley, and the Apache HttpClient).

Android continues to allow applications to use unencrypted transport (HTTP) as desired (except for Instant Apps, which must use HTTPS, which we'll examine shortly). New Developer Requirements

When developers write an application, they designate the API version that they comply with, dictating the features available in the application such as modern dangerous or normal permissions). Developers can choose older versions of the APIs and still be compliant with newer platforms, albeit with limited, backward- compatible features.

Coinciding with the release of Android Oreo, Google is notifying developers that apps must comply with newer APIs or risk being pulled from the Google Play store. According to Google, this new rule will be applied in three phases:

1. In August 2018, new apps must use API 26 (Android 8.0) or later to be approved for publishing in the Google Play Store

2. In November 2018, existing apps must use API 26 or later to be approved for updates distributed from the Google Play Store

3. In 2019 and later, each year the target SDK requirement for new and updated apps will increase within one year following the Android desert release; apps must comply with the target SDK version for new releases or updates (https://android-developers.googleblog.com/2017/12/improving-app-security-and- performance.html)

These changes won't preclude support for older devices, since a developer can choose to support the latest SDK but also maintain backward compatibility in their app as well.

In addition to SDK version compliance, as of August 2019 developers must include 64-bit versions of native libraries as well (32-bit devices can still be supported if the developer chooses to distribute both 32-bit and 64- bit libraries). This is largely a performance benefit for users with newer devices, since many native libraries today only support 32-bit processors and do not take advantage of the full capabilities of modern processors. New Phone Privilege Feature

With Android Oreo, two new privilege definitions are added to limit accessibility to phone services:

ANSWER_PHONE_CALLS: with this privilege, apps can answer incoming phone calls programmatically using the TelecomManager acceptRingingCall() method.

READ_PHONE_NUMBERS: allow an app to retrieve your phone number

Functional equivalents of these privileges have been available in Android before the release of Android Oreo, but were bundled with the READ_PHONE_STATE privilege. With Android Oreo, these two privileges are independent of READ_PHONE_STATE and marked as protection level: dangerous, indicating that the system will raise a modal dialog when the application attempts to use these privileges for the first time, requiring the user to grant or deny access to the privilege.

Source code on this page adapted from https://github.com/wangjicong/Android-6.0- packages/blob/master/code/apps/InCallUI/src/com/android/incallui/WaitSliderRelativeLayout.java. Accessibility Features Abuse: Cloak & Dagger Attack

The Android Cloak & Dagger attack uses Android accessibility features to exploit how Android renders Activity (screen) views to capture authentication credentials or other sensitive information.

The Android accessibility features are intended for developers to make their applications accessible to people with a visual impairment. With the SYSTEM_ALERT_WINDOW and/or BIND_ACCESSIBILITY_SERVICE privileges, an application can overlay other application visual components on the system, potentially tricking a user into interacting with a malicious application while preserving the visual accuracy of the legitimate application.

For example, consider the Facebook login shown on the left on this page. Observing this login page after launching the Facebook application, the user would reasonably believe that Facebook is prompting them to enter their credentials and login to the system. However, a piece of malware with the BIND_ACCESSIBILITY_SERVICE privilege could manipulate the effect of the application, creating fake username and password input dialogs shown on the right of this page. Since the fake dialogs are generated by the malware, the attacker could collect the Facebook credentials and send the data to a remote server, then complete the Facebook authentication process such that the user is unaware of a disruption in normal application use. Cloak & Dagger Attack Variations

The Cloak & Dagger attack has additional variations as well. The Content-aware Clickjacking attack attempts to access local system functions that would warrant a system modal dialog prompt (such as accessing a dangerous permission, or changing a protected system setting). The malware can't answer the system prompt for the user, but it can draw a new screen over the modal dialog, providing a different prompt for the user to answer while revealing only the modal dialog button the attacker wants the user to choose (shown left on this page, where CANCEL and OK are choices for a system access privilege, but the Content-aware Clickjacking attack only shows the OK prompt with a different message).

Another variation on the Cloak & Dagger attack is the Invisible Grid attack. Applications behave normally, but the malware creates an invisible keyboard-shaped grid over the normal system keyboard (shown on the right on this page). This allows the attacker to intercept all keystrokes, and pass them through to the legitimate application. Oreo Accessibility Fixes

With Android Oreo, Google eliminated overlays in the Settings app. In order to use the accessibility service, an Android app must be explicitly granted accessibility privilege by navigating to Settings | Accessibility and selecting the desired app. Without overlay windows in Settings, malware cannot leverage clickjacking to trick the user into granting this privilege. However, if the attacker can trick the user into granting accessibility privilege manually (e.g. as part of a phishing attack or other social engineering effort), the remainder of the Clock & Dagger attacks are still accessible.

Accessibility features are widely used by applications for non-accessibility related enhancements. Several developers have reported that Google is contacting developers using the BIND_ACCESSIBILITY_SERVICE permission, requiring that they explain how their application is offering accessibility services to people to disabilities, or to remove the permission from their application, or to unpublish the app altogether (https://www.reddit.com/r/Android/comments/7c4go5/is_google_play_really_going_to_suspend_all_apps/). Per-app Third-Party App Installation Permission

Prior to Android Oreo, users could only install apps from the Google Play Store unless the Allow unknown sources option was turned on in the Settings app. This control was very course from a security perspective since turning on Allow unknown sources allowed not only third-party app stored, but also app installation from any URL or download, sideload through ADB or through a SD card, or installation from any installed third- party application.

With Android Oreo, the Allow unknown sources option has been removed. Instead, applications grant or deny the privilege to install third-party apps on a per-app basis when built with the REQUEST_INSTALL_PACKAGES permission. For example, Chrome on Android is built with the REQUEST_INSTALL_PACKAGES permission, and in Android Oreo if you download an APK with Chrome it will prompt you to change the Settings app to explicitly grant this app Install unknown apps privilege.

As more apps update for Android Oreo, it's likely that we will see this privilege extended to Dropbox, Google Drive, and more. This change does not degrade the security of the platform (since, like earlier versions of Android, the user has to configure settings to permit third-party app installation), but it does make it more granular, since app installation must be opt-in for developers (by including the REQUEST_INSTALL_PACKAGES permission in their app). Further, users can decide which apps can install apps, where earlier versions of Android third-party installation was a global configuration option. Android Instant Apps

With Android Oreo, Instant App features are moving to the base Android platform where they were previously available in the Google Play Services of Android Marshmallow and . With Instant Apps, developers build their apps as isolated features with a single base APK, distributed as modules over HTTPS. Instead of a website or other service requiring the user to navigate to the Google Play store to download their app, an Instant App is installed immediately after clicking on a link (without additional confirmation from the user), allowing for a more seamless experience from web browsing to interacting with a merchant or other service provider in a richer app experience.

Instant Apps aren't installed but are run on-demand from the browser cache. After launch, the Instant App delivers the base APK and the necessary features in a minimal download, allowing the user to quickly continue interacting with their device.

Instant Apps have several limitations that we'll examine shortly, but one key benefit of an Instant App is access to the Android Native Development Kit. Instant Apps can run code from arbitrary libraries distributed with the Instant App, subject to the permission limitations in the operating system. User Experience

Instant Apps are delivered with any standard hyperlink over a secure HTTPS transport. When browsing the Google Play Store, developers supporting the Instant App format can deliver the app as a TRY NOW link (shown on this page) or as a full app installation. The Instant App does not look any different than a standard Android app, except that it may have less functionality than the full app installation. Instant App Limitations

Unlike full app installs, Instant Apps have several important limitations:

• HTTPS Distribution: Instant Apps must be distributed over HTTPS and cannot be distributed over HTTP.

• API 23+ Runtime Permissions: Instant Apps must comply with API 23+ runtime permissions (using the normal or dangerous notation with modal dialogs prompting users to permit or deny on use)

• Limited Permissions: Instant Apps only have access to a limited number of permissions, listed on this page. The BILLING, VIBRATE, INTERNET, and ACCESS_NETWORK_STATE permissions are all considered normal (and do not require explicit user permission). The remaining permissions are in the dangerous group, requiring explicit user permission before the Instant App can access the privilege.

• Google Play Console Distribution: Instant Apps are limited to distribution through the Google Play Console, and cannot be distributed through third-party app stores. As part of the Google Play Console, the apps are subject to Google Play Protect scanning.

• Limited Download Size: Instant Apps are limited to 4MB in size for the initial load of the app. After the Instant App launches it can download unlimited additional data.

Additional information on policies for Instant Apps and frequently asked questions about the Instant App feature is available at https://developer.android.com/topic/instant-apps/policy.html and https://developer.android.com/topic/instant-apps/faqs.html. App Impersonation

Consider the screenshot shown on this page. Is this app Chrome, or is it an Instant App pretending to be Chrome?

For end-users, the transition from a browser to an Instant App is only obvious in that the Instant App looks visibly different than the browser, and a brief animation while the Instant App is downloaded. An attacker that wishes to exploit Instant App access could write an Instant App that looks just like Chrome. If the user clicks on a link that delivers the Instant App, it would launch immediately, replacing the Chrome interface with one developed by a third-party designed to capture browsing history and keystrokes. Android Fragmentation

We speak often about the fragmented state of Android, but it is useful to articulate why Android is fragmented as a platform. Consider the following factors:

• Multiple OEMs compete for device sales to make money on the Android platform. Handset sales is the only avenue (or primary avenue for most OEMs) to make money on products. As a result, continue device sales, not software maintenance on their existing device sales is their primary revenue target.

• Manufacturers are free to customize the Android source code, and take advantage of this feature to provide competitive differentiators with other handset manufacturers. This is often realized with custom Android skins that make the platform look different than their competitors, and custom hardware support (such as iris scanning for biometric authentication, or changeable hardware add-ons).

• Brick and mortar sales are widely distributed, with many stores selling older inventory at discounted rates (commonly, Android devices are "free with service plan", but are typically not the newest Android handsets available).

• The multi-chain update cycle is complex; issuing updates to customers is cumbersome for all parties where Google may make an update to the platform, and Samsung may subsequently integrate the update for their hardware platform, but the mobile operator may choose not to make the update available to end users.

From a security perspective, Android fragmentation reduces the effective value of the platform, often preventing customers from obtaining minor and major release updates that address security flaws. Further, the lack of update availability is a common complaint from users, unable to take advantage of much-reported emerging update features for 18-24 months after the release is made available. Project Treble

With the Android Oreo release, Google announced a significant rework of the platform that attempts to eliminate some of the barriers typically associated with update availability known as Project Treble. Project Treble aims to eliminate the complexity of software updates to Android devices by creating an abstract layer between the OEM hardware-specific drivers and supporting software, and the Android platform itself. By uncoupling the OEM hardware components from the Android OS, Google is attempting to remove the barrier that prevents users from obtaining and installing platform updates.

The images on this page show a comparison to the integration of vendor hardware implementation and the Android platform before and after Treble. On the left, the image shows how the vendor implementation is an integral component of the Android OS; updates to the Android OS require reworked vendor implementations before the update can be made available to end users. On the right, the vendor implementation is uncoupled from the OS framework, allowing the OS release (updates, new desert versions, incremental API changes) to be applied independent of the vendor implementation. (Image source: https://source.android.com/devices/architecture/treble.) Treble: Hardware Abstraction Layer

Fundamentally, Treble is the implementation of a Hardware Abstraction Layer (HAL) and HAL Interface Description Language (HIDL, pronounced "hid-ell") for Android. OEM developers write their hardware layer to support the hardware using the HIDL conventions specified by Google, and Google provides the HAL that acts as a pass-through for the hardware. The Android platform does not need to be modified for custom OEM hardware with Treble, since the HAL can accommodate custom hardware using the OEM drivers written to comply with Treble's conventions and requirements.

When a device supports Treble, the end-user is able to replace the OS with new updates without risk of breaking device functionality related to hardware. Google makes support for Treble mandatory for new devices coming out with Android Oreo (but not mandatory for devices updating to Android Oreo from earlier Android desert releases). At the time of this writing, the Sony Xperia XZ1, the Google 2, and the HTC U11 Plus are all new devices that support Treble through initial Android Oreo while several other devices have been updated to Android Oreo and added Treble support ( 1/1 XL, Huawei Mate 9 and others, and the Essential Phone PH-1).

To test if your handset has Treble support, first confirm that it runs Android Oreo. Next, using ADB access to the device in debug mode, open a shell and run getprop ro.treble.enabled, as shown on this page. If the command returns true, it indicates that the device supports Treble.

Quote on this page by Iliyan Malchev, Project Treble team lead, https://android- developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html. What Treble Does Not Solve

At the time of this writing, Android Oreo and Treble are relatively new. While new handsets are emerging with Android Oreo and Treble support, there are still some considerations regarding whether or not Treble will solve the Android fragmentation problem.

First, updates for handsets with Treble support for end-users still come from OEMs (Original Equipment Manufacturers, or handset manufacturers) and MOs (Mobile Operators, such as Verizon, AT&T, etc.), not from Google directly. An OEM or an MO can choose whether or not an update is distributed to end-users. Since OEMs are motivated to sell new handsets, it is unclear if they will be sufficiently motivated to make updates available to end-users, or how quickly updates will be made available with Treble.

It's reasonable to expect third-party Treble updates for handsets from non-OEM sources, similar to ROM distribution from companies in the model of Cyanogen (Cyanogen no longer makes ROMs available). This would provide end-users with a much simpler path to updating their handsets than the sometimes complex ROM replacement that is mostly accessible to advanced hobbyists today. However, this also provides customers with an easy mechanism to eliminate bloatware installed by OEMs and MOs, which is disadvantageous for the OEM and MO since the distribution of bloatware is profitable for them. It is not clear if Treble updates will also be accompanied by a signing mechanism, which would preclude the option for end- users to get Android platform updates from any source.

Through the use of Treble, the update path for Android handsets is easier than it was before, but it still requires effort on the part of the OEM or MO. For example, OEMs that extensively "skin" Android, or MOs that are paid to add third-party apps will require additional effort to integrate their changes to updated Android releases prior to distribution to end-users. Further, the easy availability of new desert releases through Treble could cost OEMs in terms of new handset sales (if Android P is available through Treble, customers may not be as motivated to purchase new handsets to get access to the new platform), reducing the motivation of OEMs to make updates available.

Treble is clearly a massive initiative by Google, and a welcome addition to the platform that reduces many of the barriers that preclude update available for end-users. Further, it is wise that Google makes Treble support mandatory for new Android Oreo devices, eliminating the option for OEMs to opt-out of the platform improvements. However, it is unknown if OEMs and MOs fully embrace Treble and make updates to the platform readily available to customers. Conclusion iOS 11 offers many new features which are advantageous to end users. Face ID support, the new Files app, Intelligent Tracking Prevention, and Emergency SOS are all welcome improvements to the platform. Continued improvements to SSL/TLS and consistency changes to location service permissions are also beneficial to end- users, mitigating potential misuse or abuse of the platform.

For Android users, Android Oreo is also a feature-rich update from a security perspective, with new Google Play Protect features, fixes to anuses of the accessibility features, SafetyNet opportunities for developers, WebView improvements, SSL/TLS fixes, and more granular Phone service privileges. The use of Instant Apps, while advantageous to developers and possibly useful for end-users represents a potential attack opportunity that has yet to be fully explored.

Project Treble is likely the most significant new feature in Android Oreo, eliminating many of the barriers typically associated with making updates available to end-users. Google made many smart decisions in the design, implementation, and policy requirements for OEMs in the adoption of Treble, though it is still unclear how effective the introduction of Treble will be based on if and how OEMs make updates available to end users.