Before diving into the depths of Android’s attack surface, we must fi rst defi ne and clarify the terminology we use in this chapter. On a computer network, it is possible for users to initiate actions that can subvert the security of computer systems other than their own. These types of actions are called attacks; and thus the person perpetrating them is called an attacker. Usually the attacker aims to infl uence the confi dentiality, integrity, or accessibility (CIA) of the target system. Successful attacks often rely on specifi c vulnerabilities present in the target system. The two most common topics when discussing attacks are attack vectors and attack surfaces. Although attack vectors and attack surfaces are inti-mately related, and thus often confused with one another, they are individual components of any successful attack.
N O T E The Common Vulnerability Scoring System (CVSS) is a widely accepted stan-dard for classifying and ranking vulnerability intelligence. It combines several impor-tant concepts to arrive at a numeric score, which is then used to prioritize eff orts to investigate or remediate vulnerabilities.
Attack Vectors
An attack vector generally refers to the means by which an attacker makes his move. It describes the methods used to carry out an attack. Simply put, it describes how you reach any given vulnerable code. If you look deeper, attack vectors can be classifi ed based on several criteria, including authentication, accessibil-ity, and diffi culty. These criteria are often used to prioritize how to respond to publicly disclosed vulnerabilities or ongoing attacks. For example, sending electronic mail to a target is a very high-level attack vector. It’s an action that typically doesn’t require authentication, but successful exploitation may require the recipient to do something, such as read the message. Connecting to a listen-ing network service is another attack vector. In this case, authentication may or may not be required. It really depends on where in the network service the vulnerability lies.
N O T E MITRE’s Common Attack Pattern Enumeration and Classifi cation (CAPEC) project aims to enumerate and classify attacks into patterns. This project includes and extends on the concept of traditional attack vectors.
Attack vectors are often further classifi ed based on properties of common attacks. For example, sending electronic mail with an attachment is a more
specifi c attack vector than just sending electronic mail. To go further, you could specify the exact type of attachment. Another, more specifi c attack vector based on electronic mail is one where an attacker includes a clickable uniform resource locator (URL) inside the message. If the link is clickable, curiosity is likely to get the better of the recipient and they will click the link. This action might lead to a successful attack of the target’s computer. Another example is an image pro-cessing library. Such a library may have many functions that lead to execution of the vulnerable function. These can be considered vectors to the vulnerable function. Likewise, a subset of the application programming interface (API) exposed by the library may trigger execution of the vulnerable function. Any of these API functions may also be considered a vector. Finally, any program that leverages the vulnerable library could also be considered a vector. These classifi cations help defenders think about how attacks could be blocked and help attackers isolate where to fi nd interesting code to audit.
Attack Surfaces
An attack surface is generally understood as a target’s open fl anks—that is to say, the characteristics of a target that makes it vulnerable to attack. It is a physical world metaphor that’s widely adopted by information security professionals.
In the physical world, an attack surface is the area of an object that is exposed to attack and thus should be defended. Castle walls have moats. Tanks have strategically applied armor. Bulletproof vests protect some of the most vital organs. All of these are examples of defended attack surfaces in the physical world. Using the attack surface metaphor allows us to remove parts of informa-tion security from an abstract world to apply proven logical precepts.
More technically speaking, an attack surface refers to the code that an attacker can execute and therefore attack. In contrast to an attack vector, an attack surface does not depend on attackers’ actions or require a vulnerability to be present.
Simply put, it describes where in code vulnerabilities might be waiting to be discovered. In our previous example, an e-mail-based attack, the vulnerability might lie in the attack surface exposed by the mail server’s protocol parser, the mail user agent’s processing code, or even the code that renders the message on the recipient’s screen. In a browser-based attack, all the web-related technolo-gies supported by the browser constitute attack surfaces. Hypertext Transfer Protocol (HTTP), Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), and Scalable Vector Graphics (SVG) are examples of such technologies.
Remember, though, by defi nition, no vulnerabilities need be present for an attack surface to exist. If a particular piece of code can be exercised by an attacker, it is a considered an attack surface and should be studied accordingly.
Similar to attack vectors, attack surfaces can be discussed both in general and in increasingly specifi c terms. Exactly how specifi c one chooses to be usually
depends on context. If someone is discussing the attack surface of an Android device at a high level, they might point out the wireless attack surface. In con-trast, when discussing the attack surface of a particular program they might point out a specifi c function or API. Further still, in the context of local attacks, they might point out a specifi c fi le system entry on a device. Studying one particular attack surface often reveals additional attack surfaces, such as those exposed through multiplexed command processing. A good example is a func-tion that parses a particular type of packet inside a protocol implementafunc-tion that encompasses many different types of packets. Sending a packet of one type would reach one attack surface whereas sending a packet of another type would reach a different one.
As discussed later in the “Networking Concepts” section, Internet commu-nications are broken up into several logical layers. As data traverses from one layer to the next, it passes through many different attack surfaces. Figure 5-1 shows an example of this concept.
PHP Application Code PHP
Interpreter CGI
Web Server Web Server Ports
Figure 5-1: Attack surfaces involved in a PHP web app
In Figure 5-1, the outermost attack surface of the system in question consists of the two web server ports. If the attack vector is a normal request (not an encrypted one), the underlying attack surface of the web server software, as well as any server-side web applications, are reachable. Choosing to target a PHP web application, application code and the PHP interpreter both handle untrusted data. As untrusted data is passed along, more attack surfaces are exposed to it.
On a fi nal note, a given attack surface might be reachable by a number of attack vectors. For example, a vulnerability in an image processing library might be triggered via an e-mail, a web page, an instant messaging application, or other vectors. This is especially relevant when vulnerabilities are patched. If the fi x is only applied to one vector, the issue may still be exploited via remaining vectors.