---------------------------------------------------------------------
■「ghost domain names（幽霊ドメイン名）」脆弱性について
株式会社日本レジストリサービス（JPRS）
初版作成 2012/02/17（Fri）
最終更新 2012/04/05（Thu）
（BIND 9における対応状況、解決策を追加）
---------------------------------------------------------------------
▼本文書について
2012年2月8日（米国時間）に開催された研究発表会「NDSS Symposium 2012」
において、清華大学のHaixin Duan（段海新）氏らのグループが「Ghost
Domain Names: Revoked Yet Still Resolvable」と題した論文を発表しまし
た。この論文では、複数のキャッシュDNSサーバーの実装・サービスに、これ
まで知られていなかった脆弱性が存在することが報告されています。
また、この論文発表に先立つ2012年2月7日（米国時間）、BINDの開発元であ
るISCが緊急のセキュリティアドバイザリを公開し、論文発表時点における
BIND 9のすべてのバージョンが、この脆弱性の影響を受けることを公表しま
した。
本文書では今回発表された脆弱性に関し、以下の項目について記述します。
（2012年4月5日追加）
ISCから今回の脆弱性に対応したBIND 9.9.0/9.8.2/9.7.5/9.6-ESV-R6がリリー
スされています。詳細は下記「解決策」を併せてご参照ください。
・背景
・概要
・技術的背景
- NSレコードの信頼度
- キャッシュの更新ポリシー
・攻撃のシナリオ例
・影響範囲
- 影響を受ける実装・サービス
- 影響を受けない実装・サービス
- 特記事項
・解決策 （2012年4月5日更新）
- サーバーソフトウェアの更新・切り替え
- 適切なアクセスコントロールの実施
- 定期的なキャッシュデータのクリア
・参考リンク
▼背景
フィッシングやボットネットの制御、マルウェアの伝播など、不正な目的で
使われているドメイン名を強制的に使用不能にする際の有効な手段として、
TLDレジストリなどの親ゾーンにおいて、委任情報（NSレコード）を強制的
に削除することが行われています。
しかし、今回発表された論文では、親ゾーンで委任情報が削除されたことに
より、本来であれば名前解決が不可能になるはずのドメイン名を、委任情報
の削除後も長期にわたって名前解決可能、つまり使用可能な状態にし続ける
ように仕向けることができる脆弱性が存在することが報告されました。
そこでは、BIND 9を始めとする複数のキャッシュDNSサーバーの実装、及び
公開キャッシュDNSサービスがこの脆弱性の影響を受けること、インターネッ
トに存在するオープンリゾルバーを用いた検証により、調査対象のうち70％
以上のサーバーがこの脆弱性の影響を受けたことなどが具体的な攻撃方法と
共に示されました。
論文では、この脆弱性によりキャッシュDNSサーバーにおいて名前解決可能
な状態にさせられ続けてしまうドメイン名を「ghost domain names」と呼ん
でいます。以降、本文書ではこれを示す用語として「幽霊ドメイン名」を使
用します。
▼概要
DNSには、権威DNSサーバーで公開されたデータを無効にする（revoke）ため
のしくみや、権威DNSサーバーから各キャッシュDNSサーバーに対し、データ
を能動的に伝えるしくみがありません。そのため、親ゾーンの権威DNSサー
バーにおいて委任情報が削除されたことを各キャッシュDNSサーバーに対し
て能動的に伝えることは不可能です。
そのため、各キャッシュDNSサーバー側で親ゾーンの委任情報の状態を必要
に応じてチェックし、もし親ゾーンが委任情報を削除した場合、当該ゾーン
の委任先からの情報を受け取らないように、適切に実装する必要があります。
しかし、現在のDNSプロトコルでは親ゾーンの委任情報の削除の検出や、そ
の後の処理における具体的な手法が明確に規定／定義されておらず、実装依
存の事項となっています。
今回の脆弱性はこうした背景から、キャッシュDNSサーバーの実装／動作に
起因する新しい攻撃手法が発見されたことにより、顕在化したものです。
▼技術的背景
今回の脆弱性の技術的背景となった二つの事項、NSレコードの信頼度とキャッ
シュの更新ポリシーについて解説します。
▽NSレコードの信頼度
親ゾーンにおける子ゾーンへの委任情報はNSレコードで記述します。例えば、
jpゾーンにおいてexample.jpゾーンへの委任情報を記述する場合、以下のよ
うになります。
（親ゾーンにおける設定内容）
example.jp. 86400 IN NS ns1.example.jp.
ns1.example.jp. 86400 IN A 192.0.2.1
NSレコードは子ゾーンにおいても記述します。子ゾーンにおけるNSレコード
は自身が当該ゾーンの権威を持つこと、すなわち、当該ゾーンを管理する権
限があることを提示するために使われます。
DNSの仕様の明確化について定めたRFC 2181では、NSレコードは子ゾーンで
設定されるもののみが権威を持ち、親ゾーンで設定されるNSレコードよりも
高い信頼度（trustworthiness）で取り扱うように規定されています。その
ため、現在のキャッシュDNSサーバーの実装では親のNSレコードは委任情報
として正しい委任先（子）を得る目的のみに使用し、子ゾーンで設定される
NSレコードを優先的に使用する形が主流となっています。
▽キャッシュの更新ポリシー
権威DNSサーバーが権威を持つ応答を返す際、権威を持つことを提示するた
め、AUTHORITYセクションに自身の持つNSレコードを設定します。以下は
www.example.jpのAレコードを検索した際、example.jpゾーンの権威DNSサー
バーであるns1.example.jpからキャッシュDNSサーバーに返される応答を示
しています。
（キャッシュDNSサーバーに返される応答）
;; ANSWER SECTION
www.example.jp. 86400 IN A 192.0.2.10
;; AUTHORITY SECTION
example.jp. 86400 IN NS ns1.example.jp.
;; ADDITIONAL SECTION
ns1.example.jp. 86400 IN A 192.0.2.1
この応答内容は、キャッシュDNSサーバーにおいてキャッシュされます。
それから40000秒後に、そのキャッシュDNSサーバーを利用しているユーザー
がwww2.example.jpのAレコードを検索し、ns1.example.jpからキャッシュ
DNSサーバーに、以下の応答が返されたとします。
（キャッシュDNSサーバーに返される応答）
;; ANSWER SECTION
www2.example.jp. 86400 IN A 192.0.2.11
;; AUTHORITY SECTION
example.jp. 86400 IN NS ns1.example.jp.
;; ADDITIONAL SECTION
ns1.example.jp. 86400 IN A 192.0.2.1
この応答を受け取った時点で、キャッシュDNSサーバーのキャッシュには前
回受け取った応答のキャッシュ情報として、以下が格納されています。
（キャッシュDNSサーバー上のキャッシュの内容：
40000秒経過したため、TTL値が46400に減算されている）
www.example.jp. 46400 IN A 192.0.2.10
example.jp. 46400 IN NS ns1.example.jp.
ns1.example.jp. 46400 IN A 192.0.2.1
この際、既にキャッシュされているexample.jpのNSレコードと、今回受け取っ
た応答に記述されているexample.jpのNSレコードは、同じ信頼度を持ってい
ます。
このような、既にキャッシュされているexample.jpのNSレコードと同じ信頼
度を持つNSレコードをキャッシュDNSサーバーが受け取った場合、それを新
しいものに置き換える（上書きする）かどうかは現在のDNSプロトコルでは
明確に規定されておらず、実装依存の事項となっています。
▼攻撃のシナリオ例
論文に記述されている攻撃シナリオに基づいた、攻撃手法の概要を解説しま
す。以下の例では親ゾーンをjp、子ゾーンをexample.jpとします。
1）攻撃者は親ゾーン（jp）の委任情報が削除される前に、攻撃対象のキャッ
シュDNSサーバーに対し、自身の制御下にある子ゾーン（example.jp）に
属する任意のドメイン名、例えばwww.example.jpのAレコードを検索させ
るように仕向けます。
2）応答を受け取ったキャッシュDNSサーバーには、以下の情報がキャッシュ
されます。
（キャッシュDNSサーバー上のキャッシュの内容）
www.example.jp. 86400 IN A 192.0.2.10
example.jp. 86400 IN NS ns1.example.jp.
ns1.example.jp. 86400 IN A 192.0.2.1
3）親ゾーンにおいて委任情報が削除されます。
4）攻撃者は自身の制御下にあるIPアドレス192.0.2.1で動作している
example.jpの権威DNSサーバーのデータを、以下のように書き換えます。
（権威DNSサーバー上の設定内容）
example.jp. 86400 IN NS ns2.example.jp.
ns2.example.jp. 86400 IN A 192.0.2.1
5）その後、攻撃者はキャッシュデータのTTLが満了する前（例えば 1）から
40000秒後）に攻撃対象のキャッシュDNSサーバーに対し、
ns2.example.jpのAレコードを検索させるように仕向けます。
6）キャッシュDNSサーバーはキャッシュされているNS情報を参照し、
ns1.example.jpのIPアドレスである、192.0.2.1に問い合わせを送ります。
その結果、キャッシュDNSサーバーは以下の応答を受け取ります。この応
答のNSレコードは前述の通り、1）で受け取った応答と同じ信頼度を持っ
ています。
（キャッシュDNSサーバーに返される応答）
;; ANSWER SECTION
ns2.example.jp. 86400 IN A 192.0.2.1
;; AUTHORITY SECTION
example.jp. 86400 IN NS ns2.example.jp.
;; ADDITIONAL SECTION
ns2.example.jp. 86400 IN A 192.0.2.1
7）応答を受け取った時点で、キャッシュDNSサーバーのキャッシュには前回
受け取った応答に由来するキャッシュ情報として、以下が格納されてい
ます。
（キャッシュDNSサーバー上のキャッシュの内容：
40000秒経過したため、TTL値が46400に減算されている）
www.example.jp. 46400 IN A 192.0.2.10
example.jp. 46400 IN NS ns1.example.jp.
ns1.example.jp. 46400 IN A 192.0.2.1
この応答によってキャッシュDNSサーバーの既存のNSレコードのキャッシュ
データが上書きされた場合、今回の脆弱性による攻撃が成立します。
（キャッシュDNSサーバー上のキャッシュの内容：
当該レコードが上書きされる）
www.example.jp. 46400 IN A 192.0.2.10
example.jp. 86400 IN NS ns2.example.jp.
ns1.example.jp. 46400 IN A 192.0.2.1
ns2.example.jp. 86400 IN A 192.0.2.1
8）以降、4）からの手順を繰り返すことにより、事実上無期限にキャッシュ
の期限切れを延長できます。
▼影響範囲
▽影響を受ける実装・サービス
論文及びISCのセキュリティアドバイザリによると、以下の実装が今回の脆
弱性の影響を受けます。
・論文発表時点におけるBIND 9のすべてのバージョン
・djbdns 1.05に付属のdnscache
・Unbound 1.4.7以前
・PowerDNS recursor 3.3
・Windows Server 2008に付属のMicrosoft DNS
また、以下の公開キャッシュDNSサービスがこの脆弱性の影響を受けます。
・DNS Advantage
・OpenDNS
・Norton DNS
・GTEI DNS
▽影響を受けない実装・サービス
以下の実装及び公開キャッシュDNSサービスは、この脆弱性の影響を受けま
せん。
・BIND 9.9.0/9.8.2/9.7.5/9.6-ESV-R6以降 （2012年4月5日追加）
・Unbound 1.4.8以降
・MaraDNS
・Windows Server 2008 R2に付属のMicrosoft DNS
・Google Public DNS
▽特記事項
この脆弱性の影響を受けるのはキャッシュDNSサーバーのみであり、再帰検
索要求を受け付けないように設定されている権威DNSサーバーでは、この脆
弱性の影響を受けません。
この脆弱性により、現在使用中のドメイン名の権限が奪われることはありま
せん。
▼解決策 （2012年4月5日更新）
▽サーバーソフトウェアの更新・切り替え
2012年2月～4月にリリースされたBIND 9.9.0/9.8.2/9.7.5/9.6-ESV-R6、及
びUnbound 1.4.8以降（2012年4月5日現在の最新版は1.4.16）にはこの脆弱
性を回避するためのコードが含まれており、攻撃に対する耐性を備えていま
す。また、Windows Server 2008 R2に付属のMicrosoft DNSは、この脆弱性
の影響を受けないと報告されています。
このため、キャッシュDNSサーバーをこれらのソフトウェアに更新・切り替
えることにより、この脆弱性を回避できます。
なお、MaraDNSもこの脆弱性の影響を受けないと報告されていますが、NSレ
コードの取り扱いがRFC 2181で定められている仕様に従っておらず、権威
DNSサーバーの引っ越しなどにおいて悪影響を及ぼす可能性があり、導入に
は注意が必要です。
▽適切なアクセスコントロールの実施
キャッシュDNSサーバーにおける適切なアクセスコントロールの実施により、
この脆弱性による危険性を低減できます。ただし、この方法は根本的な問題
解決とはならないことに注意が必要です。
▽定期的なキャッシュデータのクリア
この脆弱性は、親ゾーンにおいて委任情報が削除された時点でキャッシュ
DNSサーバーにキャッシュされていなかったドメイン名には影響を与えませ
ん。そのため、キャッシュDNSサーバーにおいて定期的なキャッシュデータ
のクリアを実施することにより、危険性を低減できます。
▼参考リンク
Network and IT Security Conference: NDSS 2012
<http://www.isoc.org/isoc/conferences/ndss/12/>
（「NDSS Symposium 2012」公式ページ）
Ghost Domain Name: Revoked Yet Still Resolvable (in NDSS 2012)
<http://netsec.ccert.edu.cn/duanhx/archives/1313>
（Haixin Duan（段海新）氏による公式ページ）
Ghost Domain Names: Revoked Yet Still Resolvable
<https://www.isc.org/software/bind/advisories/cve-2012-1033>
（ISCによるセキュリティアドバイザリ）
CVE-2012-1033
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1033>
（CVE情報）
JVNVU#542123 複数の DNS ネームサーバの実装に問題
<https://jvn.jp/cert/JVNVU542123/>
（JVNの脆弱性レポート）
---------------------------------------------------------------------
▼更新履歴
2012-02-17 12:00 初版作成
2012-04-05 14:00 BIND 9における対応状況、解決策を追加
株式会社日本レジストリサービス Copyright©2001-2024 Japan Registry Services Co., Ltd.