DNS: Victim or Attacker Paul Ebersman - - PowerPoint PPT Presentation

▶
dns victim or attacker
SMART_READER_LITE
LIVE PREVIEW

DNS: Victim or Attacker Paul Ebersman - - PowerPoint PPT Presentation

Jan 10, 2023 203 likes •578 views

DNS: Victim or Attacker Paul Ebersman Paul_Ebersman@cable.comcast.com, @paul_ipv6 ICANN49, 24 Mar 2014, Singapore 1 Attacking your cache 2 Recursion DNS queries are either recursive or nonrecursive 2) Nonrecursive query recursive for

slide-1
SLIDE 1

DNS: Victim or Attacker

Paul Ebersman Paul_Ebersman@cable.comcast.com, @paul_ipv6 ICANN49, 24 Mar 2014, Singapore

1

slide-2
SLIDE 2

Attacking your cache

2

slide-3
SLIDE 3

Recursion

DNS queries are either recursive or nonrecursive

root name server resolver com name server google.com name server

1) Recursive query for www.google.com/ A 2) Nonrecursive query for www.google.com/A 6) Nonrecursive query for www.google.com/A 4) Nonrecursive query for www.google.com/A 3) Referral to com name servers 5) Referral to google.com name servers 7) A records for www.google.com 8) A records for www.google.com

recursive servername

slide-4
SLIDE 4

Cache Poisoning

  • What is it?
  • Inducing a name server to cache bogus records
  • Made possible by
  • Flaws in name server implementations
  • Short DNS message IDs (only 16 bits, or 0-65535)
  • Made easier on
  • Open recursive name servers

4

slide-5
SLIDE 5

Cache Poisoning Consequences

  • A hacker can fool your name server into

caching bogus records

  • Your users might connect to the wrong web

site and reveal sensitive information

  • Your users’ emails might go to the wrong

destination

  • Man in the middle attacks, phishing,

credentials theft

5

slide-6
SLIDE 6

The Kashpureff Attack

Eugene Kashpureff’s cache poisoning attack used a flaw in BIND’s additional data processing

alternic.net name server Recursive name server Evil resolver Q u e r y : x x x . a l t e r n i c . n e t / A ? Query: xxx.alternic.net/A? Reply: xxx.alternic.net/A + www.internic.net/A Cache

Owns nameserver

slide-7
SLIDE 7

DNS Message IDs

  • Message ID in a reply must match the message ID in the

query

  • The message ID is a “random,” 16-bit quantity

ns1 ns2

Query [Msg ID 38789] Reply [Msg ID 38789]

slide-8
SLIDE 8

How Random - Not!

Amit Klein of Trusteer found that flaws in most versions of BIND’s message ID generator (PRNG) don’t use sufficiently random message IDs

  • If the current message ID is even, the next one is one of
  • nly 10 possible values
  • Also possible, with 13-15 queries, to reproduce the

state of the PRNG entirely, and guess all successive message IDs

slide-9
SLIDE 9

Birthday Attacks

  • Brute-force guessing Msg ID is a birthday attack:
  • 365 (or 366) possible birthdays, 65536 possible message IDs
  • Chances of two people chosen at random having different birthdays:
  • Chances of n people (n > 1) chosen at random all having different

birthdays:

364 365 ≈ 99.7% p n

( ) = 364

365 × 363 365 × ...× 366 − n 365 p(n) = 1− p n

( )

( )

slide-10
SLIDE 10

Birthday Attacks (continued)

People Chances of two or more people having the same birthday 10 12% 20 41% 23 50.7% 30 70% 50 97% 100 99.99996% Number of reply messages Chances of guessing the right message ID 200 ~20% 300 ~40% 500 ~80% 600 ~90%

slide-11
SLIDE 11

The Kaminsky Vulnerability

How do you get that many guesses at the right message ID?

paypal.com name servers Recursive name server Hacker q00001.paypal.com/A? NXDOMAIN!

slide-12
SLIDE 12

The Kaminsky Vulnerability (continued)

How does a response about q00001.paypal.com poison www.paypal.com’s A record? Response:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61718
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 
 ;;; QUESTION SECTION:
 ;q00001.paypal.com. IN A
 ;;; AUTHORITY SECTION
 q00001.paypal.com. 86400 IN NS www.paypal.com.
 ;;; ADDITIONAL SECTION
 www.paypal.com. 86400 IN A 10.0.0.1


slide-13
SLIDE 13

Initial Kaminsky fixes

  • To make it more difficult for a hacker to spoof a response,

we use a random query port in addition to a random message ID

  • If we use 8K or 16K source ports, we increase entropy by 13
  • r 14 bits
  • This increases the average time it would take to spoof a

response substantially

  • However, this is not a complete solution
  • Spoofing is harder, but still possible
  • Evgeniy Polyakov demonstrated that he could successfully

spoof a patched BIND name server over high-speed LAN in about 10 hours

slide-14
SLIDE 14

Defending your cache

14

slide-15
SLIDE 15

Defenses

  • More randomness in DNS msg IDs,

source ports, etc.

  • Better checks on glue
  • DNSSEC

15

slide-16
SLIDE 16

Overwhelming your authoritative servers

16

slide-17
SLIDE 17

Sheer volume and persistence

  • 10s of thousands of bots
  • 10s of millions of open resolvers
  • (see http://openresolverproject.org/)
  • Gbps of traffic generated
  • 45% of ISPs experience 1-10 DDoS/month,

47% experience 10-500 DDoS/month

17

slide-18
SLIDE 18

High yield results

  • Small queries, large responses

(DNSSEC records)

  • Using NSEC3 against you

18

slide-19
SLIDE 19

Make sure they’re your servers…

  • Vet your registry/registrar
  • Think about NS TTLs

19

slide-20
SLIDE 20

How to defend your servers

20

slide-21
SLIDE 21

Harden your server

  • Perimeter ACLs
  • Higher capacity servers
  • Clusters or load balanced servers
  • Response Rate limiting (RRL)
  • http://www.iana.org/about/presentations/20130512-

knight-rrl.pdf

  • https://www.isc.org/blogs/cache-poisoning-gets-a-

second-wind-from-rrl-probably-not/

21

slide-22
SLIDE 22

Spread yourself out

  • Fatter internet pipes (but makes you more

dangerous to others)

  • More authoritative servers (up to a point)
  • Anycast
  • High availability

22

slide-23
SLIDE 23

Being a good internet citizen

23

slide-24
SLIDE 24

It’s not just you being attacked

  • If you allow spoofed packets out from your

network, you are part of the problem…

  • Use BCP38/RFC3704 Ingress filtering
  • Implement RFC5358
  • http://openresolverproject.org/

24

slide-25
SLIDE 25

Revise DNS Standards?

25

slide-26
SLIDE 26

Changing RFCs?

  • Glaciers start to look speedy
  • Source Address Validation
  • TCP vs UDP
  • DNS Cookies
  • http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-04

26

slide-27
SLIDE 27

DNS use by the bad guys

27

slide-28
SLIDE 28

DNS use by bad guys

  • Command and control
  • DNS Amplification
  • Fastflux
  • single flux
  • double flux
  • Storm, Conficker, etc.

28

slide-29
SLIDE 29

Protecting your users

29

slide-30
SLIDE 30

Dealing with malware

  • Prevent infections (antivirus)
  • Block at the perimeter (NGFW, IDS)
  • Block at the client (DNS)

30

slide-31
SLIDE 31

Antivirus

  • Useful but has issues:

Ø Depends on client update cycles Ø Too many mutations Ø Not hard to disable Ø Poor catch rates for new viruses

31

slide-32
SLIDE 32

Perimeter defenses

  • Necessary but not complete:

Ø Limited usefulness after client is already infected Ø Detection of infected files only after download starts Ø Usually IP-based reputation lists Ø Limited sources of data

32

slide-33
SLIDE 33

RPZ DNS

  • Uses a reputation feed(s) (ala spam)
  • Can be IP or DNS based ID
  • Fast updates via AXFR/IXFR
  • Protects infected clients, helps ID them
  • Can isolate infected clients to walled garden

33

slide-34
SLIDE 34

There is *not* only one

Use all methods you can!

34

slide-35
SLIDE 35

Q & A

35

slide-36
SLIDE 36

Thank you!

36