

The cat is out of the bag - DNS spoofing details - st3fan
http://amd.co.at/dns.htm

======
sysop073
Here's a non-pastebin destroyed version:
[http://blogs.buanzo.com.ar/2008/07/matasano-kaminsky-dns-
for...](http://blogs.buanzo.com.ar/2008/07/matasano-kaminsky-dns-forgery.html)

------
seregine
Here's the CERT vulnerability listing, with a list of affected vendors:

<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...](http://maradns.blogspot.com/2008/07/maradns-is-immune-to-new-
cache.html)

------
kobs
Google Reader can be used as a pseudo-cache:
[http://www.google.com/reader/view/feed/http://www.matasano.c...](http://www.google.com/reader/view/feed/http://www.matasano.com/log/feed/)

------
EastSmith
This is the best explanation of all the DNS stuff I've ever read.

~~~
d0mine
_tyme 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>
A record) as an additional RR._

</quote> [http://www.matasano.com/log/1105/regarding-the-post-on-
charg...](http://www.matasano.com/log/1105/regarding-the-post-on-chargen-
earlier-today/#comments)

This is a good description of the attack.

------
axod
I 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
If I'm understanding your question correctly, the Matasano post outlines
why/how.

~~~
axod
Last 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
Okay, 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
My 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
Real men use IPs only ;)

~~~
huhtenberg
Actually real men use /etc/hosts :)

------
jonnyso
is 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.

