<> ---- = DNS/毒盛/成立の要件 = <> キャッシュ毒盛攻撃が成立する条件が少し見えてきたようなので、ここにメモを残しておく。 {{{ 偽UDPパケットがキャッシュサーバに渡るまでの条件については触れない。 }}} [[../taxonomy]]　[[../target]] == 問い合せ（きっかけ） == {{{ 「キャッシュにないレコード」をキャッシュサーバに問い合わせる。（Kaminsky の指摘） 　キャッシュが外部に問い合わせる動作を引き起こすような名前とレコードタイプ }}} {{{ ゾーンサーバからの返事は「キャッシュされない」ような問い合わせを送る。（Mueller の指摘） }}} 毒盛したいレコードを送り込む邪魔にならない返事でもよい。（NXDOMAINなどが返るもの） == 毒入れしやすい返答 == {{{ キャッシュにないレコードがもっとも都合がよい。 }}} キャッシュにあっても、オーバーライトするかどうかがポイントとなる。かつ、効果的なもの。 　 BINDキャッシュはオーバーライトしやすいらしい。　 RFC2181 が関係するかのような説明は間違いだと思う。（実装の脆弱性だろう） === キャッシュにないレコードセットを毒返答として送る === {{{ キャッシュにないレコード群（RRSet)は受け入れられやすい。 }}} Mueller の指摘からの帰結。 　A レコードが存在していても、NSレコードを注入する障害とはならない。（Mueller の指摘） 正規のサーバからの返事がNXDOMAINだったら、 (例： co.jp ドメイン） 　（委譲を示す） NS RRSet はキャッシュにない状態が続く。 　negative caching が働くので、直接の問い合せによる注入はより困難となるが、委譲返答には関係しない。 {{{ NSレコードが存在しないドメイン名に対して、NSレコードを注入するというのが典型的な攻撃です。 }}} でも、NSレコードだけではない。　-- ToshinoriMaeno <> 毒がいつどう使われるかという問題はある。 親子関係にあるゾーンを一台のゾーンサーバに持たせていると、困ったことがおきるようです。(JPRSの指摘） 　大学関係のゾーンは日本のインターネット初期に設定されたままのところが多く、この脆弱性を抱えています。 === キャッシュを上書きするRRSet を返答する === 委譲返答、あるいは転居通知のようなもの。 (RFC2181, あるいは実装の問題； JPRS や鈴木氏の指摘） 　Authority Section (とAdditional Section) でキャッシュを書き換える。 Answer Section で得た返答も上書きされるかもしれない。 == 毒の保持 == せっかく注入（上書き）した毒が（正当な）別の問い合わせの返答で上書きされては毒が効果を示さない。 　毒盛手法の説明ではこの点に触れられていないことがよくある。　（RFC２１８１ 通りの動作での問題） 今後調査すべき項目だろう。 -- ToshinoriMaeno <> 正規のゾーンサーバにNSレコードが存在していないようなドメイン名があてはまる。 毒としてキャッシュされたRRSet が本来の返答により上書きされることはないからである。 Mueller でもこの条件を満足している例が書かれている。　-- ToshinoriMaeno <> == 毒情報が使われること == キャッシュに入っていても、返答のために使われないのでは毒としては無毒と同じになる。 　例えば、glue は A の問い合せには使われない。 == RFC 2181 が脆弱性のもと == 上位サーバからもらった委譲返答と自サーバがおまけとしてつけてくるAuthority/Additional では 自サーバのものが優先されるようだが、これはさまざまな問題を引き起こす。 毒盛も簡単になり、一度入った毒が有効なまま残る。 -- ToshinoriMaeno <> == 具体例 == 4/15 のJPRSがほとんど役に立たないと判断したので、具体的なドメイン名などは公開された。 　co.jp などの属性型ドメイン名はあぶない。 　-- ToshinoriMaeno <> {{{ 連休前にいくつかを公開する予定である。影響が大きいので、警告が行き渡ったあとになる。 -- ToshinoriMaeno <> }}}