Skip to content

Latest commit

 

History

History
104 lines (90 loc) · 4.62 KB

2017-04-25-DNS-Fun.md

File metadata and controls

104 lines (90 loc) · 4.62 KB
layout title scribe
notes
DNS Sec and Kaminsky attack
Megan Horan

#Guest Lecture from Professor Reyzin

DNS Review:

-> DNS issues from last time: a denial of service attack, a source of leaks since DNS is over UDP, you
can fingerprint an entire webpage, and it can be spoofed to the wrong person

-> How to spoof DNS to the wrong person: (off path attack) *16 bit number is a query address *so you know what request to resolve ie why caching a comcast is a better idea *if you're the bad guy, you want your response to beat out the right DNS request *also the query id returned by the attacker has to match *if this attack succeeds you can poision thier cache for at least 7 days every time they go to bu.edu

How are the query Id's generated? (Question from a student)

*so go to the webpage - know the query id *then ask bu.edu and find that QID *the scenerio explained above allows us to use that

How can the attacker see if they suceeded? (Question from student)

*make another request to bu.edu on your website

  • so if you succeed you will find out immediately as they will go to the attacker when it calls bu.edu

Kaminsky Attack scenerio:

Every case for the attacker now: fixed port and sequential ID --> learn these values when attackers innocent website is visited because DNS query will go to the attacker's name server

####attack scenerio: *force you to do this many times -> embed a ton of images with empty domains attackers webpage:

| [email protected] - all nonexistent domains | [email protected] - requests are guaranteed! many requests guaranteed | ... | |

*more DNS requests *going to be open for a longer time (bigger attack window) *eliminates the possibility that the website the victim looks up is already cached (wouldn't work) *non-existant means the victim will have to ask about it: ie many reuqests will come! *in response to these queries: 1.response will redirect to another name server, operated by the attacker 2. fake glue record returned by the attackers' name server

[email protected] ------->    [email protected]    NS- ( a real name: bu.edu)  
                      <--------------- A- atackers ip address

Review of DNS nameserver lookup:

*NS record will return IP address *a nameserver and its IP address is called a glue record

Now attacker can poision nameserver

*everytime you go to find bu.edu you will go to the attacker (one step up from the first attack) *now the name server is poisioned in the cache

Kaminsky attack is better:

  • more requests
  • saying we don't know and redirecting it NA and poisioning it
  • could poision comcast cache to google payoff is super high

Solutions:

*QID randomization -2^16 security (kaminsky attack still doable in 10s) *Port randomization (another 11 bits of security 2^27 overall) *(8.8.8.8 google's resolver you can play with)

DNS SEC:

*why not sign DNS like certificates from keys, so DNS maps and certs map:

    • key: domain value: PK

what does DNS SEC do? it digitally signs DNS and it adds a new record type called RRSIG

*RRSIG: Resource record signatures ex. www.google.com A --many RR
A
A --RRSIG -signs them all ( all signed with ZSK -- explained later on)

Problems:

*you still want to fit into UDP - don't want length in the DNS *DDOS is amplified

student question: who signs?

*DNS is heirarchial: so each time you go down the hierarchy you get a ket and check it against the NS key so you only need one root key

simple verison:

*new record typeL DS ("Delegation signer") comes together with NS #ex. bu.edu (comes with RRSIG) and has NS ([email protected]) and DS (heres the hash of the public key)

Key rollover:

  • what happens: 90% of the headache in PK, are very hard to do, want to be able to do rollovers but keys are long
  • solution: 2 keys at everystep
    1. a key signing key (KSK) that sits above a ZSK
    2. ZSK is a zone signing key
  • each zone has 2 DNS key records - one for KSK and one for ZSK
  • not terribly inefficient- nowyou can roll over you zsk on your own - easy note(look up DNS key signing ceremony)

Last thoughts:

*what about a negative response? How do you autheticate it: can't presign a no for every scenerio *DNS solutions: 1. going to sign executive pairs of things that exist 2. NSEC (next secure) contains the next name in alphabetical order 3. prove that a name does not exist 4. concerns about this: if there is a bogus query, the attacker can get 2 legitimate names after and before, and you can keep going ( zone walking : avenue for attack )