PR

 DNSサーバーの役割は,ユーザー(Webブラウザなどのプログラム)からの要求に対してアドレス解決することである。例えば,「www.example.com」のアドレス解決を要求されたDNSサーバーは,もしキャッシュに保存されていればそのIPアドレスを,保存されていなければ「www.example.com」の情報を管理するDNSサーバーに,www.example.comのIPアドレスを問い合わせる(DNSサーバーの動作については,「DNS完全マスター」 に詳しい)。

 つまり,ユーザーから問い合わせを受けたDNSサーバーは,example.comドメインのDNSサーバーへwww.example.comのIPアドレスを問い合わせる。example.comのDNSサーバーは,www.example.comのIPアドレス「1.2.3.4」を返す——。これだけなら当然問題はない。だが,このとき,例えば「www.example.netのIPアドレスも1.2.3.4」という情報を,example.comのDNSサーバーが返したとする。

 この情報を疑いもなくキャッシュしてしまうと,ユーザーがwww.example.netにアクセスしようと名前解決すると,“毒”を盛られたDNSサーバーは,ユーザーに対して「1.2.3.4」を返してしまう。これにより,www.example.netへのアクセスは,www.example.com(1.2.3.4)へリダイレクトされることになる。

 example.comのDNSサーバーは,www.example.netに対してauthority(権威,権限)がない。このため,www.example.netに関する情報を信用してはいけないはず。だが,DNSキャッシュ・ポイズニング攻撃を許すような脆弱性を持つDNSサーバーは,この偽情報を信用してしまうのだ。

 前述のページで,D. J. Bernstein氏は次のように書いている。「It's obvious how to eliminate all poisoning. Caches must discard yahoo.com information except from the yahoo.com servers, the com servers, and the root servers. This stops malicious poisoning, so of course it stops accidental poisoning too. End of problem.」。この言葉にあるように,例えばyahoo.comドメインのアドレス解決をする場合には,ルート(.)およびcom,そしてyahoo.comのDNSサーバー以外からの情報を捨てるようにすれば,毒を盛られる心配はない。

 実際,1997年のインシデント以降,「返された結果を鵜呑みにしないことが(DNS)キャッシュ・サーバーの実装として“MUST”になった」(日本レジストリサービス(JPRS)技術研究部の民田雅人氏)。

 とはいえ,実際には実装のミスなどで,DNSキャッシュ・ポイズニング攻撃を許す脆弱性が見つかる場合がある。前述のように,最近ではSymantecのセキュリティ・ゲートウエイ製品に含まれるDNSサーバー(DNSd)に見つかった。ただしこれについても,開発者がDNSキャッシュ・ポイズニングを考慮していなかったということは,まず考えられない。詳細は明らかにされていないが,「当然検証するように実装していたが,ある環境や条件によっては検証をすり抜けるようなミスがあったようだ」(シマンテック 法人営業事業部のエグゼクティブシステムエンジニア 野々下幸治氏)。

 なお,「DNSポイズニング攻撃」と呼ばれる攻撃もある。これは,「DNSキャッシュ・ポイズニング攻撃」そのものである場合もあるが,一般的には,DNSポイズニング攻撃のほうが,より広い意味を持つようだ。

 きちんとした定義はないものの,資料や専門家からの話を総合すると,DNSポイズニング攻撃は「名前解決時にクライアント・ソフトへ嘘のIPアドレス情報を渡して,偽サイトにリダイレクトする攻撃全般」を指す場合が多いようだ。つまり,クライアント・マシンの「hosts」ファイルの書き換えなども含めるという。「単に『ポイズニング(攻撃)』と呼ぶ場合もあるようだ」(ラック 研究開発本部 コンピュータセキュリティ研究所所長の岩井博樹氏)

 以上のように,とても古い攻撃の一つであるDNSキャッシュ・ポイズニング攻撃。SANS Instituteは3月以降,この攻撃が原因と思われるインシデントを報告し始めた。「なぜ今さらDNSキャッシュ・ポイズニング?」と思ったのは,筆者だけではないだろう。SANSでは,それらの内容や原因などを分析したレポートを公表しているので,明日は引き続き,そのレポートに基づいて,今回のインシデントを追ってみたい。また,筆者が取材をした専門家の見方もお伝えする。

(勝村 幸博=IT Pro)