万能ではないセキュリティ対策
2005年11月、インシデントレスポンス、コンピュータ・フォレンジックなどITセキュリティサービスを提供するGuidance Softwareの顧客データベースにハッカーが侵入。情報を盗難する事件があった。
セキュリティ対策は万能ではないのは常識ですがセキュリティツールを販売している会社のサーバがクラックされるのは痛いですね。医者の不養生といいますがフォレンジックツールを販売している会社を狙うとは…. プロの犯罪者はすごいですね。
Macのクラックコンテスト。30分でroot権限
Macのクラックコンテストが行われ30分でroot権限を取得された事が報道されていますが、それに対する反論。
Anyone that wanted to hack the machine was given access to the machine through a local account (which could be accessed via SSH), so the Mac mini wasn’t hacked from outside — root access was actually gained from a local user account.
“That is a huge distinction,” said Schroeder.
SSHアクセスが許可されていたことは重要だ、との主張です。
確かにそうなのですが、Web, Mail, LDAP, etcの外部向けサービスからroot権限が取得できるのであればサーバアプリのセキュリティホールなので「Macのクラックコンテスト」とは言いがたくなります。ローカルアクセスもできないのに「クラックできる？」とコンテストされてもやる気がおきません。
しかし、一般的なユーザは報道だけみると「Mac=危険」と思ってしまうかも知れません。確かにローカルアクセスができる場合、危険度は高いと思いますが、全体として安全性はそれほど悪くないと思います。
LinuxでもWindowsでもローカルユーザ権限があれば管理者権限を取得できてしまうセキュリティホールは沢山報告されています。今回利用されたセキュリティホールがどのような物だったか公開されていないので詳細は分らないですがが、Macだけが特別危険と言うことでは無いです。Macは今までクラッカーに相手にされていなかった(?)のでまだまだ問題が沢山(?)あるのかも知れません。
Windowsの場合、普通に使うためには管理者権限をを持っていないと困る場面が多くあります。アプリケーションが管理者権限を持っていないと動作しない、などというケースも少なくありません。普通のユーザは普通に管理者権限を持つアカウントでログインしてPCを利用しています。
Mac OS Xでは通常権限のユーザでログインしても普通に利用でき、普通のユーザは通常のユーザ権限を持つアカウントを使用しています。Windowsに比べればOS Xの方が比べものにならないくらいセキュリティ上まし、と言えると思います。
Listservに深刻な脆弱性
listservに深刻な脆弱性だそうです。最近はlistservを使っているMLはあまり見ませんが、だからこそ危ういのかも知れません。3ヶ月は脆弱性の詳細を公開しないそうです。
Peter Winter-Smith of NGSSoftware has discovered a number of vulnerabilities
in L-Soft’s LISTSERV list management system. The worst of these carries a
critical risk rating.Affected versions include:
– LISTSERV version 14.4, including LISTSERV Lite and HPO
– LISTSERV version 14.3, including LISTSERV Lite and HPOAnd possibly all prior versions of LISTSERV which are installed with the web
archive interface, which is currently the default installation behaviour.The vulnerabilities which have been fixed can, in the worst of cases, allow
a remote unauthenticated attacker to execute arbitrary code on the system
hosting the LISTSERV archive web interface.This issue has been resolved in the latest release of L-Soft LISTSERV
(version 14.5), which may be downloaded from:http://www.lsoft.com/download/listserv.asp
http://www.lsoft.com/download/listservlite.aspNGSSoftware are going to withhold details of this flaw for three months.
Full details will be published on the 3rd June 2006. This three month
window will allow users of L-Soft’s LISTSERV the time needed to apply the
patch before the details are released to the general public. This reflects
NGSSoftware’s approach to responsible disclosure.NGSSoftware Insight Security Research
http://www.ngssoftware.com
http://www.databasesecurity.com/
http://www.nextgenss.com/
+44(0)208 401 0070
SPAM対策
コメントSPAM対策にBBQあらしお断りシステムのチェックを入れてみました。コメントの送信時にのみチェックするようになっているので参照だけであればどこからも参照できると思います。もし問題があった場合にはご連絡いただけると助かります。
b2evolutionへの変更（htsrv/comment_post.phpのはじめの辺り）
// SPAMMER check
$srv_name = implode('.',
array_reverse(explode(".", $_SERVER['REMOTE_ADDR'])) ) . '.niku.2ch.net';
if ( checkdnsrr($srv_name, 'A') ) {
require(dirname(__FILE__)."/../b2evocore/_410_stats_gone.page.php");
}
セキュリティポリシーって?
Winnyで機密情報が流出事件が相次いでいますが、ほとんどが
「ファイル交換ソフトを入れたPCでの閲覧は禁止していた」
と報道されています。
Winnyで情報漏えいがあった組織のセキュリティポリシーは本当に「ファイル交換ソフトが入ったPCで閲覧は禁止する」と書いてあるのでしょうか?
そもそも勝手にソフトをインストールするのは一切不可にすべきです。データを持ち出して自分のPCで参照するのも当然不可にするべできす。自衛隊などが取り扱う機密情報は公開ネットワークに接続しているまたは接続する可能性があるコンピュータからデータ参照は禁止すべきだと思うのですが….
セキュリティポリシーがどうなっているのか気になる所です。公共系の組織はISO9000やISO14000を取得する前にISMSを取得した方がよいのではないでしょうか?
もしかして立派なセキュリティポリシーがあるけれど、広報担当でさえ内容を知らない状況なのでしょうか?
gmailのXSS
GoogleにXSSの情報の出所はBloggerユーザのブログだったようです。
http://ph3rny.blogspot.com/2006/03/vulnerability-in-gmail.html
予想に反してSubjectにスクリプトタグを入れるとJavaScriptを埋め込めるという単純なミスだったようです。
日本人のWebプログラマなら「Subjectがエンコードされている」いるのは常識ですがシングルバイト圏のプログラマには常識ではなかったりします。エンコードされたSubjectヘッダに対してフィルタ処理を行っていたのでしょう。（多分）
コーディング処理が終わった後にフィルタ処理を行っていない間違いはメールに限った事ではありません。PHPはブラウザからの入力は自動でデコーディングするのでこのようなミスは発生しづらいのですがPerl等のWebプログラムではよくある間違いの一つです。
F-Secueのウィルスマップ
F-Secureのウィルスマップは現在のウィルス感染状況が地図で分かるようになっています。過去の履歴も参照できるようです。
私が日本の地図を参照したときは三浦半島だけウィルスが流行している状況（Epidemic）に分類されていました。
このマップ、なかなか良くできています。
PHPのStrictセッション
Strictセッション管理パッチのダウンロード数がやっと?100を超えました。
PHP5用のパッチなのが一番の問題なのでしょうか?非常にダウンロード数が少ないように思えます。私はこのパッチはセキュリティ上かなり重要なパッチだと思っています。
PHP4のパッチが必要なのかな? 枡形さんが作ってましたっけ?
関連：
http://blog.ohgaki.net/index.php/yohgaki/2006/02/02/strict_sessioncric_a_a_a
http://blog.ohgaki.net/index.php/yohgaki/2006/02/05/phpa_rsession_fixationa_ei
http://blog.ohgaki.net/index.php/yohgaki/2006/02/27/a_ma_sa_sa_ma_ca_a_ma_a_sa_f
GoogleにXSS
詳しくはリンク先を見ていただくとして（脆弱性の詳しい情報は書いてありません)、パーソナライズド機能やgmailは修正されるまで使わない方がよいらしい。
このアドバイザリ、ちょっと待った
これはコードブログに書こうと思ったらTypePadのパスワードが分からなくなっていました。ブラウザに記憶させたはずなんですけどね…. とにかく以下のSECUNIAアドバイザリは（今度こそ）本当に間違っています。
# 前にCVSの更新が異常だったため勘違いしていた件がありました。
# 今度はSECUNIAが勘違いする番ですね。
TITLE:
PHP “mb_send_mail()” and IMAP Functions Security BypassSECUNIA ADVISORY ID:
SA18694VERIFY ADVISORY:
http://secunia.com/advisories/18694/CRITICAL:
Less criticalIMPACT:
Security Bypass*省略*
SOLUTION:
Do not compile PHP to enable support of the mbstring or imap
functions if they are not required.PROVIDED AND/OR DISCOVERED BY:
Cdric Clerget
詳しいPoCはリンク先のアドバイザリを参照していただくとして、mb_send_mailとmailの第五引数（sendmailコマンドへの追加の引数）は内部関数php_escape_shell_cmdでエスケープされています。
PoCでは普通の引数を渡しているのでphp_escape_shell_cmd関数でエスケープしても、当然ですが、そのままsendmail関数のオプションになります。
つまり、mb_send_mailだけでなくmailでもまったく同じ現象（現象です。これは問題ではありません）が発生します。コマンドの実行に注意をはらうのと同じでmail/mb_send_mail関数の第五引数の指定にも注意が必要です。
オリジナルのアドバイザリはBugTraqにあます。safe_mode/open_basedir設定のバイパスが可能なことがセキュリティ上の問題だ、としていますがsafe_mode/open_basedirはfail safe (フェイルセーフ）の為の機能です。つまり、プログラムのバグがあっても意図しないファイルへのアクセスリスクを低減させるための仕組みであって、悪意を持ったプログラマからシステムを保護する機能ではありません。
CRITICAL:
Less criticalIMPACT:
Security Bypass
となっているので気にする人はいないと思いますが、対策が以下のように書いてあります。
SOLUTION:
Do not compile PHP to enable support of the mbstring or imap
functions if they are not required.
Secuniaは何を言いたいのでしょうね?
mail関数はconfigureスクリプト実行時にsendmailバイナリを見つけられないと組み込まれません。多分、mail関数も組み込むな、とアドバイザリがでるのでしょう。
別に気にする必要はないアドバイザリですが、この対策は非常にいただけません。
百歩譲っても「disable_functionに指定する」くらいが妥当なのではないでしょうか?
追記：
SECUNIAのアドバイザリは
1) The PHP “mb_send_mail()” function allows additional parameters to be passed to sendmail via the “additional_parameter” parameter. This can be exploited to cause sendmail to read arbitrary files on the system as configuration file and saving the resulting log file to arbitrary writable directories. The saved log file may contain portions of the file that was read as configuration file.
Example:
$additional_param = “-C “.$file_to_read.” -X “.getcwd().”/”.$output_file;
mb_send_mail($email_address, NULL, NULL, NULL, $additional_param);Successful exploitation allows the bypassing of certain “safe_mode” and “open_basedir” restrictions.
The vulnerability has been confirmed in version 5.1.2 and also reported in version 4.x. Other versions may also be affected.
と書いてあるのですが、safe_modeのバイパスだ、と書いていません。
オリジナルのアドバイザリを良く読むと、safe_modeの時だけ問題がある、旨で書かれています。ソースを確認してみるとmb_send_mailの方はsafe_modeのときに5番目の引数があっても受け付けるようになっていました。
# これは修正をCVSにコミットしました。久しぶりに。
mail/mb_send_mailの両方open_basedir設定はバイパスできるのですが、SECUNIAのアドバイザリではsafe_mode, open_basedirのどっちの事を言っているか分かりませんね。open_basedirがバイパスできることも問題らしいので「mail関数は組み込むな」とアドバイザリを作る(?)のでしょうね。
繰り返しになりますが、SECUNIAのアドバイザリでは対策として
SOLUTION:
Do not compile PHP to enable support of the mbstring or imap
functions if they are not required.
と書いていますがimapもmbstringも普通に使っていれば安全に使えます。
Mailヘッダインジェクション
PHPのmail関数は\r\n,\r,\nを無視するようになっていてmb_send_mail関数の方は、チェックするマクロがphp_mail(PHPの内部関数）の前のPHP_FUNCTION()の部分で実行されていたので、mb_send_mailを使っているとMailヘッダインジェクションが出来てSPAMの踏み台にされる。という問題がありました。PHPユーザの方は覚えていると思います。
同じ問題がhns（Perlの日記アプリ）にもあったのですね。
PHPのmail関数のチェックは余計なお世話、とも言えるチェックです。PHPに慣れて他の言語でプログラムを書くと同じようなミスをするかも知れません。ユーザ入力は全部、確実にチェックしていれば防げる問題ですね。
HTTPヘッダの挿入も問題があるので今のPHPは\r\n, \r, \n, \tはheader関数ではじく様になっています。
システムではじいていても攻撃されていたかは知っておくべきですし、システムが適当に安全に処理してくれるから、といって未確認のデータを外部システムには送るべきではありません。
PHP_SELFはそのまま出力できない
追記：現在のPHPでは$_SERVER[‘PHP_SELF’]はクエリ文字列（?以降のクエリパラメータ）を含みません。しかし、index.php/<script>alert(1)</script>/aaa/bbb とすることは可能です。PHP_SELFと同様の変数は以下です。
- $_SERVER[‘PATH_INFO’]
- $_SERVER[‘PATH_TRANSLATED’]
時々見かけるのでブログでも問題を指摘します。
PHPの$_SERVER配列に入っているPHP_SELF要素はPATHINFOも含めてしまうため、そのまま出力するとXSSに脆弱になる場合があります。
phpinfo()がXSSに脆弱だ、と指摘する人がいるので（元々phpinfo()の出力は管理者・開発者のみ参照できるようにしておくべきですが..)現在のPHPはPHP_SELF内の< > を検出して
<script> </script>
等と書けないようになっています。しかし、この対策はphpinfo()の事しか考えていないので
<?php echo '<a href="'. $_SERVER['PHP_SELF'] .'">aaa</a>'; ?>
の様なケースの場合、
http://example.com/xss.php/%22%20onMouseOver=%22javascript:alert(‘xss’);
等としてJavaScriptの挿入が可能になります。
SCRIPT_NAMEにはPATH情報が無いのでこの問題は発生しません。PHP_SELFでは無くSCRIPT_NAMEを使用すべき所をPHP_SELFを利用しているケースは時々見かけます。
注意が必要かもしれませんね。
UNIX系OSならPHPのソースがあるディレクトリに移動して
find . -name “*.php” | xargs grep -n “PHP_SELF”
等として怪しいPHP_SELFの出力が無いか確認すると良いかも?!
リファラの表示は止めましょう
備考：かなり古いブログですが公開し忘れしていた分です。
前にも書いたと思いますが、一般に公開する画面でリファラ表示は止めるようにした方よいと思います。以前に比べてリファラが一般に広く公開されているサイトは少なくなりましたがまだまだ沢山あります。
リファラSPAMでbotを使っていると思われるSPAMが常識になっています。IPはリクエスト毎に異なり、短時間に大量のリファラを残す事もほとんどなくなりました。中にはリクエスト先のURLも異なる物もあります。
こうなるともうほとんど普通のリクエストとリファラSPAMは区別できません。インターネットユーザにできる自衛策は「みんながリファラを公開しない」「おかしなリファラをクリックしない」しかありません。
日本のアイドルサイトからのリファラSPAM?
久しぶりにブログへのSPAM掃除をしていたら、日本のアイドルサイトからのリファラSPAMと思われるログが複数ありました。
#リンクにならないようにhttpのhを削除しました。
ttp://suzukiairi.net/cgi-bin/up/upload.php?page=all
ttp://www.umedaerika.com/ume/uperika.php?page=all
ttp://melon-kinenbi.plala.jp/~ayumi/sam.php?start=100
ttp://ai-flavor.com/upload/flavorupload.php?page=all
ttp://www.sudomaasa.com/rabi/upmaasa.php?page=all
なにこれ?と思っていたところどうもこのアップローダ（正確にはサムネイルの表示スクリプト）にはXSS脆弱性があるようです。某サイトのサンプルファイルを修正して使っているようです。
このスクリプトはXSSに脆弱なのでファンが勝手にXSSに脆弱なスクリプトを利用してSAPMを送信したのか、とも思ったのですが同じIPアドレス（サーバのとは別のIP：xxx.87.1.155）のリファラであるためXSSを利用しているとは断定できません。書きませんがwhois情報を見ると…、となっています。
サーバ（多分このIPはプロキシ）がクラックされているか?内部のクライアントがクラックされているのか? 単純に内部の利用者によりプロモートするためにリファラSPAMが仕掛けられているのか?業者によるこれらのタレントのプロモーション用SPAMなのか?
他の業者とは異なるのは参照先のURLがトップページ固定ではなく、ほとんどが実在するURLをばらばらにリクエストしている所が新しいです。
とりあえず様子を見ることにします。
クロスサイトクッキー
随分前にブログにも書いたつもりでいたのですが、書いていないようなので。
ccTLD(*.co.jpなど）のクッキーの信頼性はTLD（*.com）に比べて低い、という話。
自分で最後に試したのは去年末か今年初め（だったかな?）だと思いますが、IE、FF共にccTLDのドメインにたいしてクッキーを設定できました。
まさかクッキーを信用しているサイトは無いと思いますが、設定されているクッキーの数が異常だとエラーになるサイトなどの場合、DoSに脆弱になります。
追記：
書き忘れていましたが、デフォルトのPHPのセッション管理ではセッションの固定化（Session Fixation）に脆弱になります。use_only_cookiesにしてもccTLDの場合、セッションIDのクッキーが設定できてしまうのでセッションの固定化攻撃には注意が必要です。