TCP/IP: DNS Network Security Lecture 8 The Domain Name System - PowerPoint PPT Presentation

TCP/IP: DNS Network Security Lecture 8

The Domain Name System • Database that primarily maps IP addresses (147.188.192.42) to names (www.cs.bham.ac.uk) and viceversa – Nice properties: distributed, coherent, reliable, autonomous, and hierarchical DNS namespace has tree structure • – Domain is a node in this tree – All nodes except the root have labels (e.g., www) – Fully qualified name: nodes labels, bottom up, each followed by a dot Nodes are grouped (clique) into zones (administrative boundaries) • – Apex is called the “start of authority” – Bottom edges with other zones below them are “delegation points” – Bottom nodes with no other zones below them are “leaf nodes” – Each zone is served by authority servers • Nodes store actual content in resource records (RRs) – RR: name, class, type, TTL, and data – Data can map IP to host name and viceversa – Data can specify the mail server for domain • More: P. Vixie, “DNS Complexity”, ACM Queue, 2007 Eike Ritter Network Security - Lecture 8 2

Domain hierarchy . (root) uk arpa com net in-addr google lloydstsb co ac 147 google bham 188 192 ph cs 42 Eike Ritter Network Security - Lecture 8 3

Mapping names to IPs and viceversa • Can a host name be mapped to many IP addresses? – Yes. For example, load balancing $ nslookup www.google.com Name: www.l.google.com Address: 209.85.143.99 Name: www.l.google.com Address: 209.85.143.104 • Can an IP address be mapped to many domain names? – Yes. For example web hosting (Some) domains seen at 74.125.53.132: amomsrantings.blogspot.com, bloxee.blogspot.com, culturadohashi.blogspot.com, ocedeloguxuf.blogspot.com, opensocial.googleusercontent.com, www-blogger-, ads.gmodules.com,, www.gmodules.com, … – Tool: Passive DNS replication @ BFK Eike Ritter Network Security - Lecture 8 4

Servers • Primary authoritative server – Authoritative for a zone – Loads mappings from local configuration (file on disk) • Secondary authoritative server – Backup – Their zone data comes to them from primary servers via a zone transfer procedure • Recursive and caching server – Caches query results until their TTL expires – Implements the recursive algorithm needed to locate a RR Eike Ritter Network Security - Lecture 8 5

Clients • Often called “resolvers” • Most often they do not cache (“stub resolver”) • Rely on recursive service of their designated full resolver $ cat /etc/resolv.conf search cs.bham.ac.uk nameserver 147.188.192.4 nameserver 147.188.192.8 • Tools: nslookup, dig, host Eike Ritter Network Security - Lecture 8 6

Queries • Recursive • Specify the information requested (type of query) – Client asks the server to respond with either the requested resource − A: address of host record or error message if none − NS: authoritative name server for exists domain – If DNS server does not have the − CNAME: canonical name queried information, it queries − MX: mailer for host other servers until it gets the − TXT information (or the query fails) • Are identified by ID field (16 bits) • Iterative – Client asks the server to respond • Can be done over UDP or TCP with the best answer it can − Typically UDP; TCP for larger provide, given its cache or zone responses data – If DNS server does not have the queried information, it may respond with a referral to server that may have it Eike Ritter Network Security - Lecture 8 7

Example $ dig google.com ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34072 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 300 IN A 209.85.143.99 google.com. 300 IN A 209.85.143.104 ;; AUTHORITY SECTION: google.com. 172800 IN NS ns4.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns3.google.com. ;; Query time: 21 msec ;; SERVER: 147.188.192.4#53(147.188.192.4) ;; WHEN: Wed Feb 2 18:29:31 2011 ;; MSG SIZE rcvd: 132 Eike Ritter Network Security - Lecture 8 8

Example % dig +norecurse google.com ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52597 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com. IN A ;; AUTHORITY SECTION: com. 172794 IN NS i.gtld-servers.net. com. 172794 IN NS e.gtld-servers.net. com. 172794 IN NS l.gtld-servers.net. com. 172794 IN NS c.gtld-servers.net. com. 172794 IN NS h.gtld-servers.net. com. 172794 IN NS d.gtld-servers.net. com. 172794 IN NS b.gtld-servers.net. com. 172794 IN NS g.gtld-servers.net. com. 172794 IN NS f.gtld-servers.net. com. 172794 IN NS a.gtld-servers.net. com. 172794 IN NS k.gtld-servers.net. com. 172794 IN NS j.gtld-servers.net. com. 172794 IN NS m.gtld-servers.net. Eike Ritter Network Security - Lecture 8 9

DNS query 13:30:08.018705 IP 10.4.130.214.51103 > 147.188.128.102.53: 1313+ A? google.com. (28) 13:30:08.047483 IP 147.188.128.102.53 > 10.4.130.214.51103: 1313 5/13/0 A 74.125.230.114, A 74.125.230.115, A 74.125.230.116, A 74.125.230.112, A 74.125.230.113 (319) Eike Ritter Network Security - Lecture 8 10

DNS spoofing server2.example.com ns1.example.com 172.16.48.2 ns1.evil.com 2.-3. 1. Assumption: server1 trusts connection from .example.com 1) attacker connects to server1 from 6.6.6.6 Attacker: server1.example.com 2) server1 looks up the name 6.6.6.6 172.16.48.1 associated with 6.6.6.6 3) ns1.evil.com replies “server2.example.com” 4) Server1 grants access to attacker Eike Ritter Network Security - Lecture 8 11

Defense: double reverse lookup • Given IP address I 1 , obtains the name N – Mapping is provided by name server responsible for I 1 , which may well be completely untrustworthy • Given N, obtain its address I 2 – Mapping is provided by name server responsible for N. In the scenario before, this name server is trusted • Check if I 1 =I 2 Eike Ritter Network Security - Lecture 8 12

DNS hijacking • DNS does not provide any means of authentication • Racing against the queried named server it is possible to provide a fake IP address/domain name mapping – Attacker could mount attack against client – Attacker could mount attack against name server • The attacker needs to set correctly the request ID – Easy if attack done on the same LAN (sniffing) – Need to guess if done blindly Eike Ritter Network Security - Lecture 8 13

DNS hijacking A 74.125.230.115 A? google.com A 172.16.48.1 ns1.example.com Victim: Attacker: 172.16.48.2 172.16.48.1 Eike Ritter Network Security - Lecture 8 14

DNS amplification attack • Certain queries can cause large responses – TXT, ANY query – Queries for “.” (root) • Most typically, queries done over UDP • Do you see a problem here? (remember smurf attacks?) • DNS amplification attack: – The attacker spoofs the source IP address to be the address of the victim – Sends these “expensive” queries to a large number of servers – Servers will send the response to the victim, overloading it • Defenses: – Don’t allow open recursive servers, that is recursive servers that respond queries from external clients – Respond to expensive queries from untrusted parties with shorter error messages (REFUSED answer, instead of providing the list of root servers) Eike Ritter Network Security - Lecture 8 15

DNS poisoning • Certain DNS implementations used to cache anything contained in a DNS reply • Malicious DNS server would return a reply with additional answers that would poison the victim’s cache – Query for foo.com answered with additional section containing the IP address of bank.com – Can you use it to bypass the double reverse lookup? • Solution: only accept additional information that is relative to the domain being queried (bailiwick check) Eike Ritter Network Security - Lecture 8 16

DNS poisoning A? google.com • Attacker forces recursive resolver ID = 1234 to initiate a DNS query ns.victim.com ns.google.com • As the resolver is waiting for answer from authority resolver, attacker forges answers Attacker needs to guess all the • transactional elements used in the victim’s query – Query ID – Port number IN A google.com • If success, victim will store wrong 172.16.48.1 IP-domain mapping ID = 1234 • If attacker looses the race, he will have to wait until the correct response expires (TTL field) – Order of several days, typically Attacker 172.16.48.1 Eike Ritter Network Security - Lecture 8 17

Kaminsky attack • Technique to “speed up” the poisoning attack • Attacker sends query for 000001.bank.com • Recursive server recursively attempts to answer the query contacting authoritative server of bank.com (ID = 1234) • Attacker sends a number of spoofed responses (trying to guess the correct ID) with 2 parts: – Answer for 000001.bank.com is arbitrary – Authority section that claims a malicious IP is the NS for the bank.com zone If the attacker guesses the ID and port number, Bailiwick check passes • If the attacker is unsuccessful, the correct answer (likely, NXDOMAIN) • arrives first and is accepted • But now attacker can simply try again, querying for 000002.bank.com – Attacker does not need to wait for TTL to expire Eike Ritter Network Security - Lecture 8 18