## page was renamed from DNS/毒盛/NS変更毒 ## page was renamed from DNS/毒盛/NS更新毒 ## page was renamed from DNS/毒盛/移転毒 == DNS/毒盛/NS更新毒 == <> ---- <> 以下の脆弱性をもつリゾルバー（BIND, Unboundなど）が存在する。[[/デモ]] {{{ キャッシュになにを保持していようが（いまいが）ある種のNSを毒として受け入れる。 }}} [[DNS/1/資源レコード/NS]] [[DNS/1/資源レコード/NS/返答中のNS]] [[../2014/NS毒]] 偽NS攻撃対象ドメインに関して、 キャッシュの状態として少なくとも以下の三つの状況考える。（これらを区別できていない文書がある） 1. キャッシュにはNSレコードがない。 1. キャッシュには委譲（委任）を示すNSレコードだけがある。 1. キャッシュには権威のあるサーバから得たNSレコードがある。 これらの状況での攻撃は以下のようになる。 1. 委譲/委任を騙る （おもにNSを持たないノードが攻撃対象、キャッシュされづらいノードも対象に） 1. 権威サーバからの返答が委譲返答より優先されることを利用する。（権威からの返答を騙る ） 1. 権威サーバ自身によるNS変更を認めてしまうという実装の問題（現状の多くのリゾルバー） 第一のケースはMuellerが指摘した委譲（委任）毒であり、別項で解説している。（委譲返答に毒） 　JPRSは「委任インジェクション」と呼んでいるが、私は使わない。 第二のケースはJPRSが移転（通知）インジェクションと呼んでいるもの。　（おまけに毒） 　tssさんの初期の文書はこれを指すように読めるのだが、本人は第三のケースを含むと言っている。 第三のケースにも名前が必要だが「移転毒」では第二のケースと混乱しそう。（おまけに毒） 　間違った命名が混乱を引き起こす例にはしたくない。 　　JPRSはこのケースについては意図的に（？）言及を避けているようだ。（知らなかったとは思えない） 　　　忘れるような話でもないから、なにか都合の悪いことがあるのだろう。　-- ToshinoriMaeno <> 委譲上書毒、権威上書毒あたりが直接的な表現だろうか。-- ToshinoriMaeno <> JPRS藤原は第一のケースだけを扱っているようだ。キャッシュ上書きには触れていない。 ---- 第二、第三のケースの違いは毒入り返答からくるものではない。 　リゾルバーが持つキャッシュにどういう情報がキャッシュされているかに違いがある。　 * 第二のケースでは上位からの委譲情報だけがキャッシュにあるのに対し、 * 第三のケースでは権威サーバ自身が返したはずのNSレコードをキャッシュに持つ。 権威サーバの返した NS を上書きすることができるからこそ、引越し時のオペレーションと同じだということで「移転」と名付けたつもりです。権威からのキャッシュがない場合も攻撃方法は同じなので名前を一緒にしてしまいましたが、確かに混乱の元のようで申し訳ないです。-- [[tss]] <> JPRSは委譲返答を上書きするケースを「移転通知インジェクション」と呼んでいる。（言葉の使い方が異なるのだろうが） 理由としてRFC２１８１を持ち出している文書については、上の主張は疑う必要がある。 　明示的に「権威サーバからのNSがキャッシュされている」と書いてないかぎりは。 　　そういえば、名前について、意見交換した記憶があるが、探すのは面倒だから、いまは放っておく。 -- ToshinoriMaeno <> 権威サーバにNSを直接問い合せて得られる返事のAnswer SectionのNSもある。 　しかし、これは同等ランクのNSでだけ上書きされるはずなので、毒盛は困難であるので、ここでの考察の対象とはしない。 -- ToshinoriMaeno <> ---- https://twitter.com/beyondDNS/status/447133620176556032 2014年3月22日 {{{ DNS query への返答に現れるNSレコードはむっつくらいの異なる用途に使われています。 それぞれについて毒盛対策を考えないといけないようです。 }}} https://twitter.com/beyondDNS/status/580179810573418496 2015年3月24日 {{{ 一方で、権威（？）のあるゾーンサーバが返す自ドメインのNSを使うともっと毒盛し易いようです。 （こちらはdelegationではないので、NS移転通知とでもいいましょうか） 実装の不良と考えていますが、こちらの対応も進んでいないようです。 }}} {{{ answer section がある返答では、残りのsectionは信用しなければいいのです。 めったにおきないDNSゾーンサーバの移転に不便だと言って、毒盛の危険を増やしているのは 正しいのでしょうか。 }}} 両方を含む言葉として、「移転インジェクション」と言っている。 http://www.e-ontap.com/dns/pandora_ieice.pdf#20　　2014.06.05 IEICE https://twitter.com/beyondDNS/status/481802729992384512 {{{ キャッシュにあるNS RRSetを上書きするような実装は よほど注意深く検査するものでないかぎり毒盛される危険がある。 RFC2181 ranking は毒排除の役にはたたない。 }}} と書いていた。ここでも前野は(も）委譲のNSと権威サーバからのNSを区別できていない。　-- ToshinoriMaeno <>@ https://twitter.com/beyondDNS/status/479021504860925953 2014年6月18日 {{{ NSレコードが上書きされるケースは過去の毒盛脆弱性を調べれば分かる。 BINDではすべて対策されているはずだが、まだ残っているらしい。RFC２１８１の欠陥か。 （実装依存なので、自分では調査していない。） }}} 2014.11.04 http://www.e-ontap.com/dns/ipsj-tokai2.pdf スライド１８ では第二、第三のケースをまぜた記述がある。 　この時点でも、対応を考えるのに区別が必要だとは思っていなかったのだろう。　-- ToshinoriMaeno <> [[DNS/毒盛/2014]] あたりを見てもらえば分かると思いますが、ごく最近まで前野は区別できていません。（毒盛に関してだけ） 　（違いを指摘できるほど、興味がなかったこともありますが、RFC2181を持ち出すひととは議論したくなかった。） -- ToshinoriMaeno <> [[DNS/毒盛/2014/NS移転通知毒/鈴木の例]] にはコメントしてありますね。　-- ToshinoriMaeno <> ---- unbound には、2のケースを排除するためのオプションがある（設定次第） ３ は攻撃成功の可能性り。 unbound の対応は片手落ちということだ。 -- ToshinoriMaeno <> これら以外にもNS毒を返答することで、リゾルバーを混乱させることができそうだが、 これ以上は書かない。　-- ToshinoriMaeno <> ---- [[DNS/毒盛/2014/NS移転通知毒]] == はじまり == http://www.e-ontap.com/dns/endofdns2.html {{{ 委譲元から得た最低ランクの NS キャッシュを、 偽権威の Answer に付随する Authority Section の NS で上書きして毒入れすることができ、そのゾーンを自由にできる。 }}} これ自身は正しい。だが、RFC2181の欠陥なのだろうか。実装次第だと考える。 さらに、ここでは鈴木が触れていないことがある。 権威あるサーバから得たNS をキャッシュしているはずなのに、 {{{ Answer に付随する Authority Section の NS （毒）で上書きできる }}} ような実装があることである。（Ghost Domain Names 脆弱性で発覚） -- ToshinoriMaeno <> (触れていますよ。前野さんが無視していただけ -- [[tss]] <>) == 真打ち == http://www.e-ontap.com/blog/20140415.html 「RFC2181の欠陥をつく方法」とあるが、欠陥とはなんのことだろう。 http://www.e-ontap.com/dns/endofdns.html http://www.e-ontap.com/blog/20140617.html 　スライド 20 にはこうある。 {{{ 本物の権威サーバから得たネームサーバ情報も上書きできる (RFC2181は禁止していない / 実装依存) }}} RFC2181 は優先度を指定しているのだから、禁止はしない。w 本来のサーバからはNSつきの返事が返ってこないような問い合せをすることが重要です。 　そうしないと、毒が入ってもすぐに正しいNSに置き換えられてしまうからです。 == JPRS == 鈴木の発表のあと、JPRSがどう言い繕っているか、調べることにしよう。 -- ToshinoriMaeno <> http://www.janog.gr.jp/meeting/janog34/doc/janog34-dnsvl-morishita-1.pdf {{{ NSレコードは子のものが優先 }}} と言いつづけているから、問題を理解していない可能性もある。 http://www.e-ontap.com/dns/fujiwaratalk.html {{{ RFC 2181のランキングの問題については触れない }}} 　　　「攻撃手法・対策ともに既知」 その割にはコソコソなにしているのだろう。 http://www.ieice.org/~ia/archives/ia20140906/20140912-ia-fujiwara.pdf (委任インジェクションだけを説明しているようだ） {{{ フルリゾルバ開発者は、対策を実装済み –Unboundではharden-referral-pathで対策済 –NominumVantioではいろいろな対策を実装済 –BIND 9.10では、ISC独自のDNS Cookieを実装 –Google Public DNS: nonce prefix, 多数のIPアドレス使用 }}} unboundの対策は不十分、Nominum対策は非公開、 Googleの対策は有効だ。 {{{ 費用対効果を考えた対策が重要である }}} そのとおりだが、誰がそれをやるのか。-- ToshinoriMaeno <> ２０１４ランチセミナーでの説明は間違い。 http://jprs.jp/tech/material/iw2014-lunch-L3-01.pdf {{{ 移転通知インジェクション攻撃 – 移転通知(子のNS)は委任応答(親のNS)よりも信頼度(trustworthiness)が上 • RFC 2181 5.4.1. Ranking data – 上記仕様に準拠しない実装では攻撃は成立しない }}} == おまけ == {{{ 攻撃者だけが問題に気づき、守りを固める必要がある側には知識が乏しい危険な状況といえるでしょう。 発見者が隠蔽に協力してくれている事例と同一視して隠蔽を続けるのはまずいと思います。 }}}