140 likes | 638 Views
DNS Poisoning Attacks. November 2005 John (Jenya) Neystadt Security Test Lead Microsoft Israel R&D. A Short Overview on DNS. Internet: Authoritive DNS Servers. dns.hacker.com. dns.microsoft.com. Caching DNS Server. Resolver: gethostbyname(www.microsoft.com).
E N D
DNS PoisoningAttacks November 2005 John (Jenya) Neystadt Security Test Lead Microsoft Israel R&D
A Short Overview on DNS Internet: AuthoritiveDNS Servers dns.hacker.com dns.microsoft.com CachingDNS Server Resolver: gethostbyname(www.microsoft.com) Server: www.microsoft.com is 1.2.3.4 Client
A Simple Attack – Sending Additional Resource Records Server gethostbyname(www.hacker.com) www.hacker.com is 1.2.3.4 And www.microsoft.com is 5.5.5.5 DNS Cache: www.hacker.com = 1.2.3.4 www.microsoft.com = 5.5.5.5 Client
An Even Easier Attack – Just Lying Server gethostbyname(www.microsoft.com) www.microsoft.com is 6.6.6.6 Client
The Problem • DNS is not a secure protocol • Every host on the internet can claim that it is an authority for resolving queries • Even if a DNS server is authoritative for domain A, it does not mean it can be trusted to give true answers for domain B • All answers are assumed to be true
Other Protocols in the TCP/IP Protocol Suite • DHCP – non-secure • HTTPS – secure
More Sophisticated Attacks • PRNG Vulnerability • The Birthday Attack • Both attacks relay on the “First answer wins” property
Query ID • Each DNS query contains an ID • A response contains the matching query ID • The ID is generated by a PRNG • In most past implementations the ID was generated by a weak PRNG function.
I don’t know… I better ask somebody else PRNG Attack First answer wins! gethostbyname(www.microsoft.com) www.microsoft.com is 1.2.3.4 gethostbyname(www.microsoft.com) Server www.microsoft.com is 6.6.6.6 Client
PRNG Attack (cont) • In older systems it was possible to predict the next PRNG number by observing only the last number generated. • In newer systems it is possible to predict the next number with success probability of 0.2 by observing the last 5000 numbers. • Much better, but still not perfect.
The Birthday Attack Gethostbyname(www.microsoft.com) Gethostbyname(www.microsoft.com) Gethostbyname(www.microsoft.com) Gethostbyname(www.microsoft.com) Gethostbyname(www.microsoft.com) Gethostbyname(www.microsoft.com) Gethostbyname(www.microsoft.com) Gethostbyname(www.microsoft.com) Gethostbyname(www.microsoft.com) Gethostbyname(www.microsoft.com) Gethostbyname(www.microsoft.com) Gethostbyname(www.microsoft.com) www.microsoft.com 6.6.6.6 www.microsoft.com 6.6.6.6 www.microsoft.com 6.6.6.6 www.microsoft.com 6.6.6.6 www.microsoft.com 6.6.6.6 www.microsoft.com 6.6.6.6
The Birthday Attack (cont) • Based on the mathematical phenomena called The Birthday Paradox: • If there are 23 people in the room, the probability that you share the same birthday with another person is at most 23/365. • But, what is the probability that 2 persons share same birthday? It is greater than 0.5! • The problem is that the server generates a recursive query for each of the client’s queries • This vulnerability has nothing to do with the strength of the PRNG function. • There are many DNS servers that are still vulnerable to this attack, including Microsoft’s implementation.
The Birthday Attack (cont) • The probability of succeeding in the birthday attack while sending 700 queries is very close to1 • The probability of succeeding with just sending 700 packets is 0.01
How Can Be done to Mitigate the Attack? • Firewalls: • Truncate packets with additional resource records • How should it deal with the birthday attack? • How should it deal with the PRNG vulnerability attack? • Deployment • “Split DNS”, protect your network caching DNS server from Man-in-the-Middle attacks