二週間ほど前に恐ろしい毒入れ手法が成立しうることに気づいて、どうやって公表したらよいか悩やんだのだけれど、何と Herzberg と Shulman の論文を読み返したところアバウトながらしっかり書いてあったので躊躇することなく解説することにした。なぜ私はこれを読み流してしまっていたのか。どうしてこれを誰も騒ぎにしていないのだろうか。
DO bit を常に on にしろという RFC 4035 の傲慢な要請は修正されるべきだと思う。そして RFC 2308 という酷い RFC (私なら査読通さない) も SOA に付随する NS を許さないよう書き直されるべきだと思う。(私に IETF に行けというのは無し)
以下、第一フラグメント便乗攻撃の原論文 Fragmentation Considered Poisonous の II 章の C. Circumventing the Cache が示唆していると思われる攻撃手法の解説 (11/4 追記: こっちの論文のほうが詳しい。同じ内容かと思ってちゃんと読んでいなかった。迂闊。https://arxiv.org/pdf/1205.4011.pdf 4.1.1 Injecting NS RR to NSEC3 Response)
検証用のゾーンを作成したのでご利用ください。
dig hoge.sub.mufj.jp txt ; dig fuga.sub.mufj.jp txt
などと二度 (負荷分散されている環境では多数回) 繰り返して
"Your_cache_server_is_vulnerable."
と出たら使用中のキャッシュサーバは第一フラグメント便乗攻撃への耐性が低いと考えられます。ただし EDNS0 への対応等は別途検査が必要です。
(Unbound で検証済/harden-referral-path:yes にしないと危険 (追記: 1.8.2 で対策されました))
要するに DNSSSEC 署名しているドメインは、どうぞ未検証のキャッシュに毒入れしてくださいと言っているようなものである。そして検証もしないのに DO bit を常に立てているキャッシュサーバはマヌケである。(パッチが提供されるべきであろう)
(「DNSSEC はなぜダメなのか」もどうぞ)
11/5 追記: Shulman らの論文 5 Conclusions and Defenses の以下の指摘はとても重大な指摘だと思う。大きな議論になっていないのが不思議だ。
We want to caution against drawing the conclusion that DNSSEC should not be used. In fact, the best defense is to apply DNSSEC correctly in all resolvers and domains (without using NSEC3 opt-out); this will certainly prevent many of our poisoning attacks, and even defend against more powerful Man-in-the-Middle adversaries. However, incremental DNSSEC deployment is vulnerable to our cache poisoning attacks, and complete adoption of DNSSEC may take considerable time, since it depends on adoption by both name server and resolver.
追記: Let's Encrypt は EDNS バッファサイズを 512 にしたとアナウンスしています。正解ですね。
p.s.
この件でも思うのだが脆弱性はぼやかさずはっきりと解説されるべきだろう。悪いやつらだけが高いモティベーションで攻撃方法にたどり着き、守備側は何が危ないかも理解できないまま放置されることになる。
Copyright by T.Suzuki
自分で考えることは無駄にはならない。でも、先行研究の調査も大切です。より、理解が進むでしょうから、期待しています。
私が見かけた論文にはいろいろ詳しく書いてあります。<br>とても危険だということが分かる。<br><br>JPRSが気づいていないはずはないから、伏せていたのでしょうね。
the best defense is to apply DNSSEC correctly in all resolvers and domains (without using NSEC3 opt-out)!<br><br>彼らもこれが実現可能だとは考えていないでしょうから、皮肉だと受け止めます。
本音は DNSSEC should not be used. では? 否定したいふりをしていはいますけれど。
twitterではまったく反応がない。<br>セキュリティ関係者からも反応がない。<br>もうこの業界は終わった。
少なくとも4年前からそういう状況でしょう。
少なくとも4年はよくない状態が続いていて、「温泉」も効果がないということですね。JPRSは悪化の一方だし。
論文にはTTL 0のレコードを利用した連続攻撃も書かれていた。<br>(CDNで使われているそうだ)<br><br>肯定返答に付随するNS,Aで毒盛するにはRRSIGも必要になるから、<br>DNSSEC検証していれば排除される。
肯定返答でもdelegationにはRRSIGは付かない。<br><br>subdomain を乗取ってなにが嬉しいのかはよく分からないが、<br>親のクッキーを覗けるようだ。:-)
<br>フラグメント化攻撃の怖さを認識しているのはLet's Encrypt だけということだろうか。
delegation返答中のadditional sectionのすり替えも可能であることが分かりました。卒研の邪魔になるようだから、今は説明しない。
Unboundなどの実装の不良だと考えています。(RFCを書かないと修正されないだろうから、面倒なのでやらない。)
additional sectionのすり替えが可能だと書きましたが、<br><br>それがキャッシュを上書きして、毒となるかどうかは確かめていません。(面倒)<br><br>毒になる実装があったら、大騒ぎすることになるでしょうし。
今までの狼少年的な騒ぎ方が問題だったのではないでしょうか?
フラグメント化されるくらい大きなAnswerあり返答で、Authority Sectionを置き換える攻撃を検討してみました。<br><br>繰り返し攻撃は困難ですが、繰り返し回数が多くなくても攻撃成功率が高いので、攻撃のリスクは大きいと考えられます。