As previously mentioned, typical confi gurations on today’s networks mask much of the traditional remote attack surface. Also, many client applications are very trusting of servers they communicate with. In response to these facts, attackers have largely shifted to targeting issues present in the attack surface presented by client software. Information security professionals call this the client-side attack surface.
Reaching these attack surfaces usually depends on potential victims initiating actions, such as visiting a website. However, some attack techniques can lift this restriction. On-path attackers are able to easily remove this restriction in most cases by injecting their attack into normal traffi c. One example is a watering hole attack, which targets the users of a previously compromised popular site.
Despite being tricky to reach, targeting the client-side attack surface allows attackers to set their crosshairs much more precisely. Attacks that use electronic mail vectors, for example, can be sent specifi cally to a target or group of targets.
Through source address examination or fi ngerprinting, on-path attackers can limit to whom they deliver their attack. This is a powerful property of attacking the client-side attack surface.
Android devices are primarily designed to consume and present data. Therefore, they expose very little direct remote attack surface. Instead, the vast majority of the attack surface is exposed through client applications. In fact, many client applications on Android initiate actions on the user’s behalf automatically. For instance, e-mail and social networking clients routinely poll servers to see if anything new is available. When new items are found, they are processed in order to notify the user that they are ready for viewing. This is yet another way that the client-side attack surface is exposed without the need for actual user interaction. The remainder of this section discusses the various attack surfaces exposed by client applications on Android in more detail.
Browser Attack Surface
The modern web browser represents the most rich client-side application in existence. It supports a plethora of web technologies as well as acts as a gateway to other technologies that an Android device supports. Supported World Wide Web technologies range from simple HTML to wildly complex and rich applica-tions built upon myriad APIs exposed via JavaScript. In addition to rendering and executing application logic, browsers often support a range of underlying protocols such as HTTP and FTP. All of these features are implemented by an absolutely tremendous amount of code behind the scenes. Each of these com-ponents, which are often embodied by third-party projects, represents an attack
surface in its own right. The rest of this section introduces the attack vectors and types of vulnerabilities to which browsers are susceptible and discusses the attack surface within the browser engines commonly available on Android devices.
Successful attacks against web browsers can be accomplished several ways.
The most common method involves persuading a user to visit a URL that is under the attacker’s control. This method is likely the most popular due to its versatility. An attacker can easily deliver a URL via e-mail, social media, instant messaging, or other means. Another way is by inserting attack code into compromised sites that intended victims will visit. This type of attack is called a “watering hole” or “drive-by” attack. Attackers in a privileged position, such as those that are on-path or logically adjacent, can inject attack content at will. These types of attacks are often called Man-in-the-Middle (MitM) attacks.
No matter which vector is used to target the browser, the underlying types of vulnerabilities are perhaps more important.
Securely processing content from multiple untrusted sources within a single application is challenging. Browsers attempt to segregate content on one site from accessing the content of another site by way of domains. This control mechanism has given rise to several entirely new types of vulnerabilities, such as cross-site scripting (XSS) and cross-site request forgery (CSRF or XSRF). Also, browsers process and render content from multiple different trust levels. This situation has given birth to cross-zone attacks as well. For example, a website should not be able to read arbitrary fi les from a victim’s computer system and return them to an attacker. However, zone elevation attacks discovered in the past have allowed just that. By no means is this a complete list of the types of vulnerabilities that affect browsers. An exhaustive discussion of such issues is far beyond the scope of this section. Several books, including “The Tangled Web” and “The Browser Hacker’s Handbook,” focus entirely on web browser attacks and are recommended reading for a more in-depth exploration.
Up until Android 4.1, devices shipped with only one browser: the Android Browser (based on WebKit). With the release of the 2012 Nexus 7 and the Nexus 4, Google started shipping Chrome for Android (based on Chromium) as the default browser. For a while, the Android browser was still available, too. In current versions of vanilla Android, Chrome is the only browser presented to the user. However, the traditional Android browser engine is still present and is used by apps discussed further in the “Web-Powered Apps” section later in this chapter. In Android 4.4, Google switched from using a pure-WebKit-supplied engine (libwebcore.so) to using an engine based on Chromium ( libwebview-chromium.so).
The primary difference between Chrome for Android and the two other engines is that the Chrome for Android receives updates via Google Play. The WebKit- and Chromium-based engines, which are exposed to apps via the
Android Framework, are baked into the fi rmware and cannot be updated with-out a fi rmware upgrade. This drawback leaves these two engines exposed to publicly disclosed vulnerabilities, sometimes for a lengthy period of time. This is the “half-day vulnerability” risk fi rst mentioned in Chapter 1.
Enumerating attack surfaces within a particular browser engine can be achieved in several ways. Each engine supports a slightly different set of features and thus exposes a slightly different attack surface. Because nearly all input is untrusted, almost every browser feature constitutes an attack surface. An excellent starting point is investigating the functionality specifi ed by standards documents. For example, the HTML and SVG specifi cations discuss a variety of features that deserve a closer look. Sites that track which features are implemented in each browser engine are priceless in this process. Also, the default browser engines on Android systems are open source. Diving down the browser attack surface rabbit hole by digging into the code is also possible.
Deeper attack surfaces lie beneath the various features supported by browsers.
Unfortunately, enumerating these second-tier attack surfaces is largely a manual process. To simplify matters, researchers tend to further classify attack surfaces based on certain traits. For example, some attack surfaces can be exercised when JavaScript is disabled whereas others cannot. Some functionality, such as Cascading Style Sheets (CSS), interact in complex ways with other technolo-gies. Another great example is Document Object Model (DOM) manipulation through JavaScript. Attacker supplied scripts can dynamically modify the structure of the web page during or after load time. All in all, the complexity that browsers bring leaves a lot of room for imagination when exploring the attack surfaces within.
The remainder of this book looks closer at fuzzing (Chapter 6), debugging (Chapter 7), and exploiting (Chapter 8 and Chapter 9) browsers on Android.
Web-Powered Mobile Apps
The vast majority of applications written for mobile devices are merely clients for web-based back-end technologies. In the old days, developers created their own protocols on top of TCP or UDP to communicate between their clients and servers. These days, with the proliferation of standardized protocols, libraries, and middleware, virtually everything uses web-based technologies like web services, XML RPC, and so on. Why write your own protocol when your mobile application can make use of the existing web services API that your web front end uses? Therefore, most of the mobile applications for popular web-based services (Zipcar, Yelp, Twitter, Dropbox, Hulu, Groupon, Kickstarter, and so on) use this type of design.
Mobile developers often trust that the other side of the system is well behaved.
That is, clients expect servers to behave and servers expect clients are not malicious.
Unfortunately, neither is necessarily the case. There are ways to increase the true level of trust between the client and the server, particularly to combat on-path or logically adjacent attackers. However, the server can never assume that the client is entirely trusted. Further, the client should never assume that the server it is talking to is a legitimate one. Instead, it should go to great lengths to authenticate that the server is indeed the correct one.
Most of this authentication takes place through the use of SSL or TLS.
Techniques like certifi cate pinning can even protect against rogue Certifi cate Authorities (CAs). Because it is entirely up to the mobile application develop-ers to properly utilize these technologies, many applications are insuffi ciently protected. For example, a group of researchers from two German universities released a paper in 2008 entitled “Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security.” The paper documented the researchers’
fi ndings on the state of SSL verifi cation in Android apps. Their research found that up to eight percent of all applications on the Google Play market that made use of SSL libraries did so in such a way that easily allowed MitM attacks due to inadequately validated SSL/TLS certifi cates.
Of course, the attack surface exposed by a web-powered mobile app varies from one application to the next. One particularly dangerous example is a common Twitter client. Twitter is a web-based social media platform, but many clients exist in the form of Android apps. These apps often use WebViews (a building block exposed by the Android Framework) to render the rich content that can be included in a tweet. For example, most Twitter clients render images inline automatically. This represents a signifi cant attack surface. A vulnerability in the underlying image-parsing library could potentially compromise a device.
Further, users on Twitter often share links to other interesting web content.
Curious users who follow the links could be susceptible to traditional browser attacks. Additionally, many Twitter clients subscribe to push messages (where the server provides new data as it appears) or regularly poll (ask) the server for new data. This design paradigm turns a client-side application into something that could be remotely attacked without any user interaction.
Ad Networks
Advertising networks are a prominent part of the Android app ecosystem because they are often used by developers of ad-supported free mobile apps.
In these apps, a developer includes additional code libraries and invokes them to display ads as they deem necessary. Behind the scenes, the app developer has an advertiser account and is credited based on various criteria, such as the number of ads displayed. This can be quite lucrative for apps that are extremely popular (for example, Angry Birds) so it is no surprise that app developers take this route.
Advertising networks represent an interesting and potentially dangerous piece of the puzzle for several reasons. The functionality that renders advertisements is usually based on an embedded browser engine (a WebView). As such, traditional browser attacks apply against these apps but typically only via the MitM vec-tors. Unlike traditional browsers, these WebViews often expose additional attack surfaces that allow remote compromise using Java-style refl ection attacks. Ad network frameworks are especially terrifying because legitimate advertisers could also potentially take control of devices using these weaknesses. Although these types of attacks are not covered further in this book, we recommend that you read up on them by doing an Internet search for the terms “WebView,”
“addJavascriptInterface,” and “Android Ad Networks.”
In addition to the risk of remote code execution, advertising frameworks also present a signifi cant risk to privacy. Many frameworks have been found to be collecting a plethora of personal information and reporting it back to the adver-tiser. This type of software is commonly referred to as adware and can become a terrible nuisance to the end user. For example, an advertising framework that collects the e-mail addresses of a user’s contacts could sell those to spammers who would then bombard those addresses with unsolicited junk e-mails. Although this is not as serious as fully compromising an Android device, it should not be taken lightly. Sometimes compromising a user’s location or contacts is all that is necessary to achieve an attacker’s goals.
Media and Document Processing
Android includes many extremely popular and well vetted open source librar-ies, many of which are used to process rich media content. Libraries like libpng and libjpeg are prolifi c and used by almost everything that renders PNG and JPEG images, respectively. Android is no exception. These libraries represent a signifi cant attack surface due to the amount of untrusted data processed by them. As discussed previously, in the “Web-Powered Mobile Apps” section, Twitter clients often render images automatically. In this situation, an attack against one of these components might lead to a remote compromise without user interaction. These libraries are well vetted, but that does not mean no issues remain. The past two years have seen the discovery of important issues in both of the aforementioned libraries.
Additionally, some OEM Android devices ship with document viewing and editing tools. For example, the Polaris Offi ce application shipped on the Samsung Galaxy S3 was leveraged to achieve remote code execution in the 2012 Mobile Pwn2Own competition. The attack vector used in the competition was Near Field Communication (NFC), which is discussed in the “NFC” section later in this chapter.
Electronic Mail
An electronic mail client is yet another client-side application that has an exposed attack surface. Like the other aforementioned client-side applications, electronic mail can be used as a vector to deliver browser attacks. In fact, Android e-mail clients are often based on a browser engine with a somewhat limited confi gura-tion. More specifi cally, e-mail clients do not support JavaScript or other scripted content. That said, modern e-mail clients render a subset of rich media, such as markup and images, inline. Also, e-mail messages can contain attachments, which have historically been a source of trouble on other platforms. Such attach-ments could, for example, be used to exploit applications like Polaris Offi ce. The code that implements these features is an interesting area for further research and seems to be relatively unexplored.