アカウント名:
パスワード:
改ざんされたファイルは前回とは違い、現在のところ原因も不明とのこと（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のアカウントさえ合っていればアクセス元を制限せず公開用サーバにファイルを置くことを許してし
> 例えば中間言語に落したものを特徴抽出するとか。JavaScriptにはevalがあるので、そういうC/C++で書かれたウイルスのような発想では検出が非常に困難です。> パターンに穴があるような作りでは困ります．そもそもパターンマッチングで何とかしようとすることに根本的な無理がある。とはいえ「/*LGPL*/」や「/*Exception*/」にマッチさせてたというのはあんまりすぎますけどね。
JavaScriptにはevalがあるので
については、コーディング規約で「eval禁止。理由はセキュリティチェック。他の方法で回避できない場合は逸脱決裁を受け、特別のパターンファイルの提供を受けること」みたいにするのもアリだと思う
Javascriptの場合、new Function("alert('EVIL CODE!!');")();のような方法もありますし、HTMLと組み合わせた場合、document.body.innerHTML = '
'+document.body.innerHTML+'
'なんてこともできますし、それらを全部防ごうとするのは結構大変ですよ。
# パターンファイル化のためとは関係なく、eval系を極力使わない/使うときは細心の注意を払って、というのはセキュリティ上、大変よいことですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
仏の顔も三度まで（二回なら許してあげてｗ） (スコア: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のアカウントさえ合っていればアクセス元を制限せず公開用サーバに
ファイルを置くことを許してし
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:仏の顔も三度まで（二回なら許してあげてｗ） (スコア:1)
document.body.innerHTML = '<div onmouseover="alert(\'EVIL CODE!!\');">'+document.body.innerHTML+'</div>'
1を聞いて0を知れ!