手を変え品を変えて続くDNSキャッシュ「汚染」攻撃

3月初めより報告されているDNSキャッシュポイズニング攻撃の手口は、わずかな期間のうちにより巧妙に変化しており、注意が必要だ。

[高橋睦美，ITmedia]

　3月初めより報告され始めた「DNSキャッシュポイズニング」攻撃の手口は、より巧妙なものに変化しているようだ。米SANSのInternet Storm Centerは、これまでのDNSキャッシュポイズニング攻撃の概要をまとめるとともに、警戒を呼びかけている。JPCERT/CCによると、今のところ国内ではこれに類するインシデントは報告されていないというが、手口が進化しているだけに注意が必要だ。

　DNSは、人間にとって分かりやすい名前である「ドメイン名」と、ネット上の一意の住所である「IPアドレス」の変換を行い道しるべ役を果たす、インターネットの根幹を担うといってもいいサービスだ。Webへのアクセスもメールの配送も、基本的にはこのDNSに頼っている。

　DNSキャッシュポイズニング攻撃は、DNS実装の脆弱性を突いて設定（レコード）を書き換え、毒（＝偽情報）を仕込む手法だ。この結果ユーザーは、普段利用しているWebサイトにアクセスしているつもりが、まったく別の場所に誘導される。下手をすれば、フィッシング詐欺やスパイウェアのインストールを行う悪質なWebサイトに、そうとは知らぬままアクセスすることになる。

　DNSキャッシュポイズニング攻撃は古くから存在した。たとえば、もっとも広く利用されているDNS実装である「BIND」の古いバージョンにもこの脆弱性が存在しており、過去にはAlterNICによるInterNICのドメイン乗っ取り事件などに悪用されたことがある。

三度の波状攻撃

　SANSによれば、ここ1カ月余りの間に三波に分かれて起こっているDNSポイズニング攻撃は、より複雑な手口を用いている。どうやら金稼ぎを目的とした行為のようだ。

　1度目の攻撃は2月22日から3月12日にかけて発生し、少なくとも1304ものドメインが攻撃を受けた（関連記事）。このとき攻撃者は、Symantecのゲートウェイ製品に存在する脆弱性を悪用して、DNSキャッシュを「毒入り」情報に書き換え、Internet Explorerの脆弱性を突いてスパイウェアをインストールさせるWebサイトにユーザーを誘導しようとした。

　2度目の攻撃は3月25日に発生した。今度は、Windows NT 4.0／2000のDNSサーバを狙ってDNSキャッシュ情報の書き換えを行い、医薬品販売を行うWebサイトに誘導させようとした。いわゆる「スパムメール」と同じ役割を果たしたわけだ。これらのプラットフォームが搭載するDNSサーバは、デフォルト設定のままではDNSキャッシュポイズニング攻撃に対して無防備であり、マイクロソフトの技術情報にしたがってレジストリを変更するのが望ましい。

　並行して3度目の攻撃が発生し、4月1日まで続いた。これは1度目の攻撃の続きと見られ、同じくスパイウェアをインストールさせようとする悪意あるWebサイトに誘導を試みる。

　一連の攻撃では、Symantecのゲートウェイ製品に存在する脆弱性やWindowsのデフォルト設定を突いてDNSキャッシュ情報の書き換えが行われているほか、適切な設定を行ったはずのWindows NT 4.0／2000、Windows Server 2003や、問題が解決されているはずのBINDを稼動させているサイトでも、攻撃を受けたとの報告が寄せられているという（これらのシステムについては、設定の不備／ミスがあった可能性も指摘されている）。

　さらに、偽の情報をアドバタイズする悪意あるDNSサーバの存在までが確認された（関連記事）。この悪意あるDNSサーバは、問い合わせを行うと毒入り情報を返すという形でDNSサーバ自身を攻撃する。この結果、.comサイトを閲覧しようとしたユーザーが、攻撃者の運営するWebサイトにリダイレクトされることになった。

　このように、一口にDNSキャッシュポイズニングといってもその手口は多様であり、わずかな期間のうちに複雑化している。攻撃者は複数の手法とツール、IPアドレスを使い分けながら「汚染」を広げようと試みている。

　SANSはさらに、「同様の手口が.netや.org、あるいは他のccTLDに適用される可能性がある。また、より目先の利く攻撃者は、特定のホスト名だけを乗っ取り、ほかのクエリについては正しい結果を返すように細工することで、攻撃を気づかれにくくする可能性もあり、潜在的な危険性はさらに大きい」旨を指摘している。

　では、被害を防ぐにはどうすべきか。根本的な対策としてはDNSSECの導入が挙げられるだろうが、残念ながらあまり現実的な解ではない。

　SANSはまず第一に、管理下のDNSサーバのキャッシュ情報が汚染されていないか、またシステムがスパイウェアに感染していないかどうかを確認するよう推奨している。

　もし無事だったとしても、今後のDNSキャッシュポイズニング攻撃を防ぐために、手元の製品に脆弱性が存在しないかを確認し、最新のものにアップデートすることが重要だ。また、SANSが公表している悪意あるDNSサーバへのアクセスをブロックする（そのためのSnort用シグネチャも公開されている）とともに、DNS検索を受ける範囲を限定するなどの手立ても必要になるだろう。