BIND各バージョンへの毒入れ実験
(Kaminsky Bug の検証)

実験目的

Kaminsky が示した毒入れ手法は DNSプロトコルの欠陥によるものであり、非常に危険なものであるという論を根拠に DNSSEC が推進されている。しかし、BlackHat USA 2008 における Kaminsky の講演のスライドに示されている方法にはいろいろな点で疑義がある(Finchなど)。qmail.jp の前野氏からあれで毒が入ると思うかとの指摘を受けたこともあり、散々考えたが、私には Kaminsky のスライドどおりに毒が入ることがどうしても納得いかなかった。そして、Kaminskyが間違っている(あるいは嘘をついている)、あるいは、BIND には毒が入るバグがあって Kaminsky の攻撃手法が成功するというのではないかという仮説が引き出せる。これは前野氏が当初から洞察していたことであった。この仮説に基づくと、Kaminsky の発表から3年経った今、そのバグが修正されているかもしれないという疑惑が浮かび上がる。

今回、Kaminsky がスライドで示した毒入れ手法で本当に毒が入り、DNSSEC 以外では回避不可能なのか、あるいは対策可能なバグであり場合によっては直っていたりはしないかを調べるため、実際にBINDに対して毒入れ実験を行うこととした。

Kaminsky のスライドには怪しいTYPOも含め疑義が多いため、民田氏(JPRS)が100％毒が入るとして紹介した比較的疑義の少ない(怪しい形式ではあるがその理由は説明されていない)バリエーション(IW2008-H3-07)を加え、4種のバリエーションを試行した。

実験方法

• 脆弱性検証ツール: metasploit-3.3.3 の bailiwicked_host モジュール(バグがある)を独自改良したもの
• 実験環境: FreeBSD 8-STABLE の VIMAGE jail の中に、攻撃者サーバ[192.168.1.222]、ルートサーバ[192.168.1.50]、example.nom権威サーバ[192.168.1.52]、被攻撃BINDサーバ[192.168.1.51]を用意し、dummynetによって権威サーバとの通信には200msの遅延を入れて攻撃時間を確保

  ルートサーバ 192.168.1.50 の設定 (tinydns)
  .:192.168.1.50:ns.root.tss:518400
  &example.nom:192.168.1.52:ns.example.nom:86400
  権威サーバ 192.168.1.52 の設定 (tinydns)
  Zexample.nom:ns.example.nom:tss.example.nom.:2011082901:3600:1800:604800:60:30:
  .example.nom:192.168.1.52:ns.example.nom:86400
  +www.example.nom:192.168.1.53:3600

• 実験方法: $random.example.nom の Aレコードを実験対象のBINDキャッシュサーバ(port 53固定で初期状態ではキャッシュは空という条件)に問い合わせ、Transaction ID を変化させながら100の偽応答を送りつける。$random を変化させながらキャッシュに偽応答が受け入れられるまでこれを繰り返す。
• 偽応答は次の4種類について実験を行った。

  	AA flag	Answer Section	Authority Section	Additional Section
  (1)	1	$random.example.nom	$random.example.nom IN NS www.example.nom	www.example.nom IN A 192.0.2.1
  (2)	1	$random.example.nom	example.nom IN NS www.example.nom	www.example.nom IN A 192.0.2.1
  (3)	0		$random.example.nom IN NS www.example.nom	www.example.nom IN A 192.0.2.1
  (4)	0		example.nom IN NS www.example.nom	www.example.nom IN A 192.0.2.1

毒入れ実験結果

• Poisoned: 被攻撃サーバに非再帰問い合わせ (dnsq a www.example.nom 対象サーバ) すると answerとして応答がある。キャッシュダンプでは additional A として取り込まれていることがわかる。
• PseudoGlue: キャッシュダンプをとると glue(BIND用語 ダンプにおいてN+Aにglueというラベルがつく) として隔離されている。
  $random.example.nom のためだけの glue(BIND用語) として扱われているようで www.example.nom のAレコードを置き換える毒として役立たない(応答に使われない)。
• Isolated: キャッシュダンプをとると additional A としてキャッシュされていることがわかるものの、www.example.nom のAレコードを問い合わせても応答に用いられない。(例)
• Refetch: 偽応答が被攻撃サーバに受け入れられても($random.example.nomがキャッシュに入る)、キャッシュにはauthority や additional section も含め本物のデータが取り込まれていて www.example.nom を問い合わせると本物のanswerが返る。ルートサーバ、example.nomの権威サーバのquery ログから、偽応答が受け入れられた時点で www.example.nom を確認するqueryが自発的に行われていることがわかる。(例)
• Not Injected: 偽応答が受け入れられてもキャッシュされない。(なお実験中になぜか被攻撃サーバが ns.example.nom の AAAA レコードを上位に問い合わせる現象が見られる。偽応答の検証動作か?)

実験結果まとめ

1. BlackHat における Kaminsky のスライドそのまま(answerなし)では毒は入らない
   
2. ダミーの Answer を加える(民田氏の紹介した手法)とBlackHat当時の BIND には毒(Additional A)が入る (AAフラグは関係なさそう)
3. AuthoritativeなAnswerがあらかじめキャッシュにあると毒は入らない(上記に示していないが別途実験) <---これ重要!
4. 9.5系以降については、'09年11月～'10年1月のCVE-2009-4022 の対応以降、今回試した攻撃バリエーションでは毒は入らない
5. 9.4系では ESV-R3 まで毒が入る。9.4.3-P5 で CVE-2009-4022 に対応したはずだが、別なバグか? (9.4-ESV-R4 2786. [bug] Additional could be promoted to answer. [RT #20663] ? )
6. 別途実験した外部名へのRe-Delegation攻撃では最新版(9.8.1)でも毒を入れることができる (詳細省略)

結論

偽応答の Additional A で狙いのAレコードに毒を入れられるというのはDNSプロトコルの脆弱性ではなくBINDの脆弱性であり、2009年末にすでに対策済みである(9.4だけ2011年9月)。そもそもAnswerがあるのだからそれに付随するレコード(glueではない!)を受け入れざるを得ないという話はなくDNSプロトコルの脆弱性ではない。対策はタイミングからみて CVE-2009-4022 2786. [bug] Additional could be promoted to answer. [RT #20663] でとられたとみられるが、詳しくは語られていない。真実を語らず、対策もでているのに明示せず、脅威を煽るのはいかがなものか。
一方、詳しく述べていないが、Glueに毒を入れ偽委譲先で狙うAレコードに毒を入れることは可能である。しかしエントロピを増やすとか、ファイアウォールなどでアドホックな対策もとりうるのであるから、運用ミスの危険性まで冒してDNSSECを導入しようという話に持っていく必然性はないと考える。

参考

• CAU-EX-2008-0002
• BIND 9の脆弱性を利用したキャッシュポイズニング攻撃について(第3版) 2010/01/20
• CVE-2009-4022
• BIND Vulnerability Matrix