11Security Analysis of DNS &Applications/EmailEE 122: Intro to Communication NetworksFall 2007 (WF 4-5:30 in Cory 277)Vern PaxsonTAs: Lisa Fowler, Daniel Killebrew & Jorge Ortizhttp://inst.eecs.berkeley.edu/~ee122/Materials with thanks to Jennifer Rexford, Ion Stoica,and colleagues at Princeton and UC Berkeley2Announcements• Next Wednesday’s lecture will be given by Lisa• I won’t have my usual 3-4PM office hours nextWednesday, but will be available at the usual 3-4PM slot on Friday …– … as well as by appointment via email (as always)• Reminder: first phase of Project #1 due nextWednesday by 11PM– The writeup has been updated for clarity, see mailing listarchives for “diffs”• Thanksgiving week: I’ll give the same lecture twice,Mon 4-5:30PM (room TBD) and Weds (usual)3Goals of Today’s Lecture• Finish discussion of the workings of DNS• DNS security analysis• Applications in general …• … and Email in particular4unix> dig +norecurse @a.root-servers.net in-addr.arpa ns; <<>> DiG 9.3.4 <<>> +norecurse @a.root-servers.net in-addr.arpa ns; (1 server found);; global options: printcmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62001;; flags: qr aa; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 12;; QUESTION SECTION:;in-addr.arpa. IN NS;; ANSWER SECTION:in-addr.arpa. 86400 IN NS G.ROOT-SERVERS.NET.in-addr.arpa. 86400 IN NS H.ROOT-SERVERS.NET.in-addr.arpa. 86400 IN NS I.ROOT-SERVERS.NET.in-addr.arpa. 86400 IN NS K.ROOT-SERVERS.NET.in-addr.arpa. 86400 IN NS L.ROOT-SERVERS.NET.in-addr.arpa. 86400 IN NS M.ROOT-SERVERS.NET.in-addr.arpa. 86400 IN NS A.ROOT-SERVERS.NET.in-addr.arpa. 86400 IN NS B.ROOT-SERVERS.NET.in-addr.arpa. 86400 IN NS C.ROOT-SERVERS.NET.in-addr.arpa. 86400 IN NS D.ROOT-SERVERS.NET.in-addr.arpa. 86400 IN NS E.ROOT-SERVERS.NET.in-addr.arpa. 86400 IN NS F.ROOT-SERVERS.NET.5unix> dig +norecurse @a.root-servers.net -x 64.236.24.12;; QUESTION SECTION:;12.24.236.64.in-addr.arpa. IN PTR;; AUTHORITY SECTION:64.in-addr.arpa. 86400 IN NS dill.ARIN.NET.64.in-addr.arpa. 86400 IN NS BASIL.ARIN.NET.64.in-addr.arpa. 86400 IN NS henna.ARIN.NET.64.in-addr.arpa. 86400 IN NS indigo.ARIN.NET.64.in-addr.arpa. 86400 IN NS epazote.ARIN.NET.64.in-addr.arpa. 86400 IN NS figwort.ARIN.NET.64.in-addr.arpa. 86400 IN NS chia.ARIN.NET.(no ADDITIONAL section);; Query time: 93 msec;; SERVER: 198.41.0.4#53(198.41.0.4);; WHEN: Thu Sep 20 23:50:49 2007;; MSG SIZE rcvd: 1946unix> dig +norecurse @dill.arin.net -x 64.236.24.12;; QUESTION SECTION:;12.24.236.64.in-addr.arpa. IN PTR;; AUTHORITY SECTION:236.64.in-addr.arpa. 86400 IN NS dns-02.atdn.net.236.64.in-addr.arpa. 86400 IN NS dns-01.atdn.net.unix> dig +norecurse @dns-02.atdn.net -x 64.236.24.12;; QUESTION SECTION:;12.24.236.64.in-addr.arpa. IN PTR;; ANSWER SECTION:12.24.236.64.in-addr.arpa. 3600 IN PTR www3.cnn.com.;; AUTHORITY SECTION:24.236.64.in-addr.arpa. 3600 IN NS dns-02.atdn.net.24.236.64.in-addr.arpa. 3600 IN NS dns-01.atdn.net.;; ADDITIONAL SECTION:dns-01.atdn.net. 3600 IN A 64.12.51.136dns-02.atdn.net. 3600 IN A 205.188.157.23627Inserting Resource Records into DNS• Example: just created startup “FooBar”• Get a block of address space from ISP– Say 212.44.9.128/25• Register foobar.com at Network Solutions (say)– Provide registrar with names and IP addresses of yourauthoritative name server (primary and secondary)– Registrar inserts RR pairs into the com TLD server:o (foobar.com, dns1.foobar.com, NS)o (dns1.foobar.com, 212.44.9.129, A)• Put in your (authoritative) serverdns1.foobar.com:– Type A record for www.foobar.com– Type MX record for foobar.com8Setting up foobar.com, con’t• In addition, need to provide reverse PTR bindings– E.g., 212.44.9.129 → dns1.foobar.com• Normally, these would go in 9.44.212.in-addr.arpa• Problem: you can’t run the name server for thatdomain. Why not?– Because your block is 212.44.9.128/25, not212.44.9.0/24– And whoever has 212.44.9.0/25 won’t be happy with youowning their PTR records• Solution: ISP runs it for you– Now it’s more of a headache to keep it up-to-date :-(9Questions(type, class, domain name)Answers(variable # of resource records)Authority(variable # of resource records)# Authority RRs # Additional RRsIdentification Flags# Questions # Answer RRs16 bits 16 bitsSecurity Analysis of DNS• What security issues does the design & operationof the Domain Name System raise?• Degrees of freedom:Additional information(variable # of resource records)10Security Problem #1: Starbucks• As you sip your latte and surf the Web, how doesyour laptop find google.com?• Answer: it asks the local name server per DynamicHost Configuration Protocol (DHCP) …– … which is run by Starbucks or their contractor– … and can return to you any answer they please– … including a “man in the middle” site that forwards yourquery to Google, gets the reply to forward back to you,yet can change anything they wish in either direction• How can you know you’re getting correct data?– Today, you can’t. (Though if site is HTTPS, that helps)– One day, hopefully: DNSSEC extensions to DNS11Security Problem #2: Cache Poisoning• Suppose you are a Bad Guy and you control thename server for foobar.com. You receive a requestto resolve www.foobar.com and reply:;; QUESTION SECTION:;www.foobar.com. IN A;; ANSWER SECTION:www.foobar.com. 300 IN A 212.44.9.144;; AUTHORITY SECTION:foobar.com. 600 IN NS dns1.foobar.com.foobar.com. 600 IN NS google.com.;; ADDITIONAL SECTION:google.com. 5 IN A 212.44.9.155A foobar.com machine, not google.comEvidence of the attackdisappears 5 seconds later!12Cache Poisoning, con’t• Okay, but how do you get the victim to look upwww.foobar.com in the first place?• Perhaps you connect to their mail server and send– HELO www.foobar.com– Which their mail server then looks up to see if itcorresponds to your source address (anti-spammeasure)• Note, with compromised name server we can alsolie about PTR
View Full Document