DNS Cache Poisoning

History

• 1993 – DNS protocol allowed attacker to inject false data which was then cached

• 1997 – BIND 16-bit transaction ids not randomized, easily guessable

• 2002 – BIND sends multiple recursive queries simultaneously, birthday paradox

• 2003 – BIND PRNG not very random

Basic DNS

• Client queries local nameserver

• Local nameserver queries root nameserver for authoritative nameservers for some domain

• Local nameserver queries authoritative nameserver

• Returns result to client

Problem

• DNS request sends transaction Id

• DNS will accepts any reply containing transaction and assuming remote IP and TCP/UDP ports match

• Transaction Ids are only 16-bits

Birthday Attack

• BIND sends multiple queries for the same domain name

• Possible to flood BIND with replies using randomly generated transaction Ids

• If you guess correctly, then BIND will accept your reply

• ~50% with 300 packets, • ~100% with 700 packets

TCP/UDP port

• BIND reused same source TCP/UDP port

• Made it easy for attacker to “guess” the destination TCP/UDP port for the false reply

• Newer versions randomize source ports

Phase Space Analysis

• Determine how random PRNG is

• BIND 8.4.3 – predict next transaction id with only 3 previous ids

• BIND 9 – better, but still predictable (~20% with 5000 spoofed replies)

Why DNS Cache Poisoning?

• Redirect traffic

• MITM attacks

Defenses

• Upgrade to BIND 9.x

• Split-split DNS– Internal DNS performs recursive queries for

users, and cannot be accessed from outside– External DNS does not do recursive queries– Makes it harder for attacker to guess what

transaction Ids your external DNS will use