アカウント名:
パスワード:
改ざんされたファイルは前回とは違い、現在のところ原因も不明とのこと（Security NEXT）。
JR東日本の管理体制が甘いと言われても仕方ないけど、今回は4日 （2010年2月18日（木）22時29分～2010年2月22日（月）17時18分） [jreast.co.jp]でサービスを停止できたわけだからまだマシな感染事例ではないかと。
一方ガンブラー攻撃は次々亜種が登場し、攻撃の様相が様変わりしている模様。
イタチごっこ続くWebサイト改ざん、埋め込みコードがまたまた変化 [so-net.ne.jp]（2010/01/28 セキュリティ通信）
昨年12月から被害が続出している国内のWebサイト改ざんだが、28日未明から、再び改ざんサイトに埋め込む
> 22日未明に「/*LGPL*/」から「/*Exception*/」に変わった際には、それまで検出できていたウイルス対策ソフトが一斉に検出不能に陥ってしまったが、今回も見事に>検出を回避してしまった。攻撃の手は緩むことなく、まだまだイタチごっこが続くようだ。
なんというやっつけ仕事。責められるべきはこっちのような…。
気持はわかりますが、誤検出(偽陽性という方向かな?)があると、それはそれで問題になりやすいし、改訂速度と伝播量/存在量を考えて厳しめのチェックルールになったりするのは、理解できるかなと。
# まあ、嬉しくないですけどね。
最近はそれじゃまともに検出できないこと多数なので、サンドボックスでの実行結果をもとに～みたいな話しもありますが、そうすると検出エンジンの大改訂が必要でしょうねぇ...いやすでにあるレベルでは搭載されてるかもですが。
そうとしても、スクリプトのコメントを目印にするのはあんまりかと。これではだれでもすぐに検出されないように改変できてしまいます。緊急対応は別としても、実動作部分でマッチングを取れないものでしょうかね。例えば中間言語に落したものを特徴抽出するとか。公開サーバに置く場合にはサンドボックス式でチェックするにしても、常用リアルタイムのものにはなかなか適用できないでしょうからパターンマッチング式がメインでしょうが、その肝心のパターンに穴があるような作りでは困ります．
それにしても、いまだにftpのアカウントさえ合っていればアクセス元を制限せず公開用サーバにファイルを置くことを許してしまうんだろうか。
今回の改ざんについては、「前回とは異なるファイルが改ざんされた」としており、原因究明に向けて調査を進めているという。
信頼性に欠けるとおもうのは、別に同じ穴から異なるファイルが改竄されたって全然不思議ではないのにこんな広報をしてしまうことです。・サイト内のキーワード検索機能以外のページは改竄されていないことをチェックしたの？・前回の改竄からどんな対策したの？ 制作部署のウィルスチェックしただけとかftpアカウント変えただけとかとか。・当該アカウントを使用しているのは、"キーワード検索機能"だけなの？ 普通、他も手がけているよね？
この件についてJRのサイトにアナウンスも見えず、internet.watchからのリンク先も「2月26日（金）より再開いたしました。」しか情報がなく、利用者にウィルスをダウンロードさせた可能性があったという責任感が薄いように思われます。
そうとしても、スクリプトのコメントを目印にするのはあんまりかと。
誤検出の可能性が一番下げやすい場所なんですよ。
緊急対応は別としても、実動作部分でマッチングを取れないものでしょうかね。例えば中間言語に落したものを特徴抽出するとか。
無理、広告用のscriptタグの埋込みによく使われる方法をなぞっているので、誤爆が多すぎます。特徴はアクセス先のサーバとコメント位です。
感染したマシンがFTPアクセスしてる可能性もあるので、そのチェックでは駄目なんじゃないかと思いますよ。正規のFTPアクセスを行っている端末が既に感染しているわけなので、その端末経由で改竄を行うことも容易なはずです。
FTPでサーバーに置いた後別のシステムで承認したらコミットするような仕組みとか。CMSがそういった仕組みを持っていても良いですよね。とりあえず一時的な防護にはなりそう。
# 踏み台にされてトロイの木馬とかが仕込まれてたら既にアウトですが。
単純にアップロードする前にハッシュ取っておいて、定期的にハッシュと比較して違ってたら公開停止……みたいなのは負荷が高そうですな。
そんなにちょこちょこ変えるもんでもなかろうし、FTPに動きがあったらメールが飛ぶ、とかでも充分な気がしなくもない。# もちろんメンテナンス時はメール送信は止めとく
動的/静的なファイルを分別してサーバサイドで改竄検知システム動かしておけばftp のアカウントで改竄検知システム止められるサーバか、権限昇格の脆弱性でもなければ防げる問題なんじゃないかと某 Gumblar 対策セミナーの資料を見た限り思ったのですけど甘いかな。自分がやること想像してもファイルの分別が難しいってのは思いつくけどー
http://www.tripwire.co.jp/solutions/gumblar.html [tripwire.co.jp]おお、ちゃんと商機に乗ってる。
http://srad.jp/~mubi/journal/485172 [srad.jp]http://afick.sourceforge.net/ [sourceforge.net]afick ってのもあるのですね。perl スクリプト？ FreeBSD で動くかなー？
FTPのアカウントを覗くなら、そのファイルにアクセスするプロセスをチェックすれば良いんじゃね?
> 例えば中間言語に落したものを特徴抽出するとか。JavaScriptにはevalがあるので、そういうC/C++で書かれたウイルスのような発想では検出が非常に困難です。> パターンに穴があるような作りでは困ります．そもそもパターンマッチングで何とかしようとすることに根本的な無理がある。とはいえ「/*LGPL*/」や「/*Exception*/」にマッチさせてたというのはあんまりすぎますけどね。
JavaScriptにはevalがあるので
については、コーディング規約で「eval禁止。理由はセキュリティチェック。他の方法で回避できない場合は逸脱決裁を受け、特別のパターンファイルの提供を受けること」みたいにするのもアリだと思う
Javascriptの場合、new Function("alert('EVIL CODE!!');")();のような方法もありますし、HTMLと組み合わせた場合、document.body.innerHTML = '
'+document.body.innerHTML+'
'なんてこともできますし、それらを全部防ごうとするのは結構大変ですよ。
# パターンファイル化のためとは関係なく、eval系を極力使わない/使うときは細心の注意を払って、というのはセキュリティ上、大変よいことですが。
「Javascriptを中間コードに置き換えて検出する」に対して、「文字列の形でウィルスコードが書かれていたら検出するのが難しい」って話じゃないの？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
仏の顔も三度まで（二回なら許してあげてｗ） (スコア:3, 興味深い)
改ざんされたファイルは前回とは違い、現在のところ原因も不明とのこと（Security NEXT）。
JR東日本の管理体制が甘いと言われても仕方ないけど、今回は4日
（2010年2月18日（木）22時29分～2010年2月22日（月）17時18分） [jreast.co.jp]でサービスを停止できたわけだからまだマシな感染事例ではないかと。
一方ガンブラー攻撃は次々亜種が登場し、攻撃の様相が様変わりしている模様。
イタチごっこ続くWebサイト改ざん、埋め込みコードがまたまた変化 [so-net.ne.jp]（2010/01/28 セキュリティ通信）
モデレータは基本役立たずなの気にしてないよ
Re: (スコア:0)
> 22日未明に「/*LGPL*/」から「/*Exception*/」に変わった際には、それまで検出できていたウイルス対策ソフトが一斉に検出不能に陥ってしまったが、今回も見事に>検出を回避してしまった。攻撃の手は緩むことなく、まだまだイタチごっこが続くようだ。
なんというやっつけ仕事。
責められるべきはこっちのような…。
Re: (スコア:2, 興味深い)
気持はわかりますが、誤検出(偽陽性という方向かな?)があると、それはそれで問題になりやすいし、改訂速度と伝播量/存在量を考えて厳しめのチェックルールになったりするのは、理解できるかなと。
# まあ、嬉しくないですけどね。
最近はそれじゃまともに検出できないこと多数なので、サンドボックスでの実行結果をもとに～みたいな話しもありますが、そうすると検出エンジンの大改訂が必要でしょうねぇ...いやすでにあるレベルでは搭載されてるかもですが。
M-FalconSky (暑いか寒い)
Re:仏の顔も三度まで（二回なら許してあげてｗ） (スコア:1, すばらしい洞察)
そうとしても、スクリプトのコメントを目印にするのはあんまりかと。
これではだれでもすぐに検出されないように改変できてしまいます。
緊急対応は別としても、実動作部分でマッチングを取れないものでしょうかね。
例えば中間言語に落したものを特徴抽出するとか。
公開サーバに置く場合にはサンドボックス式でチェックするにしても、常用リアルタイムのものには
なかなか適用できないでしょうからパターンマッチング式がメインでしょうが、その肝心の
パターンに穴があるような作りでは困ります．
それにしても、いまだにftpのアカウントさえ合っていればアクセス元を制限せず公開用サーバに
ファイルを置くことを許してしまうんだろうか。
信頼性に欠けるとおもうのは、別に同じ穴から異なるファイルが改竄されたって全然不思議ではないのに
こんな広報をしてしまうことです。
・サイト内のキーワード検索機能以外のページは改竄されていないことをチェックしたの？
・前回の改竄からどんな対策したの？ 制作部署のウィルスチェックしただけとかftpアカウント変えただけとかとか。
・当該アカウントを使用しているのは、"キーワード検索機能"だけなの？ 普通、他も手がけているよね？
この件についてJRのサイトにアナウンスも見えず、internet.watchからのリンク先も
「2月26日（金）より再開いたしました。」しか情報がなく、利用者にウィルスをダウンロードさせた可能性があったという責任感が薄いように思われます。
Re: (スコア:0)
そうとしても、スクリプトのコメントを目印にするのはあんまりかと。
誤検出の可能性が一番下げやすい場所なんですよ。
緊急対応は別としても、実動作部分でマッチングを取れないものでしょうかね。
例えば中間言語に落したものを特徴抽出するとか。
無理、広告用のscriptタグの埋込みによく使われる方法をなぞっているので、誤爆が多すぎます。
特徴はアクセス先のサーバとコメント位です。
それにしても、いまだにftpのアカウントさえ合っていればアクセス元を制限せず公開用サーバに
ファイルを置くことを許してしまうんだろうか。
感染したマシンがFTPアクセスしてる可能性もあるので、そのチェックでは駄目なんじゃないかと思いますよ。
正規のFTPアクセスを行っている端末が既に感染しているわけなので、その端末経由で改竄を行うことも容易なはずです。
Re:仏の顔も三度まで（二回なら許してあげてｗ） (スコア:2, 参考になる)
FTPでサーバーに置いた後別のシステムで承認したらコミットするような仕組みとか。
CMSがそういった仕組みを持っていても良いですよね。
とりあえず一時的な防護にはなりそう。
# 踏み台にされてトロイの木馬とかが仕込まれてたら既にアウトですが。
Re:仏の顔も三度まで（二回なら許してあげてｗ） (スコア:1)
単純にアップロードする前にハッシュ取っておいて、
定期的にハッシュと比較して違ってたら公開停止……みたいなのは負荷が高そうですな。
そんなにちょこちょこ変えるもんでもなかろうし、FTPに動きがあったらメールが飛ぶ、とかでも充分な気がしなくもない。
# もちろんメンテナンス時はメール送信は止めとく
Re:仏の顔も三度まで（二回なら許してあげてｗ） (スコア:2, 参考になる)
動的/静的なファイルを分別してサーバサイドで改竄検知システム動かしておけば
ftp のアカウントで改竄検知システム止められるサーバか、
権限昇格の脆弱性でもなければ防げる問題なんじゃないかと
某 Gumblar 対策セミナーの資料を見た限り思ったのですけど甘いかな。
自分がやること想像してもファイルの分別が難しいってのは思いつくけどー
http://www.tripwire.co.jp/solutions/gumblar.html [tripwire.co.jp]
おお、ちゃんと商機に乗ってる。
http://srad.jp/~mubi/journal/485172 [srad.jp]
http://afick.sourceforge.net/ [sourceforge.net]
afick ってのもあるのですね。perl スクリプト？ FreeBSD で動くかなー？
Re: (スコア:0)
FTPのアカウントを覗くなら、そのファイルにアクセスするプロセスをチェックすれば良いんじゃね?
Re: (スコア:0)
> 例えば中間言語に落したものを特徴抽出するとか。
JavaScriptにはevalがあるので、そういうC/C++で書かれたウイルスのような発想では検出が非常に困難です。
> パターンに穴があるような作りでは困ります．
そもそもパターンマッチングで何とかしようとすることに根本的な無理がある。
とはいえ「/*LGPL*/」や「/*Exception*/」にマッチさせてたというのはあんまりすぎますけどね。
Re: (スコア:0)
については、コーディング規約で「eval禁止。理由はセキュリティチェック。他の方法で回避できない場合は逸脱決裁を受け、特別のパターンファイルの提供を受けること」みたいにするのもアリだと思う
Re:仏の顔も三度まで（二回なら許してあげてｗ） (スコア:1)
Javascriptの場合、new Function("alert('EVIL CODE!!');")();のような方法もありますし、
HTMLと組み合わせた場合、document.body.innerHTML = '
'+document.body.innerHTML+'
'
なんてこともできますし、それらを全部防ごうとするのは結構大変ですよ。
# パターンファイル化のためとは関係なく、eval系を極力使わない/使うときは細心の注意を払って、というのはセキュリティ上、大変よいことですが。
1を聞いて0を知れ!
Re: (スコア:0)
これでいいじゃん。
Re: (スコア:0)
「Javascriptを中間コードに置き換えて検出する」に対して、「文字列の形でウィルスコードが書かれていたら検出するのが難しい」って話じゃないの？
Re:仏の顔も三度まで（二回なら許してあげてｗ） (スコア:1)
document.body.innerHTML = '<div onmouseover="alert(\'EVIL CODE!!\');">'+document.body.innerHTML+'</div>'
1を聞いて0を知れ!
Re: (スコア:0)
本来、とても高度な技術が必要なはずのセキュリティ対策ソフト市場に、有象無象の多数の企業が参入しているという時点でアヤシイんです。
実は何もしないプラセボのセキュリティ対策ソフトでも、第三者から知らされなければ、役に立たなかったことが判明するまで、気が付かないのではないでしょうか。
それにしても、JR東日本には学習能力がないのか?
一度ヤられてるのに、
「このページはJavaScriptを使用しています。 」
なんて表示をして、ユーザーにJavaScriptを許可するよう暗に求めてる。
そう表示されて、ホイホイとJavaScriptを許可する人もマヌケだとは思うが、
セキュアなWebサイトを作れないのなら、JavaScriptを使わずにサイトを作れ。