cs 557 - lecture 22 dns securitymassey/teaching/cs557/...cs 557 - lecture 22 dns security dns...
Post on 11-Jul-2020
3 Views
Preview:
TRANSCRIPT
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?
www.darpa.mil A 128.9.128.127
Root DNS Server
mil DNS Server
darpa.mil DNS Server
Dan’s Laptop
Easy to observe UDP DNS query sent to well known server on well known port.
www.darpa.mil A 192.5.18.19
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 ….
Authoritative DNS Servers
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 ….
Authoritative DNS Servers
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 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 DNSKEY (pub key 2)
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 DNS Server
darpa.mil DNSKEY (pub key 1)
darpa.mil DNSKEY (pub key 2)
darpa.mil RRSIG(A) by key 1
darpa.mil DS record (hash of pubkey 1)
darpa.mil RRSIG(DS) by mil private key
darpa.mil DNSKEY (pub key 3)
darpa.mil RRSIG(A) by key 3
darpa.mil DS record (hash of pubkey 3)
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.
top related