| layout | title | scribe |
|---|---|---|
notes |
Kaminsky Attack and DNS Sec |
Kathryn Quirk |
*DNS as being a source of attacks *Convenient for censorship – can just unlist an entry, no need for nation wide firewall *Denial of service amplification attacks *Leak of what domains you are looking at *Spoofing can lead someone to go to the wrong address *Spoofing DNS *If you know the query ID you can create a race – adversary attempts to come back with answer faster than actual answer *If the bad response comes back faster, then the resolver will return with the bad response *Essentially poisoning the cache *How does adversary find the Query ID? *If you are man-in-the-middle or on-path you can simply look at the query IDs *Off-path attacker *If you didn’t have a specific target, you could just chose random query IDs because they are only 16-bits long *make the user click on another website that attacker operate (N.B. this website is a “nice” website) that has a request embedded in it – induce the request, then add a small number to the query ID (know it’s incremented by some amount) of the query ID of your own website, start flood, could even delay serving until you have sent the flood *How do you know you’ve succeeded? *You will find out immediately because it will be requested from your page *Easy case for the attacker = fixed port and sequential ID *Learn these two values when attackers innocent website is visited because DNS query will go to attacker’s name servers *If domain does not exist – NXDOMAIN (does not exist) is returned *SAO record = start of authority record *Kaminsky attack with the easy case *Embed the attacker’s webpage with many images – non-existent and random e.g. aaxyz.bu.edu, aaxyzz.bu.edu, etc. *Victim sends more DNS queries for these non-existent domain names = longer (gives you bigger attack window) and also guarantees that it will not be in your cache from a previous query (many requests guaranteed) *Poison value in your cache for aaxyz.bu.edu – not poisoned on anything that you currently care about *In response to the DNS queries – responses will redirect to another name server operated by the attacker *Will say NS for bu.edu is ns1.bu.edu *Next record will have an A record for ns1.bu.edu with the attacker’s IP address = a glue record that glues the ip address for a name server to the name server so that you don’t have to make more calls *Cache is now poisoned for anything that ends with bu.edu *Solutions to Kaminsky attack *Randomized query ID = gives you 2^16 security, this is not great because of the large number of requests you make as an attacker (attack is still doable in about 10 seconds) *Randomized port = does reasonably well and would have to maintain a very long flood (another 11-bits of security for 2^27 total) *Many people have closed off their resolvers to prevent attacks as seen above *Attack now has to come from within the network
*In what we have seen so far, DNS records were not signed, now someone decided that these records should be signed *New record type called RRSIG = resource record signature *Accompanying the A records will be an RRSIG that will be a signature for all of the records (separate signature if there are name server records) *Since signatures are fairly long = stronger DDOS amplifier *Need record types because people view DNS as a database *DNSKey is a record type that contains the public key *Key needs to be signed – chicken and egg problem *Hierarchical – there is one root key = good foundation for the system *Public key for root, PK for .edu, PK for bu.edu, etc. *Need to watch out for key rollover, the key changes *For every zone, you will actually have two keys: key signing key (KSK) that sits above zone signing key (ZSK) *ZSK will sign the RRSIG of the records *Each one has 2 DNSKey records, one for KSK and one for ZSK, KSK will sign them *Can have long KSK because it only signs ZSK = infrequent key roll overs *ZSK signs the records and is short = easy to roll over *On the other hand, root key roll over is a major undertaking *DS = record type that stands for Delegation Signer *Comes together with NS e.g. you query www.bu.edu, you get NS record for ns1.bu.edu and a DS record that has the hash of their PK (All of this comes with an RRSIG) *When you go to the name server you will be able to verify the key because it has to match the hash *If a record doesn’t exist *It is easy to authenticate a yes – the signatures already sit there *Can’t pre-sign a no – will show a consecutive pair that already exists, and will show that the name you are looking for does not exist in between them, pre-signed *Zonewalking = if you continuously submit requests for names that don’t exist, you will be able to get a full list of the zone by observing the pairs that are returned