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-authoritative answer.

DNS Protocol Refresher

Cache Poisoning - MotivationCorrupt cache mapping: URL ???Why? Redirect web traffic (DOS):

www.google.com www.myPopUps.com www.whitehouse.gov www.. . o... omabc

Man-in-the-Middle Attack

www.USBankLogin.com www.U.. n.Lo n. oma gi c

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 BIND Birthday 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.

Phase Space of BIND 8.3.4

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).

Phase Space of BIND 9

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.

Phase Space for djbdns

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.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.

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/

Questions?