14
DNS Poisonin g Attacks November 2005 John (Jenya) Neystadt Security Test Lead Microsoft Israel R&D

DNS Poisoning Attacks November 2005 John (Jenya) Neystadt Security Test Lead Microsoft Israel R&D

Embed Size (px)

Citation preview

DNS PoisoningAttacks

November 2005John (Jenya) Neystadt

Security Test LeadMicrosoft Israel R&D

Internet: AuthoritiveDNS Servers

A Short Overview on DNS

Resolver: gethostbyname(www.microsoft.com)

Server: www.microsoft.c

om is 1.2.3.4

Client

CachingDNS Server

dns.microsoft.com

dns.hacker.com

A Simple Attack – Sending Additional Resource Records

gethostbyname(www.hacker.com)

www.hacker.com is 1.2.3.4

And www.microsoft.com is 5.5.5.5

Server

DNS Cache:www.hacker.com = 1.2.3.4www.microsoft.com = 5.5.5.5

Client

An Even Easier Attack – Just Lying

gethostbyname(www.microsoft.com)

www.microsoft.com is 6.6.6.6

Server

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.

PRNG Attack

gethostbyname(www.microsoft.com)

Server

www.microsoft.com is 6.6.6.6

I don’t know…I better ask

somebody else

www.micr

osof

t.com

is 1

.2.3

.4

geth

ostb

ynam

e(www.m

icros

oft.c

om)

First answer wins!

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.6www.microsoft.com 6.6.6.6

www.microsoft.com 6.6.6.6www.microsoft.com 6.6.6.6

www.microsoft.com 6.6.6.6www.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 to 1

• 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