Android devices, though powerful, rely on cloud-based services for much of their functionality. A large portion of the infrastructure behind these services is hosted by Google itself. The functionality provided by these services ranges from contact and e-mail data used by the phone dialer and Gmail to sophisti-cated remote management features. As such, these cloud services present an interesting attack surface, albeit not one that is usually reachable by a typical attacker. Many of these services are authenticated by Google’s Single Sign On (SSO) system. Such a system lends itself to abuse because credentials stolen from one application could be used to access another application. This section discusses several relevant back-end infrastructure components and how they can be used to remotely compromise an Android device.
Google Play
Google’s primary outlet for content, including Android applications, is Google Play. It allows users to purchase music, movies, TV shows, books, magazines, apps, and even Android-based devices themselves. Most content is download-able and is made availdownload-able immediately on a chosen device. In early 2011, Google opened a website to access Google Play. In late 2013, Google added a remote device management component called Android Device Manager. The privileged and trusted role that Google Play serves makes it an interesting infrastructure component to consider when thinking about attacking Android devices. In fact,
Google Play has been used in several attacks, which are covered more in the following sections.
Malicious Apps
Because much of the content within Google Play comes from untrusted sources, it represents another signifi cant remote attack surface. Perhaps the best example is an Android app. As is evident by now, Android apps contain code that executes directly on an Android device. Therefore, installing an application is equivalent to granting arbitrary code execution (albeit within Android’s user-level sandbox) to the app’s developer. Unfortunately, the sheer number of apps available for any given task overwhelms users and makes it very diffi cult for them to determine whether they should trust a particular developer. If a user incorrectly assesses trust, installing a malicious app could fully compromise her device. Beyond making incorrect trust decisions, attackers could also compromise a developer’s Google Play account and replace his application with malicious code. The mali-cious application would then be automatically installed on any device where the current, safe version of the app is already installed. This represents a powerful attack that could be devastating to the Android ecosystem if carried out.
Other content made available through Google Play might also be able to compromise a device, but it’s not entirely clear where this content originates.
Without knowing that, it’s impossible to determine if there is an attack surface worth investigating.
Apart from the Google Play web application itself, which is outside the scope of this chapter, the Google Play application on an Android device exposes an attack surface. This app must process and render untrusted data that is sup-plied by developers. For example, the description of the application is one such source of untrusted data. The underlying code beneath this attack surface is one interesting place to look for bugs.
Third-Party App Ecosystems
Google allows Android users to install applications outside of Google Play. In this way, Android is open to allowing independent third parties to distribute their applications from their company (or personal) websites. However, users must explicitly authorize application installs from third parties by using the workfl ow shown in Figure 5-3.
Figure 5-3: Authorize unknown apps workflow
The ability to install third-party applications on Android devices has natu-rally led to the creation of third-party application ecosystems, which come with their own set of dangers. Perhaps the biggest threat posed by third-party app markets is one that carries over from pirated or cracked software on PCs and Macs: Trojans. Malicious actors will decompile code for a popular trusted app and modify it to do something malicious before posting it to the third-party app market. A 2012 study by Arxan Technologies entitled “State of Security in the App Economy: ‘Mobile Apps Under Attack’” found that 100 percent (or all) of the applications listed on Google Play’s Top 100 Android Paid App list were hacked, modifi ed, and available for download on third-party distribution sites.
The report also provides some insights into the popularity (or pervasiveness) of these sites, mentioning downloads of more than 500,000 for some of the more popular paid Android apps.
In Android 4.2, Google introduced a feature called Verify Apps. This feature works through the use of fi ngerprinting and heuristics. It extracts heuristic data from applications and uses it to query a Google-run database that determines if the application is known malware or has potentially malicious attributes. In this way, Verify Apps simulates a simple signature-based blacklisting system similar to that of antivirus systems. Verify Apps can issue warnings to the user or block installation entirely based on the classifi cation of attributes from the application. Figure 5-4 shows this feature in action.
Figure 5-4: Verify Apps blocking and warning
In early 2013, the Android.Troj.mdk Trojan was found embedded in up to 7,000 cracked Android applications available on third-party application sites.
This included some popular games such as Temple Run and Fishing Joy. This Trojan infected up to 1 million Chinese Android devices, making them part of one of the biggest botnets known publicly at the time. This dwarfed the previ-ously discovered Rootstrap Android botnet that infected more than 100,000 Android devices in China. Obviously third-party app markets pose a clear and present danger to Android devices and should be avoided if possible. In fact, whenever possible, make sure that the Allow Installations from Unknown Sources setting is disabled.
Bouncer
In an attempt to deal with malicious applications in Google Play, the Android Security Team runs a system called Bouncer. This system runs the applications that developers upload inside a virtual environment to determine whether the app exhibits malicious behavior. For all intents and purposes, Bouncer is a dynamic runtime analysis tool. Bouncer is essentially an emulator based on
Quick Emulator (QEMU), much like the one included in the Android SDK, to run Android and execute the app in question. To properly simulate the environment of a real mobile device, Bouncer emulates the common runtime environment for an application, which means the app can access
■ Address books
■ Photo albums
■ SMS messages
■ Files
All of these are populated with dummy data unique to Bouncer’s emulated virtual machine disk image. Bouncer also emulates common peripherals found on mobile devices, such as a camera, accelerometer, GPS, and others. Furthermore, it allows the application to freely contact the Internet. Charlie Miller and Jon Oberheide used a “reverse shell” application that gave them terminal-level access to Google’s Bouncer infrastructure via HTTP requests. Miller and Oberheide also demonstrated a number of ways that Bouncer can be fi ngerprinted by a malicious application. These techniques ranged from identifying the unique dummy data found in Bouncer’s SMS messages, address books, and photo albums to detecting and uniquely fi ngerprinting the QEMU instance unique to the Bouncer virtual machines. These identifi cation techniques could then be used by a malicious attacker to avoid executing the malicious functionality of their application while Bouncer was watching. Later, the same application executing on a user’s phone could commence its malicious activities.
Nicholas Percoco published similar research in his Blackhat 2012 white paper
“Adventures in Bouncerland,” but instead of detecting Bouncer’s presence, his techniques involved developing an application with functionality that justi-fi ed permissions for the download and execution of malicious JavaScript. The application was a web-backed, user-confi gurable SMS blocking application.
With permissions to access the web and download JavaScript, the backend web server ostensibly became a command and control server that fed the application malicious code at runtime. Percoco’s research also demonstrated that relatively minor updates made to a new release of an app can go relatively unnoticed as having malicious content.
Even excluding these very interesting techniques for evading Bouncer, mali-cious applications still manage to surface on Google Play. There is a burgeoning malware and spyware world for default-confi gured Android devices. Because devices can be confi gured to allow installing apps from third parties, the major-ity of malicious applications are found there.
Google Phones Home
Behind the scenes, Android devices connect to Google’s infrastructure through
transport and connects a device to many of Google’s back-end services. For example, Google Play and Gmail use this service to access data in the cloud.
Google made Cloud to Device Messaging (C2DM), which uses GTalkService, available in Android 2.2. In June 2012, Google deprecated C2DM in favor of Google Cloud Messaging (GCM). GCM continues to use GTalkService for cloud communications. A more specifi c example involves installing applications from the Google Play website as shown in Figure 5-5.
Figure 5-5: Installing an application from the web
Apart from user-initiated installation, one of those most interesting proper-ties of GTalkService is that it allows Google to install and remove applications at its own will. In fact, it is possible to do so silently without notifying the end user. In the past, Google used this mechanism as an emergency mechanism to remove confi rmed malicious applications from the entire device pool at once.
Also, it has been used to push applications onto the device as well. In 2013, Google launched an initiative to provide APIs to older devices called Google Play Services. In doing so, Google installed a new application on all Android devices to provide this functionality.
Although GTalkService represents an interesting attack surface, vectors into it require trusted access. This functionality’s connection to the cloud is secured using certifi cate-pinned SSL. This limits attacks to those that come from within Google’s own back end. That said, leveraging Google’s back end to conduct attacks is not entirely impossible.
Unfortunately, diving deeper into the attack surface exposed by GTalkService requires signifi cant reverse-engineering effort. The components that implement
this part of Android devices are closed source and aren’t part of Android Open Source Project (AOSP). Inspecting them requires the use of disassem-blers, decompilers, and other specialized tools. A good starting point is to reverseengineer the Google Play application or the GTalkService itself.
Jon Oberheide demonstrated two separate attacks that utilized GTalkService to compromise devices. The fi rst, at SummerCon 2010, showed that it was pos-sible to access the authentication token used to maintain the persistent back-end connection via the com.accounts.AccountManager API. Malicious applications could use this to initiate application installs without prompting or reviewing application permissions. More information on this attack is available at https://
jon.oberheide.org/blog/2011/05/28/when-angry-birds-attack-android-edition/. The second attack, discussed in detail at https://jon.oberheide .org/blog/2011/03/07/how-i-almost-won-pwn2own-via-xss/, showed that an XSS vulnerability in the Google Play website allowed attackers to do the same.
This time, however, it was not necessary to install a malicious application. In both cases, Oberheide developed proof-of-concept codes to demonstrate the attacks.
Oberheide’s fi ndings are high-impact and fairly straightforward. Exploring this attack surface further is an interesting area for future work.