1. DNS/毒盛/Kaminsky講演/スライド(16 - 18)
注：BlackHat Japan 2008 のスライドが見えますが、いくつか途中が省略されていて、#10-12 が対応しています。
スライド番号を読み変えてください。-- ToshinoriMaeno 2009-08-06 08:08:50
Kaminsky blogが移転していたので、2008 年のBlackhat の講演videoを発掘してきました。 http://www.vimeo.com/17247507 スライド
TTL に関係なく、多数の問合せを送らせることが可能なキャッシュサーバがあったときに、 問い合わせと偽返答のtransaction ID が合致し、キャッシュサーバは偽返答を受け取るものとします。
2. どうすれば、なにを騙ることができるか
毒耐性のないキャッシュサーバに対して、DNSプロトコルに従った返答を送りつけるとしたときに、 「どうすれば、なにを騙ることができるか」について検討する。
Kaminsky のスライドの説明のままでは、手元の筆者の環境では毒盛できなかったのがきっかけである。
以下、Kaminsky の説明にそって、検討する。
2.1. 目的は www.foo.com を騙ること
"He wanted www.foo.com." (これは当然ながら、A レコードのこと)
2.2. どこに問合せさせているか
スライド(16)を追ってみると foo.com サーバだとわかる。
2.2.1. スライド(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 の効果で攻撃回数に制約があるので、今回の方法が登場する。
2.2.2. スライド(18)
- $RANDOM.foo.com についての query を送りつける。(start)
- 200個 の偽返答を送る。
- 偽返答は以下の通り (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 の返答は整合していないから、このままでは受け取られない。 つまり、毒盛できない。少なくとも一方に間違いがある。
2.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]- だと解釈するのが妥当だ。
2.4. www.foo.com の A レコードが書き換えできるか
しかし、上の偽返答の www.foo.com A レコード (glue)でキャッシュの書き換えができるのだろうか。
そういう脆弱なキャッシュ(bind-?)も存在したのだろう。それなら毒盛は簡単だ。
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 への毒盛だけでは意味をもたない。
2.5. 修正案 (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の実装不良が関係したのか。）
2.6. www.foo.com Aレコードの毒入れは困難である
これまでの検討により、BIND実装になんらかの不良が存在したのでなければ、 Kaminskyの説明したようなAレコードの毒を入れることは困難だと判断する。 ただし、別の手法（NS攻略)による毒盛方法が存在することはすでに知られている。
2.7. ISCが毒入れ成功と認めた理由はなにか
Kaminsky はまずはISCに連絡したらしい。なぜ、ISCはすぐに公表しなかったのか。
- Kaminsky は毒盛の可能性を示唆したが、必らずうまく行くとは言っていない。
- 簡単に毒盛されるサーバがあるので、port random 化は必須の対策だ。
- 本当の手口は公開したくない理由があった。
- 類似の手口は多数あって、まとめて防御するのは困難だ。
そして、ISCはDNSSECを売り込むために、危険性を強調したという疑惑である。
2.8. もっと確実な毒盛手法
port random 化が十分実施されたあとであれば、議論するという Kaminsky 提案に従う。
- ヒントは検索："Bernhard Mueller re-delegation"
３年が経過したので、もうはっきり書いても害は少ないだろう。
- 最近になって、「Kaminsky講演のスライドにはバグがある。」とか言っている関係者もいる。
- かつての説明は訂正されたのだろうか。
Aレコードをターゲットにした毒の混入はいろいろの防禦法がある。
NSレコードに視点を移してみよ。簡単かつ本質的に回避困難な方法がすぐに見つかる。
それでも、DNS/DNSSECが持ち出される根拠になるだろうか。
- どの程度の危険性があるのか、きちんとした評価が必要だ。
-- ToshinoriMaeno 2011-05-21 02:42:51