カミンスキー氏が発表したDNSアタック手法と対策例：DNSキャッシュポイズニングの影響と対策（前編）（1/4 ページ）
2008年7月に公開されたDNSキャッシュポイズニングの脆弱性。DNSの仕様に深く関係するこの手法に対して、エンジニアはどのように対策を打つべきでしょうか。この脆弱性の本質的な問題と対策、そして私たちが考えなくてはならないセキュリティの心構えなど、2回に分けてお送りします（編集部）
※ご注意
本記事に掲載した行為を自身の管理下にないネットワーク、コンピュータに行った場合は、攻撃行為と判断される場合があり、最悪の場合、法的措置を取られる可能性もあります。また、今回紹介するツールの中には、攻撃行為に利用されるという観点から、アンチウイルスソフトにウイルスとして検出されるものも存在します。このような調査を行う場合は、くれぐれも許可を取ったうえで、自身の管理下にあるネットワークやサーバに対してのみ行ってください。
また、本記事を利用した行為による問題に関しましては、筆者およびアイティメディア株式会社は一切責任を負いかねます。ご了承ください。
インターネットの世界を揺るがす攻撃手法が公開される
DNSの代表的な役割は、IPアドレスとドメイン名、そしてFQDN（完全修飾ドメイン名）を結び付けることにあります。通常この組み合わせはドメインを所有する組織、および個人が、そのドメインを管理するDNSサーバ（コンテンツDNSサーバ、あるいはAuthoritative DNSサーバ）に対して設定を行うことで、そのリソースを必要とするクライアント、およびインターネット全体に公開することが可能になります。
DNSサーバの機能が、ドメイン情報を公開するコンテンツDNSと、公開されているコンテンツDNSの情報を検索するキャッシュDNSの2つに分かれていることは、おそらく読者の皆さまはすでにご存じのことと思います。この機能に関する詳細は、連載「もう一度見直したいDNS／DHCP」をご参照ください。
もしこのIPアドレスとドメイン名の組み合わせを第三者が自由に変更できたら……？ 当然の話ですが、DNSという名前解決システムが成り立たなくなるばかりでなく、DNSの仕組みを利用して成長したインターネットの世界が成り立たなくなってしまいます。
2008年7月、ダン・カミンスキー（Dan Kaminsky）氏により、キャッシュDNSサーバが本来得られる正しい検索結果は、攻撃者による詐称が可能であることが分かりました。これによって、意図しないIPアドレスとドメイン名／FQDNをキャッシュDNSサーバに仕込むことが可能であることが判明しました。過去にもこのたぐいのセキュリティホールや、攻撃手法は存在していましたが、今回の攻撃手法は深刻で、あらゆるキャッシュDNSサーバに対して影響する手法となっています。
そのため、DNSキャッシュポイズニング対策は、インターネットを利用する誰もが意識しなければならない重要な課題の1つとなった、といっても過言ではないと考えます。本記事では「もう一度見直したいDNS／DHCP」同様、BIND9を利用した環境を例にし、この問題に関する攻撃手法と対処を深くご紹介していきたいと思います。
【注】
本記事執筆に当たり、NTT情報流通プラットフォーム研究所 豊野剛氏による“DNS Cache Poisoningの概要と対処”を参考にしました。こちらも併せてご参照ください。
DNS Cache Poisoningの概要と対処http://www.nttv6.net/files/DKA-20080723.pdf
カミンスキー氏が発見したDNSアタック手法と影響
まずは、図1をご覧ください。
（1）dummy1.nosuchdomain.comに関する正規DNSクエリ
(nosuchdomain.comは存在するが、dummy1というホストは存在しない)
（2）（1）の通信に対する再帰問い合わせ
（3）（2）に対する正規応答（dummy1.nosuchdomain.comはNXDOMAIN／存在しない、という応答）
（3'）dummy1.nosuchdomain.comについての詐称応答
応答に利用する通信元IPアドレスは、本来の、答えを返すはずのDNSサーバのIPアドレスを詐称する。また、DNS通信に含むトランザクションIDとADDITIONAL SECTION内容も適宜詐称する。
●詐称された応答内容例：
ANSWER SECTION
dummy1.nosuchdomain.com xxD IN A 攻撃者が誘導したいIPアドレス
AUTHORITY SECTION
AuthoritativeDNS xxD IN NS 詐称したいドメイン（1）
AuthoritativeDNS xxD IN NS 詐称したいドメイン（2）
：
AuthoritativeDNS xxD IN NS 詐称したいドメイン（n）
ADDITIONAL SECTION
詐称したいドメイン（1） xxD IN A 攻撃者が誘導したいIPアドレス
詐称したいドメイン（2） xxD IN A 攻撃者が誘導したいIPアドレス
：
詐称したいドメイン（n） xxD IN A 攻撃者が誘導したいIPアドレス
（4）,（5）正規ユーザーによる正規DNSクエリとその応答
図1 攻撃手法概要
（1）で攻撃者は、存在しないFQDN（FQDNに含まれるドメイン名は存在しても構わない）に対する再帰DNSクエリをキャッシュDNSサーバに送信します。このクエリに対しキャッシュDNSサーバは再帰問い合わせを行います。キャッシュを保持していない場合は、ルートDNSサーバへ再帰問い合わせを行います。これが（2）の通信になります。
再帰問い合わせの対象となるFQDNは存在しないため、（3）のように、この通信で得られるクエリ結果はどこかのDNSサーバでNXDOMAINが返却されることが本来の結果となるはずです。FQDNに含まれるドメイン名が存在しない場合はルートDNSサーバから、存在するドメイン名であればそのドメイン名を管理するAuthoritative DNSサーバから返答されます。
では、もしキャッシュDNSサーバがAuthoritative DNSサーバから（3）の応答を得る前に、攻撃者から虚偽の応答（3'）を受け取ったらどうなるでしょうか。そして、その虚偽の応答（3'）の通信元をキャッシュDNSサーバが信用してしまったらどうなるでしょうか。実際、キャッシュDNSサーバは、下記条件に一致したDNS応答を信頼し、自身のキャッシュに蓄えてしまいます。
・自身がDNSクエリした際に利用したSource IPアドレス／ポートあての応答であること
・自身がDNSクエリした際に利用したトランザクションID（TXID）に対するDNS応答であること
攻撃者は本来の答えを返すべきAuthoritative DNSサーバになりすまし、想定できるDNSクエリポート番号とTXIDを類推し、総当たり（ブルートフォース）で虚偽応答を仕掛けてきます。
(1)で行うクエリに”存在しないFQDN”を用いることで、攻撃試行チャンスを実質的に無限に増やし、総当り攻撃の成功確率を圧倒的に高くできることが、今回の攻撃手法のポイントとなります。従来は、TTLが短い実在するFQDNの乗っ取りについて、そのTTLの切れ目(キャッシュ期限切れ)を狙って攻撃されやすいが指摘されていました
さらに、この虚偽応答にADDITIONAL SECTIONを含ませることで、任意のドメイン／FQDNの組み合わせ情報をキャッシュることも可能です。ADDITIONAL SECTIONに含まれる情報は攻撃者が自由に設定することが可能であるため、これによりさらに広範なドメイン名とFQDNの詐称が可能になるのです。
このような攻撃手法を話題にした場合、机上の話ではないか、という声も聞こえてきますが、実際に下記のように攻撃を試みることは容易に可能です。すでにこの手法を用いたツールは公開されており、ちょっとしたUNIXコマンドが利用できれば容易に確認できます。
Copyright © ITmedia, Inc. All Rights Reserved.