557 Lecture 22

CS 557 - Lecture 22 DNS Security

DNS Security Introduction and Requirements,

RFC 4033, 2005

Fall 2013

•  Virtually every application uses

the Domain Name System (DNS).

•  DNS database maps:

–  Name to IP address

www.darpa.mil = 128.9.176.20

–  And many other mappings

(mail servers, IPv6, reverse…)

•  Data organized as tree structure.

–  Each zone is authoritative

for its local data.

Root

edu mil ru

darpa isi mil af

nge andrews

The Domain Name System

DNS Query and Response

Caching DNS Server

End-user

www.darpa.mil A?

www.darpa.mil A 128.9.128.127

Root DNS Server

Actually www.darpa.mil = 192.5.18.195. But how would you determine this?

mil DNS Server

darpa.mil DNS Server

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.

A Simple DNS Attack

Caching DNS Server

Joe’s Laptop

www.darpa.mil A?


Root DNS Server

mil DNS Server


Dan’s Laptop

Easy to observe UDP DNS query sent to well known server on well known port.


First response wins. Second response is silently dropped on the floor.

A More Complex Attack

ns.attacker.com

Secure64 Caching Server

Remote attacker

Query www.attacker.com

Response www.attacker.com A 128.9.128.127 attacker.com NS ns.attacker.com attacker.com NS www.google.com ns.attacker.com A 128.9.128.2 www.google.com A 128.9.128.127

Secure64 Laptop

Query www.google.com

www.google.com = 128.9.128.127

Routing Based DNS Attacks

Internet c.gtld-servers.net

BGP monitor

192.26.92.30

originates route to 192.26.92/24

•  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

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.

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

Secure DNS Query and Response

Caching DNS Server

End-user

www.darpa.mil

www.darpa.mil = 192.5.18.195 Plus (RSA) signature by the darpa.mil private key

Attacker can not forge this answer without the darpa.mil private key.

Authoritative DNS Servers

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.

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.

Example DNSSEC Records

darpa.mil. 81020 IN DNSKEY 256 3 1 ( Base64 encoding of pub key ) darpa.mil. 81020 IN RRSIG DNSKEY 1 3 86400 20040226023910 ( 20040127023910 569 mil. Base 64 encoding of signature )

name TTL class DNSKEY FLAGS PROTOCOL Algorithm public key

Note the darpa.mil DNSKEY is signed by the mil private key

(We later show why this doesn’t work)

name TTL class RRSIG type_covered Algorithm labels TTL expiration ( inception dates key_tag key_name signature )

www.darpa.mil. 82310 IN A 192.5.18.195 www.darpa.mil. 82310 IN RRSIG A 1 4 86400 20040226023910 ( 20040127023910 468 darpa.mil. Base 64 encoding of signature )

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”

NSEC Records

Caching DNS Server

End-user

foo.isi.edu. ?

foo.isi.edu. does not exist a.isi.edu NSEC g.isi.edu. a.isi.edu RRSIG NSEC ….


Solution: sign “next name after a.isi.edu. is g.isi.edu.”

There is no magic fairy dust

Zone Walking and Monitoring

Caching DNS Server

End-user

foo.colostate.edu. ?

foo.colostate.edu. does not exist a.colostate.edu NSEC g.colostate.edu. a.colostate.edu RRSIG NSEC ….


Solution: sign “next name after a.colostate.edu. is g.colostate.edu.”

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.

Revised DNS Key Management

mil DNS Server


darpa.mil NS records

www.darpa.mil A record

www.darpa.mil RRSIG(A) by key 2

darpa.mil DNSKEY (pub key 1)


darpa.mil RRSIG(A) by key 1

darpa.mil DS record (hash of pubkey 1)

darpa.mil SIG(DS) by mil private key

Can Change mil key without notifying darpa.mil

Can Change key 2 without notifying .mil

}

DNS Key Signing Key Roll-Over

mil DNS Server






darpa.mil RRSIG(DS) by mil private key




darpa.mil RRSIG(DS) by mil private key

Objective: Replace DNSKEY 1

with new DNSKEY 3

darpa.mil RRSIG(A) by key 1 darpa.mil RRSIG(A) by key 3

}} }

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.

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.

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 www.ucla.edu now returns:

cache says all ucla.edu servers are broken

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

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.

Over Use of KEY Record

•  Original KEY record used for DNSSEC

and IPSEC, email, 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.

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

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.

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

DNSSEC Deployment

Oct 16, 2007: 10,319 Secure Zones

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

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

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?

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

Islands of Security

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

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….

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

Minimum and Maximum Values

Average Key Lifetimes

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

Challenge 3: Lifetimes&Replays •  Each cryptographic signature has a fixed lifetime

–  Ex: Signature for www.colostate.edu 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

Vulnerable DNS Record Sets

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

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

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

http://secspider.cs.ucla.edu

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.

Documents

557 Lecture 22