modeling systemic dependencies through attack surface analysiseoster/doc/2013-04-26-sys-deps.pdf ·...
Post on 17-Jul-2020
1 Views
Preview:
TRANSCRIPT
Modeling Systemic Dependencies through Attack Surface Analysis!
Eric Osterweil!Danny McPherson!Lixia Zhang!
2 !Verisign Public !
• Well, do we know what our Internet services rely on? !• Are their foundations secure and reliable? !
• We’ve become very good at using the Internet to make our lives easier!• I can use one tweet to tell 50 million people that I just spilled
my coffee on Emma Stone at Starbucks!
• Our Internet services depend on networked systems, they are becoming increasingly layered and complex!
• Ultimately, what are we paying for these conveniences?!
What’s so important about systemic dependencies and attack surfaces?!
3 !Verisign Public !
What networked systems do I need to tweet to 50 million followers?!
Tweet
Desktop PC
Desktop PC
Desktop PC
Just splld coffee on @EmmaStonë #fail!
4 !Verisign Public !
• What is the relationship between dependent systems?!• We aim to map out what we gain, and what do we pay!
• But the application is so much broader: what systems do national critical infrastructures rely on?!• DNS resolution for the Estonian government? Routing for
Cairo? Cross modal threats from China? SCADA systems?!
• Our engineering precepts tell us to build systems on top of other systems!• But, does it make us more vulnerable to attacks, failures, etc.?!
• Is there a difference between vulnerability and availability?!
Systemic Dependencies!
5 !Verisign Public !
• Lots of ways to describe vulnerabilities, taxonomize attack vectors, etc.!
• We can’t always enumerate all of the attacks a priori!• They’re often only discovered reactively!
• We turn to attack surface ::= what could feasibly be used to attack a system’s correct operation!• If I keep my attack surface small, I reduce my exposure!• Quantifying targets and their values are different problems!• But, a quantifiable definition is elusive!
• We will quantify the attack surface of HTTPS using X.509 CA verification and compare it to HTTPS+DANE!
Measuring Vulnerability!
6 !Verisign Public !
• X.509 CA verification and DANE verification!• Attack surface methodology!• Measuring the Alexa top 1,000!• Discussion and future work!
Outline!
7 !Verisign Public !
!!• Protocols like Transport Layer Security (TLS) need to
be bootstrapped by cryptographic keys!• Servers offer certificates and clients must verify authenticity!
• CA verification uses a set of globally trusted authorities who can each vouch for any certificate’s authenticity!• Certificates represent previous verification: contain signatures
from CAs, and point to revocation points for status checks!
Certificatation Authority (CA) Verification!
CA List
DNSSEC
root
example.com
.com
1 - Resolvinghttps://www.example.com
Web Server
2 - DNSresponse
3 - HTTPS
Client
OCSPservers
CRLservers
4 - CheckCert
CheckCA Rev
CheckCA Rev
8 !Verisign Public !
• The systemic dependencies are:!• We first need to resolve its domain name (i.e. use DNS)!• Next we connect to a webserver that we found from DNS!• Then we pull an X.509 certificate down from that webserver!• With that, we use a list of pre-bundled CA certificates that we
have pre-configured to verify the webserver’s certificate!• Then we check to make sure the certificate was not revoked
since being issued!• Finally, we exchange a TLS session key with the webserver,
and start our online experience!• During this process, the attack surface includes any
resource that could feasibly enable an attack!• Possibly, a DNS secondary could give us a bogus answer that
directed us to a malicious web site, or DigiNotar could have verified a bogus certificate, etc.!
So, when we go to Facebook…!
9 !Verisign Public !
• DNS-Based Authentication of Named Entities (DANE)!• IETF working group, and standards track RFC for TLS!
• Observation: since even CA verification is frontloaded by DNS, why not do verification there too?!• Rather than the multi-rooted X.509 hierarchies, DANE uses
DNSSEC for verification!• DNS zones have TLSA record(s) that uniquely
authorize cert used by web servers!
DANE verification process!
DNSSEC
root
example.com
.com
1 - Resolvinghttps://www.example.com
Web Server
2 - DNSresponse
3 - HTTPS
Client
10 !Verisign Public !
• Qualitatively, a picture is worth 1,000 words: we can see that the attack surface is reduced!
• By cutting out our CA check and revocation checks, we removed a lot of moving parts!
Look at what we just cut out…!
CA List
DNSSEC
root
example.com
.com
1 - Resolvinghttps://www.example.com
Web Server
2 - DNSresponse
3 - HTTPS
Client
OCSPservers
CRLservers
4 - CheckCert
CheckCA Rev
CheckCA Rev
DNSSEC
root
example.com
.com
1 - Resolvinghttps://www.example.com
Web Server
2 - DNSresponse
3 - HTTPS
Client
11 !Verisign Public !
• Qualitatively, we can see that DANE’s attack surface is smaller, but…!• Talk is cheap, how can we quantify it?!
• We use the measure of systems’ systemic dependencies to quantify their attack surfaces!• Added complexity and moving parts, increases attack surface!• If a system needs n resources for ``correct operation,’’ and its
complexity increases this to n+m, its attack surface is greater!• But, we need a way to systematically decompose systems into
the resources they need…!
• Our methodology starts by identifying the logical procedural steps (processes) needed in Functional Process Digraphs (FPDs)!
• Then, we map each process to the resources it needs, and those resources are the actual attack surface!
Attack Surface Methodology!
12 !Verisign Public !
• Identifying all of the resources needed by networked systems can be non-trivial!
• To identify what resources a networked system uses, we start by identifying the logical processes it uses!
• FPDs are a way to codify networked systems!• Every logical step/procedure becomes a process in the FPD!
• Then, we look deeper at each process node and decompose it into a high-level workflow!• Workflows don’t fully
describe all of the processes’ inner-workings, but focuson how they access resources!
Functional Process Digraphs (FPDs)!
CA List
DNSSEC
root
example.com
.com
1 - Resolvinghttps://www.example.com
Web Server
2 - DNSresponse
3 - HTTPS
Client
OCSPservers
CRLservers
4 - CheckCert
CheckCA Rev
CheckCA Rev
13 !Verisign Public !
• Imagine a networked system that first required (say) a domain name resolution, and then connected to a remote system to search for a file!
• Below we might see the DNS process checking and processing, followed by a server process searching for a file!
!
• In creating an FPD, we must avoid the temptation to recursively codify processes the invoke processes beyond the semantic scope the networked system!
• For example, it may not be semantically useful to identify the process of electrons interacting with copper atoms!
Example FPD!
Decision
processYes
No
processDecision
process
process
process
Stop
Stop
Start
Start
14 !Verisign Public !
CA List
DNSSEC
root
example.com
.com
1 - Resolvinghttps://www.example.com
Web Server
2 - DNSresponse
3 - HTTPS
Client
OCSPservers
CRLservers
4 - CheckCert
CheckCA Rev
CheckCA Rev
CA verification FPDCA!
Start
Use poDNS
DNSSEC
Use DNSSEC
object security
Download cert
Check ANY CA verifies
cert
EEcert has
revocation info
Site has DNSSEC
Use poDNS
Use DNSSEC object security
Contact Server(s) for revocation info
Stop
YesNoYes No
No
Yes
DNS Resolution
Connect to web server on port 443
WWW / TCP
Web Server Cert
CAs
OCSP/CRL DNSFootprint
TLSEstablish
session key(s)
OCSP/CRLServer(s)
Note: DNSSEC!is optional!
15 !Verisign Public !
• Domain name lookups!• This could be plain old DNS (poDNS) or DNSSEC!
• Connection over a network path to a webserver!• An X.509 certificate (from that webserver)!
• Could require a chain of certificates!• The list of CA certificates in the client browser!• Domain name lookups for each revocation point!
• CRL domain names and/or OCSP domain names!• Connection over a network path to a revocation point!• A TLS session key!
CA verification requires…!
16 !Verisign Public !
DNSSEC
root
example.com
.com
1 - Resolvinghttps://www.example.com
Web Server
2 - DNSresponse
3 - HTTPS
Client
DANE verification FPDDANE!
Start
Use DNSSEC
object security
Download cert
DNS Resolution
Connect to web server on port 443
WWW / TCP
Stop
Establish session key(s)
TLS
Web Server Cert
Note: DNSSEC!is mandatory!
17 !Verisign Public !
• Domain name lookups!• DANE requires DNSSEC!
• Connection over a network path to a webserver!• An X.509 certificate (from that webserver)!• A TLS session key!
DANE verification requires…!
18 !Verisign Public !
• We can visibly see one system’s FPD is different than the other, but this is not quantitatively measurable!• FPDs help us codify the control flow of networked systems!• This helps us isolate their decision processes!• This helps us focus on what resources are used!• That helps us transform FPDs into resource graphs!• Finally, these graphs form our attack surfaces!
• The resources that each process uses inherit the same graphical relationships that they have in the FPD!
• We chose a candidate set of classification types of resources that processes use!• Network-Delivery Assurances, Session-Level Security, and
Object-Level Security!
Turning FPDs into something more meaningful!
19 !Verisign Public !
Network-Delivery Assurances
Object-Level Security
Session-Level Security
DNSResolution
WWW/TCP
WebCert CAs
OCSP/CRL
DNS Footprint
TLS
OCSP/CRLServer(s)
CA Verification’s Attack Surface!
20 !Verisign Public !
Network-Delivery Assurances
Object-Level Security
Session-Level Security
WWW/TCP
WebCert
TLS
DNSSECResolution SLD
TLDroot
DANE’s Attack Surface!
21 !Verisign Public !
• These graphs offer us several novel facilities!• We can quantify the sizes of each resource node!• We have a formal dependency/relationship between
fundamentally different types of resources (certs can be related to IP servers)!
• We can observe resource footprint changes from protocol decisions (re: DNSSEC)!
• Consider this last point: note that DANE’s requirement of DNSSEC moves the DNS portion of its attack surface out of the Network-Delivery Assurances tier, and into the Object-Level Security tier!• This is a fundamental change!!• In DNSSEC, secondary servers cannot successfully lie!!
Modeling resource element graphs!
22 !Verisign Public !
• In DNS, zones depend on name servers, and those name servers can depend on other zones!• This recursive dependency can lead to large graphs!• The transitive trust graph of the IPv4 and IPv6 name servers
of (for example) internetsociety.org are 119 and 85 nodes, respectively!
• But, because DANE requires DNSSEC, these graphs are reduced to just the DNSKEYs in the chain of trust!
Transitive trust graph sizes!
23 !Verisign Public !
• We crawled the Alexa top 1,000 sites!• We examined:!
• How many ran HTTPS on their main site!• How many ran HTTPS on www.<their-site>!• How many had different certificates on <their-site> and
www.<their-site>!• From this, and the certificates we calculated the attack
surface for each of them!• Then, we calculated what their attack surfaces would
be if:!• They deployed DNSSEC!• They deployed DNSSEC + DANE!
Evaluation!
24 !Verisign Public !
• The CA verification process requires us to calculate how large the CA set is!
• However, this is client-vendor specific!
• We can see that the list size can vary, so we evaluated using Mozilla’s size: 169!
CA list size!
Number of CAs! RP software!169! Mozilla!167! Windows!167! Apple’s iOS 5!92! Apple’s iOS 3!
25 !Verisign Public !
CA delegation chains!
26 !Verisign Public !
Revocation details (from CRL/OCSP URIs)!
27 !Verisign Public !
Network-Delivery Assurances
Object-Level Security
Session-Level Security
DNSResolution
WWW/TCP
WebCert CAs
OCSP/CRL
DNS Footprint
TLS
OCSP/CRLServer(s)
CA Verification’s Attack Surface!
28 !Verisign Public !
Quantitatively comparing these two systems!
29 !Verisign Public !
Non-log scale (just DNSSEC and DANE)!
30 !Verisign Public !
• Almost no sites in the Alexa top 1,000 had DNSSEC deployed!• Just deploying DNSSEC reduced attack surfaces by up to a
factor of 102!
• Deploying DANE reduced attack surfaces by as much as a factor of 103!
DNSSEC (alone) makes a huge difference!
Max! Average! Min! Type!1,104.92! 531.68! 309! Actual measured attack surface!40.42! 17.29! 7! Attack surface if sites deployed DNSSEC!10! 7.38! 7! Attack surface if sites deployed DANE!
31 !Verisign Public !
• Attack surface and Availability can be seen as orthogonal concepts!
• One might add additional servers to their deployment, but does this increase their attack surface?!• It might: if any of these servers is able to compromise the
correct operation of the system!• This is why DNSSEC reduces the attack surface over DNS:
secondaries cannot lie!• Conversely, one might find that higher redundancy
does not add to attack surface if increasing resources is independent of correctness!
Attack surface vs. Availability!
32 !Verisign Public !
• FPDs may lend nicely to kill chain-analysis!
• Disrupting a step in an FPD can render the rest of the process moot!
• Example: failing in the DNS stage renders following processing useless!
Using FPDs for kill chain analysis!Start
Use poDNS
DNSSEC
Use DNSSEC
object security
Download cert
Check ANY CA verifies
cert
EEcert has
revocation info
Site has DNSSEC
Use poDNS
Use DNSSEC object security
Contact Server(s) for revocation info
Stop
YesNo
Yes No
No
Yes
DNS Resolution
Connect to web server on port 443
WWW / TCP
Web Server Cert
CAs
OCSP/CRL DNSFootprint
TLSEstablish
session key(s)
OCSP/CRLServer(s)
33 !Verisign Public !
• There are lots of systems and protocols that have dependencies!• Many times, these dependencies are non-obvious!
• Nation states need ways to evaluate who and what they depend on so they know their vulnerability!
• Enterprises need ways to know which of their systems have cyclic dependencies!
• With this methodology we hope to offer a tool that lets people start evaluating what systems depend on!
Thoughts going forward…!
34 !Verisign Public !
http://irl.cs.ucla.edu/~eoster/pubs.html!
Our Technical Report!
35 !Verisign Public !
• DANE. https://datatracker.ietf.org/wg/dane/charter/.!• Flame: Massive cyber-attack discovered, Kaspersky Labs researchers
say, !May !2012. !http://www.bbc.com/news/technology-18238326 !• E. Hutchins, M. Cloppert, and R. Amin. Intelligence-Driven Computer
Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains. In Proceedings of the 6th International Con- ference on Information Warfare and Security (ICIW), page 113. ACI, March 2011.!
• E. Osterweil, D. McPherson, and L. Zhang. Operational implications of the dns control plane. IEEE Reliability Society Newsletter, May 2011.!
• 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, 2005. USENIX Association.!
• W. A. C. Weekly. !DigiNotar SSL certificate com- promise!widens !to !include !security !agencies, !2011 http://
www.computerweekly.com/Articles/2011/09/05/247792/ DigiNotar-SSL-certificate-compromise-widens-to-include-security.htm!
!
Selected References!
Thank You!
© 2012 VeriSign, Inc. All rights reserved. VERISIGN and other trademarks, service marks, and designs are registered or unregistered trademarks of VeriSign, Inc. and its subsidiaries in the United States and in foreign countries. All other trademarks are property of their respective owners.!
top related