CS Lecture 22 DNS Security

Transcription

1 CS Lecture 22 DNS Security DNS Security Introduction and Requirements, RFC 4033, 2005 Fall 2013

2 The Domain Name System Virtually every application uses the Domain Name System (DNS). DNS database maps: Name to IP address Root edu mil ru = And many other mappings isi darpa af mil (mail servers, IPv6, reverse ) Data organized as tree structure. Each zone is authoritative nge andrews for its local data.

3 DNS Query and Response A? Root DNS Server End-user A Caching DNS Server mil DNS Server Actually = But how would you determine this? darpa.mil DNS Server

4 DNS Vulnerabilities Original DNS design focused on data availability DNS zone data is replicated at multiple servers. A DNS zone works as long as one server is available. DDoS attacks against the root must take out 13 root servers. But the DNS design included no authentication. Any DNS response is generally believed. No attempt to distinguish valid data from invalid. Just one false root server could disrupt the entire DNS.

5 A Simple DNS Attack Easy to observe UDP DNS query sent to well known server on well known port. Joe s Laptop A? A A Dan s Laptop First response wins. Second response is silently dropped on the floor. Caching DNS Server Root DNS Server mil DNS Server darpa.mil DNS Server

6 Secure64 Caching Server A More Complex Attack Response A attacker.com NS ns.attacker.com attacker.com NS ns.attacker.com A A = Query Query ns.attacker.com Secure64 Laptop Remote attacker

7 Routing Based DNS Attacks BGP Also Provides No Authentication Faults and attacks can mis-direct traffic. One (of many) examples observed from BGP logs. Server could have replied with false DNS data. ISPs announced new path for 20 minutes to 3 hours originates route to /24 BGP monitor Internet c.gtld-servers.net

8 The Problem in a Nutshell Resolver can not distinguish between valid and invalid data in a response. Idea is to add source authentication Verify the data received in a response is equal to the data entered by the zone administrator. Must work across caches and views. Must maintain a working DNS for old clients.

9 DNS Security Extensions Cryptography is like magic fairy dust, we just sprinkle it on our protocols and its makes everything secure - IEEE Security and Privacy Magazine, Jan 2003

10 Secure DNS Query and Response Caching DNS Server Authoritative DNS Servers End-user = Plus (RSA) signature by the darpa.mil private key Attacker can not forge this answer without the darpa.mil private key.

11 Authentication of DNS Responses Each zone signs its data using a private key. Recommend signing done offline in advance Query for a particular record returns: The requested resource record set. A signature (SIG) of the requested resource record set. Resolver authenticates response using public key. Public key is pre-configured or learned via a sequence of key records in the DNS heirarchy.

12 Learning DNS Public Keys Public key is required to verify signature RRSIG record identified the key name and key tag. If you are pre-configured with key, then done. UCLA resolver is configured with the ucla.edu key Typical resolver does not have all the public keys. Configure root key and perhaps some local keys Query zone for the desired public Query returns DNSKEY record and a signature from the parent zone.

13 Example DNSSEC Records name TTL class RRSIG type_covered Algorithm labels TTL expiration ( inception dates key_tag key_name signature ) IN A IN RRSIG A ( darpa.mil. Base 64 encoding of signature ) name TTL class DNSKEY FLAGS PROTOCOL Algorithm public key darpa.mil IN DNSKEY ( Base64 encoding of pub key ) darpa.mil IN RRSIG DNSKEY ( mil. Base 64 encoding of signature ) Note the darpa.mil DNSKEY is signed by the mil private key (We later show why this doesn t work)

14 Authenticated Denial of Existence What if the requested record doesn t exist? Query for foo.isi.edu returns No such name How do you authenticate this? Must meet a variety of operational constraints Some zones refuse to store any keying information online. Some zones don t trust (all) of their secondary servers. Can t control which server a resolver contacts. Some zones don t have compuational resources to sign on the fly Can t predict user would ask for foo.isi.edu

15 NSEC Records Solution: sign next name after a.isi.edu. is g.isi.edu. foo.isi.edu.? Caching DNS Server Authoritative DNS Servers End-user foo.isi.edu. does not exist a.isi.edu NSEC g.isi.edu. a.isi.edu RRSIG NSEC.

16 There is no magic fairy dust

17 Zone Walking and Monitoring Solution: sign next name after a.colostate.edu. is g.colostate.edu. foo.colostate.edu.? Caching DNS Server Authoritative DNS Servers End-user foo.colostate.edu. does not exist a.colostate.edu NSEC g.colostate.edu. a.colostate.edu RRSIG NSEC.

18 Revising DNS Key Management Operational Problems in RFC 2535 DNSSEC USC/ISI led one of the first multi-administion testbeds. Identified fundamental key management & scaling issues. Revision now at the end of the standards process Provide a coherent design that meets needs of vendors/operators Currently co-editor of the IETF revision [1]. Basic Principles Behind the DNS Revision The DNS succeeded by de-coupling zones. But authentication chains require coordination. Store a hash (copy) of the child key at the parent. Overcomes the DNS atomic RRset problem. Manages authentication chains using operations similar to those currently used for maintaining server chains.

19 Revised DNS Key Management darpa.mil NS records Can Change mil key without notifying darpa.mil darpa.mil DS record (hash of pubkey 1) darpa.mil SIG(DS) by mil private key mil DNS Server darpa.mil DNS Server darpa.mil DNSKEY (pub key 1) darpa.mil DNSKEY (pub key 2) darpa.mil RRSIG(A) by key 1 } Can Change key 2 without notifying.mil A record RRSIG(A) by key 2

20 DNS Key Signing Key Roll-Over mil DNS Server darpa.mil DS record (hash of pubkey 3) darpa.mil RRSIG(DS) by mil private key darpa.mil DS record (hash of pubkey 1) darpa.mil RRSIG(DS) by mil private key darpa.mil DNS Server darpa.mil DNSKEY (pub key 1) darpa.mil DNSKEY (pub key 2) darpa.mil RRSIG(A) DNSKEY (pub by key 13) darpa.mil RRSIG(A) by key 13 darpa.mil RRSIG(A) by key 3 } Objective: Replace DNSKEY 1 with new DNSKEY 3

21 Minimal Requirements Parent must indicate how to reach the child. NS records at parent MUST identify at least one valid name server for child. Parent must identify a trusted key at child. DS record at parent MUST match a valid KEY stored at the child.

22 Protocol Complications Building on an existing system Objective is to strengthen the system. But additions also add stress to weak points. Some example cases: Denial of service added by the DS record. NS records stored at the parent. Over use of the KEY record.

23 Hidden DS Denial of Service DS Record is Stored Only at the Parent. All DS records should be sent to parent. What if you ask ucla.edu for the ucla.edu DS? Early BIND Implementation Choice: Server says I m not authoritative for this data. Resolver hears Not authortitative for ucla.edu The Resulting Under-Specification Attack Ask resolver to send DS query to each ucla.edu server. Each server declared not authortiative for ucla.edu! Query for now returns: cache says all ucla.edu servers are broken

24 Flaws in the DNS Design (glue) Parent (edu) stores NS records for child (isi.edu) Provides a hint on how to reach the child Child also stores a copy of the same NS RRset. Child (isi.edu) is the authoritative source. Implications for Authentication: Parent is not the authoritative source of the data. Child data is not available if parent is wrong. Resolver/cache can t distinguish between the set stored at the child and the set stored at the parent. DNSSEC Solution: Only the child signs its NS RRset

25 NS records stored at the Parent Edu server stores NS records for ucla.edu Tells a resolver where to find ucla.edu servers. Ucla.edu server also stores ucla.edu NS set. Ucla.edu is the authoritative source. Parent and child differ due to various reasons SeePappas SIGCOMM 2004 Loose coordination works since only requires some overlap in parent/child NS. Security assumes identical. Security also says parent can t sign NS set. Parent is not the authoritative source of the data.

26 Over Use of KEY Record Original KEY record used for DNSSEC and IPSEC, , TLS, etc. Resolver looking for DNSSEC key gets all possible keys. Data (ipsec key) should be separate from control (DNSSEC) key. Fixed in RFC 3449 that limits KEY to DNSSEC.

27 Wild Cards Authenticated denial further complicated by wildcards. Must prove b.darpa.mil does not exist Must also prove no wildcard would match. Algorithm for computing necessary wildcards now available in revised specification. Pathological cases require many NXT records. Motivates one further change Proposal to add bit indicating: next (signed?) name after a is c and no wildcards apply in between

28 Moving DNSSEC to the End Host DNS security design worked with DNS resolvers and servers. Default was to send DNSSEC data. Verified old resolvers and servers ignore it. But DNS interacts with many other pieces. Firewalls did not ignore the extra records. Our subcontract was blackholed by DARPA. DARPA firewall thought the SIG records were an attack! DNSSEC OK bit added to protocol Resolver sets this bit indicated DNSSEC data is okay.

29 Who is Deploying DNSSEC? Monitoring Started From Close to Day One DNSSEC RFCs published in March 2005 Monitoring launched in October 2005 Find Zones Using Crawling and User Submissions Continually crawl DNS looking for secure zones Allow users to submit the names of secure zones

30 DNSSEC Deployment Oct 16, 2007: 10,319 Secure Zones

31 Deployment Observations (Undirected) Crawling DNS Finds Few Secure Zones Vast DNS + tiny DNSSEC => low (near 0) hit rate for crawler User Submissions Drive Current Monitoring SecSpider is well publicized => high submission rate Augment secure zones with parent/child and popular sites Trend is positive, but still very small deployment overall Some top level domains deploying or deployed (e.g. se zone) Not yet at critical mass for DNSSEC

32 A Closer Look at Secure Zones Monitor Closely Tracks All Secure Zones Frequent Queries to Monitor Changes Exploit DNSSEC zone walking Still tractable due to relativley small DNSSEC deployment Monitoring Reveals Many Challenges DNSSEC deployment is not simple after all Challenge in Islands of Security Challenge in Key Management Challenge in Preventing Replays

33 Challenge 1: Islands of Security DNS relies on the tree herarchy to learn public keys Everyone knows root public key But how would this happen and who manages it? Root key used to sign edu public key But neither root or edu have public keys now. edu key used to sign colostate.edu key But no hierarchy leads to the public key? How does a resolver learn a secure zone s public key?

34 Challenge 1: Islands of Security Island of Security: DNS sub-tree where every zone in the sub-tree has deployed DNSSEC Design envisioned a single island of security All zones deploy DNSSEC and manually configure the root key Monitoring reality shows disconnected deployments DNSSEC deployed in isolated subtrees and must manually configure the public key for each island of security

35 Islands of Security Vast majority of secure zones are single zone islands. Small number of large islands but this includes testbeds.

36 Addressing Islands of Security Deploy DNSSEC at all zones or at least from root down Has yet to happen operationally.. Develop an Alternative PKI? DLV provides some service to store and report public keys Can we trust the public keys visible at the monitor? Must ensure keys came from monitor Must ensure monitor was not tricked But can rely on distributed services and checking by actual admins.

37 Challenge 2: Key Management Design is Relatively Simple, But Operations are complex Establish key pair and sign the zone Relatively straight-forward, but issues below add challenges.. Establish an Authentication Chain with a Secure Parent Cross-domain coordination with a different administration Update the key pair periodically Due to planned changes or key compromise Simple concept of parent private key signs the child public key. But many complex details

38 Minimum and Maximum Values

39 Average Key Lifetimes

40 Addressing Key Management Manual operation of complex steps is unrealistic Need to improve management tools and increase automation Possible, but need to overcome off-line key issues Match operations with monitoring Must have monitoring to provide external view of zone Must have some form of correctness check Monitoring data can aide in the automation process by checking which steps have been done Ex: detect when the DS record at the parent has changed

41 Challenge 3: Lifetimes&Replays Each cryptographic signature has a fixed lifetime Ex: Signature for edu expires on Oct 31. What if the addresses changes today? Actions Taken in the DNS Server removes changed record and replaces with new copy But attacker can still replay the old record and signature Vulnerable Records: data has changed, but the signature on old copy has not yet expired Vulnerable records can be replayed and resolver will authenticate the old copy

42 Vulnerable DNS Record Sets

43 Addressing Lifetimes & Replays With sufficient prediction, vulnerable records can be avoided Make signature lifetime match data lifetime Dramatic Improvement Coincided With Monitoring Vulnerable records greatly reduced in current data

44 The Role of Monitoring Monitoring is essential is large-scale systems Monitoring illustrates extent of known issues in deployment Monitoring identifies new challenges in deployment SecSpider Monitoring Benefits DNSSEC Illustrates progress and documents scale of known issues Identifies new challenges Allows zone admins to see how others perceive them Various examples of how monitoring led to changes Monitoring is the solution to many challenges

45 Future Directions Challenge 1: Islands of Security Monitor can be used to bootstrap public key information Challenge is to authenticate public keys came from monitor and limit chance monitor data is subverted by attacer Challenge 2 and 3: Cryptographic Management Given an external view of data, zone admins can adapt Monitoring can verify key management is working Monitoring can aide in automating DNS key management Current work is using SecSpider data to identify new challenges and practically solve existing challenges

46

47 Summary DNSSEC is useful example. Protocol evolved when it hit operations. Lesson highlight flaws So do we abandon DNSSEC? The solution is multiple fences. If DNSSEC is the solution, it failed. If DNSSEC is part of the solution, it succeeds.