トップ «前の日記(2018-08-27) 最新 次の日記(2018-11-04)» 編集

インターノット崩壊論者の独り言

過去の日記
EPIC2014
Google Public DNS (8.8.8.8, 8.8.4.4) および Cloudflare (1.1.1.1, 1.0.0.1) 経由では本サイトにアクセスできないよう措置させて頂いております。

2018-10-31 DNSSEC は危ない

- これを NSEC/NSEC3 Replacement Attack と呼ぶのはどうだろう?

二週間ほど前に恐ろしい毒入れ手法が成立しうることに気づいて、どうやって公表したらよいか悩やんだのだけれど、何と 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)

  1. 第一フラグメント便乗攻撃は成立しうる
  2. だが Answer 応答の差し替えはバッファとキャッシュに阻まれて連続的な攻撃が困難 (うちの学生が卒研で検証中)
  3. 否定応答であれば連続的な攻撃が可能となる
  4. RFC 2308 は否定応答の SOA レコードに NS や A が付随することを許している
  5. 否定応答の SOA レコードに付随する NS や A をキャッシュする実装が存在する
    検証用のゾーンを作成したのでご利用ください。
    dig hoge.sub.mufj.jp txt ; dig fuga.sub.mufj.jp txt
    などと二度 (負荷分散されている環境では多数回) 繰り返して
    "Your_cache_server_is_vulnerable."
    と出たら使用中のキャッシュサーバは第一フラグメント便乗攻撃への耐性が低いと考えられます。ただし EDNS0 への対応等は別途検査が必要です。
    (Unbound で検証済/harden-referral-path:yes にしないと危険)
  6. NSEC/NSEC3 とその署名 (RRSIG) のついた否定応答の応答は大きい
  7. 第二フラグメントに追い出された NSEC/NSEC3 や RRSIG の一部を NS や A に差し替えることが可能である
    (NSCOUNT,ARCOUNTの数合わせとパディング等によってチェックサムを合わせることは難しくない)
  8. つまり否定応答を用いた第一フラグメント便乗攻撃により、移転インジェクションが可能となる (たぶん委任インジェクションも)
  9. RFC 4035 の要請により現代的なキャッシュサーバは DO bit が常に on になっており、署名検証をしない場合この攻撃が成立する
    (検証しても DoS になる / 鈴木が示したように条件によっては検証していても成立しうる )
  10. 応答内容が分かっていて変化しない場合、IP ID が完全にランダムであってもエントロピーは高々 16 bit だ (ポートランダマイズは役に立たない)

要するに DNSSSEC 署名しているドメインは、どうぞ未検証のキャッシュに毒入れしてくださいと言っているようなものである。そして検証もしないのに DO bit を常に立てているキャッシュサーバはマヌケである。(パッチが提供されるべきであろう)
(「DNSSEC はなぜダメなのか」もどうぞ)

11/5 追記: シャルマンらの論文 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.

p.s.
この件でも思うのだが脆弱性はぼやかさずはっきりと解説されるべきだろう。悪いやつらだけが高いモティベーションで攻撃方法にたどり着き、守備側は何が危ないかも理解できないまま放置されることになる。

本日のツッコミ(全9件) [ツッコミを入れる]
_ tm (2018-11-05 11:37)

自分で考えることは無駄にはならない。でも、先行研究の調査も大切です。より、理解が進むでしょうから、期待しています。

_ tm (2018-11-06 19:56)

私が見かけた論文にはいろいろ詳しく書いてあります。 <br>とても危険だということが分かる。 <br> <br>JPRSが気づいていないはずはないから、伏せていたのでしょうね。

_ tm (2018-11-06 19:58)

the best defense is to apply DNSSEC correctly in all resolvers and domains (without using NSEC3 opt-out)! <br> <br>彼らもこれが実現可能だとは考えていないでしょうから、皮肉だと受け止めます。

_ tss (2018-11-06 22:35)

本音は DNSSEC should not be used. では? 否定したいふりをしていはいますけれど。

_ tm (2018-11-09 09:25)

twitterではまったく反応がない。 <br>セキュリティ関係者からも反応がない。 <br>もうこの業界は終わった。

_ tss (2018-11-09 12:05)

少なくとも4年前からそういう状況でしょう。

_ tm (2018-11-12 18:54)

少なくとも4年はよくない状態が続いていて、「温泉」も効果がないということですね。JPRSは悪化の一方だし。

_ tm (2018-11-19 08:10)

論文にはTTL 0のレコードを利用した連続攻撃も書かれていた。 <br>(CDNで使われているそうだ) <br> <br>肯定返答に付随するNS,Aで毒盛するにはRRSIGも必要になるから、 <br>DNSSEC検証していれば排除される。

_ tm (2018-11-19 18:32)

肯定返答でもdelegationにはRRSIGは付かない。 <br> <br>subdomain を乗取ってなにが嬉しいのかはよく分からないが、 <br>親のクッキーを覗けるようだ。:-)

[]

最近の日記

リンク

Copyright by T.Suzuki