200 likes | 329 Views
DNS Cache Poisoning – The Next Generation by Joe Stewart, GCIH Presented by Stephen Karg CS510, Advanced Security Portland State University Oct. 24, 2005. Domain Name System: a Quick Review. URL IP mapping Hierarchical in nature, subdivided by domains and sub-domains.
E N D
DNS Cache Poisoning – The Next Generation by Joe Stewart, GCIH Presented by Stephen Karg CS510, Advanced Security Portland State University Oct. 24, 2005
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-authoritativeanswer.
Cache Poisoning - Motivation Corrupt cache mapping: URL ??? Why? • Redirect web traffic (DOS): www.google.com www.myPopUps.com www.whitehouse.gov www.Playboy.com • Man-in-the-Middle Attack www.USBankLogin.com www.USBankLogin.com www.MyPhishingSite.com
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.
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 1st 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.
Birthday Attack (n queries) vs. Conventional Spoofing (1 query)
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)
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.
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).
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.
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.
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?)
ISP Nameserver Defenses • Upgrade BIND to 9.xseries, 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.
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/