thedns scareof 2008 - terena...9 draft-ietf-dnsext-forgery-resilience state of the game in 2008 an...

Otmar Lendl18. September 2008

The DNS Scare of 2008

What was it all about and how didAustria react?

Otmar Lendl <[email protected]>

2

Content

� The bug� Background on DNS forgeries� What was new

� Austria reacts to VU#800113� Patch statistics

� What are the long-term solutions?� Various ideas

3

The DNS

� Global, distributed Database� Input: Domain name� Output: Resource Record Sets

� A, AAA IP addresses� MX Mail routing� CNAME Aliasing� NS Delegation� PTR, NAPTR, SRV, � RRSIG, DS, NSEC, NSEC3

� Transport: mainly UDP� Lot’s of caching

You all know that

You all know that

You all know that

You all know that alreayalreayalreayalreay …………

4

The players

� Authoritative Nameservers� Recursive Nameservers� Stub Resolvers

stub Recursor

AuthAuth

AuthAuth

AuthAuth

AuthCache

5

DNS Spoofing

Recursor

Auth

Query

Recursor

Auth

Answer

Attacker

Forged Answer

Tim

e

6

Details: DNS Protocol

$ dig cert.at MX

[…]

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8861

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:

;cert.at. IN MX

;; ANSWER SECTION:

cert.at. 7200 IN MX 100 nuwen.cert.at.

;; AUTHORITY SECTION:

cert.at. 6450 IN NS ns1 .cert.at.

cert.at. 6450 IN NS ns5 .univie.ac.at.

;; ADDITIONAL SECTION:

nuwen.cert.at. 7200 IN A 83. 136.33.135

7

Security?

$ dig cert.at MX

[…]

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8861

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1


;cert.at. IN MX

;; ANSWER SECTION:

cert.at. 7200 IN MX 100 nuwen.cert.at.


cert.at. 6450 IN NS ns1 .cert.at.

cert.at. 6450 IN NS ns5 .univie.ac.at.


nuwen.cert.at. 7200 IN A 83. 136.33.135

This is the safety net

16 bits of entropy might 16 bits of entropy might 16 bits of entropy might 16 bits of entropy might have been enough in have been enough in have been enough in have been enough in 1987, but not in 2008.1987, but not in 2008.1987, but not in 2008.1987, but not in 2008.

8

Bailiwick checks

� Legitimate Servers can play games, too.

� What stops a server from adding?

� “in-bailiwick checks”: only accept what you were asking for. See RFC 2181 for details.


nuwen.cert.at. 7200 IN A 83. 136.33.135


nuwen.cert.at. 7200 IN A 83. 136.33.135

xxx. 50000 IN NS ns1 .cert.at.

xxx. 50000 IN NS ns2 .cert.at.

9

draft-ietf-dnsext-forgery-resilience

� State of the game in 2008� An attack needs to match

1. The question section of the reply packet is equivalent to that of a question packet currently waiting for a response

2. The ID field of the reply packet matches that of the question packet

3. The response comes from the same network address the question was sent to

4. The response comes in on the same network address, including port number, as the question was sent from

� Calculations on forgery success probabilities

10

Attacks on the ID

� A good PRNG is needed� Older Bind versions simply incremented� Good entropy isn’t that easy

� Avoid multiple outstanding requests for the same question� n queries * m forgeries give good odds for

the attacker.

11

TTL to the rescue?

� How often can an attack take place?� Forcing a query helps the attacker.� One attack per TTL

� “The calculations above indicate the relative ease with which DNS data can be spoofed. For example, using the formula derived earlier on an RRSet with a 3600 second TTL, an attacker sending 7000 fake response packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a record in the first 24 hours, which rises to 50% after a week.”

12

Summary pre-Kaminsky

� Entropy from ID (16) and server (2) is barely enough.

� Recommendations:� Use Source Port Randomization to get

another 15 bits.� Make sure you don’t mess up the entropy

13

July 8th, 2008: VU#800113

� Dire Warning� Insufficient entropy in ID� Multiple outstanding requests� Fixed source port

� Recommendation� Update� Implement Source Port Randomization� Restrict Recursion� Filter spoofed IP traffic

14

What happened?

� RFC 3833, 2.3 proved to be right� “Perhaps the most interesting class of DNS-

specific threats are the name chaining attacks. These are a subset of a larger class of name-based attacks, sometimes called "cache poisoning" attacks.“

� The TTL wall had been broken.� Idea: don’t attack the Domain itself, go for

random hostnames within the target domain.○ A way to initiate recursion is needed.

15

Example 1


;345678.example.org. IN A

;; ANSWER SECTION:

345678.example.org. 3600 IN A 192.0.2.1


example.org. 3600 IN NS evil1.example.net .

example.org. 3600 IN NS evil2.example.net .

Source: IETF namedroppers list. (P. Koch, T. Finch)

16

Example 2



;; ANSWER SECTION:

345678.example.org. A 192.0.2.1


example.org. NS 345678.example.org.

17

Example 3


;345678.www.example.org. A


www.example.org. NS evil1.example.net.

www.example.org. NS evil2.example.net.

18

Example 4


;345678.www.example.org. A


www.example.org. NS evil.example.net.


evil.example.net. A 192.0.2.53

19

Example 5



;; ANSWER SECTION:

345678.example.org. CNAME www.example.org.

www.example.org. A 192.0.2.80 ; evil

20

Potential Damage

� Man-in-the-middle *everything*� Phishing� Email hijacking

� DoS� Password reset emails� What about SSL?

� CA email-loop � CA whois lookup

21

CERT.at Reaction

� Warnings on all channels� Wait a second …

� the patch changes the query pattern� resolver in Austria query for domains under

.at� we have query-logs of the .at nameservers � important resolvers ask for a lot of domains

We can monitor the patching progressWe can monitor the patching progressWe can monitor the patching progressWe can monitor the patching progress

22

Scoring Resolvers

23

Data set

� Query log of one server in Austria� ~ 10M queries / day (from Austrian IP space)� from ~ 13.000 IP addresses� ~2000 of which sent more than 100 queries� Known domain catchers / registrars excluded� Data starts with July 4th, i.e. before the

announcements

Thanks to Markus Heimhilcher from the .at nameserver management team!

24

Before ..

0

200

400

600

800

1000

1200

1400

0.05 0.15 0.25 0.35 0.45 0.55 0.65 0.75 0.85 0.95

score

coun

t

25

Patching by Server

0%

20%

40%

60%

80%

100%

04.07 .200806.07 .200808.07 .200810.07 .200812.07 .200814.07 .200816.07 .200818.07 .200820.07 .200822.07 .200824.07 .200826.07 .200828.07 .200830.07 .200801.08 .200803.08 .200805.08 .2008

0.95

0.85

0.75

0.65

0.55

0.45

0.35

0.25

0.15

0.05

Announcement

Exploit published

26

Long Term

0%

20%

40%

60%

80%

100%

04 .07 .200811 .07 .2 00818 .07 .200825 .07 .200801 .08 .200808 .08 .200815 .08 .200822 .08 .200829 .08 .200805 .09 .200812 .09 .200819 .09 .2008

0.95

0.85

0.75

0.65

0.55

0.45

0.35

0.25

0.15

0.05

27

By request, not by server:

0%

20%

40%

60%

80%

100%

04.07

.2008

11.07

.2008

18.07

.2008

25.07

.2008

01.08

.2008

08.08

.2008

15.08

.2008

22.08

.2008

29.08

.2008

05.09

.2008

12.09

.2008

19.09

.2008

0.95

0.85

0.75

0.65

0.55

0.45

0.35

0.25

0.15

0.05

28

Absolute numbers

0

2.000.000

4.000.000

6.000.000

8.000.000

10.000.000

12.000.000

04.07 .2008

11.07 .2008

18.07 .2008

25.07 .2008

01.08 .2008

08.08 .2008

15.08 .2008

22.08 .2008

29.08 .2008

05.09 .2008

12.09 .2008

19.09 .2008

0.95

0.85

0.75

0.65

0.55

0.45

0.35

0.25

0.15

0.05

Looks like a number of ISPs reworked their DNS setup over the summer.

29

Whither DNS?

� Source Port Randomization is a stopgap.

� Brings the time to exploit down from “oh sh*t, we’re f***ed” to “not really secure”

� So: what is the outlook? What can be done?

30

Categories

1. Get more entropy2. Changing resolver behavior3. Cooperation from both sides4. Changing the protocol5. Agile defenses

� See namedroppers list archive� draft-wijngaards-dnsext-resolver-side-

mitigation-00

31

More Entropy

� QID� Source port� Source Address

� IPv6!� Destination Address� 0x20

� Case is preserved, but not relevant

32

Resolver behavior

� Repeated Queries� Same server� Different servers

� Use TCP� Time spaced� New rules on how to trust information

� Never cache glue� Be careful when overwriting the cache� i.e. update the RFC 2181 rules

33

Cooperation

� TSIG� SIG(0)� IPsec

� DNSSEC

34

Protocol Changes

� More Entropy� EDNS ECHO

○ draft-hubert-ulevitch-edns-ping-00� Query name hacks

○ Prefixes / Postfixes○ http://www.jhsoft.com/dns-xqid.htm○ http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg015

55.html� QCount > 1� DNS Cookies

○ draft-eastlake-dnsext-cookies� More Crypto

� http://dnscurve.org/

All need protection against down-grade attacks

35

Agile Defense

� Some of the mitigation strategies carry a cost, thus:

1. Try to notice an attack� Many mismatches� Timing

2. React� Refuse to cache� Fallback to TCP� Multiple queries

36

Summary

� The DNS Scare was justified.� Patching is progressing slowly.� We’re far from a long-term solution

� Low-impact patches?� DNSSEC?

Questions ?

thedns scareof 2008 - terena...9 draft-ietf-dnsext-forgery-resilience state of the game in 2008 an...

Documents