1. DNS Cache Poisoning – The Next Generation by Joe Stewart, GCIH Presented by Stephen Karg CS510, Advanced Security Portland State University Oct. 24, 2005

2. Domain Name System: a Quick Review URL  IP mapping Hierarchical in nature, subdivided by domains and sub-domains. Distributed database of servers manage domain subsets (too large to centralize). We don’t want to work down the tree every time as root servers have a heavy load. So local name-server may often have cached hit. This is called a non-authoritative answer.

3. DNS Protocol Refresher

4. Cache Poisoning - Motivation Corrupt cache mapping: URL  ??? Why? Redirect web traffic (DOS): www.google.comwww.google.com  www.myPopUps.comwww.myPopUps.com www.whitehouse.gov  www.Playboy.com www.whitehouse.govwww.Playboy.com Man-in-the-Middle Attack www.USBankLogin.comwww.USBankLogin.com   www.USBankLogin.comwww.USBankLogin.com www.MyPhishingSite.com

5. Brief History 1993: First paper outlining several vulnerabilities in DNS, including the technique of cache poisoning. 1997: CERT releases advisory on BIND (used by virtually every name-server) vulnerability revolving around sequential transaction ID #’s. Newer versions now randomize. 2002: Discovered that BIND will send multiple recursive queries for same IP address, opening up 16-bit transaction ID#’s to Birthday attack or more savvy Phase-Space Analysis Spoofing attack.

6. The BIND Birthday Attack

7. The Birthday Attack Send n queries to vulnerable nameserver (for URL to hijack) while sending equal number of phony replies at the same time. Each spoofed reply packet has randomly generated transaction ID#. Attacker needs to win race between the 1 st successful collision of his spoofed transactions and the legitimate answer from the Authoritative NS.* 100% success probability @ n=700. * Can further slant race in attacker’s favor by flooding ANS with bogus packets to slow it down.

8. Birthday Attack (n queries) vs. Conventional Spoofing (1 query)

9. Successful Packet must match: Transaction ID (guessed) Source and destination IP addresses (easy) Destination port (always 53) Source port: BIND often reuses same source port for replies to the same client. tcpdump of DNS request to target ANS before attack should reveal this. An example: 10:54:12.423228 192.168.1.2.33748 > 66.218.71.63.53: 21345 [1au] A? www.yahoo.com. (42) (DF) 10:54:21.313293 192.168.1.2.33748 > 216.239.38.10.53: 53735 [1au] A? www.google.com. (43) (DF) 10:54:27.182852 192.168.1.2.33748 > 149.174.213.7.53: 19315 [1au] A? www.netscape.com. (45) (DF) 10:54:43.252461 192.168.1.2.33748 > 66.35.250.11.53: 43129 [1au] A? www.linux.com. (42) (DF)

10. Phase Space Analysis Spoofing Michael Zalewski's paper "Strange Attractors and TCP/IP Sequence Number Analysis" describes a method for analyzing the predictability of transaction IDs. Tools plot random number dumps into 3-D space, revealing clustering and exposing predictability. Geometric patterns are “attractors”. An ideal random number generator appears as an evenly dispersed cloud.

11. Phase Space of BIND 8.3.4

12. Attacking BIND 8.3.4 Limit spoofing set to attractors and greatly increase odds in Birthday attack. With phase space data, Zalewski’s second tool predicts next transaction ID# with 100% probability by looking at the 3 previous ID#s. So even if birthday attack patched, BIND 8 still vulnerable (no attack specifics in paper).

13. Phase Space of BIND 9

14. BIND 9 Uses completely new random number generating engine – /dev/random Trans. ID# predictable 20% of the time w/spoofing set of n=5000. Very high bandwidth required to win race with Authoritative NS unless combined with successful DOS attack on ANS.

15. Phase Space for djbdns

16. D.J. Bernstein DNS Despite nice looking “cloud”, randomness is actually slightly worse than BIND 9 (30% @ 5000). However, djbdns randomizes source ports of each query: 22:42:41.790753 192.168.1.2.16075 > 64.58.77.85.53: 36904 A? www.yahoo.com. (31) (DF) 22:42:53.876719 192.168.1.2.53928 > 216.239.38.10.53: 1776 A? www.google.com. (32) (DF) 22:43:07.996666 192.168.1.2.59368 > 207.200.73.80.53: 16261 A? www.netscape.com. (34) (DF) 22:43:18.290976 192.168.1.2.9183 > 66.35.250.10.53: 5110 A? www.linux.com. (31) (DF) Forces attacker to guess trans. ID# and source port of spoofed reply – approx. 1 billion possible id-port pairs.

17. Recommended Defenses Users Conform SSL certificates when making secure online transactions (man-in-the-middle) Use http://www.arin.net/whois/ if suspect site is being spoofed. Run own resolver and bypass ISP altogether! Web-Servers Can use SSL to authenticate self with browsers. Be on lookout for short DOS attacks (wipe cache?)

18. ISP Nameserver Defenses Upgrade BIND to 9.x series, rewritten from scratch with security in mind. Not vulnerable to this attack. Djbdns also more resilient to Birthday attacks. Divides NS responsibilities between two separate servers (resolver/advertiser). Public server disallows recursive queries, and recursive (caching) server firewalled. Drawback: expensive, more hardware and overhead. If can’t use split-split, use “listen-on” option to bind nameserver daemon to interface protected from outside world.

19. DNSSec DNS Security Extensions IETF working group Designed to counter Cache Poisoning dynamic DNS updates KEY/SIG records using RSA public keys zone authority may sign all DNS records http://www.dnssec.net/

20. Questions?