ダン・カミンスキー氏は先ごろDNSサーバーに存在するセキュリティ・ホールを発見したが，多くの情報を伏せていた。そしてIT業界に広く働きかけた結果，複数のDNS関連ベンダーが修正パッチを公開してきた。ところが，同氏はセキュリティ・ホールの技術的詳細を公開していないにもかかわらず，関連情報が誤って米マタサノ・セキュリティのブログから大量に漏れてしまったらしい（関連記事：DNSサーバーに見つかったぜい弱性の詳細が公開，すぐにパッチの適用を）。
編集部注：このDNSサーバーのぜい弱性について，カミンスキー氏は8月に開催されたBlack Hatで情報を公開した（関連記事：カミンスキー氏，DNS脆弱性について詳細を公開--Black Hatカンファレンスで）。
同氏は2008年8月開催のセキュリティ会議「Black Hat」で詳細情報を公表する予定だが，漏えいブログ記事（既に削除済み）と同じ内容かどうかについて，現在のところ何とも言えない。ただし，同ブログで示された悪用シナリオは，インターネット全体にとって極めて深刻な脅威となる。この脅威は，情報漏えい後にたくさんのブログ（その2，その2）や記事で議論された通り，DNSプロトコルに存在する二つの問題が原因である。
（1）ソース・ポートとトランザクションIDの予測：
DNSは問い合わせの送信と返答えの受信を実行する際，主にUDPパケットを使う。クライアントが「www.bob.com」のIPアドレスを導き出すルックアップ処理について，ごく単純化した例を以下の図で示す。
図1●正常なDNSルックアップ処理
DNSが問い合わせ（要求）と返答（応答）で使用するUDPパケットは，以下のように簡単な構造をしている。
図2●DNSパケット
このクライアントは，DNSサーバーから届いたパケットを例外なく問い合わせに対する答えとみなし，こうした応答パケット（Answer Packet）のソース・ポート（SP1）/デスティネーション・ポート（DP1）と要求パケット（Question Packet）のデスティネーション・ポート（DP1）/ソース・ポート（SP1）を付き合わせる。さらに重要なのは，応答パケットのトランザクションID（TID1）と問い合わせ内容（Q1）を，実際に送ったものと比べることだ。ここで攻撃者がクライアントの通信相手であるDNSサーバーをかたり，ソース・ポートとトランザクションIDの予測もできれば（デスティネーション・ポートは通常53番），応答パケットの偽装が可能となる。ただし，攻撃者は本物のDNSサーバーの出した本物の応答パケットよりも先に偽装応答パケットをクライアントまで届けなければならない。この攻撃の仕組みを以下の図で簡単にまとめた。
図3●DNS攻撃のシナリオ
（2）追加リソース・レコード：
DNSサーバーは要求パケットに応答する際，その後の処理を効率化する目的で，応答パケットに追加情報を入れることができる。クライアントから問い合わされたDNSサーバーが「www.bob.comのIPアドレスは？」といった内容の要求パケットをbob.comドメインのDNSサーバーに送ったとすると，これに対応する応答パケットは次のような構造になる。
図4●正常な応答DNSパケット
この応答パケットの最後には追加情報として，bob.comドメイン用ネーム・サーバー「ns1.bob.com」と「ns2.bob.com」のIPアドレス「1.1.1.254」と「1.1.1.244」が記載されている。その後，クライアント側のDNSサーバーがbob.comドメイン配下にある別マシン「mail.bob.com」のIPアドレスを調べる場合，要求パケットを1.1.1.254または1.1.1.244というIPアドレスのDNSサーバーに直接送る。
この二つの問題を組み合わせると，もっと興味深い状況になる。攻撃者がソース・ポートとトランザクションIDの予測に成功し（一つ目の問題），攻撃用DNSサーバーのIPアドレスを答えるDNSサーバーに関する情報を追加情報として偽装した応答パケットに入れると（二つ目の問題），ドメインあてのトラフィックを自由に制御できるのだ。この攻撃用の偽装応答パケットを以下に示す。
図5●攻撃用DNSパケット
単純明快な手口に見えるものの，この攻撃を成功させるにはソース・ポートとトランザクションIDという二つの情報を予測することが欠かせない。実際に攻撃を行うには，本物のDNSサーバーの応答パケットがクライアントに届く前の段階で，攻撃者は何度も繰り返し試行錯誤して正しいDNS要求のソース・ポートとトランザクションIDを当てる必要がある。ただし，すべてのDNSサーバーが完全にランダムなトランザクションIDを使っているわけではない。さらに，短時間に似たようなルックアップ処理を行う場合，同一DNSサーバーに対する接続には同じソース・ポートを使う例もあるようだ。このような動きをするDNSサーバーかどうかは，攻撃者の管理しているドメインに対するルックアップ処理を実行させる偵察用パケットを送りつければ確認できる。「誕生日攻撃」（訳注：ある集団に同じ誕生日の人がいる確率は，直感的な値より相当高い。このように「滅多なことでは当てられるはずはない」という思い込みを逆手に取って攻撃を行う手法）など別の戦略と組み合わせると，比較的少ない回数の試行錯誤でソース・ポートとトランザクションIDの予測が可能となる。
クライアントのDNSサーバーが，内部ネットワークのランダムなソース・ポートを値の連続した外部向けソース・ポートに割り当てる（もしくはソース・ポートの割り当てパターンが決まっている）ような，低レベルな変換処理を行うNetwork Address Translation（NAT）デバイスの背後にあると，もっと深刻な事態になる。このような状況の場合，攻撃成功に必要な試行錯誤の回数が減ってしまう。
注意しておいてほしいことがある。攻撃が成功した場合の影響は，DNSサーバーにキャッシュ・ポイズニング攻撃が仕掛けられた場合の方が大きい。ただし，今回のぜい弱性はDNSクライアントおよびサーバーそのものに存在するのだ。自分の使っているDNSサーバーが安全かどうか知りたければ，カミンスキー氏のツール「DNS CHECKER」を使うか，米サンズのサンズ・ダイアリーに掲載されている指示に従えば確認できる。米マカフィーのセキュリティ製品系列「McAfee Network Security Platform」（旧名称は「IntruShield」）のユーザーは，「sigset4.1.30.4」「sigset 3.1.67.3」でリリースされた攻撃シグネチャID「0×40303200」で保護される。
DNSプロトコルには，カミンスキー氏がBlack Hatで発表する問題以外にも極めて重大な問題があるだろう。
Copyrights (C) 2008 McAfee, Inc. All rights reserved.
本記事の内容は執筆時点のものであり，含まれている情報やリンクの正確性，完全性，妥当性について保証するものではありません。
◆この記事は，マカフィーの許可を得て，米国のセキュリティ・ラボであるMcAfee Avert Labsの研究員が執筆するブログMcAfee Avert Labs Blogの記事を抜粋して日本語化したものです。オリジナルの記事は，「“The-Cat-is-Out-of-The-Bag” DNS Bug」でお読みいただけます。
