#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: ——–
| aaxyz@bu.edu - all nonexistent domains | aaxyz2@bu.edu - 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

aaxyz@bu.edu ------->    ns1@bu.edu    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 (ns1@bu.edu) 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 )