4 ms·
The cat is out of the bag - DNS spoofing details
- EastSmith 18y agoThis is the best explanation of all the DNS stuff I've ever read.
- d0mine 18y agotyme July 21st, 2008 9:45 pm Nate: as I understand it, the additional RR is the key. You can’t keep requesting the foo.com NS record and trying to poison with forged responses because it’ll be cached. You can keep requesting bogus_random.foo.com, because each different one will generate a new recursive query. Then mallory can reply with a foo.com NS record (or http://www.foo.com http://www.foo.com A record) as an additional RR. </quote> http://www.matasano.com/log/1105/regarding-the-post-on-chargen-earlier-today/#comments http://www.matasano.com/log/1105/regarding-the-post-on-charg... This is a good description of the attack.
- kobs 18y agoGoogle Reader can be used as a pseudo-cache: http://www.google.com/reader/view/feed/http://www.matasano.com/log/feed/ http://www.google.com/reader/view/feed/http://www.matasano.c...
- sysop073 18y agoHere's a non-pastebin destroyed version: http://blogs.buanzo.com.ar/2008/07/matasano-kaminsky-dns-forgery.html http://blogs.buanzo.com.ar/2008/07/matasano-kaminsky-dns-for...
- seregine 18y agoHere's the CERT vulnerability listing, with a list of affected vendors: http://www.kb.cert.org/vuls/id/800113 http://www.kb.cert.org/vuls/id/800113 We use MaraDNS, and it was very comforting to see this on their blog: http://maradns.blogspot.com/2008/07/maradns-is-immune-to-new-cache.html http://maradns.blogspot.com/2008/07/maradns-is-immune-to-new...
- axod 18y agoI don't see why it should accept any address that isn't needed for the original query. Even if it does accept those additional addresses, surely they should be held in a separate area and only used for that particular query and nothing else?
- silencio 18y agoIf I'm understanding your question correctly, the Matasano post outlines why/how.
- axod 18y agoLast paragraph: "It also contained Additional RRs pointing WWW.VICTIM.COM to 6.6.6.0. Those records are in-bailiwick: Bob is in fact interested in VICTIM.COM for this query." Why would it accept a record for www.victim.com for a query against aaaaa.victim.com, when www.victim.com isn't needed for that particular query? Surely the fix is to further restrict fix 2: "The RR set poisoning attack is fixed by bailiwick checking, which is a quirky way of saying that resolvers simply remember that if they’re asking where WWW.VICTIM.COM is, they’re not interested in caching a new address for WWW.GOOGLE.COM in the same transaction." Change that to say they are only interested in addresses that help them resolve the current query, and they will only use those intermediate addresses for the current query, and not globally.
- silencio 18y agoOkay, I misunderstood it. Yes, what you're suggesting (basically to only keep the glue for the current query and not to cache it, right?) would be a fix. Buuuut you'd have to consider that legitimate glue usage includes A records for NS records.
- DaniFong 18y agoMy friend insists, 'please don't bring down the internet. I need it. It can't go down. I need to write my grant proposal.'
- axod 18y agoReal men use IPs only ;)
- huhtenberg 18y agoActually real men use /etc/hosts :)
- jonnyso 18y agois it just me or is the scenario he describes fundamentally wrong. if we want to poison 'Bob's' nameserver, we have to get 'Alice' to send a request to the legitimite nameserver of victim.com, and then spoof the request to ALICE, not Bob. Its almost as if he's changed the meaning of Alice and Bob in the final scenario.