アカウント名:
パスワード:
改ざんされたファイルは前回とは違い、現在のところ原因も不明とのこと（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*/」に変わった際には、それまで検出できていたウイルス対策ソフトが一斉に検出不能に陥ってしまったが、今回も見事に検出を回避してしまった。攻撃の手は緩むことなく、まだまだイタチごっこが続くようだ。■埋め込みコードは無印に 今回の変更では、「/*LGPL*/」や「/*Exception*/」といった記述がなくなり、scriptタグの後から「try{window.onload=…」という感じで、いきなりスクリプトが記述されている。これまでのマークをキーワードに改ざんチェックをしていると、あっさり見過ごしてしまう。(中略) ソフォスが「Troj/JSRedir-AK」で検出するのは、改ざんされたページに埋め込まれた「/*LGPL*/」までの不正なスクリプト。この段階で検出すると、以後の攻撃コードやパソコンにインストールされるウイルス本体にはたどり着かないので、ほかは検出されない。すなわちこれは、改ざんページがいかに多いのかを示しているわけだ。
昨年12月から被害が続出している国内のWebサイト改ざんだが、28日未明から、再び改ざんサイトに埋め込むコードの書き換えが始まっている。 22日未明に「/*LGPL*/」から「/*Exception*/」に変わった際には、それまで検出できていたウイルス対策ソフトが一斉に検出不能に陥ってしまったが、今回も見事に検出を回避してしまった。攻撃の手は緩むことなく、まだまだイタチごっこが続くようだ。
■埋め込みコードは無印に
今回の変更では、「/*LGPL*/」や「/*Exception*/」といった記述がなくなり、scriptタグの後から「try{window.onload=…」という感じで、いきなりスクリプトが記述されている。これまでのマークをキーワードに改ざんチェックをしていると、あっさり見過ごしてしまう。(中略) ソフォスが「Troj/JSRedir-AK」で検出するのは、改ざんされたページに埋め込まれた「/*LGPL*/」までの不正なスクリプト。この段階で検出すると、以後の攻撃コードやパソコンにインストールされるウイルス本体にはたどり着かないので、ほかは検出されない。すなわちこれは、改ざんページがいかに多いのかを示しているわけだ。
ここでJR東日本を「ノーガード戦法」と非難したところで、他の改ざんサイトが改善するわけでなし。ガンブラーの攻撃は進化しているわけだから、これはもうユーザー側で防御するしかないでしょう。
# 同じ管理体制ならJR東日本に三度目がありそうですけどね
気になるのは１．サイトの管理体制 同じ失敗を繰り返すって、とてつもない人が管理していそうだな。 予算が無いからとかいう理由だったら悲しい。
２．管理用コンソールがまた感染したのか？ セキュリティ対策はしなかったのか？
３．駆除しきれなかったのか？ Rootkit系にやられてる？ 実はガンブラー系に見せかけた、スピア型の攻撃を受けてる？
コメント変えたり、変数名変えたり、間に関係のない処理を挟んだら検出できなくなるものが結構あるとか？
心の広い仏でさえ二度までが限度で三度目はNGです。一般人は仏みたいに心が広くないので二度目でNGです。一度目でNGの場合もあり得ます。
> これまでのマークをキーワードに改ざんチェックをしていると、あっさり見過ごしてしまう。
「鈴木という名前で犯行を繰り返しています」「鈴木が来たら注意しましょう」（全国の、そしてシアトルの鈴木さんごめんなさい）というやりかたじゃ、そりゃ鈴木が佐藤に名を変えて犯行をおこなったら捕まえられないでしょう。犯行手口というか、実際のスクリプト部分の内容でチェックできないのでしょうか。
> 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を中間コードに置き換えて検出する」に対して、「文字列の形でウィルスコードが書かれていたら検出するのが難しい」って話じゃないの？
いや、それはそれで業者任せにしてるってことで、どうかという気もします。 まあ専門家でもなんでもないJRがじゃあどうすればと言われると難しいですが・・・。
＃ 専門家のはずのNから、Gumbler感染してないか調査してくれ、とお手紙きたよ＼(^o^)／ ＃ いいんだな？調査方法も何も指定せずに、俺に丸投げして本当にいいんだな？俺がぐぐった範囲でしか調べられんぞ？
より多くのコメントがこの議論にあるかもしれませんが、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 セキュリティ通信）
ここでJR東日本を「ノーガード戦法」と非難したところで、他の改ざんサイトが改善するわけでなし。
ガンブラーの攻撃は進化しているわけだから、これはもうユーザー側で防御するしかないでしょう。
# 同じ管理体制ならJR東日本に三度目がありそうですけどね
モデレータは基本役立たずなの気にしてないよ
Re:仏の顔も三度まで（二回なら許してあげてｗ） (スコア:3, 興味深い)
気になるのは
１．サイトの管理体制
同じ失敗を繰り返すって、とてつもない人が管理していそうだな。
予算が無いからとかいう理由だったら悲しい。
２．管理用コンソールがまた感染したのか？
セキュリティ対策はしなかったのか？
３．駆除しきれなかったのか？
Rootkit系にやられてる？
実はガンブラー系に見せかけた、スピア型の攻撃を受けてる？
Re:仏の顔も三度まで（二回なら許してあげてｗ） (スコア:1)
なので、今回の件を「同じ失敗」とみなすのはちょっと可哀想だと思います。
Webサイト管理者の職位に優秀な技術者が十分供給されているわけではないことは、ご存知のはずです。
Lv5以下の社員全員にデスマーチ！
こういうマヌケな対策、多いのですか？ (スコア:2, 興味深い)
コメント変えたり、変数名変えたり、間に関係のない処理を挟んだら検出できなくなるものが結構あるとか？
1を聞いて0を知れ!
Re:仏の顔も三度まで（二回なら許してあげてｗ） (スコア:2, すばらしい洞察)
心の広い仏でさえ二度までが限度で三度目はNGです。
一般人は仏みたいに心が広くないので二度目でNGです。一度目でNGの場合もあり得ます。
Re: (スコア:0)
> これまでのマークをキーワードに改ざんチェックをしていると、あっさり見過ごしてしまう。
「鈴木という名前で犯行を繰り返しています」「鈴木が来たら注意しましょう」（全国の、そしてシアトルの鈴木さんごめんなさい）
というやりかたじゃ、そりゃ鈴木が佐藤に名を変えて犯行をおこなったら捕まえられないでしょう。
犯行手口というか、実際のスクリプト部分の内容でチェックできないのでしょうか。
Re: (スコア:0)
履歴管理がしっかりしている製作現場ならば出来ます。
単純にファイルのタイムスタンプを照らし合わせただけでも改竄は確認できますし、
仰る「スクリプト部分の内容」についても、それほどバリエーションがあるわけではないので、
「このファイル以外で××を使っているはずが無い」等と言う事になります。
ただ、そのようにちゃんと環境や仕組みを整備するまでが難儀です。
特に古くから存在するWebSiteについては、中の人が現存するファイルの大部分を把握出来ていません。
コンテンツ管理、ファイル管理、履歴管理の仕組みが当たり前になる以前にサーバに上がっちゃったファイルが足を引っ張ります。
5年以内にゼロから構築したようなサーバでは、最初から管理された環境で作られているはずなので、たぶん平気。
# 「捨てる勇気」って大事だなぁと思いつつ、個人的には出来てない。
Re: (スコア:0)
Re: (スコア:0)
― 隣の会社 ―
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を使わずにサイトを作れ。
対策したつもりとノーガード戦法は別では？ (スコア:0)
・ウイルスに対する理解が不足していて対策になってなかったとか
・委託していた業者を対策済みという業者に変えたら、まるで対策されてなかったとか
・業者に変えたら、孫請けが一緒だったとか
そういう事例ではないかと思ったので。
人任せはよくない (スコア:0)
いや、それはそれで業者任せにしてるってことで、どうかという気もします。
まあ専門家でもなんでもないJRがじゃあどうすればと言われると難しいですが・・・。
＃ 専門家のはずのNから、Gumbler感染してないか調査してくれ、とお手紙きたよ＼(^o^)／
＃ いいんだな？調査方法も何も指定せずに、俺に丸投げして本当にいいんだな？俺がぐぐった範囲でしか調べられんぞ？