1. DNS/毒盛/Kaminsky講演/スライド(16 - 18)

注:BlackHat Japan 2008 のスライドが見えますが、いくつか途中が省略されていて、#10-12 が対応しています。

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)

  1. $RANDOM.foo.com についての query を送りつける。(start)
  2. 200個 の偽返答を送る。
  3. 偽返答は以下の通り (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 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)でキャッシュの書き換えができるのだろうか。

DNS/毒盛/Kaminsky手法/毒盛対策

Kaminsky が 2008 年初めにこの方法で毒盛できると言ったときに、 Paul Vixie らはそれを認めたのだろうか。

  port 固定という大きな穴の存在を認めたあとでは
  毒盛の手法は大した問題ではないことは事実なのだが。

偽返答内の www.foo.com A レコード(additional)を受け入れることに疑問がある。

仮に(広義の)glueであるとしても、以下のような動作をするキャッシュサーバなら うえの方法では"毒盛できない"と考える。(unbound などを試してみよ)

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 レコード) がキャッシュされてないことが毒盛にとっては望ましい。

glue として受け入れてもAとしての問い合わせには答えない、という実装もあると聞く。

TTLの満期のタイミングも問題になる。結局、毒盛確実とまでは言えない。(あるいはBINDの実装不良が関係したのか。)

2.6. www.foo.com Aレコードの毒入れは困難である

これまでの検討により、BIND実装になんらかの不良が存在したのでなければ、 Kaminskyの説明したようなAレコードの毒を入れることは困難だと判断する。 ただし、別の手法(NS攻略)による毒盛方法が存在することはすでに知られている。

2.7. ISCが毒入れ成功と認めた理由はなにか

Kaminsky はまずはISCに連絡したらしい。なぜ、ISCはすぐに公表しなかったのか。

そして、ISCはDNSSECを売り込むために、危険性を強調したという疑惑である。

2.8. もっと確実な毒盛手法

port random 化が十分実施されたあとであれば、議論するという Kaminsky 提案に従う。


3年が経過したので、もうはっきり書いても害は少ないだろう。

Aレコードをターゲットにした毒の混入はいろいろの防禦法がある。

NSレコードに視点を移してみよ。簡単かつ本質的に回避困難な方法がすぐに見つかる。

それでも、DNS/DNSSECが持ち出される根拠になるだろうか。

-- ToshinoriMaeno 2011-05-21 02:42:51

MoinQ: DNS/毒盛/Kaminsky手法/講演/スライド(18) (last edited 2021-05-02 07:00:32 by ToshinoriMaeno)