/.Jの投稿で気が付いたのですが前に書いた「Mambo, Coppermine, PHPBBが攻撃対象に」でワームが活動している記載しましたが、日本のサーバでも感染しているらしいです。
http://www.merit.edu/mail.archives/nanog/msg14612.html
ネットワークブロックが記載されています。対象のアプリケーションを使っている方は確認された方がよいと思います。
# XMLRPCの対策をされていない方も直ぐに対策が必要です。
私のWikiに荒らしがり、昨日それに気が付いたので修正しました。MenuBarとFrontPageページにゴミが入っていたのですが、FrontPageの方は意図が何なのか不明な変更なのです。（リンク先はページを更新するのでそのうち無くなります）
http://wiki.ohgaki.net/index.php?cmd=backup&page=FrontPage&age=22&action=diff
MenuBarの方はPukiwikiを狙った自動SPAM（？）のだったのかも知れません。
http://wiki.ohgaki.net/index.php?cmd=backup&page=MenuBar&age=10&action=diff
DIVタグを使って（Pukiwikiではそんなタグ書けませんが）URLリンクは表示されないようにしつつ、リンクを作ろうとした攻撃だったようです。DIVタグが書けるWebアプリでは見かけ上分からないので気が付きづらいです。
いくらWikiとは言え、組織的SPAMが当たり前になってきているのでFrontPage、MenuBarくらいは凍結しておくべきでした。Wikiにもある程度体系的な認証や保護が必要な時代になりました。来年は更に自動的なSPAM行為が増えると思われます。と言うことで来年のTODOの一つはWikiをMediaWikiに乗り換える、かな?
# Pukiwikiに本格的な認証機能を付ける、という手もありますが。
リモートから攻撃可能な脆弱性が公開されてからパッチが当てられていない期間(unsafeな期間）を調査したレポートがあるそうです。
http://bcheck.scanit.be/bcheck/page.php?name=STATS2004
詳しく脆弱性の公開日とパッチ公開日が記載されています。
MSIE was 98% unsafe. There were only 7 days in 2004 without an unpatched publicly disclosed security hole.
Firefox was 15% unsafe. There were 56 days with an unpatched publicly disclosed security hole. 30 of those days were a Mac hole that only affected Mac users. Windows Firefox was 7% unsafe.
Opera was 17% unsafe: 65 days. That number is accidentally a little better than it should be, as two of the upatched periods happened to overlap.
しかし、2004年の事とはいえ98%は安全ではなかったとは想像以上に悪いですね、IEは。
2005年のレポートがどうなるか非常に興味があります。
NSAがメールを盗聴（メールのみではなくエシュロンでありとあらゆる通信を傍受している）している事は有名ですが、盗聴されているか確認する手法の紹介です。
秘密のURLを使って盗聴を検知する手法です。
この方法だとNSAが盗聴を実行しているか確認できます。会社のシステム管理者が従業員を監視しているか確認する方法に応用されそうな気がします。
しかし、テロリストは暗号化しないでメールでやり取りしているのでしょうか?案外テキトーに平文で通信しているのでしょうか? 現状では暗号化しているだけで目立つので暗号化したメールの方がテロリストには危険なのかも知れません。
マイクロソフトの以下のサイトでは画像とFAXビューアを(Shimgvw.dll) を登録抹消するよう推奨しています。
http://www.microsoft.com/japan/technet/security/advisory/912840.mspx
登録抹消
1.[スタート] メニューの [ファイル名を指定して実行] に “regsvr32 -u %windir%\system32\shimgvw.dll” （二重引用符は必要ありません） と入力し、次に [OK] をクリックします。
2.ダイアログ ボックスに、登録を解除するプロセスが正常に完了したことを確認するメッセージが表示されます。[OK] をクリックして、ダイアログ ボックスを閉じます。
回避策の影響: Windows 画像と Fax ビューア は、ユーザーが Windows 画像と Fax ビューア に関連するイメージの種類へのリンクをクリックしても起動されません。
再登録
この変更を取り消すためには、上のステップに従って Shimgvw.dll を再登録してください。ステップ 1 のテキストを “regsvr32 %windir%\system32\shimgvw.dll” に変更してください (二重引用符は必要ありません)。
Explorerで参照するだけで感染する可能性があるようなので念のためにMS推奨の回避策も実行しておきました。この変更を行うとExplorerで縮小版を表示しなくなります。自動的にアクセスしなくなるのでとりあえずは大丈夫、と言うことなのでしょう。
ところで、この脆弱性を利用した攻撃、私のところにも幾つかメールで来ていました。ClamAVはすり抜けていましたがNorton AntiVirus2006はBloodhound.Exploit.56として検知しました。アンチウィルスソフトをインストールしていてもタイミングが悪く感染してしまった人も多いのではないかと思います。
セキュリティメモにいろいろリンクが載っています。
http://www.st.ryukoku.ac.jp/%7Ekjm/security/memo/2005/12.html#20051230_tuiki
http://www.st.ryukoku.ac.jp/%7Ekjm/security/memo/2005/12.html#20051228_WMF
Webサーバのフィンガープリンティングツールのhttprintの新バージョンがリリースされてるようです。
# [new] Multi-threaded engine. httprint v301 is a complete re-write, featuring a multi-threaded scanner, to process multiple hosts in parallel. This greatly saves scanning time. *multi-threading is not yet supported in the FreeBSD version.
# [new] SSL information gathering. httprint now gathers SSL certificate information, which helps you identify expired SSL certificates, ciphers used, certificate issuer, and other such SSL related details.
# [new] Automatic SSL detection. httprint can detect if a port is SSL enabled or not, and can automatically switch to SSL connections when needed.
パフォーマンスとSSLサポートが向上しています。
ちなみに手元のLinux/Apache2に対して57.23%の確立でApache2であると判定しました。本気で隠そう、とまでは思っていないですが単純なスキャンでは分かりづらいくらいには隠そうとしていてこの結果です。まずまずの検知性能と思います。
OSもそうですが、隠しているつもりでも隠れていない場合も結構あるので気になる方は試してみてはいかがでしょうか?
# OSならnmapが定番のフィンガープリンティングツールです。念の為。
試しに実行してみたhttprintのアクセスログは次の通りです。
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET / HTTP/1.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET / HTTP/1.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “OPTIONS / HTTP/1.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET /antidisestablishmentarianism HTTP/1.0” 404 7556 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “PUT / HTTP/1.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “JUNKMETHOD / HTTP/1.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET / JUNK/1.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “get / http/1.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “POST / HTTP/1.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET /cgi-bin/ HTTP/1.0” 403 7556 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET /scripts/ HTTP/1.0” 404 7556 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET / HTTP/1.1” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET / HTTP/1.2” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET / HTTP/3.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET /.asmx HTTP/1.1” 404 7556 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET /../../ HTTP/1.0” 400 226 “-” “-“
Hardedned PHPプロジェクトのStefan EsserさんがPHP SESSIONをより安全に運用するパッチを公開しています。
このパッチはPHPのセッション管理の問題に対応します。PHPのSESSIONモジュールがSession Fixation（セッションIDの固定化）に対して脆弱であることは随分前から広く（？）知られていました。このパッチを適用すればSession Fixation問題も随分改善します。
例えば、PHP SESSIONを利用しているサイトで
http://example.jp/index.php
と言うURLがクッキーを利用したセッション管理行っているとします。セッションデータが初期化されサーバに保存されているか、されていないかに関わらず、ブラウザが送信したクッキーによって指定されたセッションIDがそのまま使われます。このパッチはセッションIDのデータが無ければ、セッションIDを再生成してセッションを開始するよう動作が変わります。（通常のPHPのセッション管理はpermissiveなセッション管理と呼ばれています。パッチ適用後はstrictなセッション管理も選択できるようになります。）クッキーだけを使ったセッション管理では、セッションIDが固定化する問題はあまり深刻な問題ではありませんが、好ましい動作とは言いがたいです。
session.use_only_cookiesがoffの場合、問題は深刻です。
http://example.jp/index.php?PHPSESSID=123456
とすると、セッションデータが無い場合、セッションIDが123456になってしまいます。session.use_cookies=on設定（デフォルト値）でクッキーを利用するセッション管理でも、PHPSESSID=123456をクッキーに設定されます。つまり、デフォルトの状態のPHPのセッション管理はsession.use_only_cookiesがoffである為、普通にSession Fixationに脆弱になってしまいます。一応、サイト外のURLに埋め込まれたセッションIDを受け付けないようにするsession.referer_check設定もあるのですが、REFERERを使っているので十分な対策とはいえません。許可するドメインなどを記載する設定項目なので、当然ですが、デフォルトでは何も設定されていません。何も設定されていない時はREFERERチェックは行われません。
追記：色々書いていますが、要するにデフォルト設定のPHPだとSession Fixationに脆弱である、と言うことです。
より厳格なセッションID管理を行うには、パッチを適用後、
session.use_strict_mode = on
と設定するだけです。
このパッチを適用するとユーザ定義セッションセーブハンドラで以下の2つの関数が利用（定義）できるようになります。
string create_sid()
bool validate_sid($key)
create_sid関数は新しいセッションIDを作成します。
validate_sid関数は$keyが正しいかチェックします。
ところで、デフォルトではsession.use_only_cookiesはoffに設定されています。しかし、普通のサイトはsession.use_only_cookiesはONで運用するべきです。もし、offで運用されている場合、強くONに変更して運用することをお勧めします。先ほども書きましたが、session.use_only_cookies=onであればSession Fixation問題はそれほど重大な問題とは言えません。パッチを適用していない場合でもsession.use_only_cookies=onであればそれほど心配する必要はありません。
# 随分古いInternet ExplorerではXMLHttpRequestで他のサイトにリクエスト
# を送信できたりしました。しかし、今は出来ないのでクッキーを利用した
# セッション管理に対して効果的なSession Fixation攻撃は出来ないと思い
# ます。
本来はデジタルディバイドについて話し合うはずだった(?) WSIS（世界情報社会サミット）で関係ない、余計な議論が行われているという話。
今回のサミットの最大の争点はどうやら米国がインターネットの根幹の管理を手放すかどうかだったらしい。インターネットは自律・分散・協調で成り立っているのは広く知られているが、IPアドレスとドメイン・ネームの管理はどうしても中央集権的にやらなくてはいけない部分が残っている。この点について米国政府は、政府機関自身が前面に立つのではなく、契約に基づいて民間に委託をしてきた。管理といってもきわめて技術的な話であり、米国政府の政治的な意向が働くわけではない。
至極当然の話ですが、しかし
挙げ句の果てには、米国におかれているルート・サーバーに世界中のインターネットのトラフィックが集まり、米国政府がそれをすべて傍受しているというナンセンスな主張まで準備会合の過程でなされたという。
とか
米国がインターネットでの覇権を守るために管理を手放さないのだという情緒的な批判も繰り返された。
理解に苦しむ、というかナンセンスな議論です。
個人的な考えとしては、ルートサーバは今の管理状態の方がよっぽど安心できます。政治的な圧力の強い国またはセキュリティ管理が甘い国がルートサーバを管理してる国を挙げてのファーミングなどという事になったら笑っていられる場合ではありません。
# BGP4が…. という話もありますが考えない、考えない…
政府も含めてみんなが放っておくのが一番だ。
規制したくなる気持ちは十分理解できますが、結局は放置が一番、という意見には賛成です。犯罪の取り締まりは基本的には現状の枠組みの中で厳重に行えば良いのではないでしょうか?
例えば、DELLのショッピングサイトなどはIEしかサポートしていません。
FirefoxのUser Agent Switcherを使えばDELLのショッピングサイトでもLinux+Firefoxでも発注できる（多少問題はありますが）ので致命的とは言えませんが、普通にFirefoxをサポートしてくれるようになってほしいですね。
Mac用IEの終了でFirefoxサポートが加速される?!
特定のターゲットのみ狙い撃ちするスピアフィッシング（スピアーフィッシングとは中銃や銛を使い魚を突く事）前からあるのですが、ITMediaの翻訳記事にあったので。困った物ですよね。見ないとならないようなメールで来ると開かざるを得ないですから。この記事以外にもネットショップ経営者にクレームメールを装ったフィシングも話題になっていました。（これは日本の話）
VMwarePlayer等を使ってWebとメールは仮想ホスト上で実行するくらいの用心が必要になってきてます… ちなみに私はそこまでしてません…
コメント＆トラックバックスパムが増えてきています。さっきも20数個のスパムを削除しました。TODOとしてCAPTCHA導入… しかし、CAPTCHAを入れるとアクセシビリティの問題も発生するので公共系サイトでは気をつけないとならないですね。
ところでWikipediaのCAPTCHAページ、リンクが豊富ですね。
http://ja.wikipedia.org/wiki/Captcha
ITMediaでもコメント＆トラックバックSPAMが話題になってますね。
http://www.itmedia.co.jp/enterprise/articles/0512/20/news046.html
しかし、何故かCAPTCHAに言及してませんね。
FC5でSUNのJavaパッケージをインストールすると問題が発生するらしい。リリース版でも同じかな?
VLANにも色々セキュリティホールがあるのですが、 これは”802.1q, various PVLAN implementations”でプロトコル設計の問題だそうです。ローカルネットワークのユーザが信頼できない場合は困る方もいるかも。
Mambo, Coppermine, PHPBBがワームか何かの攻撃対象になっているそうです。
Mambo、PHPBBは日本でもよく利用されていると思います。
Coppermineはフォトギャラリーの様ですね。
攻撃に成功するとlistenと言うmalwareをインストールされるそうです。
ところでXMLRPCの不具合を狙った攻撃が行われている、とこのブログにも書いたかも知れませんがこの攻撃も続いています。もしXMLPRCを使っているPHPアプリで対策を取られていない方は直ぐにシステムをチェックした方が良いと思います。
# XMLRPC脆弱性への攻撃は私のサーバログにも残っています。
# 上記の3つのアプリケーションへの攻撃があるかは出先なの
# で確認していません。
プログラミング言語によらずセキュリティ対策には3つの基本があると思います。
1．外部からの入力は信用せず、形式、範囲が想定内か確認する
2．外部システムへ出力を行う場合は適切なエスケープ処理を行う
3．セキュリティ上の問題が発生しても被害を最小限に留める措置を行う
1．の外部からの入力は信用しない、にはユーザからの入力だけでなく他のサブシステムの入力も信用してはならないです。例えばqmailのコマンド郡は同じ作者が作っているにも関わらずお互いに信用していません。
2．の適切にエスケープ処理を行う、はシステムに合った最適なエスケープ処理を行う事が必要です。例えば、システム上のコマンドを実行する場合やSQL文を実行する場合、適切なエスケープ処理は処理系によって異なる場合があります。
3．はfail safe機能は使えるものは使う、という事です。プログラミング上でのセキュリティ対策ではないですが適切な例を思いつかなかったのでGCCのstack protector機能を例に説明します。GCCにはstack protectorと言う機能を追加する事ができます。この機能を追加すれば仮に1．の「外部入力を信用しない」を守った「つもり」でプログラム作っていても、万が一スタックオーバーフローがあった場合でも任意コードを実行される危険性を大幅に低減することが可能になります。
どうしてわざわざこんな事を書くかというと、fail safeとして有用な機能やコードに対して「どうして有用なのか解らない」と思われてしまうケースがよくあるからです。Cプログラマでオーバーフローが発生したときにコード実行を防止してくれる機能がどうして有用なのか解らない、と考えられる方は少ないと思います。
# OSやGCCの基本機能として入れるか、入れないか、という部分では
# いろいろ議論の余地はあるとは思いますが…
使用する言語を問わず致命的な問題にならないよう対策が取れる場合は有用に活用するべき、と私は考えています。fail safeな機能や仕組みは軽視されがちですが、私は非常に重要だと考えています。普通はだれでも間違えたくて（バグを作りたくて、セキュリティホールを作りたくて、など適当に読み替えてください）間違える訳ではありません。それでも間違いは起きる物です。間違いは起きるのは当たり前、を前提とするとfail safe機能の重要性は理解してもらえるのはないか、と考えています。
このブログでセキュリティ上の対策などを断片的に書く事がありますが、これらの基本は踏まえた上での対策として書いています。
ところで、PHPの場合、fail safe機能として利用できる機能には
– open_basedir設定
– allow_url_fopen設定
– カスタムエラーハンドラ登録
があります。safe_modeもありますがPHP6では削除候補なので入れていません。
# あまりよく考えていないので他にもあるかも。コメント歓迎します。
追記：
fail safe的な機能として利用できる機能：
-disable_function設定
-disable_classes設定
-max_execution_time設定
-max_input_time設定
-post_max_size設定
-memory_limit設定
-log_errors設定
-auto_prepent/append設定
-シャットダウン関数登録
-file_upload設定
-upload_max_filesize設定
-default_socket_timeout設定
-DB接続の永続的接続無効化