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