DNS Sec and Kaminsky attack
#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:
- key: domain value: PK
- 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
- a key signing key (KSK) that sits above a ZSK
- 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 )