## page was renamed from DNS/毒盛/Kaminsky講演/スライド(18) ## page was renamed from DNS/毒盛/Kaminsky講演/講演のスライド(18) == DNS/毒盛/Kaminsky講演/スライド(16 - 18) == 注：BlackHat Japan 2008 のスライドが見えますが、いくつか途中が省略されていて、#10-12 が対応しています。 　スライド番号を読み変えてください。-- ToshinoriMaeno <> [[attachment:BlackHat-Japan-08-Kaminsky-DNS08-BlackOps.pdf]] Kaminsky blogが移転していたので、2008 年のBlackhat の講演videoを発掘してきました。 http://www.vimeo.com/17247507 [[http://www.slideshare.net/dakami/dmk-bo2-k8|スライド]] ---- TTL に関係なく、多数の問合せを送らせることが可能なキャッシュサーバがあったときに、 問い合わせと偽返答のtransaction ID が合致し、キャッシュサーバは偽返答を受け取るものとします。 == どうすれば、なにを騙ることができるか == 毒耐性のないキャッシュサーバに対して、DNSプロトコルに従った返答を送りつけるとしたときに、 「どうすれば、なにを騙ることができるか」について検討する。 Kaminsky のスライドの説明のままでは、手元の筆者の環境では毒盛できなかったのがきっかけである。 以下、Kaminsky の説明にそって、検討する。 === 目的は www.foo.com を騙ること === "He wanted www.foo.com." (これは当然ながら、A レコードのこと) === どこに問合せさせているか === スライド(16)を追ってみると foo.com サーバだとわかる。 ==== スライド(17) ==== スライド(17)にはこうある。 {{{ Is it possible for a bad guy, who has won the race for 83.foo.com, to end up stealing www.foo.com as well? }}} これからも「www.foo.com を騙る」ことが当面の目的であることがわかる。 つまり、foo.com サーバからの返答を騙った偽返答をキャッシュに送りつけることで、 www.foo.com の 偽 A レコードをキャッシュさせることができるか、 を論じていることが分る。 www.foo.com の A レコードを foo.com サーバに問合せさせることは TTL の効果で攻撃回数に制約があるので、今回の方法が登場する。 ==== スライド(18) ==== 1. $RANDOM.foo.com についての query を送りつける。(start) 1. 200個 の偽返答を送る。 1. 偽返答は以下の通り (referral 返答) {{{ * $RANDOMwww.foo.com IN NS www.foo.com [authority section] * www.foo.com IN A 6.6.6.6 [additional section] }}} 1 の query と 3 の返答は整合していないから、このままでは受け取られない。 つまり、毒盛できない。少なくとも一方に間違いがある。 === スライドの修正案 === スライド (17)には毒盛が成功したときの例示があった。 83.foo.com についての query に対して下の偽返答(referral)をする。 {{{ * 83.foo.com IN NS www.foo.com [authority section] * www.foo.com IN A 6.6.6.6 [additional section] }}} この Kaminsky の説明の流れからすると、スライド(18) の (3)返答部分は {{{ * $RANDOM.foo.com IN NS www.foo.com [authority section] * www.foo.com IN A 6.6.6.6 [additional section] }}} だと解釈するのが妥当だ。 === www.foo.com の A レコードが書き換えできるか === しかし、上の偽返答の www.foo.com A レコード (glue)でキャッシュの書き換えができるのだろうか。 そういう脆弱なキャッシュ(bind-?)も存在したのだろう。それなら毒盛は簡単だ。 :-) [[DNS/毒盛/Kaminsky手法/毒盛対策]] Kaminsky が 2008 年初めにこの方法で毒盛できると言ったときに、 Paul Vixie らはそれを認めたのだろうか。 {{{ port 固定という大きな穴の存在を認めたあとでは 毒盛の手法は大した問題ではないことは事実なのだが。 }}} 偽返答内の www.foo.com A レコード(additional)を受け入れることに疑問がある。 　www.foo.com は 83.foo.com の内部名ではない。従って、狭義のglueではないのだから。 仮に（広義の）glueであるとしても、以下のような動作をするキャッシュサーバなら うえの方法では"毒盛できない"と考える。(unbound などを試してみよ) * A レコードがキャッシュには存在していないことを確認する。 glue より A レコードを優先する。[DNS の効率を重視する立場には反する。] * glue として受け入れても A レコードとしては使わない。 ウェブサーバの乗っ取り(ファーミング)に使うのであれば、 A レコードを上書きする必要があるため、glue への毒盛だけでは意味をもたない。 === 修正案 (1) === より成功するように少し手直しするとしたら、こんなものか： {{{ $RANDOM.www.foo.com について query を送る }}} 問合せる相手は foo.com の権威サーバである必要がある。 その偽返答 (referral)はこういうものにする。(in bailiwick name) {{{ $RANDOM.www.foo.com IN NS www.foo.com [authority section] www.foo.com IN A 6.6.6.6 [additional section] }}} ここでも www.foo.com (A レコード) がキャッシュされてないことが毒盛にとっては望ましい。 　今回の偽返答のAレコードは狭義のglue レコードである。 　しかし、BIND実装ではキャッシュにあるAレコードより優先順位が低いので、 受け入れないはずである。 glue として受け入れてもAとしての問い合わせには答えない、という実装もあると聞く。 TTLの満期のタイミングも問題になる。結局、毒盛確実とまでは言えない。（あるいはBINDの実装不良が関係したのか。） === www.foo.com Aレコードの毒入れは困難である === これまでの検討により、BIND実装になんらかの不良が存在したのでなければ、 Kaminskyの説明したようなAレコードの毒を入れることは困難だと判断する。 ただし、別の手法（NS攻略)による毒盛方法が存在することはすでに知られている。 === ISCが毒入れ成功と認めた理由はなにか === Kaminsky はまずはISCに連絡したらしい。なぜ、ISCはすぐに公表しなかったのか。 * Kaminsky は毒盛の可能性を示唆したが、必らずうまく行くとは言っていない。 * 簡単に毒盛されるサーバがあるので、port random 化は必須の対策だ。 * 本当の手口は公開したくない理由があった。 * 類似の手口は多数あって、まとめて防御するのは困難だ。 そして、ISCはDNSSECを売り込むために、危険性を強調したという疑惑である。 === もっと確実な毒盛手法 === port random 化が十分実施されたあとであれば、議論するという Kaminsky 提案に従う。 ヒントは検索："Bernhard Mueller re-delegation" ------ ３年が経過したので、もうはっきり書いても害は少ないだろう。 　最近になって、「Kaminsky講演のスライドにはバグがある。」とか言っている関係者もいる。 　　かつての説明は訂正されたのだろうか。 Aレコードをターゲットにした毒の混入はいろいろの防禦法がある。 NSレコードに視点を移してみよ。簡単かつ本質的に回避困難な方法がすぐに見つかる。 　　http://scientia.jpn.org/index.php?%A5%B3%A5%F3%A5%D4%A5%E5%A1%BC%A5%BF%B9%D6%BA%C22FKaminsky%20Attack それでも、[[DNS/DNSSEC]]が持ち出される根拠になるだろうか。 　どの程度の危険性があるのか、きちんとした評価が必要だ。 -- ToshinoriMaeno <>