初夏にネームサーバ管理者を襲う「毒混入事件」：Security Incident Report

複数のDNSソフトウェアにおけるDNSキャッシュポイズニングの脆弱性について、改めて注意喚起が行われている。リソースレコードのTTLが極端に短いネームサーバの管理者は特に、すべてのネームサーバ管理者は週末を迎える前に再度チェックしておきたい。

　7月22日以降、複数のDNSソフトウェアにおけるDNSキャッシュポイズニングの脆弱性について、改めて注意喚起が行われている。

　複数のDNS実装にキャッシュポイズニングの脆弱性があるという報告は、7月8日にUS-CERTから発表されていたが、7月22日以降にこの問題に対する注意喚起が活発に行われているのは、この脆弱性の攻撃手法に関する情報が誤って公開されてしまったためである。当初は8月に開催予定の「Black Hat」カンファレンスで詳細が発表される予定だったが、このタイミングで情報が万人の知るところとなったことで、すでにこの脆弱性を使用した攻撃用プログラムの存在も確認されているという。毒入りネームサーバとならないよう、ネームサーバの管理者は至急対応すべき状況にある。

DNSキャッシュポイズニングの脆弱性はなぜ危険なのか

　DNSキャッシュポイズニングとは、DNSキャッシュサーバ（リゾルバ）がDNSサーバに名前解決を行う際、DNSサーバの応答より速く偽のDNS情報をリゾルバに渡すことで、ユーザーをフィッシングサイトなどに誘導するもの。

　この問題の原因は、DNSプロトコル自身が持つ脆弱性に起因するが、中でもDNSパケットの中に含まれる識別IDが16ビット、つまり6万5536個しかないことも攻撃者にとって有利に働いている。偽装したDNSパケットの中のIDをランダムに変化させながら渡すことで、リゾルバの問い合わせ頻度が高くなるようなケース、つまり、リソースレコードのTTLが30秒など極端に短い場合などでは、非常に短時間でキャッシュポイズニングに成功してしまうことが分かっている。詳細については日本レジストリサービスの民田雅人氏が2007年1月に発表した資料を参照するとよいだろう。

　キャッシュポイズニングに対する根本的な解決策としては、リゾルバからの問い合わせに対する応答に、デジタル署名を施してデータの改ざんを検知可能にするDNSSEC（DNS Security Extensions）などが挙げられるが、応答パケットが大きくなったり、その管理の手間などから現実的にはDNSSECの採用はそう簡単ではないことは現場の管理者はご存じのことだろう。DNSSECの採用を検討項目に挙げるのは後にして、まずは今の問題を解決していきたい。

パッチの適用を終えたらネットワークの再点検を

　この脆弱性への最初の対策としては、パッチの適用が挙げられる。BINDの開発元であるISC（Internet Systems Consortium）、Microsoft、Ciscoをはじめベンダー各社からはすでにアドバイザリや修正パッチなどがリリースされており、速やかにそれらを適用する必要がある。ただし、これらの対策の多くが、それまで弱い形でしか実装していなかったソースポートランダム化を図ったものである点に注意しておく必要がある。つまり、現時点では「キャッシュポイズニングが成立する確率を可能な限り下げること」がパッチ適用の目的であり、問題の根本的な解決とはなっていない点で継続して注視すべき脆弱性であると言える。

　また、目先の問題もパッチの適用と再起動だけで済む話ではない。例えばDebian Projectのサイトでは、BINDパッケージについての詳細なセキュリティ情報が確認できる。パッチの適用後、問題が解決したかを確認するため、クエリごとにUDPソースポートが変化しているかどうか、または、リゾルバの前にNATデバイスがある場合、NATによってソースポートのランダム性が損なわれていないかなどを確認する必要があるとしている。そのほか、Debian GNU/LinuxやFedoraでは、クエリのソースポートを固定する「query-sourceport 53;」「query-source-v6 port 53;」といった設定がnamed.confに記述されている可能性がある。この場合、該当行を削除するか、記載されているポート番号を「*」に置き換える必要があるとしている。

　こうしてクエリのソースポートがランダムに変化するようになると、今度は一部のファイアウォールやIDS（侵入検知システム）が誤動作や誤検知を起こす可能性をつぶす作業が発生する。外部からDNSクエリを受け付けているネームサーバならrecursiveクエリを拒否する設定をするなど、ネットワークの多くに見直しが必要となる部分が発生するだろう。

　なお、こうしてパッチを当てることで、リゾルバのパフォーマンスが若干低下することも報告されているので、この点が気になる管理者は注意したい。ISCでは現在、パフォーマンスの問題を解決するための緊急リリースを計画しているという。

　なお、BIND 8ではクエリソースポートのランダム化を実装することが困難であるとされている。すでにISCはBIND 9に専念する方針を固めているため、BIND 8のユーザーは、BIND 9に移行するか、ソースポートランダム化機能を持つ別の実装に切り替えることをすぐにでも検討すべきだろう。