CS 356 Using Cryptographic Tools to Secure the Domain Name System (DNS) Spring 2017

Transcription

1 CS 356 Using Cryptographic Tools to Secure the Domain Name System (DNS) Spring 2017

2 Background Motivation Overview Network Infrastructure Security DNS and DNS Vulnerabilities The DNS Security Extensions Authentication of DNS Responses Learning DNS Public Keys Authenticated Denial of Existence Critical Failures and Lessons Learned 7

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

4 DNS Query and Response Root DNS Server End-user Caching DNS Server 9

5 DNS Query and Response A? Root DNS Server End-user Caching DNS Server 9

6 DNS Query and Response A? Root DNS Server End-user Caching DNS Server 9

7 DNS Query and Response A? Root DNS Server End-user Caching DNS Server mil DNS Server 9

8 DNS Query and Response A? Root DNS Server End-user Caching DNS Server mil DNS Server 9 darpa.mil DNS Server

9 DNS Query and Response A? Root DNS Server End-user l A Caching DNS Server mil DNS Server darpa.mil DNS Server 9

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

11 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. 10

12 A Simple DNS Attack Root DNS Server Lixia s Laptop Caching DNS Server 11

13 A Simple DNS Attack A? Root DNS Server Lixia s Laptop Caching DNS Server 11

14 A Simple DNS Attack Easy to observe UDP DNS query sent to well known server on well known port. A? Root DNS Server Lixia s Laptop Dan s Laptop Caching DNS Server 11

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

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

17 CSU Caching Server A More Complex Attack ns.attacker.com Laptop Remote attacker 12

18 CSU Caching Server A More Complex Attack ns.attacker.com Query Laptop Remote attacker 12

19 CSU Caching Server A More Complex Attack Response A attacker.com NS ns.attacker.com attacker.com NS ns.attacker.com A A ns.attacker.com Query Laptop Remote attacker 12

20 CSU Caching Server A More Complex Attack Response A attacker.com NS ns.attacker.com attacker.com NS ns.attacker.com A A ns.attacker.com Query Query Laptop Remote attacker 12

21 CSU Caching Server A More Complex Attack Response A attacker.com NS ns.attacker.com attacker.com NS ns.attacker.com A A = ns.attacker.com Query Query Laptop Remote attacker 12

22 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. 13

23 Dan Kaminsky 9

24 The Kaminsky summer of fear The Kaminsky attack: replied with 1.example.com, 2.example.com, 3.example.com over and over until it got accepted. 10

25 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

26 Secure DNS Query and Response Caching DNS Server Authoritative DNS Servers End-user 15

27 Secure DNS Query and Response Caching DNS Server Authoritative DNS Servers End-user 15

28 Secure DNS Query and Response Caching DNS Server End-user = Plus (RSA) signature by the darpa.mil private key Authoritative DNS Servers 15

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

30 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. 16

31 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. 17

32 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 ) 18

33 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) 18

34 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 19

35 NSEC Records Caching DNS Server Authoritative DNS Servers End-user 20

36 NSEC Records foo.isi.edu.? Caching DNS Server Authoritative DNS Servers End-user 20

37 NSEC Records 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. 20

38 Solution: NSEC Records 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. 20

39 What s Next Read Chapter 1, 2, 3, and 4 Chap 1: Focus on big picture and recurring concepts Chap 2: Identify cryptographic tools and properties Chap 3: How can you authenticate a user? Chap 4: Access Control Homework Posted on Course Website Due Tuesday Project 1 Posted on Course Website Next Lecture Topics From Chapter 4 Access Control