1. DNS/毒盛/NS更新毒


以下の脆弱性をもつリゾルバー(BIND, Unboundなど)が存在する。/デモ

キャッシュになにを保持していようが(いまいが)ある種のNSを毒として受け入れる。

DNS/1/資源レコード/NS DNS/1/資源レコード/NS/返答中のNS ../2014/NS毒

偽NS攻撃対象ドメインに関して、 キャッシュの状態として少なくとも以下の三つの状況考える。(これらを区別できていない文書がある)

  1. キャッシュにはNSレコードがない。
  2. キャッシュには委譲(委任)を示すNSレコードだけがある。
  3. キャッシュには権威のあるサーバから得たNSレコードがある。

これらの状況での攻撃は以下のようになる。

  1. 委譲/委任を騙る (おもにNSを持たないノードが攻撃対象、キャッシュされづらいノードも対象に)
  2. 権威サーバからの返答が委譲返答より優先されることを利用する。(権威からの返答を騙る )
  3. 権威サーバ自身によるNS変更を認めてしまうという実装の問題(現状の多くのリゾルバー)

第一のケースはMuellerが指摘した委譲(委任)毒であり、別項で解説している。(委譲返答に毒)

第二のケースはJPRSが移転(通知)インジェクションと呼んでいるもの。 (おまけに毒)

第三のケースにも名前が必要だが「移転毒」では第二のケースと混乱しそう。(おまけに毒)

委譲上書毒、権威上書毒あたりが直接的な表現だろうか。-- ToshinoriMaeno 2015-07-26 16:06:33

JPRS藤原は第一のケースだけを扱っているようだ。キャッシュ上書きには触れていない。


第二、第三のケースの違いは毒入り返答からくるものではない。

権威サーバの返した NS を上書きすることができるからこそ、引越し時のオペレーションと同じだということで「移転」と名付けたつもりです。権威からのキャッシュがない場合も攻撃方法は同じなので名前を一緒にしてしまいましたが、確かに混乱の元のようで申し訳ないです。-- tss 2015-07-24 00:07:22

JPRSは委譲返答を上書きするケースを「移転通知インジェクション」と呼んでいる。(言葉の使い方が異なるのだろうが)

理由としてRFC2181を持ち出している文書については、上の主張は疑う必要がある。

-- ToshinoriMaeno 2015-07-26 15:58:33

権威サーバにNSを直接問い合せて得られる返事のAnswer SectionのNSもある。

-- ToshinoriMaeno 2015-08-15 02:35:50


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 2015-07-26 15:52:04@

https://twitter.com/beyondDNS/status/479021504860925953 2014年6月18日

NSレコードが上書きされるケースは過去の毒盛脆弱性を調べれば分かる。
BINDではすべて対策されているはずだが、まだ残っているらしい。RFC2181の欠陥か。
(実装依存なので、自分では調査していない。)

2014.11.04 http://www.e-ontap.com/dns/ipsj-tokai2.pdf スライド18 では第二、第三のケースをまぜた記述がある。

DNS/毒盛/2014 あたりを見てもらえば分かると思いますが、ごく最近まで前野は区別できていません。(毒盛に関してだけ)

-- ToshinoriMaeno 2015-07-24 00:31:38


unbound には、2のケースを排除するためのオプションがある(設定次第) 3 は攻撃成功の可能性り。 unbound の対応は片手落ちということだ。 -- ToshinoriMaeno 2015-07-23 10:54:48

これら以外にもNS毒を返答することで、リゾルバーを混乱させることができそうだが、 これ以上は書かない。 -- ToshinoriMaeno 2015-07-23 23:29:56


DNS/毒盛/2014/NS移転通知毒

2. はじまり

http://www.e-ontap.com/dns/endofdns2.html

委譲元から得た最低ランクの NS キャッシュを、
偽権威の Answer に付随する Authority Section の NS で上書きして毒入れすることができ、そのゾーンを自由にできる。

これ自身は正しい。だが、RFC2181の欠陥なのだろうか。実装次第だと考える。

さらに、ここでは鈴木が触れていないことがある。 権威あるサーバから得たNS をキャッシュしているはずなのに、

Answer に付随する Authority Section の NS (毒)で上書きできる

ような実装があることである。(Ghost Domain Names 脆弱性で発覚) -- ToshinoriMaeno 2015-07-22 23:05:17

3. 真打ち

http://www.e-ontap.com/blog/20140415.html

http://www.e-ontap.com/dns/endofdns.html

http://www.e-ontap.com/blog/20140617.html

本物の権威サーバから得たネームサーバ情報も上書きできる 
(RFC2181は禁止していない / 実装依存)

本来のサーバからはNSつきの返事が返ってこないような問い合せをすることが重要です。

4. JPRS

鈴木の発表のあと、JPRSがどう言い繕っているか、調べることにしよう。 -- ToshinoriMaeno 2015-07-22 23:51:03

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 2015-07-23 00:43:15

2014ランチセミナーでの説明は間違い。 http://jprs.jp/tech/material/iw2014-lunch-L3-01.pdf

移転通知インジェクション攻撃
 – 移転通知(子のNS)は委任応答(親のNS)よりも信頼度(trustworthiness)が上
   • RFC 2181 5.4.1. Ranking data
 – 上記仕様に準拠しない実装では攻撃は成立しない

5. おまけ

攻撃者だけが問題に気づき、守りを固める必要がある側には知識が乏しい危険な状況といえるでしょう。
発見者が隠蔽に協力してくれている事例と同一視して隠蔽を続けるのはまずいと思います。