The Shape and Size of Threats: Defining Attack Surface

Transcription

1 The Shape and Size of Threats: Defining Attack Surface [Verisign Labs Technical Report # version 4] Eric Osterweil Verisign Danny McPherson Verisign Lixia Zhang UCLA Abstract Security and privacy have become very relevant concerns in our online lives. However as we have created complex and layered security services, it has become increasingly difficult to quantify their vulnerability to compromise. Security solutions must strive for both usability of the security system and understandability of their vulnerabilities. The concept of attack surface has emerged in recent years as a measure of such vulnerabilities, however systematically quantifying the attack surfaces of networked systems with high degrees of interdependencies remains an open challenge (especially in an expressive way). In this work we propose a methodology to both quantify the attack surface and visually represent semantically different components (or resources) of such systems by identifying their systemic dependencies. To illustrate the efficacy of our methodology, we use two real Internet standards (the X.509 CA verification system and DANE) as case studies. We find that, with conscientious design, one can minimize attack surface vulnerabilities without sacrificing availability and usability. Our methodology suggests that, by leveraging the already existing DNS/DNSSEC system, DANE can quantifiably reduce attack surface by orders of magnitude for some popular websites today, when compared to X.509 CA verification. We believe this work represents the first step towards systemically modeling dependencies of actual Internet networked systems, and illustrates the usability benefits from leveraging existing services. I. INTRODUCTION As we have enhanced our online services with increasing numbers of features, many of them have become correspondingly dependent on more and more underlying systems. In the case of cryptographic protections, even just cryptographic key management can make systems far more complex than they were before. Moreover, failure modes often result in non-intuitive user interactions (such as pop-up boxes in web browsers when HTTPS encounters errors). By trying to make the user s life easy, protocols like HTTPS have inadvertently conflated some goals, and this has enabled some types of attacks that the user cannot even detect (let alone remediate) [35]. While these protections are added in the spirit of trying to enhance the system s security, we believe that streamlining the cryptographic protections by utilizing existing services can make them more available by end users, operationally usable by administrators, as well as less vulnerable to some forms of compromise. Moreover, we feel that quantifying and visualizing the presence of and relationships between systematically dependent resources is key in understanding and enhancing the designs and usability of networked systems. One aspect of assessing the usability of a security system involves analyzing both the vulnerabilities that it protects against, and the vulnerabilities it has itself. In order to fully understand the vulnerability of the networked systems we depend on, it is also important to understand the vulnerabilities of those systems on which they depend. However, it is generally held that fully enumerating all possible ways in which an attack could be launched against a given system is difficult, if even possible. As a result, a concept dubbed attack surface has emerged in recent years as a notion to describe the potential vulnerability that may be introduced to a system by its nested dependencies on other subsystems. This term is generally used to mean the set of resources that a system relies upon, which could feasibly be used to launch an attack against it. Thus, systems with larger attack surfaces are judged as potentially more vulnerable. Yet, the heterogeneity of networked systems, their complex dependencies, the dynamism of their interactions, and more have proven both difficult to quantify and difficult to illustrate (in a methodical way). As a result, security professionals often evaluate a system s attack surface in a somewhat informal fashion, and there has been no report on quantitative measurements of attack surface for any existing networked systems. In this work, we present four contributions: i) we believe we are the first to suggest a candidate generalized quantitative definition of attack surface for networked systems, ii) we use this to codify a repeatable methodology for quantifying attack surfaces for networked systems, iii) we present a visualization technique (called resource graphs) to make attack surface analysis more intuitive and usable to system designers and users, and iv) we show that leveraging existing services can avoid introducing new attack surface while maintaining usability. Our candidate definition of attack surface refers to the the specific set of resources that a networked system uses, such that if any of them were to act incorrectly (by being compromised, subverted, replaced, etc.), the networked system (as a whole) would not be able to discern a problem and could therefore malfunction. That is, if a component of the networked system is queried for an answer, but that answer (such as a DNS Resource Record, RR) cannot be verified,

2 then that server (or possibly an element along a network path) can undetectably lie. Alternately, if an answer can be verified by a cryptographic signature that is verifiable by an X.509 certificate (for example), then if that certificate s private key were to be subverted, any false attestations it made would not be detectable by the networked system s protocol. This makes the certificate key-pair part of the attack surface, but since there is a signature covering that RR, the protocol is ensuring that it cannot be tampered with, so it is not part of the attack surface anymore. Using this approach, we propose a novel methodology that offers a systematic way to measure and quantify the attack surface of network systems by codifying their systemic dependencies, using a construct that we call a Functional Process Digraph (FPD). We use FPDs to systematically identify the resources used by networked systems and quantify the resultant attack surfaces through enumerating the number of, and dependencies between, these resources. To illustrate the efficacy of this approach, we quantified the attack surface of one of the core security substrates used by online services today, Transport Layer Security (TLS) [9] (the successor to the Secure Sockets Layer, SSL). Specifically, we compare the attack surfaces of two competing standards-based verification approaches employed by TLS, X.509 Certification Authority (CA) verification and the DNSbased Authentication of Named Entities (DANE) [1] (a newly standardized alternative solution). By measuring the attack surfaces exposed by operational websites using the current CA model, we were able to compare the attack surfaces of CA verification to DANE. Among our findings, we show that one of the fundamental protocol semantics of DNSSEC (its use of object-level security) can quantifiably reduce the attack surface of reliant systems by up to two orders of magnitude, and that using DANE can reduce the attack surface of systems by leveraging existing DNS service. In addition, our methodology exposes a fundamental orthogonality between attack surface and availability, which we discuss further in Section VI. The remainder of this paper is structured as follows: Section II describes some details of CA verification and DANE verification and illustrates some rationale behind using their attack surfaces for comparison. Then, Section III details our candidate methodology for quantifying the attack surface of these verification methods. Next, we present our measurements in Section IV. Following that, we examine related work in Section V, before wrapping up with a discussion in Section VI and concluding remarks in Section VII. II. CA VS. DANE VERIFICATION In this section, we distinguish between two ways to compare CA verification with DANE: the verification services they each offer, and the systemic dependencies they inherit from the way they offer their services. A. CA Verification The goal of the CA verification system (specified in [7]) is twofold: it both verifies the authenticity of the binding between a certificate and a domain name, and it allows the CA organization to vouch for the trustworthiness of the entity that is managing the domain name in question (and by extension, the certificate too). That is, when a Relying Party (i.e. an entity that is trying to validate the authenticity of a remote service), such as a web browser, wants to make a secure HTTPS connection to a web site, it wants to be sure it has received the right certificate, and (in some cases) that the certificate holder (the domain name authority) is trustworthy. 1 This simple operation implies that Relying Party (RP) software must be able to verify certificates from the multitudes of web sites it may visit, without knowing them ahead of time. Moreover, those web sites may change their certificates periodically, and RP software must be able to avoid using an outdated certificate, and must be able to learn and verify new ones for sites it may have visited in the past. One approach that Public Key Infrastructures (PKIs) have long relied on, is the notion that a globally trusted root authority can be used to vouch for certificates. That is, if everyone in the world agreed to trust a root organization, then we could all rely on that organization to vouch for (say) web site certificates. However, security systems that have their protections predicated on finding a single root of trust in the Internet have often encountered usability problems. Today s RP software uses a set of trusted root certificates that are issued by Certification Authorities (CAs). RP software vendors determine which CA organizations they should trust, and then pre-install certificates from these CAs in their software. Typically, whenever this set needs to be refreshed or changed the vendor updates the list out of band, via code updates. In order for RPs to verify website certificates, they must see that a CA has vouched for them. When an RP receives a certificate, it checks to see if that certificate has a chain of signatures that leads to a CA and if the CA that generated the root signature is trusted. Then it performs various sanity checks on the certificate (has it expired, is it formatted properly, etc.), and then it must also see if the certificate itself has been revoked (which adds a significant amount of added complexity). Certificates can include URL pointers to where their revocation statuses can be checked. their statuses. So, when certificate owners want to revoke their certificates, they put them in Certificate Revocation Lists (CRLs), or advertise the revocation on Online Certificate Status Protocol (OCSP) servers. For this reason, RP software has to check CRLs (by downloading them), or OCSP servers (over the network) whenever they are specified in a downloaded certificate. The usefulness of these services is clear, but the way they are offered is important too. The CA verification model involves numerous systemic dependencies on other systems, and it is important to consider whether this leaves the model open to attacks and subversion. The current CA verification model involves: i) a recursive set of DNS lookups (to find a web server s IP(s)), ii) a web server connection (to get a certificate), iii) consultation of/verification with root CA list (maintained out of band, and is of variable size ), iv) external check to see 1 Trustworthiness is clearly a subjective notion. c 2014 Verisign, Inc. All rights reserved. 2 Verisign Labs Technical Report # version 4

3 if certificates have been revoked (via CRLs or OCSP checks), and then v) the TLS session generates session keys and begins communication. While this model has been deployed and running for many years, it is vulnerable to an attack dubbed, attack on one, defeats all [23]. This vulnerability exists because any CA can issue a certificate for any domain name, and is thereby able to assert verification for any domain name. As a result, suppose a web site www has a certificate from CA A (let s call the cert C A ), and serves it from their web servers. If an adversary has compromised a different CA Comp, and uses it to issue a forged certificate that purports to belong to www (let s call that certificate C Comp ), then the adversary can launch a Man-in-the-Middle attack against a browser and supply the C Comp instead of C A. If Comp is one of the 160 CAs in that browser s CA list, then the RP has no reason to suspect that it is not authentic for www (even though it is forged). This is because there is no way for the site to tell RPs what to expect. In fact, this was the very attack used when DigiNotar was compromised and used to attack Google [35], and several other instances of this attack are well known too [4], [17], [35], [31], [22]. These, and other, problems have led some to seek alternative verification methods. B. DANE As an alternative to the CA model, a new approach has been standardized in an IETF working group, called the DNS-based Authentication of Named Entities (DANE) [1]. Using DNSSEC as a verification substrate, DANE allows domain owners to control and manage their own verification, and implicitly cuts out a measurable portion of the systemic dependencies inherited by the CA verification model (Section III). In addition, DANE s streamlined design makes some cryptographic operations more usable by allowing resource holders (such as those administrators the manage domain names) to manage the life cycle and operations of their own cryptographic keys and other aspects of security, and it makes it more transparent to Relying Parties. The core intuition behind DANE follows from two simple observations: i) DNSSEC is now an operationally viable protocol, with a growing deployment base [27], and ii) any HTTPS transaction that uses a DNS domain name (as opposed to a hard coded IP address) already begins with a DNS look up. DANE capitalizes on both to perform the necessary verification. Since an RP will be querying a zone owner for the IP addresses of their web server(s), and that transaction can be cryptographically secured by DNSSEC, then the zone owner can also use DNS to convey details about the web server s certificate. DANE specifies a new type of DNS resource record, called the TLSA record. This record contains a hashed fingerprint of the certificate that RPs should expect to see when they contact the web server. Previously, RPs had no way to determine which CA a web site had actually obtained their certificate from [35]. DANE inherently eliminates this vulnerability by explicitly stapling a domain name to a certificate. RPs can then verify what certificate they should see when they contact a corresponding web server, and DNSSEC implicitly makes this data self-verifying. That is, DNSSEC RRsets include the necessary cryptographic signatures to allow RPs to verify the authenticity of the stapling. In DANE, deauthorization of a certificate is implicitly handled by simply removing the TLSA record from a zone. After that, the certificate will only be authorized for as long as it exists in DNS caches (until its TTL expires). Consequently, in DANE, the complicated systemic dependencies needed for revocation are obviated. Consider the following illustrative example, when an RP wants to connect to it queries for both the address records for that domain name (A and/or AAAA records), and for the TLSA record type at 443. tcp.www. example.com (and uses DNSSEC to verify all returned values). If it gets back a TLSA record for that name, then it knows that there is an HTTPS server running there (so sslstrip attacks will not work), it knows exactly what certificate to expect from that web server (the web server s certificate must match that TLSA fingerprint), and if that certificate comes from a CA, only that CA will be able to attest to the certificate (stapling). After that, no other verification or revocation needs to be done, and the RP can query the web server at the IP addresses it found. While DANE s model does allow domain owners to unambiguously publish the information about their certificates directly to RPs, it does not directly address trust in data owners key management (like the CA method does). Rather, trust is left separate, so domain owners can (for example) staple themselves to a specific CA to trust. Stapling means that a TLSA record points to a certificate that does have an attestation from a specific CA that RPs (hopefully) know and trust. Thus, the RPs will be able to reject the attacks that resulted from [4], [17], [35], [31], [22]. Ultimately, DANE keeps its systemic dependencies in just DNS. III. AN ATTACK SURFACE METHODOLOGY The attack surface phrase has appeared in many different security focused communities [16], [33], [18]. We will discuss these (and other) related works in greater detail in Section V, but the literature lacks a clear and concise definition of what an attack surface actually is, a general way to derive one for networked systems like CA verification or DANE, and an intuitive mechanism to represent the memberships of (and relations between) heterogeneous types of elements in an attack surface. One of the challenges is that it is not always clear how to decompose a method like TLS verification into a quantifiable attack surface. We interpret attack surface as quantifying how many active elements might be used in some way by potential attack vectors and adversaries. In this Section, we propose i) the definition of attack surface, which directly leads to ii) a measurement methodology that gives quantitative results. This allows us to concisely quantify the attack surface of CA verification and DANE. While our methodology is unambiguous about which elements contribute to the attack surface, we submit this as just one candidate c 2014 Verisign, Inc. All rights reserved. 3 Verisign Labs Technical Report # version 4

4 way to systematically define the attack surface for these specific systems, others may choose to define attack surfaces differently. Our definition of an attack surface of a networked system is cast through the actual usage model of that system. In other words, in order to quantify a networked system s attack surface, we model the way that the networked system actually operates. We begin by modeling a networked system as a set of protocols, systems, procedures, etc. We collectively call these a logical set of processes P. Each process p i P is composed of both a set of functional logic (the things it does, the decisions of which data it uses and trusts, etc.), and the set of resource elements that it uses (the actual data it uses, the network elements it needs to contact, etc.). We codify each of these processes as a two-tuple of these sets: p i = {W i, R i }, where we define W i as a workflow graph that describes how a process acquires and determines the trustworthiness of data (or network resources, etc.), and where we define R i as a resource graph of the elements identified by W i. Ultimately, our goal is to use the set of all R i graphs by all processes in P as our attack surface. To this end, we break our methodology down into three general phases. We first identify what processes are involved in P. To do this, we create a Functional Processes Digraph (FPD), and denote it G F P D = (P, E). This FPD identifies the set and functional interactions (adjacencies) between all the processes involved. Next, we determine the internal workflow W i for each p i P. These workflows are critical because, in the final phase, they help us identify the resource elements in each process R i graph. A. Processes in the FPD Knowing the set of processes P that are involved in verification, and how they interact with each other is a critical first step in our methodology, as it shapes our attack surface. Formally, in the process digraph G F P D = (P, E), we represent each separate protocol and system as a separate process p i P, and for each process p i that leads to an invocation of process p j (where {p i, p j } P ), we add a directed edge e (i,j) E. One of the challenges in doing a quantitative analysis of a networked system like CA verification or DANE is knowing how deeply to recurse into systems that depend on other systems that depend on other protocols, etc. For simplicity (but without loss of generality), in this paper we focus our analysis on just those processes that are visible to, directly involved in, invoked by, and involved in protocol actions and directly specified at the same logical layer(s) of those actions. That is, rather than recursively including processes that represent resource element all the way down to the physical layer, we represent just a single level of abstraction (like a network path instead of a sequence of transport, network, media, and physical layer elements). In addition, because our attack surface is modeled from the actual usage of a networked system, we avoid modeling external processes that are responsible for shaping and influencing the process that we do model. To illustrate this, consider the simple case of a web browser that connects to a web server. Initially, the browser sends a DNS request (so DNS is a visible process), and this leads to an HTTP connection to a web server (which is now, also, a visible process). So, we do include each of these and make each of them their own process node and connect our DNS process to our web server process, with an edge. By contrast, we do not include a routing process that computed which network paths our packets would take, because that process is orthogonal to the operation of the networked system being modeled. Routing is clearly needed to facilitate connections for both DNS and HTTP, and the actual network paths taken are relevant, but we make the simplifying assumption that components that run out of view of our verification process (while clearly candidate attack elements that could influence our attack surface), are better described in another system s view of its attack surface. For example, a routing security framework would likely enumerate this protocol s elements in its attack surface. Similarly, we do not consider the various vulnerabilities of certain cryptographic suites (like, whether Camellia is more vulnerable than RSA). B. Workflow Graphs The workflow graphs (W i ) that we generate for each process p i P are intended to be tools to identify how processes determine their data and trust needs. In these workflows, we try to focus on the inner workings of the processes that are directly relevant to our networked system s attack surface. As a result, our workflow diagrams become narrowly focused representations of their overall processes. Consider (again) our example above, where the DNS process connects to our web server process. In each of these we define the steps each process takes in acquiring and trusting data (as internal workflow diagrams). Since the DNS process connects to the web server process, the last node/stage in the DNS lookup workflow connects to the start node/state of the web server workflow. Now consider what happens when the browser is making an HTTPS connection (to run TLS). In this case, when a web server returns its X.509 certificate, that web workflow s final node/stage leads to an X.509 workflow. Using the FPD, we can now logically model the connectivity and process dependencies between systems whose semantics exist in completely different layers of the logical OSI stack, based solely on dependencies (DNS to HTTP to x.509). 1) CA Functional Process Digraph: Since the CA verification model for TLS is different than the DANE model, we create separate process graphs for each of them, and Figure 1 illustrates CA verification (G CA ). First, web clients go to DNS to look for a domain name-to-ip mapping for a web site. Then they initiate a TCP connection to the returned web server, which returns an X.509 certificate. The client then validates the certificate by checking that the certificate s reported CA is in the client s internal list of trusted CAs, and that each link in the cryptographic chain from that CA is verifiable. Then, the client examines the certificate to see if it specifies any revocation mechanisms, like CRLs, or OCSP servers. If these exist, it queries them to see if this certificate is still valid. c 2014 Verisign, Inc. All rights reserved. 4 Verisign Labs Technical Report # version 4

5 No Use podns WWW / TCP CAs Start DNSSEC Connect to web server on port 443 Download cert Check ANY CA verifies cert DNS Resolution Yes Use DNSSEC object security Web Server Cert Yes Site has DNSSEC Yes Use DNSSEC object security OCSP/CRL Server(s) EE cert has revocation info No Contact Server(s) for revocation info Establish session key(s) OCSP/CRL DNS Footprint No Use podns Fig. 1. This Figure shows the FPD for CA verification. DNS Web connection web cert CA list Check revocation TLS. Start WWW / TCP DNS Resolution Use DNSSEC object security Connect to web server on port 443 TLS Download cert Establish session key(s) TLS Stop Web Server Cert Fig. 2. This Figure shows the FPD for DANE verification. : DNSSEC Web connection web cert TLS Finally, if all of the above works, the client will setup a TLS session key with the server. 2) DANE Function Process Digraph: Figure 2 illustrates the DANE verification process (G DANE ). This verification FPD is actually a logical subset of the CA verification FPD (G CA, in Figure 1). There is, however, one notable difference: in the DNS process: DNSSEC is mandatory in G DANE, but optional in G CA. We will see in the next Section how this impacts the attack surface. Note that the simple addition of DANE s TLSA record overloads the DNS dependency, and removes a relying party s need for all of the processes that come between fetching a web server s certificate and the TLS setup. C. Creating Resource Element Graphs The verification workflows defined in our FPDs provide the direction needed to identify the resource element graphs (R), which collectively define our actual attack surface. For example, we can see that the DNS and a web server s X.509 Stop certificate are needed by both CA and DANE verification. However (as we noted earlier), these systems and protocols are not all specified in the same logical way. DNS is concerned with name mappings, network-layer server IP addresses, connecting to name servers, and more. By contrast, X.509 is a cryptographic certificate format, and even the semantics of its protections are described in a fundamentally different way than a network protocol like DNS; it specifies a notion of object-level security that is session agnostic. While our FPDs illustrate logical adjacency, it is still important to note that the resource element graphs R for each element may contain different types of elements. In order to quantify the attack surface that spans these conceptually different resource types, we represent the set of R i graphs in a way that focuses on the type and number of security elements each process uses. We do this by creating a model where different types of resources exist as elements in different tiers of our resource graph. In other words, we create a set of tiers in our graph where each tier models a separate (but somewhat general) type of element in the spectrum of security. We seed our model with three general tiers: i) object-level security, ii) session-level security, and iii) Network-Delivery Assurances. 2 While we conceptualize each tier as distinct from the others, we use dependencies from our FPDs to dictate procedural adjacencies between nodes in any tier. For example, an FPD may specify that after a DNS process runs, an X.509 process runs. The result would be that a DNS node in our tiered resource graph would have an adjacency to an X.509 node, even though they are in logically different tiers (Network- Delivery Assurances and Object-Level Security, respectively). Since we are ultimately planning to evaluate our overall attack surface, the relative sizes of these R graphs in P is important. Just as the FPDs were used to create workflow graphs W, we use our set of W graphs to quantify the resource elements and any relationships between them as the R graph for each process p i P. For example, an element that uses one or more X.509 certificates (such as the CA process node) would correspond to a single process node in the objectlevel security tier, but that node would encapsulate the set of X.509 elements that are used by the logical process. We would represent the internal structure of the CA node (in the objectlevel security tier) as a tree (or set of trees) of certificates. Every X.509 certificate that is involved in the CA hierarchy s Object-Level Security process (p CA = {W CA, R CA }) will be represented as a separate resource element in R CA, and linked to any other certificates in R CA that it has relationships to. 1) Modeling the CA Tiers: We begin by decomposing the process/dependencies from Figure 1 into Figure 3. The rationale for the placement of each process in its specific tier, and the process for decomposing each workflow process into its specific functional elements is as follows: 2 While this may be neither an optimal set, nor a complete set of the tiers that others may use, we choose these as general examples of types of security in which many different protocols and systems can be aggregated. c 2014 Verisign, Inc. All rights reserved. 5 Verisign Labs Technical Report # version 4

6 Object-Level Security Web Cert CAs DNSSEC Resolution SLD TLD root Object-Level Security Web Cert Session-Level Security TLS Session-Level Security TLS Network-Delivery Assurances OCSP/CRL Server(s) Network-Delivery Assurances DNS Resolution WWW/ TCP OCSP/ CRL DNS Footprint WWW/ TCP Fig. 3. This Figure depicts our proposed three tiers of network resource graphs for the CA verification s attack surface. Modeling DNS: In order to quantify the elements involved in the DNS process p DNS, we leverage the prior work [26], [29]. These works describe the notion of Transitive Trust in the DNS, and illustrate that simple DNS lookups often involve recursive (not strictly hierarchical) dependencies. The basic idea is that any zone depends on its hierarchical parents, but if it is served by name servers in other zones, it depends on those zones too. For example, at the time of this writing, the zone internetsociety.org depended on name servers under.info and nlnetlabs.nl. Each of these zones might have a similar spread in their dependencies. According to the tool cited in [26], the size of the IPv4 + IPv6 dependency graph of internetsociety.org was = 204 nodes. 3 These belong in R DNS, and exist in the Network-Delivery Assurances tier as elements that could be used in an attack vector, and therefore each increase the attack surface. Modeling the Web Server: Quantifying the web server process (p web ) is comparatively easy to the DNS, because we do not recurse below the specified protocol level. We simply model a separate element in R web for every IPv4 and IPv6 server that the site s zone specifies, in the Network-Delivery Assurances tier. Because these nodes do not have any visible relationship to each other, we do not model any adjacencies between these nodes in R web. Modeling the Web Server s Certificate: Quantifying the web server s certificate resource element graph (R cert ) is important, but often times it is also trivial. The certificate certainly exists as part of the attack surface, but aside from the single element in the Object-Level Assurances tier, it may not expose any additional attack surface (itself). However, in some cases, organizations have their own certificate delegation hierarchy. That is, a company like Foo Corp might buy a certificate from a CA, and then use that certificate to delegate to multiple other Foo Corp certificates. In this way, Foo Corp can reprovision, revoke, or otherwise change their own certificates at any time. Where this organization-dependent hierarchy exists, we include it in this portion of the attack 3 From [26], the URL to plot these graphs is available at verisignlabs.com. Fig. 4. This Figure shows the attack surface of DANE s resource graphs. surface. Modeling the CA List: The CA list seems deceptively simple but in reality it is very complicated to model. While the CAs are each just X.509 certificates whose assurances exist in the Object-Level Security tier (which is straightforward), the number of resource elements (i.e. the driving portion of the attack surface size) actually also depends on the specific software platform that the Relying Party (RP) uses. This is because the list of CAs that each software vendor bundles is independent. We will see in Section IV that they can be measurably different, but in general, the size of the CA list is often roughly 160 elements. In addition, many CAs delegate signing authority to other subordinate certificates (for load, scalability, operational ease, etc.). As a result, the CA model includes multiple levels of CA signers, each of which increases the attack surface. Therefore, the CA process resource element graph R CA is a set of trees, the set of whose root certificates C roots vary depending on client software (but are knowable, a priori), and the set of whose subordinate/delegated certificates C deleg is learned dynamically during verification. Because of this, we define R CA = ({C roots C deleg }, D), where D represents the set of delegations. Modeling Certificate Revocation: The revocation system for X.509 certificates is designed to let RPs determine if a certificate that is about to be used has been revoked (and therefore should not be used). The idea is that since a certificate s signature provides integrity assurances (no one can modify its contents without invalidating its signature), then any pointer to a revocation site that is embedded in the certificate can be trusted. The ways that certificate revocation is specified in X.509v3 certificates is either via a CRL or OCSP server(s). In either case, the RP must use DNS to locate the server(s) responsible for serving the CRL, or OCSP, and then contact those servers. Thus, for p rev, the resource element graph (R rev ) is computed just as we previously did for the initial DNS lookup and for the web server: the Transitive Trust graph and the server IP addresses in the Network-Delivery Assurances tier. Modeling the TLS Session: Finally, after the site s certificate has been vetted by all of the above processes, the TLS process p T LS will setup a session key, and that key is a single c 2014 Verisign, Inc. All rights reserved. 6 Verisign Labs Technical Report # version 4

7 resource element in the R T LS graphs, in the Session-Level Security tier. 2) DANE: As we noted earlier, G DANE G CA. Therefore, the tiered attack surface representation is also a logical subset. Figure 4 shows that DANE cuts out the CA verification hierarchy, and the certificate revocation surface. However, the Figure also illustrates the effect that DANE s requirement to use DNSSEC has: the R DNS graph is in the Object-Level Security tier. Next, we quantitatively compare the benefits of reducing elements in one tier while adding elements in another tier. D. Measuring and Comparing the Attack Surface Areas In our model, we consider the attack surface S to be defined as the union of resource element graphs in our G F P D : S = G F P D i=0 R i (1) Clearly, the heterogeneity of our attack surface (which includes IP addresses, certificates, session keys, and more) makes comparing the benefits or vulnerabilities challenging. Each element in each tier of our resource graphs can clearly have different importance in the role of compromising the overall system (some things are more useful in an attack than others). For example, can we claim that compromising a DNS secondary server is as easy or useful as compromising a CA s certificate? While we do not presume this is necessarily the case, one of the benefits of using the attack surface model is that it does not attempt to address these relative importance. So, our evaluation models each element as having the same weight in the overall attack surface area, A: A = G F P D i=0 R i (2) For those sites whose zones use DNSSEC (and sites whose revocation zones use DNSSEC), the DNS component of the attack surface is computed from the DNSSEC delegation chain, instead of the Transitive Trust graph. As with the DNS component of the initial lookup, a similar reduction in attack surface results. IV. EVALUATION In this Section, we use our methodology from Section III to measure the actual attack surface areas (A CA and A DANE ) exposed by a corpus of actual web sites. However, the attack surfaces defined in Section III have components that are described by both the specific client software, and the operational deployment of the specific site a client is querying. For this reason, we must consider both client software being used and the site being queried, in order to measure attack surface areas. In the case of CA verification, the client s Relying Party (RP) software dictates the list of CAs that are used in verification. It is, therefore, important to understand the varying surface area that different types of RP software expose. Table I Number of CAs RP Software 169 Mozilla 167 Windows 167 Apple s ios 5 92 Apple s ios 3 TABLE I CA LIST SIZES FROM SOME POPULAR RP SOFTWARE. details the size of a few RP software distributions [5], [6], [19], [21], measured at the time of this writing. The intention of this table is not to be an exhaustive list of RP software (as that is beyond the scope of this paper). Rather, we simply submit these measurements as relative notions of attack surfaces (of C roots ) exposed by some RP software. Unfortunately, we cannot measure the full set of CA delegations (C deleg, from Section III) directly from the RP software, because these are learned from the certificates returned by web servers. However, we can observe them by measuring actual TLS sites. Next, we present measurements taken from a corpus of popular web sites. Recall from Section III that to compute our attack surface area for each site, we need to measure the size of its Transitive Trust structure (R DNS ), the size of its web server set (R web ), the size of its CA list (R CA = ({C CA, C deleg }, D)), the size of its revocation graph (R rev ), and its TLS graph (R T LS ). To gain a rough idea of attack surface areas today, we use the most popular 1,000 websites described by Alexa [34] as examples of sites whose TLS deployment (where it exists 4 ) is likely frequented by Internet users. Previous work [11], [10] has measured and characterized large numbers of X.509 certificates served throughout the Internet. Our findings generally match those previously seen, but our goal here is quite different. Whereas prior work attempted to describe a general notion of the global X.509 CA system, we intent to quantify very specific aspects of the overall verification process. Thus, we present measurements with a more narrow focus here. For this corpus, we first quantify how many sites are using HTTPS. We found that of those sites that did offer HTTPS, 2.0% offered the service only at the their zone s apex (i.e. example.com), while 11.9% offered it only at a www label (i.e. and 47.7% offered service at both of these names. This set of 616 sites constitutes our corpus of measured attack surface areas. From this set, we begin by examining the transitive trust footprints. To do this, we implemented the technique described in [26], and ran it on each zone in our site list. Next, we considered the surface area of the web servers for each site. However, based on CDNs, load balancing, IP anycasting, and other technologies, it is difficult to measure this number. Queries for A and AAAA records often get answered selectively based on issues ranging from location, to 4 It is very reasonable that not every web site may have TLS. c 2014 Verisign, Inc. All rights reserved. 7 Verisign Labs Technical Report # version 4

8 latency, and more. As such, rather than present a skewed attack surface area measurement, we treat each site s web server as having area = 1. We note that this represents a lower bound that, if anything, underestimates the attack surface area. Our next component of the attack surface (at least for S CA ) comes from elements in the actual X.509 certificates. Interestingly, 18.03% of the sites that offered HTTPS at both domain names (e.g., example.com and used unique certificates for each. Each of these certificates expose a different attack surface (as they each define separate resource elements in R cert ). Of the 616 sites that ran HTTPS, we found 702 different certificates. However, recall the R CA portion of the overall attack surface includes the certificates that root CAs delegate to (C deleg ), which are also used to sign certificates. One of these delegated certificates was used in the Flame malware to circumvent Microsoft s signed code protections [4]. In order to estimate the the attack surface exposed by all of the CAs in an RP s list R CA (including C deleg ), we use our observations to calculate the average number of delegated signing certificates, and use that to calculate attack surfaces. 5 From the data in this Figure, we calculated the average number of delegated signing certificates from each root to be Across the certificates seen, 24.9% used only CRL-based revocation, 3.3% used only OCSP, and 40.7% used both. The remainder did not use either of these revocation systems. However, each certificate can specify multiple points (or domain names) from which its revocation can be retrieved. For example, a certificate might list three URLs from which to download its CRL, and/or two OCSP sites to query. Only 4.6% of the sites measured had DNSSEC deployed. While this is a small fraction, it is larger than earlier reports of DNSSEC s penetration [27]. However, this (and the lack of any TLSA DNS record in the zones) indicates that none of these sites are currently utilizing DANE. The above measurements are sufficient to calculate both the CA attack surface areas and what the DANE surface areas would be. To calculate this, we used Equation 2 (for attack surface area A) and presume the Mozilla set of CAs (from Table I). In addition to the actual attack surface area for each site, we calculated what the attack surface area would be, both if each site deployed DNSSEC (on its own zone, and its revocation zones), and also if it deployed DANE. Figure 5 illustrates the attack surfaces for each site we measured (note the logscale y-axis). From this Figure, it is evident that the attack surface areas for our measured sites are at least two orders of magnitude larger than what they would be with DNSSEC, and the DNSSEC surface area is an order of magnitude larger than it would be with DANE. Specifically, Table II shows the respective maximum, average, and minimum areas for each type of attack surface area. 5 In the future, we plan to do more exhaustive measurements in order to quantify the actual number of delegations under each CA. Surface Area Attack Surface Areas Sites Surface Area Area with DNSSEC Area with DANE Fig. 5. The lower curve shows what A would be if these sites deployed DANE. This Figure shows the observed attack surface for the certificates seen for the Alexa top 1,000 (the top curve), the attack surface of sites if they were to deploy DNSSEC (middle curve), and the attack surface if DANE were deployed (lower curve), and is drawn to log scale. Max Average Min Type 1, Measured Attack Surface Surface if DNSSEC Deployed Surface if DANE Deployed TABLE II CALCULATED ATTACK SURFACE AREAS. V. RELATED WORK Attack Surface Work: Attack surfaces have long been discussed by a variety of communities. For example, the operational community has long used attack surfaces as general notion of system vulnerability [18], even though no quantitative model existed to formalize them. Also, some systems research employs notions of attack surfaces to illustrate vulnerabilities. In NoHype [33], the authors broadly classify the logical boundary between guest operating systems and their hypervisors as an attack surface. Because they were able to eliminate the entire attack space between these two components, their attack surface went from a loosely specified size to none. The authors chose not to quantify the detailed nature of this surface, the specific elements involved, or the methodology to define it because of this absolute simplification. In contrast to the above, there is a set of work that defines the attack surface that exists in software and its APIs. In the set of work [16], the authors define ways in which to analyze single-instance software systems and detect how much programmatic attack surface they expose by examining and quantifying them through state machines and I/O automata. The intuition of these works is that vulnerabilities can be quantified through detailed modeling of the software processes. These works focus on the Windows operating system (with some consideration of Linux), and quantify only a relative notion of attack surface between successive versions of the same system (as opposed to an absolute surface area). Through the iterations of these works, the authors attempt to fully c 2014 Verisign, Inc. All rights reserved. 8 Verisign Labs Technical Report # version 4

9 quantify the details of how systems operate (at the code level), how they are used (they require specific user actions), and a set of exploits that have been found in the systems. These works attempts to quantify the full spectrum of vulnerabilities and security but they conflate the notion of attack surface (that which might be leveraged in some way) with how an attack will be actually be realized, how dangerous it might be, and what the motivations for employing it might be. By contrast, our work encompasses networked systems and decouples attack surface from attack vectors. It is our belief that an attack surface definition is maximally useful when it accounts for resource elements that could feasibly be used in an attack even before the attack is known. In other recent work [3], the authors create a quantifiable metric for attack surface based on configuration parameters used to compile the Linux kernel. The approach focuses on notion that additional functionality offers additional attack surface, and reducing Linux kernel modules inherently reduces this. While this work bases part of its evaluation on discovered attack vectors, it follows the same spirit of attack surface quantification as our own. However, while it is very useful in understanding exposure to attacks, it is very specific to just the Linux kernel. Attack Modeling: There are many examples of structured analysis of attacks and defenses in which authors have fully specified both system defenses and attacks. Some notable examples are Attack Graphs [32], [14], Attack Trees [8], [15], [30], and Fault Tree analysis [28]. Due to space restrictions, we omit a detailed review of each. Rather, we claim that such formal models are critically important to the security field, but they fulfill a different requirement than attack surface modeling. Since these models largely use known attack vectors and/or fully specified aspects of actual systems, they are inherently focusing on a subset of the vulnerabilities a complex system may have. In contrast, attack surface modeling focuses on the systemic dependencies of an overall system in order to expose the elements that may be used in attacks. The difference in these approaches actually suggests that they are complementary, rather than contradictory. VI. DISCUSSION The work reported here represents a first step towards the quantitative measurement of systems attack surfaces. In the process of developing our solution we encountered interesting design considerations worth further discussion. DNSSEC Collapses Attack Surface: As we saw in Section III, the plain old DNS (podns) has transitive trust relationships as a side-effect of the fact that DNS design says nothing about where zone authorities should put their secondary servers (by name or address). As a result of this and DNS lack of verifiability (i.e., any DNS server can send forged responses without being detected), podns s transitive trust relationships appear in the attack surface s element graph. However, one of the insights that our methodology uncovers about DNSSEC (in general) is that since it offers Object-Level Security based solely on the DNS hierarchy, it effectively removes the ability of any name server to lie. This allows DNS secondary servers to run as untrusted systems and is is a fundamental shift in DNS trust model, because only authorities for a zone can issue verifiable data. We saw in Section IV that, using our candidate methodology on its own, this can reduce the attack surfaces of operational zones by two orders of magnitude. This is because DNSSEC removes the recursive attack surface, and changes DNS security model from Network-Delivery Assurances into Object-Level Security (because each DNS RRset is now signed and self-verifying). That is, while podns entire transitive trust graph is its attack surface, DNSSEC s model reduces DNS attack surface to just the zone s signing keys. The Difference Between Attack Surface and Availability: Protocol designers, operators, and many other engineers often try to bolster the availability of their systems by augmenting them with multiple redundant resources (such as by increasing the number of secondary DNS servers, etc). Part of our analysis illustrates that the two concepts of vulnerability and availability are not necessarily competing notions, and can be made independent of each other. That is, one could design a system in which increased availability resulted in additional attack surface, but this is not necessary. Consider that our candidate definition of attack surface is only composed of resources that can lie, and thereby successfully subvert a system s correct operation. This is not a measure of availability. Availability can be thought of as a measure of the probability that one gets data in the presence of unexpected failures. Higher redundancy can result in higher availability. It is true that higher redundancy can result in larger attack surface (if, for example, the correctness of the system depends on the correctness of the individual components added). However, redundancy has no impact on attack surface if the system s correctness is independent from the correctness of individual components. That is, if one can bolster a system s availability by adding resources that are unable to effectively tell lies, the attack surface will not increase with availability. Indeed, this is illustrate well by comparing podns secondaries (that augment availability and attack surface) with DNSSEC secondaries (that augment availability, but not attack surface). Limitations of Enumerating Attack Vectors: As we discussed in Section V, some prior work [8], [30] rigorously attempted to enumerate the space of attack vectors and their relative severity. While one would like to know all of the attack vectors that exist, and all of the ways in which attacks might be constructed, we believe that complex systems (like networked systems) are often exploited in numerous unforeseen ways. For example, much of the faith users have in the CA model is predicated on the notion that CAs (or their subordinate CAs) will not be compromised. However this was exactly the attack vector used by the Flame malware to get signed code accepted by Windows machines (described by Kaspersky Labs as, one of the most complex threats ever discovered [2]). DANE s Design Insights: One of DANE s central insights is realizing that since TLS starts off with DNS lookups, why not just use it for verification? That is, DANE collapses c 2014 Verisign, Inc. All rights reserved. 9 Verisign Labs Technical Report # version 4

10 many of the systemic dependencies into just DNS (with DNSSEC), and thereby reduces the overall attack surface. The original design of DNS [20] has proven to be very effective at recognizing and honoring the boundaries of administrative domains, and DANE inherits these benefits. VII. CONCLUSION AND FUTURE WORK The systemic dependencies of today s Internet-scale systems can be far more complex than we often realize, and this can sometimes lead to unforeseen security vulnerabilities. Perhaps just as unsettling is the realization that the security solutions we employ are often so complex that they reduce the overall usability of a networked system, and may even introduce more vulnerabilities. The concept of an attack surface has been developed recently to capture an upper bound to such potential vulnerabilities. Yet it still remains an open challenge to describe (given a system) how exactly one should go about defining and quantitatively measuring the attack surface, and how to represent such a decomposition in a meaningful way. In this work we defined a novel methodology that both precisely quantifies and graphically illustrates the systemic dependency graphs of actual networked systems. We then used this to define and quantify the attack surfaces of actual deployments of X.509 CA verification and DANE. We were able to measure and quantify that DANE reduces the average attack surface that is exposed by today s Alexa top 1,000 websites by orders of magnitude. Our methodology can also be used to visualize precisely why the attack surface of DANE precludes the possibility of certain types of attacks, like those exposed by DigiNotar [35]. Our methodology could be used to visualize compromised CAs and RPs, and actually see when sites are vulnerable. This facility would make attack surface analysis a feasible option for real-time attack detection. In the future, we plan to apply this methodology to other systems like the Resource Public Key Infrastructure (RPKI) and Secure BGP (BGPsec) [12] in order to quantify their relative merits and drawbacks to other approaches. In addition, we plan to investigate how this methodology can be actively used with techniques like kill chain analysis [13] to quantify how a reduction in attack surface area can provably protect systems from certain types of attacks. This would be done by recognizing that certain attacks can only succeed in the presence of certain attack surface elements, and eliminating those elements implicitly eliminates such attacks. Also, we plan to begin longitudinal monitoring and analysis of the global DANE rollout, similar to our earlier DNSSEC tracking [24], [25], in order to investigate the new interactions users will be having with DNSSEC through the use of DANE. REFERENCES [1] DNS-based Authentication of Named Entities (DANE). datatracker.ietf.org/wg/dane/charter/. [2] Flame: Massive cyber-attack discovered, Kaspersky Labs researchers say, May [3] Attack Surface Metrics and Automated Compile-Time OS Kernel Tailoring. In 20th Annual Network & Distributed System Security Symposium NDSS, February [4] M. S. A. ( ). Unauthorized digital certificates could allow spoofing, [5] Apple. ios 3.x: List of available trusted root certificates. apple.com/kb/ht3580. [6] Apple. ios 5: List of available trusted root certificates. apple.com/kb/ht5012. [7] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk. Internet x.509 public key infrastructure certificate and certificate revocation list (crl) profile. RFC 5280, May [8] R. Dewri, N. Poolsappasit, I. Ray, and D. Whitley. Optimal security hardening using multi-objective optimization on attack tree models of networks. In 14th conference on Computer and Communications Security, CCS, CCS 07, [9] T. Dierks and E. Rescorla. The transport layer security (tls) protocol version 1.2. RFC 5246, [10] P. Eckersley and J. Burns. An observatory for the ssliverse. In Defcon 18, [11] R. Holz, L. Braun, N. Kammenhuber, and G. Carle. The ssl landscape: a thorough analysis of the x.509 pki using active and passive measurements. In 2011 Internet Measurement Conference, IMC 11, [12] G. Huston and R. Bush. Securing bgp with bgpsec. The Internet Protocol Forum, 14(2), june [13] E. Hutchins, M. Cloppert, and R. Amin. Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains. In 6 th International Conference on Information Warfare and Security (ICIW), [14] S. Jha, O. Sheyner, and J. Wing. Two formal analyses of attack graphs. In Computer Security Foundations Workshop, Proceedings. 15th IEEE, [15] A. Jrgenson and J. Willemson. Serial model for attack tree computations. In Information, Security and Cryptology, ICISC 2009, [16] P. Manadhata and J. Wing. An attack surface metric. Software Engineering, IEEE Transactions on, 37(3), may-june [17] M. Marlinspike. Breaking SSL with null characters. Black Hat, [18] D. McPherson. DNS Attack Surface, April arbornetworks.com/2009/04/dns-attack-surface/. [19] Microsoft. Windows Root Certificate Program - Members List (All CAs), October articles/2592.aspx. [20] P. Mockapetris and K. J. Dunlap. Development of the domain name system. In SIGCOMM 88, [21] Mozilla. Mozilla Root Certificate List. source/security/nss/lib/ckfw/builtins/certdata.txt. [22] E. Nigg. Untrusted Certificates, [23] E. Osterweil, B. Kaliski, M. Larson, and D. McPherson. Reducing the X.509 Attack Surface with DNSSEC s DANE. In Securing and Trusting Internet Names, SATIN 12, [24] E. Osterweil, D. Massey, and L. Zhang. Observations from the DNSSEC Deployment. In The 3rd workshop on Secure Network Protocols (NPSec), [25] E. Osterweil, D. Massey, and L. Zhang. Deploying and Monitoring DNS Security (DNSSEC). In ACSAC 09, [26] E. Osterweil, D. McPherson, and L. Zhang. Operational implications of the dns control plane. IEEE Reliability Society Newsletter, May [27] E. Osterweil, M. Ryan, D. Massey, and L. Zhang. Quantifying the operational status of the dnssec deployment. In IMC 08, [28] H. Phan, G. S. Avrunin, M. Bishop, L. A. Clarke, and L. J. Osterweil. A Systematic Process-Model-based Approach for Synthesizing Attacks and Evaluating Them. In 2012 Electronic Voting Technology Workshop/Workshop on Trustworthy Elections. EVT/WOTE 12, [29] V. Ramasubramanian and E. G. Sirer. Perils of transitive trust in the domain name system. In Proceedings of the 5th ACM SIGCOMM conference on Internet Measurement, IMC 05, pages 35 35, Berkeley, CA, USA, USENIX Association. [30] I. Ray and N. Poolsapassit. Using Attack Trees to Identify Malicious Attacks from Authorized Insiders. In European Symposium on Research in Computer Security, [31] M. W. N. Security. Fraudulent certificates issued by Comodo, is it time to rethink who we trust?, fraudulent-certificates-issued-by-comodo-is-it-time-to-rethink-who-we-trust/. [32] O. Sheyner, J. Haines, S. Jha, R. Lippmann, and J. Wing. Automated generation and analysis of attack graphs. In IEEE Symposium on Security and Privacy, 2002., c 2014 Verisign, Inc. All rights reserved. 10 Verisign Labs Technical Report # version 4

11 [33] J. Szefer, E. Keller, R. B. Lee, and J. Rexford. Eliminating the hypervisor attack surface for a more secure cloud. In Computer and Communications Security, CCS 11, [34] the Web Information Company. Alexa. [35] W. A. C. Weekly. DigiNotar SSL certificate compromise widens to include security agencies, SSL-certificate-compromise-widens-to-include-security.htm. c 2014 Verisign, Inc. All rights reserved. 11 Verisign Labs Technical Report # version 4