カテゴリー: Security

カード暗証番号入力の問題

クレジットカード利用時に不必要な電話番号の記入を強要するカード加盟店は昨年の記入された電話番号を悪用した事例のおかげでやっと無くなりました。カード規約には書名でサービスを利用できると明記されているので私はいつも電話番号記入は拒否していました。電話番号の記入を求める加盟店はまずカードの署名と伝票の署名が一致しているか確認していませでした。海外では署名を確認しない、ということはあり得ないのですが日本では確認しない加盟店の方が今でも多いくらいです。署名を確認されないと私は非常に不満なのですが、署名を確認されると不満に感じる利用者も多い(?)ということかも知れません。

もっと読む

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が安全でないことはqmaildjbdnsの作者として有名な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ファイルが無いか確認すると良いでしょう。

IEのセキュリティーホール

CERTも放っておくわけには… 2004/12/2 US-CERTのメールから。

TA04-315A describes a buffer overflow vulnerability in Microsoft Internet Explorer HTML elements that could allow a remote attacker to execute arbitrary code. Note that any program that hosts the WebBrowser ActiveX control could be affected. Microsoft Security Bulletin MS04-040 contains an update to fix this vulnerability.

The vulnerability is described in further detail in VU#842160.

URL: http://www.us-cert.gov/cas/techalerts/TA04-336A.html

「サーバ」に対する誤った認識

要は個人でサーバを立てるな、と言う話。巷には「簡単サーバ構築」本が溢れていますがサーバ構築と運用は「簡単」ではない、と言うことが完結にまとまっています。すばらしい。
私も以前から悶々と考えていた事が丁寧に記載されています。

# Webセキュリティー関係の基礎をwikiにまとめてアップしたいですね。
# 題して「Webプログラミング」に対する誤った認識、かな。(進歩は真似からはじまる by yohgaki

Windows XP SP2に脆弱性

Inetnet Watchによると

米セキュリティベンダーのFinjan Softwareは10日、Windows XP SP2に深刻な脆弱性が10件発見されたと発表した。同社ではすでにMicrosoftに連絡しているという。

だそうです。

Pukiwikiページ改竄

先日私のPukiwikiのページが荒しにあいました。初めての荒しでしたが、ついに来たかと、さっさとバックアップを使ってページを回復し気にせず放っておいたのですが、どうも他のサイトも荒しあったようです。

ググってみるとPukiwikiの開発日記にこの荒しと関連していると思われる記載がありました。これによると荒しにも関わらず不正侵入で書き換えたようなメッセージが表示されていましたがご丁寧にもzone-hにまで登録したらしい… 恥じを知らないクラッカーですね。

HTTP Response Splitting Attack: PHPの場合

ここの日記にも書いたHTTP Response Splitting Attackの対策がPHPでも取られるようです。

header(“bad-header: This is bad header\r\n but having CR/LF in a haeder is allowed by the standard in some case.”);

上記のヘッダが送られた際に\r\nを自動削除可能な設定が追加されます。ただし、\r\nがヘッダ中に現れる事は標準で認められいいますが、パッチを適用したPHPの場合は拒否&警告エラー(php.ini設定のデフォルト値になる)が発生します。もちろん「不正なユーザ入力対策は万全」というサイト向けではそのままCR/LFを送ることも可能です。次のPHPリリース時には取り込まれていると思いますが、仕様が変わっているかも知れないのでChangeLogなどで確認する必要があります。

未対策のアプリがあるサーバはエラーハンドラ(必ず作ってますよね。PHPプログラマの方!)で処理するだけです。普通にエラー処理しているPHPアプリケーションならPHP本体にパッチを当てるだけで完了です。

SANS Top 20

SANS Top 20が10/8日に発表されていますね。UNIXはBINDが1位になっています。インストールしたままアップグレードしない、古いパッケージをそのまま使う管理者も多いと言うことなのでしょう。

ちなみに私は出来るかぎりdjbdnsを使ってます。このリンク先にDan J. Bernstein氏が随分前から指摘していたDNS キャッシュを DNS サーバから分離することの重要性を知らないユーザも多いと言うこともあるでしょう。こちらも随分前になりますがCERTもこの件に関してアドバイザリを出しています。

しかし、今でもDNSキャッシュとDNSサーバに同じIPアドレスを指定させているISPがあります。CERTアドバイザリのURL等を添付して改善を依頼するメールを送った所、「検討します」という内容のメールが来ました。しかし、それから早くも半年近くも経ちます。DNSキャッシュの汚染によるサイトの乗っ取りなどの被害が発生した場合、このISPは損害賠償を請求されても仕方が無いですね。

世界中にはこの様なISPが沢山あるのかも!?

HTTP Response Splitting Attack

HTTP Reponse Splitting AttackはOWASPの新しい脅威のカテゴリになるそうですね。

簡単言うと言語やブラウザ等のHTTP Reuqestヘッダによって別のページに振り分ける(リダイレクト)させるWebサイトのヘッダに問題があると脆弱性が発生し攻撃が可能になります。

可能になる攻撃にはクッキーの漏洩からキャッシュシステムが組み込まれたWebサイトでは意図しないページの表示(複数のユーザ向けへのページの改竄)まで、と色々な影響があります。対処方法は正しいヘッダを返す。つまりCR,LFを含んだ入力をリダイレクトに使わない。

詳しくは
http://lists.virus.org/webappsec-0403/msg00004.html

クリックしてwhitepaper_httpresponse.pdfにアクセス

PDFは非常に丁寧にHTTP Response Splitting Attackを解説しています。

Apache 2.0.51 Secirity Hole

Apache 2.0.51がリリースされましたが重大なセキュリティー上の問題が見つかりました。

From http://www.apacheweek.com/features/security-20

Fixed in Apache httpd 2.0.52-dev

Bypass of authentication CAN-2004-0811

A flaw in Apache 2.0.51 (only) broke the merging of the Satisfy directive which could result in access being granted to resources despite any configured authentication
Affects: 2.0.51

Satisfyディレクティブは外部のIPからはHTTP認証行い、プライベートIPからはIPアドレスベースの認証を行ってユーザ/パスワードの記入を省略する、など使います。(反対に両方要求することも出来ます)

昨夜の時点ではアナウンスは無い&ミラーには2.0.52のファイルは無かったですが、apache.orgには既に配置されていました。今はミラーリングも完了したころかもしれません。