Part 5 DNS Security. SAST01 An Introduction to Information Security Martin Hell Department of Electrical and Information Technology

Transcription

1 SAST01 An Introduction to Information Security Part 5 DNS Security Martin Hell Department of Electrical and Information Technology How DNS works Amplification attacks Cache poisoning attacks DNSSEC 1 2 label Domain Name System Idea: It is easier for people to remember hostnames than IPaddresses Hostname: IP-address: Before DNS: Hosts file was used Became very big... Can still be used today common for ad blocking DNS is a distributed database primarily used to translate names to numbers Has other uses as well Protocol uses UDP on port 53 server.example.com Subdomain of example.com Top-level domain Subdomain of com Each label can be 63 bytes There can be up to 127 levels But total length can be max 253 bytes com is parent of example, example is child of com A host name is a domain name that has an IP More specific More specific 3 4 1

2 . root Location of root servers (more than 100) com edu net... org dk se uk... Hierarchical organization Compare with file system Written in opposite direction Each node in the tree has a label Case insensitive There are 13 root IPs A DNS server must know these IPs lth www 5 6 Parent knows authoritative name servers for its children (but not grand children etc) Find IP of server.example.com 1. Contact a root server to get IP of server.example.com 2. Responds with IP of name server authoritative of the.com domain 3. Contact.com name server to get IP of server.example.com 4. Responds with IP of name server authoritative for example.com 5. Contact example.com name server to get IP of server.example.com 6. Responds with IP of server.example.com If this was always done, it would be lots of traffic to and from root servers Cache is used Answers from name servers are cached A DNS server has its own cache A DNS resolver also has a cache so name server might not have to be contacted An application may also have its own cache Subsequent queries requesting the same information can be answered using cache Start at longest match in cache If we previously asked for example.org we immediately go to.org NS to find server.org Answer can stay in cache as long as TTL says A DNS response has a Time-To-Live Reduces DNS traffic 7 8 2

3 Application (Firefox, IE, Safari,...) DNS resolver Preferred DNS server Authoritative servers Application cache Other DNS A DNS server may or may not know the answer Recursive query Server must give complete answer or say that it does not know Servers are not required to support this but Iterative query Server is allowed to refer the DNS to another server to ask Server must implement this Also called non-recursive DNS Resolver Preferred DNS 9 10 name server.se name server sunet.se name server Information is stored in a resource record. Name server uses iterative queries to determine IP of Resolver in OS contacts primary name server using recursive query Some examples are: A Defines an IP address Several A-records with same name but different IP allows for load balancing NS Authoritative Name Server for a zone example.com has an NS record that specifies the name of the name server for server.example.com. CNAME Canonical Name for an Alias Used to have several names pointing to one IP Should point to A-record Example: can point to example.com MX Mail exchange record Used to point to server responsible for handling mail to a domain PTR pointer record Used to lookup name for an IP address But there are several more

4 A server is authoritative for a domain if it hosts DNS records for that domain name Answers are authoritative The part of the domain for which a DNS server is authoritative is called a zone Example: Everything ending with microsoft.com belong to the microsoft.com domain example.microsoft.com can be delegated to another DNS server and will constitute its own zone microsoft.com will have an NS-record for the zone example.microsoft.com Normal use is to look up IP address for a name Also possible to look up name corresponding to an IP address Reverse DNS Domain in-addr.arpa is reserved for this purpose A PTR record is used to map IP to host name ISP in charge of an IP range is responsible for the PTR record (or to redirect to a server who is) in-addr.arpa Root servers are very important to the functionality of the Internet If all go down Internet would in practice stop working Two known attempts of DDoS attacks on root servers October 21, 2002 February 6, 2007 Neither managed to take down all DoS attack targeting specific victim Background: Since UDP is used, it is easy to spoof IP address of client Idea: Use botnet to query DNS servers and send response to victim IP: Amplification: Answer is much larger than question Spoofed source:

5 Idea: Respond to query with false information Example: Attacker running DNS server for attacker.com Has A records for his own hosts Additionally has fake records, e.g., = Attacker controls web server with IP When a DNS server asks for IP of attacker.com, the fake records are included in answer A vulnerable DNS server would accept the extra information as real and put it in cache DNS server should only accept records which are part of the domain the query was for Each DNS query has a transaction ID can be seen as nonce An answer has to contain the same transaction ID as the question The question part is included in the answer An answer is accepted if 1. The question section is the same in the reply as in the query 2. The transaction ID matches the ID in the question 3. Response comes from same IP as query was sent to 4. Response comes to same port as query was sent to Attack goal: Respond to query pretending to be the answering DNS Also known as DNS spoofing or DNS forgery Ask server to resolve name bank.com (recursive query) 2. DNS asks for IP of bank.com (iterative queries) 3. When quering name server authoritative of bank.com, response is sent from attacker before it is sent from bank.com name server Problem 1: Transaction ID has to be guessed Problem 2: Port has to be guessed Root 1. query 3. response 2a 2b 2c.com bank.com Port is not always random enough Newer implementations support this better Transaction ID is 16 bits We need to send about responses in order to be lucky with colliding IDs Improving the attack: Send several queries at one time If we can guess port then we only need about 300 queries and 300 responses according to birthday paradox All responses must be sent before real response and after query Attacker can also buy some time by doing DoS attack on bank.com name server If port number is random, the attack is much more difficult Attacker

6 Improved attack 2a 2b Root.com Identity theft: User enters name, password or other sensitive data on remote site 3. responses 2c bank.com 1. queries 3. DDoS Attacker zombies Providing false information: Users think they are connected to a site they trust for information Original DNS design does not include security DNSSEC = Domain Name System Security Extensions Idea: Use digital signatures for the data that is sent DNSSEC provides Authentication of DNS data Authenticated denial of existence Only the holder of the private key can sign the data Integrity protection The data has not been modified during transport Note: There is no encryption of data

7 A DNSSEC secured DNS zone has a private/public key pair 4 new resource records are used DNSKEY, RRSIG, NSEC, DS Public key stored in record of type DNSKEY Algorithm is also stored in record (e.g., RSA/SHA1) A DNS response will include The requested record RRset = Resource Record set All resource records that have the same name, class and type Smallest transmission unit An RRSIG record Signature Zone administrator RRset RRSIG NSEC record is used to prove that a certain record does not exist NSEC records confirms the edges between different names after ordering all records Assume a zone includes domains alfa.example.com and gamma.example.com (and no other) NSEC record for name alfa.example.com will include alfa.example.com gamma.example.com The types of records that exists for alfa.example.com Signing this record will prove that beta.example.com does not exist A certain record type does not exist for alfa.example.com Now we have a public key and signed records Signature can be verified using public key Problem: How can we trust the public key Attacker should not be able to send fake records, signatures and then send his own public key Solution: DS-record (Delegation Signer) A record storing the hash of the public key (and some identifying info) Stored in parents zone Signed by parent in a corresponding RRSIG record We achieve the same functionality as a digital certificate Use public key of parent (.com) to verify the signature in RRSIG This will give the hash of DNSKEY according to parent Compare with the claimed DNSKEY Assuming that we trust parent public key, we trust public key of child Continue up until we find a public key that we trust (compare with selfsigned certificate) Ideally, this would be the root public key DNSKEY.com RRSIG(DS) DS (Hash of DNSKEY a.com ).com DNSKEY a.com a.com

8 Deployment of DNSSEC is considered very important to the security of Internet Sending fake responses will no longer be possible Possible to store more important data in DNS Records used in security is a example There are issues though: Messages will be larger since RRSIG will also be sent Amplification attacks will be more efficient If something in a RRset will change, server has to recalculate signatures Zone file will increase due to RRSIG and NSEC records Slower resolution because of verification 29 8