------------------------------------------------------------------------ フォワーダを詐称したWindows DNSキャッシュポイゾニング 2007.4.16 (最終更新: 2007.11.26) 塩月 誠人 ---------- はじめに ---------- 約2年前、Windows DNSサーバのキャッシュポイゾニングに関する脆弱性がSANS Handler's Diaryによって報告された[1][2]。これは、Windows DNSがフォワーダ 設定をしている場合、たとえ「Pollutionに対してセキュリティでキャッシュを 保護する」という設定を有効にしていたとしても、キャッシュポイゾニング攻撃 によりDNSキャッシュが汚染されてしまうというものである。 Handler's Diaryによると、このキャッシュポイゾニング攻撃はフォワーダDNS サーバ自身にキャッシュポイゾニングの脆弱性がある場合か、またはフォワーダ DNSサーバがキャッシュポイゾニング攻撃に含まれる不正なリソースレコードを 除去しない場合に成功するとされている。それゆえこれらの問題を持たないBind 9等をフォワーダに使用すれば、Windows DNSに対するフォワーダ経由でのキャッ シュポイゾニング攻撃を防ぐことができると一般に考えられている。 しかし別の起こりうる攻撃シナリオが存在し、その場合、攻撃成功の可否はフォ ワーダDNSの種類やバージョンに依存しない。したがって、Windows DNSのキャッ シュポイゾニング攻撃に関するリスクは、一般に思われているよりも大きいとい える。 筆者が試した限り、Windows Server 2003 SP2のDNSサービスにも依然としてこの 脆弱性が存在している。 ---------------------------------- フォワーダ経由のポイゾニングとは ---------------------------------- Windows DNSには、「Pollutionに対してセキュリティでキャッシュを保護する」 というオプションがある。このオプションは、攻撃者がターゲットDNSサーバに 対し、自分の管理するDNSサーバに再帰的に問い合わせを行わせ、そのリプライ に第三者のドメインに関する不正なリソースレコード（RR）を混入させることで ターゲットDNSサーバのキャッシュを汚染させる、いわゆるDNSキャッシュポイゾ ニング攻撃を防ぐために存在する[3]。 だがWindows DNSがフォワーダとして他のDNSサーバを参照している場合、フォ ワーダからのリプライに不正なRRが混入していると、このオプションを有効にし ているにもかかわらず、その不正RRをキャッシュに入れてしまう。この現象は、 フォワーダからのリプライを無条件に信用し、第三者のドメインに関するものを 含むリプライ中のRRすべてをキャッシュするというWindows DNSの「仕様」に起 因していると思われる（図1）。 +-----------+ +-----------+ | | (1)Query | | | | -------------------------> | | | Attacker | | Windows | | | | DNS | | | | | | | | (Victim) |(6)Poisoned!! | | | | +-----------+ +-----------+ | ^ (2)Query | | (5)Answer | | (poisoning) v | +-----------+ +-----------+ | | (3)Query | | | | <------------------------- | | | Attacker | | Forwarder | | DNS | | DNS | | | | | | | -------------------------> | | | | (4)Answer(poisoning) | | +-----------+ +-----------+ 図1 フォワーダ経由のDNSキャッシュポイゾニング (1) AttackerはWindows DNSに対しAttacker DNSへの再帰的問合せを要求 (2) Windows DNSはForwarder DNSへ問合せをフォワード (3) Forwarder DNSはAttacker DNSに対し問合せを実行 (4) Attacker DNSは正規のAnswerの中に不正なRRを混入してリプライ (5) Forwarder DNSが不正なRRをそのままWindows DNSへ戻すと... (6) Windows DNSがリプライを受け入れることでキャッシュが汚染 このような環境下でWindows DNSのキャッシュが汚染される可能性として、以下 が考えられる。 1) フォワーダDNSにキャッシュポイゾニング脆弱性がある場合 2) フォワーダDNSが不正RRを浄化せずにリプライを戻す場合 3) フォワーダDNSを詐称してポイゾニング攻撃された場合 1のケースは、そもそもフォワーダDNSにキャッシュポイゾニングの脆弱性が存在 し、ゆえにフォワーダからのリプライにも不正RRが入ってくるため、それを受け るWindows DNSのキャッシュも汚染されるというものである。キャッシュポイゾ ニングの脆弱性を持つDNSサーバはインターネット上にそれほど多くないと考え られるため、実際にこのケースに該当するのは稀であろう。 2のケースは、フォワーダDNS自体にはキャッシュポイゾニングの脆弱性が存在し ないのだが、フォワーダDNSがリプライ中の不正RRを浄化せずにそのままWindows DNSへ渡す場合である。前出のSANS Handler's Diaryによれば、Bindバージョン4 およびバージョン8がフォワーダとして用いられている場合、このような振る舞 いをするとのことである。つまりBind 4/8をフォワーダとして使用している Windows DNSは、キャッシュポイゾニングの攻撃を受ける可能性があることにな る。 3のケースは、攻撃者がフォワーダDNSからのリプライを詐称して、不正RRを含む 偽リプライパケットをWindows DNSへ送りつけ、Windows DNSがそのリプライを受 け入れることで不正RRがキャッシュに入るというものである。DNSリプライパ ケットを詐称するためにはQuery IDを推測する必要があるが、バースデイアタッ クの理論を用いればこの攻撃はきわめて現実的なものとなる。 以下、この第3のケース、つまりフォワーダDNSを詐称したWindows DNSに対する キャッシュポイゾニング攻撃について解説する。 ---------------------------------- フォワーダを詐称したポイゾニング ---------------------------------- フォワーダからのリプライを詐称したキャッシュポイゾニングの基本的な流れを 図2に示す。 +-----------+ +-----------+ | | (1)Query | | | | -------------------------> | | | Attacker | | Windows | | | | DNS | | | | | | | -------------------------> | (Victim) |(6)Poisoned!! | | (5)Answer(poisoning) | | +-----------+ +-----------+ | | (2)Query | v +-----------+ +-----------+ | | (3)Query | | | | <------------------------- | | | Attacker | | Forwarder | | DNS | | DNS | | | | | | | (4) no reply | | | | | | +-----------+ +-----------+ 図2 フォワーダからのリプライを詐称したDNSキャッシュポイゾニング (1) AttackerはWindows DNSに対しAttacker DNSへの再帰的問合せを要求 (2) Windows DNSはForwarder DNSへ問合せをフォワード (3) Forwarder DNSはAttacker DNSに対し問合せを実行 (4) Attacker DNSはAnswerを返さない（返答しない） (5) AttackerがForwarderのリプライを装った不正RR入りリプライを送出 (6) Windows DNSがリプライを受け入れることでキャッシュが汚染 この攻撃が成功するためには、つまりWindows DNSが(5)の詐称リプライパケット を受け入れるためには、Attackerが送出する詐称リプライUDPパケットは以下の 条件を満たす必要がある。 1) フォワードしたリクエストのタイムアウト前に到着（デフォルト5秒） 2) ソースIPアドレスはForwarder DNSのIPアドレスと等しい 3) デスティネーションポートはWindows DNSのソースポートと等しい 4) フォワードしたリクエストとQuery IDが合致 Forwarder DNSからAttacker DNSに対してリクエストが来るので、Attacker側で Forwarder DNSのIPアドレスを知ることは容易である（条件2）。また詳細は後述 するが、Windows DNSのソースポート番号、つまり図2の(2)のパケットにおける ソースポート番号についても、基本的には推測が可能である（条件3）。あとは タイムアウトする前に（条件1）、Query IDが合致したパケット（条件4）を送り 込めばよい。ここでは、どのようにしてQuery IDを推測するかが重要なポイント となる。 ---------------------------------------- バースデイアタックによるQuery IDの推測 ---------------------------------------- DNSのQuery IDは、第三者から不正なリプライパケットが挿入されることを防ぐ ために、リクエストごとにランダムな値が割り当てられる。DNSサーバはリプラ イパケットを受け取る際に、Query IDを調べ、リクエストに割り当てたものと同 じQuery IDでなければそのリプライは破棄される。リクエストを受け取った正規 のDNSサーバは正しいQuery IDを知っているので、正しいリプライを返せるが、 第三者はQuery IDを正しく推測しない限り、リプライを偽造して挿入することが できない。 Query IDは2バイトの整数のため、そのとりうる値の範囲は65,536通りとなる。 一つのリクエストに割り当てられたQuery IDを単純に推測する場合、攻撃者は Query IDの値を0から65535まで変化させて65,536発のリプライを返せば、そのう ちのどれかはヒットするわけだが、このような総当り攻撃はタイムアウトの時間 を考えると、不可能ではないがあまり現実的とはいえない。 だが攻撃対象のDNSサーバが、同一内容の多数の問合せを同時並行的に処理する 場合、バースデイアタックの理論を用いることで、より少ないリプライパケット 数でQuery IDをヒットさせることが可能となる。 DNSリプライにおけるバースデイアタックの理論を簡単に説明すると、一つのリ クエストのQuery IDを推測するためには前述の通り65,536発のリプライが必要だ が、500発程度のリクエストとそれに対する500発程度のリプライがあれば、いず れかのQuery IDが合致する確率は80%を超えるというものである[4]。 すなわち、Windows DNSに対して500発程度の再帰的要求を発行し、フォワーダ経 由で問合せを行わせ、それに対する詐称リプライ（不正RR入り）をやはり500発 程度送りつける。フォワーダに対する500のリクエストのQuery ID（ランダムな 値）と、詐称した500のリプライのQuery ID（ランダムな値）は、そのいずれか が80%以上の確率で合致し、Windows DNSによって受け入れられる。しかも500発 と比較的少数であるため、タイムアウト時間内に攻撃を完了させることができ る。このリプライはフォワーダからのリプライを詐称しているので、その中に混 入している不正RRは前述の通り無条件にキャッシュされてしまうことになる（図 3）。 +-----------+ (1)Query +-----------+ | | -------------------------> | | | | -------------------------> | | | Attacker | -------------------------> | Windows | | | | DNS | | | -------------------------> | | | | -------------------------> | (Victim) |(6)Poisoned!! | | -------------------------> | | +-----------+ (5)Answer(poisoning) +-----------+ ||| ||| (2)Query ||| vvv +-----------+ (3)Query +-----------+ | | <------------------------- | | | | <------------------------- | | | Attacker | <------------------------- | Forwarder | | DNS | | DNS | | | | | | | (4) no reply | | | | | | +-----------+ +-----------+ 図3 バースデイアタックによりQuery IDを推測してポイゾニング (1) Windows DNSに対しAttacker DNSへの再帰的問合せを500発要求 (2) Windows DNSはForwarder DNSへ500の問合せをフォワード (3) Forwarder DNSはAttacker DNSに対し500の問合せを実行 (4) Attacker DNSはAnswerを返さない（返答しない） (5) Forwarderからのリプライを装った500の不正RR入りリプライを送出 (6) (2)のQueryと(5)のAnswerのいずれかでQuery IDが合致し、 Windows DNSでキャッシュが汚染 ------------------------------------- ターゲットDNSのポート番号を知るには ------------------------------------- さて前述の通り、攻撃者がターゲットWindows DNSに対して詐称リプライを送り つける際に、もう一つ推測しなければならない情報として、Windows DNS側のUDP ポート番号がある。すなわち、Windows DNSがフォワーダに対して発信したクエ リパケットのソースポート番号をいかにして知るかであるが、Windows DNSは フォワーダからのリプライが一定時間内に返らない場合、自分で再帰的に問合せ を行うようにデフォルトで設定されている。そのため、攻撃者がこのポート番号 を知ることは通常可能である（図4）。 +-----------+ +-----------+ | | (1)Query | | | | -------------------------> | | | Attacker | | Windows | | | | DNS | | | | | | | | (Victim) | | | | | +-----------+ +-----------+ / | -------- | (2)Query (5)Query / | ---------- v +-----------+ / +-----------+ | | <-------- (3)Query | | | | <------------------------- | | | Attacker | | Forwarder | | DNS | | DNS | | | | | | | (4) no reply | | | | | | +-----------+ +-----------+ 図4 フォワーダからのリプライが返らないとWindows DNSは自ら問合せる (1) AttackerはWindows DNSに対しAttacker DNSへの再帰的問合せを要求 (2) Windows DNSはForwarder DNSへ問合せをフォワード (3) Forwarder DNSはAttacker DNSに対し問合せを実行 (4) Attacker DNSはAnswerを返さない（返答しない） (5) Windows DNSはForwarderからの返答が来ないので自らAttacker DNS へ問合せを実行（デフォルト設定の場合） Windows DNSがクエリで使用するUDPソースポート番号は、サービスが再起動しな い限り常に固定であるため、このようにして一度ソースポート番号を調べ、その 番号を詐称リプライパケットのデスティネーションポートに指定すればよい。 Windows DNS側でこのデフォルトの振る舞いを変更し、フォワーダ以外には問合 せに行かないようにするには、DNSのフォワーダ設定で「このドメインに再帰を 使わない」を有効にする必要がある。その場合でも、攻撃者はWindows DNSホス トに対してUDPポートスキャンを行い、1024以上で開いているUDPポートを特定す ることができれば、それらのポートを試すことでDNSが使用しているソースポー トを推測することが可能である。 ------------------ 影響を受ける製品 ------------------ Windows Server 2003のDNSサービス（〜SP2） Windows 2000 ServerのDNSサービス（〜SP4） ------------------ ベンダの対応状況 ------------------ 本件については2006年11月にIPAに対し「ソフトウエア製品脆弱性関連情報」と して届出を行い、2007年2月にIPA経由で「これはWindows DNSのデザインに基づ いた動作であり、今後サービスパックレベル等でのデザインの変更を検討してい る」という趣旨のベンダからの返答を受けた。ただし筆者が試した限り、2007年 4月にリリースされたWindows Server 2003のSP2でも、依然として修正されてい ない模様である。 なおIPAに対する当該届出については、既知の脆弱性であることから2007年2月26 日をもってその取り扱いが終了された。（取扱い番号 IPA#39710635） ------ 対策 ------ Windows DNSの設定にてフォワーダの使用を停止する。 -------------------- 問題を緩和する要素 -------------------- Windows DNSサーバに対するサイト外部からの再帰的問合せを、ファイアウォー ル等で拒否する。それによりインターネットからの直接的な攻撃の可能性を低減 させることができる。 ---------- おわりに ---------- ここで述べてきたとおり、Windows DNSサービスはフォワーダの設定をしている 場合、キャッシュポイゾニング攻撃によってキャッシュに不正なリソース情報を 挿入されてしまう危険性が高い。これは既に公開されている既知の脆弱性である が、そのリスクの大きさについてはあまり認識されていないと思われる。 インターネット環境でWindows DNSサーバを使用しているサイトは、フォワーダ 設定を停止するか、外部からの再帰的問合せを拒否するような運用をすることが 求められる。またベンダに対しては、早期の修正を望みたい。 なおここで解説したDNSへの攻撃手法を用い、他者が管理するDNSサーバに対して 許可無く攻撃を行った場合、その行為は電子計算機損壊等業務妨害罪あるいは不 正アクセス罪に相当すると考えられる。 ---------- 参考文献 ---------- [1] March 2005 DNS Poisoning Summary http://isc.sans.org/presentations/dnspoisoning.html [2] SANS/ISC Handler's Diary April 7th 2005 http://isc.sans.org/diary.php?date=2005-04-07 [3] DNSキャッシュ破壊の防止策 http://support.microsoft.com/kb/241352 [4] DNS Cache Poisoning - The Next Generation http://www.lurhq.com/cachepoisoning.html ---------------- 2007.11.26追記 ---------------- 2007年11月14日にWindows DNSのセキュリティ更新プログラムMS07-062が公開さ れた。この更新プログラムは、Windows 2000 ServerおよびWindows Server 2003 のDNSサービスにおいて、Query IDが容易に推測できるという新たに報告された 脆弱性を修正するものである。脆弱性の詳細については以下のサイトで公開され ている。 Windows DNS Server Cache Poisoning http://www.trusteer.com/docs/windowsdns.html この更新プログラムの適用により、Query IDの生成方法が改善され、Query IDは 容易に推測することができなくなる。 Windows Server 2003 SP1/SP2に本更新プログラムを適用してテストしてみたが、 この更新プログラムはさらに、以前からのWindows DNSの特徴であった「同一内 容の多数の問合せを同時並行的に処理する」という性質についても改善を施した 模様である。つまり本更新プログラム適用後は、バースデイアタックの手法を用 いてWindows DNSのQuery IDを推測することも基本的にはできない。 ただしフォワーダ経由であれば「Pollutionに対してセキュリティでキャッシュ を保護する」という設定を有効にしていてもキャッシュが汚染されてしまうとい う問題自体は、この更新プログラムでも修正されていないため、Windows DNSで フォワーダを使用している場合は依然としてキャッシュ汚染に関する注意が必要 とされる。 ------------------------------------------------------------------------