270 likes | 276 Views
Lecture A.3: DNS Security. Domain Name Service Security Problems in DNS. Domain : a subtree of a domain name space Zone : some part of the domain name space Name servers generally have complete information about a zone Distributed management thru delegation. DNS name service.
E N D
Lecture A.3: DNS Security • Domain Name Service • Security Problems in DNS
Domain: a subtree of a domain name space Zone: some part of the domain name space Name servers generally have complete information about a zone Distributed management thru delegation DNS name service
Distributed database: no server has all name-to-IP address mappings local name servers: each ISP, company has local (default) name server host DNS query first goes to local name server authoritative name server: for a host: stores that host’s IP address, name can perform name/address translation for that host’s name DNS name servers root name server: • contacted by local name server that can not resolve name • contacts authoritative name server if name mapping not known • gets mapping • returns mapping to local name server • dozen root name servers worldwide
Resolver: queries the name server interpret the responses return result to user recursive query: puts burden of name resolution on contacted name server heavy load? iterated query: contacted server replies with name of server to contact “I don’t know this name, but ask this server” local name server dns.eurecom.fr intermediate name server dns.umass.edu DNS: iterated queries root name server iterated query 2 3 4 7 5 6 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu
once (any) name server learns mapping, it caches mapping cache entries timeout (disappear) after some time update/notify mechanisms under design by IETF RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html DNS: caching and updating records
DNS: distributed db storing resource records (RR) 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) DNS records • Type=CNAME • name is an alias name for some “cannonical” (the real) name • value is cannonical name • Type=A • name is hostname • value is IP address • Type=MX • value is hostname of mailserver associated with name
DNS protocol :queryand reply messages, both with same message format DNS protocol, messages msg header • identification: 16 bit # for query, reply to query uses same # • flags: • query or reply • recursion desired • recursion available • reply is authoritative
DNS protocol, messages Name, type fields for a query RRs in reponse to query records for authoritative servers additional info that supplements other sections
Troubleshooting tools for DNS nslookup 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 dig @a.root-servers.net ns . ; queries a.root-servers.net ; for NS records for . domain DNS query
First query: authoritative gslacks[pts/3]:~> dig www.cse.ucsc.edu ; <<>> DiG 8.2 <<>> www.cse.ucsc.edu ;; 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: ;; www.cse.ucsc.edu, type = A, class = IN ;; ANSWER SECTION: www.cse.ucsc.edu. 1D IN CNAME ftp.cse.ucsc.edu. ftp.cse.ucsc.edu. 1D IN A 128.114.48.173 ;; 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 128.114.48.10 fs1.cse.ucsc.edu. 1D IN A 128.114.48.11 ;; Total query time: 89 msec ;; FROM: gslacks.cs.umass.edu to SERVER: default -- 128.119.240.1 ;; WHEN: Thu Apr 12 08:25:04 2001 ;; MSG SIZE sent: 34 rcvd: 153 qr: query packet aa: authoritative answer rd: recursion desired ra: recursion available
Second query: cached gslacks[pts/3]:~> dig www.cse.ucsc.edu ; <<>> DiG 8.2 <<>> www.cse.ucsc.edu ;; 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: ;; www.cse.ucsc.edu, type = A, class = IN ;; ANSWER SECTION: www.cse.ucsc.edu. 23h59m57s IN CNAME ftp.cse.ucsc.edu. ftp.cse.ucsc.edu. 23h59m57s IN A 128.114.48.173 ;; 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 128.114.48.10 fs1.cse.ucsc.edu. 15h54m19s IN A 128.114.48.11 ;; Total query time: 1 msec ;; FROM: gslacks.cs.umass.edu to SERVER: default -- 128.119.240.1 ;; WHEN: Thu Apr 12 08:25:07 2001
Name servers for a zone Primary master name server: reads zone data from a file on its host Secondary master (slave) name server: gets zone data from another name server that is authoritative for the zone Zone transfer: When a slave name server starts up, it contacts its master server and pulls the zone data over Zone transfer
Zone transfer to get a list of all machines in a domain > dig @192.168.1.85 dumb.target.jay axfr ; transfer zone dumb.target.jay from 192.168.1.85 ; <<>> DiG 8.2 <<>> @192.168.1.85 dumb.target.jay axfr ; (1 server found) $ORIGIN dumb.target.jay. @ 20H IN SOA ns1 hostmaster.dumb.target.jay ( 2000111001 ; 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 192.168.1.85 1D IN HINFO "Pentium 133" "Red Hat 6.1" 1D IN MX 10 mail mail 1D IN A 192.168.1.2 really 1D IN A 192.168.1.20 1D IN TXT "Admin's Trusted Workstation" 1D IN HINFO "Athlon 850" "Red Hat 6.1" rather 1D IN A 192.168.1.15 1D IN HINFO "Pentium 266" "Mandrake 7.1" serious 1D IN CNAME extra extra 1D IN A 192.168.1.80 ns 1D IN A 192.168.1.30 r_g 1D IN A 192.168.1.68 roblimo 1D IN MX 10 r_g 1D IN A 192.168.1.44 tahara 1D IN A 192.168.1.27
BIND • Be careful not announce what version of bind you are running when answering queries <- security by obscurity. • In unix, DNS is handled by the BIND package, and a program called “named” • Configuration of the daemon is kept in /etc/named.conf
/etc/named.conf // Config file for caching only name server options { directory "/var/named"; version “hackerz must die” allow-transfer {192.154.1.30}; 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 ”1.154.192.in-addr.arpa" in { For converting from address to name type master; file "pz/db.192.154.1"; }; More on this in a minute...
dns.victim.com Result cached 2 3 4 1 user.victim.com 5 www.bank.com Normal Operation dns.hacker.com • Normally, DNS is resolved with an authoritative server. • (Not shown is lookup to .com root server) resolving www.bank.com
DNS Cache Poisoning • URL spoofing attack: • register a similar name of someone you are attacking • e.g., www.ibn.com, … • Cache poisoning is a more sophisticated version of the same idea. • The two key ideas we will take advantage of are: • The query number (and reply id) are often predictable if you can learn earlier IDs. • DNS caches previous results
foo.hacker.com dns.victim.com user.victim.com www.bank.com Old Version of the Attack dns.hacker.com • On older versions of BIND, replies that came in could include additional lookup information. • This additional lookup information would be stored for future use. • The next time a user from victim.com looks for the bank, it will be redirected to the hacker’s site. • All the hacker has to do is create a mock-up of the banks site to get passwords, etc. dns query: hacker.com? hacker.com=x.x.x.x www.bank.com=x.x.x.x result cached dns query: hacker.com?
www.hacker.com dns.victim.com user.victim.com www.bank.com Old Version of the Attack dns.hacker.com • On older versions of BIND, replies that came in could include additional lookup information. • This additional lookup information would be stored for future use. • The next time a user from victim.com looks for the bank, it will be redirected to the hacker’s site. • All the hacker has to do is create a mock-up of the banks site to get passwords, etc. result cached
More attacks • The old attack no longer work since BIND was patched to ignore additional information provided in the reply. • However, a more complex version of the attack still works.
dns query: hacker.com? dns.hacker.com foo.hacker.com dns query: hacker.com? www.bank.com The Attack query id stored • The first step of the attack is to learn victim.com’s current query id number. • The simplest way to do that is to get the victim to query the attacker’s DNS machine. • A simple method is to query the victim’s (shown left) • Or, if victim.com sends its queries recursively through a 3rd dns machine, attack the 3rd machine. dns.victim.com user.victim.com
dns query: hacker.com? dns.hacker.com foo.hacker.com dns query: hacker.com? www.bank.com The Attack query id stored • If the attack has queries sent to it’s own domain, that leaves a trace. • Smarter attackers will compromise some remote authoritative name server. • This querying can be repeated many times to get an idea of how the query ids change over time. dns.victim.com user.victim.com
dns.hacker.com foo.hacker.com www.bank.com=x.x.x.x(correct query ID) dns query: bank.com? dns query: bank.com? www.bank.com The Attack query id stored • If the attack has queries sent to it’s own domain, that leaves a trace. • Smarter attackers will compromise some remote authoritative name server. • This querying can be repeated many times to get an idea of how the query ids change over time. result cached dns.victim.com user.victim.com
www.hacker.com dns.victim.com user.victim.com www.bank.com The Attack dns.hacker.com • Just as before, the cached result is used to avoid performing an expensive DNS lookup. • The victim is directed towards hacker.com • Can do this to banks, newspapers, etc. result cached
Defenses • New versions of BIND have harder to predict query IDs. • DNSSEC (RFC 2535) is a secure version of DNS with RSA signed DNS records. • You could use a secure connection to your bank. • Split-split defense: • One DNS server for resolving names for users inside your domain; this server doesn’t respond to outside queries at all. • Another separate DNS server is setup for responding to queries from outsiders. • The two never exchange information. Your users never are subject to poisoned information.
Defenses in /etc/named.conf // Config file for caching only name server options { directory "/var/named"; version “hackerz must die” allow-transfer {192.154.1.30}; allow-query { any; }; allow-recursion { 192.154.1.0/24; }; }; zone “foobar.brian.edu” in { type master file “pz/db.foobar.brian.edu” allow-query { 192.154.1.0/24; } }; zone ”1.154.192.in-addr.arpa" in { type master; file "pz/db.192.154.1"; allow-query { 192.154.1.0/24; } }; Global access control list (ACL): Only this subnet can query us Zone specific ACL: take precedence over a global ACL