1 Lecture A.3: DNS Security r Domain Name Service r Security Problems in DNS

2 DNS name service r Domain: a subtree of a domain name space r Zone: some part of the domain name space m Name servers generally have complete information about a zone r Distributed management thru delegation

3 DNS name servers r Distributed database: no server has all name-to-IP address mappings local name servers: m each ISP, company has local (default) name server m host DNS query first goes to local name server authoritative name server: m for a host: stores that host’s IP address, name m can perform name/address translation for that host’s name root name server: r contacted by local name server that can not resolve name m contacts authoritative name server if name mapping not known m gets mapping m returns mapping to local name server r  dozen root name servers worldwide

4 DNS: iterated queries Resolver: r queries the name server r interpret the responses r return result to user recursive query: r puts burden of name resolution on contacted name server r heavy load? iterated query: r contacted server replies with name of server to contact r “I don’t know this name, but ask this server” requesting host surf.eurecom.fr gaia.cs.umass.edu root name server local name server dns.eurecom.fr authoritative name server dns.cs.umass.edu intermediate name server dns.umass.edu 7 8 iterated query

5 DNS: caching and updating records r once (any) name server learns mapping, it caches mapping m cache entries timeout (disappear) after some time r update/notify mechanisms under design by IETF m RFC 2136 m

6 DNS records DNS: distributed db storing resource records (RR) r Type=NS  name is domain (e.g. foo.com)  value is IP address of authoritative name server for this domain RR format: (name, value, type,ttl) r Type=A  name is hostname  value is IP address r Type=CNAME  name is an alias name for some “cannonical” (the real) name  value is cannonical name r Type=MX  value is hostname of mailserver associated with name

7 DNS protocol, messages DNS protocol : query and reply messages, both with same message format msg header r identification: 16 bit # for query, reply to query uses same # r flags: m query or reply m recursion desired m recursion available m reply is authoritative

8 DNS protocol, messages Name, type fields for a query RRs in reponse to query records for authoritative servers additional info that supplements other sections

9 DNS query r Troubleshooting tools for DNS m nslookup m dig (domain information gopher) dig cic.ulsan.ac.kr; looks up A records for ; cic.ulsan.ac.kr dig mail.ulsan.ac.kr mx ; looks up MX records for ; mail.ulsan.ac.kr ns. ; queries a.root-servers.net ; for NS records for. domain

10 First query: authoritative gslacks[pts/3]:~> dig ; > DiG 8.2 > ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUERY SECTION: ;; type = A, class = IN ;; ANSWER SECTION: 1D IN CNAME ftp.cse.ucsc.edu. ftp.cse.ucsc.edu. 1D IN A ;; AUTHORITY SECTION: cse.ucsc.edu. 1D IN NS services.cse.ucsc.edu. cse.ucsc.edu. 1D IN NS fs1.cse.ucsc.edu. ;; ADDITIONAL SECTION: services.cse.ucsc.edu. 1D IN A fs1.cse.ucsc.edu. 1D IN A ;; Total query time: 89 msec ;; FROM: gslacks.cs.umass.edu to SERVER: default ;; WHEN: Thu Apr 12 08:25: ;; MSG SIZE sent: 34 rcvd: 153 qr: query packet aa: authoritative answer rd: recursion desired ra: recursion available

11 Second query: cached gslacks[pts/3]:~> dig ; > DiG 8.2 > ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUERY SECTION: ;; type = A, class = IN ;; ANSWER SECTION: 23h59m57s IN CNAME ftp.cse.ucsc.edu. ftp.cse.ucsc.edu. 23h59m57s IN A ;; AUTHORITY SECTION: cse.ucsc.edu. 15h54m19s IN NS services.cse.ucsc.edu. cse.ucsc.edu. 15h54m19s IN NS fs1.cse.ucsc.edu. ;; ADDITIONAL SECTION: services.cse.ucsc.edu. 15h54m19s IN A fs1.cse.ucsc.edu. 15h54m19s IN A ;; Total query time: 1 msec ;; FROM: gslacks.cs.umass.edu to SERVER: default ;; WHEN: Thu Apr 12 08:25:

12 Zone transfer r Name servers for a zone m Primary master name server: reads zone data from a file on its host m Secondary master (slave) name server: gets zone data from another name server that is authoritative for the zone r Zone transfer: When a slave name server starts up, it contacts its master server and pulls the zone data over

13 Zone transfer to get a list of all machines in a domain > dumb.target.jay axfr ; transfer zone dumb.target.jay from ; > DiG 8.2 dumb.target.jay axfr ; (1 server found) $ORIGIN 20H IN SOA ns1 hostmaster.dumb.target.jay ( ; serial 5H ; refresh 1H ; retry 4d4h ; expire 1D ) ; minimum 1H IN NS dumb.target.jay. 20H IN NS ns.dumb.target.jay. 20H IN NS ns.dumbs.isp. 20H IN A D IN HINFO "Pentium 133" "Red Hat 6.1" 1D IN MX 10 mail mail 1D IN A really 1D IN A D IN TXT "Admin's Trusted Workstation" 1D IN HINFO "Athlon 850" "Red Hat 6.1" rather 1D IN A D IN HINFO "Pentium 266" "Mandrake 7.1" serious 1D IN CNAME extra extra 1D IN A ns 1D IN A r_g 1D IN A roblimo 1D IN MX 10 r_g 1D IN A tahara 1D IN A

14 BIND r Be careful not announce what version of bind you are running when answering queries <- security by obscurity. r In unix, DNS is handled by the BIND package, and a program called “named”  Configuration of the daemon is kept in /etc/named.conf

15 /etc/named.conf // Config file for caching only name server options { directory "/var/named"; version “hackerz must die” allow-transfer { }; Your secondary server }; zone "." in { type hint; file "root.hints"; root name server hints }; zone “foobar.brian.edu” in { For converting from name to address type master file “pz/db.foobar.brian.edu” zone ” in-addr.arpa" in { For converting from address to name type master; file "pz/db "; }; More on this in a minute...

16 Normal Operation r Normally, DNS is resolved with an authoritative server. r (Not shown is lookup to.com root server) dns.hacker.com user.victim.com Result cached dns.victim.com resolving

17 DNS Cache Poisoning r URL spoofing attack: m register a similar name of someone you are attacking m e.g., … r Cache poisoning is a more sophisticated version of the same idea. r The two key ideas we will take advantage of are: m The query number (and reply id) are often predictable if you can learn earlier IDs. m DNS caches previous results

18 Old Version of the Attack r On older versions of BIND, replies that came in could include additional lookup information. r This additional lookup information would be stored for future use. r The next time a user from victim.com looks for the bank, it will be redirected to the hacker’s site. r All the hacker has to do is create a mock-up of the banks site to get passwords, etc. dns.hacker.com foo.hacker.com dns.victim.com user.victim.com hacker.com=x.x.x.x dns query: hacker.com? result cached

19 Old Version of the Attack r On older versions of BIND, replies that came in could include additional lookup information. r This additional lookup information would be stored for future use. r The next time a user from victim.com looks for the bank, it will be redirected to the hacker’s site. r All the hacker has to do is create a mock-up of the banks site to get passwords, etc. dns.hacker.com dns.victim.com user.victim.com result cached

20 More attacks r The old attack no longer work since BIND was patched to ignore additional information provided in the reply. r However, a more complex version of the attack still works.

21 The Attack r The first step of the attack is to learn victim.com’s current query id number. r The simplest way to do that is to get the victim to query the attacker’s DNS machine. r A simple method is to query the victim’s (shown left) r Or, if victim.com sends its queries recursively through a 3rd dns machine, attack the 3rd machine. dns.hacker.com foo.hacker.com dns.victim.com user.victim.com dns query: hacker.com? query id stored

22 The Attack r If the attack has queries sent to it’s own domain, that leaves a trace. r Smarter attackers will compromise some remote authoritative name server. r This querying can be repeated many times to get an idea of how the query ids change over time. dns.hacker.com foo.hacker.com dns.victim.com user.victim.com dns query: hacker.com? query id stored

23 The Attack r If the attack has queries sent to it’s own domain, that leaves a trace. r Smarter attackers will compromise some remote authoritative name server. r This querying can be repeated many times to get an idea of how the query ids change over time. dns.hacker.com foo.hacker.com dns query: bank.com? query id stored (correct query ID) dns.victim.com user.victim.com result cached

24 The Attack r Just as before, the cached result is used to avoid performing an expensive DNS lookup. r The victim is directed towards hacker.com r Can do this to banks, newspapers, etc. dns.hacker.com dns.victim.com user.victim.com result cached

25 Defenses r New versions of BIND have harder to predict query IDs. r DNSSEC (RFC 2535) is a secure version of DNS with RSA signed DNS records. r You could use a secure connection to your bank. r Split-split defense: m One DNS server for resolving names for users inside your domain; this server doesn’t respond to outside queries at all. m Another separate DNS server is setup for responding to queries from outsiders. m The two never exchange information. Your users never are subject to poisoned information.

26 Defenses in /etc/named.conf // Config file for caching only name server options { directory "/var/named"; version “hackerz must die” allow-transfer { }; allow-query { any; }; allow-recursion { /24; }; }; zone “foobar.brian.edu” in { type master file “pz/db.foobar.brian.edu” allow-query { /24; } }; zone ” in-addr.arpa" in { type master; file "pz/db "; allow-query { /24; } }; Zone specific ACL: take precedence over a global ACL Global access control list (ACL): Only this subnet can query us