年: 2005年

DNSキャッシュ汚染

BINDのバグの多さに辟易して2000年にdjbdnsに乗り換えてからBINDを使っていないのですがDNSキャッシュ汚染問題はまだまだ続いているようです。

DNS ‘pharming’ attacks target .com domain で広範囲なDNSキャッシュ汚染攻撃があったとニュースになっています。

SANSのブログによると

1,304 domains poisoned (pulled from the referer entries in the HTTPD logs)

と、1,300以上のDNSキャッシュ汚染(DNS cache poisoning)エントリが見つかったと書いています。

セキュリティに詳しい方には古い問題ですがなかなか改善されていません。私自身も昨年、日本のあるISPにDNS設定の問題を連絡したのですが、知合いのシステム管理者からISPから変更の連絡あったと聞いていないのできっとまだ改善されていないと思います。ISPでさえもこのレベルなので日曜DNS管理者(私もDNS管理を専門としていないので日曜DNS管理者ですが)が設定したDNSサーバに問題があっても当然かもしれません。

これから書く事を理解するためにはDNSサーバとDNSキャッシュを明確に区別する必要があります。example.comドメインを例に説明します。example.comのDNSサーバはexample.comドメインに権限を持ち、www.example.com, ftp,example.com等、example.comのサブドメインにホストを登録できます。一方、DNSキャッシュはDNS問い合わせをクライアントに代わって行うサーバです。DNSキャッシュサーバはトップレベルドメインから目的のホストのIPアドレスを取得するまで再帰的にDNS問い合わせを行い、結果をキャッシュします。ISP等が”DNSサーバ”と呼んでいるのは通上はDNSキャッシュサーバです。BINDでは再帰問い合わせに答えるサーバがDNSキャッシュサーバになります。

DNSサーバを構築する場合、DNSサーバとDNSキャッシュは別サーバとしなければならない、のですがBINDの悪いデザインのためDNSサーバとDNSキャッシュが同じサーバに設定できるようになっています。しかも、古いBINDではデフォルトで全てのクライアントから再帰問い合わせを受け付けるように設定されていました。このため、間違ったDNSサーバ設定方法ドキュメントが大量に再生産／再利用され現在でも間違った設定のDNSサーバが大量に存在します。

example.comドメインでDNSサーバとDNSキャッシュが同じDNSプログラム(BINDなど)で実行されていると、DNSキャッシュが汚染されるとexample.com以下のwww.example.com,ftp.example.comヘのアクセスを別のIPアドレスのサーバに誘導する事が可能です。SSLのサイト証明を使用していないと http://www.example.com/ へアクセスしたユーザは意図しているサイトにアクセスしているか、偽サイトにアクセスしているか全く区別がつきません。
# HTTP Response Splitting Attackでも同じ効果をHTTPキャッシュを汚染し
# 偽サイトを表示させることも出来ますが、DNSキャッシュ汚染に比べると
# DNSキャッシュ汚染の方が強力な攻撃方法です。

DNSが安全でないことはqmailとdjbdnsの作者として有名なDan J. Bernstein氏が詳しく説明しています。

DNSを安全に利用する為には

• DNSサーバとDNSキャッシュは必ず別サーバにする
• DNSキャッシュサーバは必要なクライアント(社内クライアントなど)のみ問い合わせを受け付ける
• ISPが提供するDNSキャッシュ(DNSサーバ)は利用しない
• DNSキャッシュサーバは権限のあるDNSサーバ(Authoritative DNS)からの応答のみをキャッシュするサーバ(djbdnsのdnscacheなど)を使用する

などの対策が必要です。これらの対策を行ってもDNSサーバとDNSキャッシュを同じサーバプログラムで実行しているサイトでDNSキャッシュ汚染があると偽ホストにアクセスしていても普通は気が付かないでしょう。

The importance of separating DNS caches from DNS serversの中で指摘されているようにBINDのマニュアルでもDNSサーバとDNSキャッシュを必ず別するよう書いてあます。DNSキャッシュとDNSサーバを同じサーバに設定しても構わない場合は、分離されているネットワークシステムの実験環境などでDNSを使えるするようにする、など非常に限定された状況しかありません。本来、DNSサーバプログラムはDNSサーバとDNSキャッシュは別プログラムとして提供されるべき物です。djbdnsではDNSサーバ(tinydns)とDNSキャッシュ(dnscache)プログラムは別プログラムになっており、DNSサーバとDNSキャッシュは別サーバとして動作します。当然ですが最近作られたDNSサーバプログラムはDNSキャッシュとDNSサーバは別サーバととして動作します。

個人的にはsendmailの様に捨てられるサーバプログラムになっても構わないのですが、ISCはいつになったら壊れたBINDのデザインを修正するつもりなのでしょうね?

追記：念のために書いておきますがDNSキャッシュ汚染はdnscacheを使っていても可能です。dnscacheの場合汚染がより難しいだけです。DNSキャッシュ汚染は仕組の問題であるためプログラムでは修正できません。通常、ISP以外の組織がDNSキャッシュを公開する必要はなく、また公開DNSキャッシュを運用するべきではありません。

不正アクセスとは?

個人的にはACCSの訴えに合理性を全く感じられなかったのですが、日本のコンピュータセキュリティ上非常に影響が大きい判決が出てしまった様です。

個人的には関連性を見出してしまう発言が政治家からありました。片山元総務大臣はインターネットも放送と同じく公共性を持たせ規制するべき、と言う旨の発言があったようです。

自民党の片山虎之助参院幹事長はフジテレビの番組で、「放送とインターネットは（役割が）似てきた。法的な環境の整備も含めて考える必要がある」と述べ、【インターネットにも放送法のような公共性を求める法規制を整備する必要があるとの認識を示した】（日経）

http://www.janjan.jp/media/0503/0503285040/1.php

一見全く関係ないようですが、ACCS裁判の裁判官と片山幹事長は同じ間違い、国境さえもない完全にボーダーレスなインターネットの世界に無理矢理現在の都合のよい(?)世界観を適用させようとする間違い、をしていると思います。

考え方を変えないと録画サーバサービスの例もあるように色々な問題が発生し、その度に騒ぎになると思います。

野放しがよいとは思いませんが、なんらかの規制を行う場合はその必要性と実効性をよく検討し、既得権益を持つ者の道具にならないような形で規制してもらいたいものです。

カーネルrootkit

最近カーネルrootkitがまた話題になっています。カーネルrootkitへの対処策ソリューションを提供し始めたからの様です。

First Winternals/Sysinternals did their RootkitRevealer
Then Microsoft started fear-mongering
Now F-Secure jumped on the bandwagon with their Blacklight Beta

rootkitとはバックグラウンドで動作してシステムの利用状況を記録したり、バックドアを開けてリモートから管理者権限でシステムを使用できるようにするプログラムの総称です。

全てのrootkitが良くないか、と言うとそうでは無い場合もあります。システム管理者がネットワーク上のコンピュータを管理する為に開発されたrootkitもあり、これらのツールはネットワークシステム管理者にとって非常に便利です。

問題なのはadware、malwareと呼ばれるプログラムにユーザが意図しないrootkitが含まれていたり、ウィルスに含まれていたりする事です。これらのrootkitはSPAMメールの送信に利用されたり、ユーザがどのようなWebページをブラウズしているか記録する為に利用される事がほとんどです。しかし、その気になれば銀行のWebアカウントへログインする為のユーザ名とパスワードを盗む事も簡単です。

通上のrootkitの検出はプロセスの一覧を見ることで簡単に検出できます。ファイルシステム上を検索する事により不審なファイルを捜す事によっても検出できます。しかし、カーネルレベルrootkitの検出は簡単ではありません。カーネルレベルrootkitは文字どおりカーネルレベルで動作しプロセスの一覧、ファイルの一覧などを取得するシステムコールを横取りし、rootkitのプロセス、ファイルの存在を隠してしまいます。この隠蔽はカーネルレベルで行われているため、一旦インストールされてしまうとユーザレベルで実行されるアンチウィルス対策は全く役に立ちません。

snort等のIDS(Intrusion Detection System)を使えばネットワークトラフィックから検出できると思われるかも知れませんが、例えばHacker Defenderの場合、135番ポートで通信し他のWindowsアプリも正常に動作するため通常の状態ではsnortで検出できません。

Microsoft Resarchの場合、カーネルrootkitもCross View Diffと呼ばれるテクニックで検出するようにしたようです。詳しい、説明はリンク先を見て頂くとして、より低いレベルでのスキャンとAPI出力の差分からrootkitを検出するという手法です。現在確認されているrootkitは検出可能ですがどのような方法を取ったとしてもイタチごっこの様な気もします。

ちなみにこの手のカーネルrootkitはWindows用ばかりではありません。当然ですがLinux用のカーネルrootkitも多数存在します。

今すぐrootkitが入っていないか確認したい！と言う場合、検査するシステムのHDDを取り外し、信頼できるシステムにマウントしてrootkitファイルが無いか確認すると良いでしょう。