DNS/Kaminsky/Finchについて、ここに記述してください。
- Kaminsky
I've now read Dan Kaminsky's slides, which are mostly ranting "the sky is falling" and pointing out what assumes secure DNS.
The actual attack is not described in any more detail than previous public sources. I still don't understand why resolvers accept the poison:
- Kaminsky seems to be suggesting that data in the additional section of a reply is overwriting cached answers, which RFC 2181 says must not happen. Anyway,
$ md5 <kaminsky; echo; cat kaminsky; echo ef96f2d9e973a36e825793ddeff48ae5
Kaminsky says his attack allows him to overwrite data in a DNS cache. The reason Matasano's glue / additional RR explanation is wrong can be found in RFC 2181 section 5.4.1, which says that additional RRs must not override authoritative data in the DNS cache.
However, if you look at RFC 1034 section 3.6.2 you'll see that the data for a CNAME target goes in the answer section, not the additional section.
Presumably this means the resolver treats it as trustworthy and therefore overwrites its "old" cached data with the CNAME target data. (However RFC 2181 also says that a resolver shouldn't trust CNAME target data, which implies this attack shouldn't work, though I can see why it does if the CNAME target is in the same zone as the CNAME owner.)
"resolver shouldn't trust CNAME target data" は どこにあるのだろう。
So the attack is:
(1) cause the victim to look up lots of random invalid domain names adjacent to the goal name whose data you want to overwrite;
(2) spoof authoritative answers that contain two records:
- a CNAME whose owner is your random invalid name and whose target is your
goal name, plus the data for the goal name that you want to insert into the victim's cache;
(3) when you win the spoofing race your data for the goal name overwrites whatever the victim previously had cached.
$ md5 <kaminsky2; echo; cat kaminsky2 d4b70e6abfa3e7d49e159d75b5fc277b
So there's another form of attack which is closer to the Matasano description but still different in significant ways.
This relies on the fact that (again according to RFC 2181 section 5.4.1) data in the authority section of a reply is given a lot of trust.
The attack is:
- (1) cause the victim to look up lots of random invalid domain names
adjacent to the goal name whose data you want to overwrite;
- (2) spoof authoritative answers that have an authority section containing
replacement NS records for the target's zone which point to nameservers you control;
- (3) when you win the spoofing race the victim
will start using your name servers for the target zone instead of the proper nameservers;
- (4) your nameserver can reply in whatever way you
want for the target name, but you'll have to wait for it to expire from the victim's cache. Therefore this attack is slower than the CNAME attack.