震度7を初体験、そこで感じた「分かっちゃいるけど」
皆さんこんにちは、川口です。
先日、墨田区にある本所防災館の防災体験ツアーに参加してきました。この防災体験では「消火」「煙」「暴風雨」「地震」の4つを体験することができます。どれも初めての体験でとても新鮮でしたが、特に衝撃的だったのは「地震」体験でした。これは、家具を配置した地震体験コーナーなのですが、今回選択したのは震度7強のコース。ここまでくると未知の領域です。万が一のときのために一度は経験しておかねば、ということで挑戦してみました。
ほかの方が震度5や震度6の揺れを体験しているのを見て、「なかなか動けないものなんだな」ということだけは分かりました。そしていざ自分の番になって震度7を体験してみると、「足がすくんで動けない」「来ると分かっていても体が反応しない」という状態でした。
地震が始まると、机の下に隠れるように指示をされているのですが、地面が揺れているため、足がずれてうまくしゃがめません。そして机の下に入ろうにも机が動いて止まらない……。さらに机の脚にしがみついても、机が動くので体が安定しない……など、たった数秒間でしたが驚きの連続でした。震度7の激しさを経験したことがないと、いざ本当の地震が発生したときにパニックになり、机の下に隠れることすらも難しいかもしれません。
アカウント情報盗用ボットとは？
さて今回は、分かっていても体が動かなかった震度7強の体験から、分かってはいるけど対応が難しい“ボット”のお話をしましょう。特に最近発生している、パスワードを盗み、ホームページを改ざんする事件に使われているボットのお話です。世間ではGENOウイルスやZLKONウイルスなどと呼ばれている場合もありますが、今回は「アカウント情報盗用ボット」とします。
このアカウント情報盗用ボットは以下のような活動をします。
- パソコンにボットが感染
- パソコンが使うFTPのアカウント情報（ユーザー名／パスワード／接続先情報）を盗む
- 盗んだアカウントを外部に送信
- 盗んだアカウントでFTPサーバにログイン
- 対象サーバのウェブコンテンツのファイルを改ざん
- 改ざんされたファイルを参照したユーザーもボットに感染
まず1．のボット感染経路に関しては、「クライアントアプリケーションの脆弱性を狙った攻撃」「USBメモリ」「Windows管理共有」など、いままでのボットと同じ経路で感染が行われます。そして2．と3．にてFTPのアカウント情報を盗み、4．と5．でコンテンツを改ざんします。
これら活動はまったく新しいものはありません。そうなると、対策も既存の方法で対応できるはずです。しかし、対策が簡単にいかないところが、アカウント情報盗用ボットが問題となっている理由なのです。
対策を行うべき3つのポイント
アカウント情報盗用ボットの対策を行うべきポイントを、「PC」「サービスの提供者」「ネットワーク」の3つに分けて考えます。
●PCの対策、まずはウイルス対策ソフト
まず、PC側での対策について考えましょう。企業の情報システム部で、パッチの適用やUSBメモリの使用制限などが行われていれば、ボットに感染する確率は低いでしょう。しかし、企業ではパッチがリリースされてからすぐに適用することは難しいですし、USBメモリの使用制限が行われていない環境もたくさんあります。さらに個人所有のPCであればなおさら、セキュリティ対策が行われていないでしょう。セキュリティの専門家（といわれている）の私でも、日々発見される脆弱性への対応が間に合わずボットに感染するのではないかと心配しているくらいです。
このような環境において、ボットに感染しないように使用することは困難です。また、ウイルス対策ソフトが常に新しいボットに対応してくれていればいいのですが、残念ながらボットの亜種・新種の対応には数時間、数日かかり、そのすき間にボットが入り込んでしまいます。
●サービス提供者はセキュリティの基本を再度見直すべし
次にサービスの提供者側での対策です。サービスの提供者としては、まったく無関係な第三者にアカウント情報が渡ったとしても、使用させなければ問題ありません。
一般的なセキュリティ対策を実施している企業では、FTPサーバにアクセスできるパソコンを制限しているため、アカウント情報が漏れたとしてもそれを悪用することができません。しかし、不特定多数にFTPサービスを公開しているサービスの場合、アクセス制御での対策を行うことができません。FTPサービスのログインの際に、ワンタイムパスワードや二要素認証を使うことでの対策も技術的には可能ですが、コストも時間もかかるため、すぐに実施することは難しいでしょう。
さらに、コンテンツに不審な文字列が含まれていないかをチェックすることも可能ですが、改ざんされる内容も変化しているため、「運がよければ発見できる」程度と考えるべきです。
JPCERT/CCからの注意喚起にも記載されていますが、多くのサイトではJavaScriptのコードが埋め込まれています。しかし、攻撃者はすべてのウェブコンテンツを自由に書き換えることができる権限を手に入れていますので、埋め込まれる文字列はJavaScriptだけとは限りません。JSOCでもiframeタグの埋め込みを確認しています。ボットを埋め込む悪性サイトに誘導するためであればMETAタグでRefreshを使うこともあり得ます。それでもチェックできる環境にあるのであれば、不審な文字列が埋め込まれていないか確認してみるのも1つの手でしょう。
●ネットワークではブラックリストを活用せよ
最後に、ネットワーク側での対策を考えます。ネットワーク側では3、4、5の活動は日常的に使用されるプロトコルで行われているため、検知・防御することがとても難しくなっています。特に以前までのように、FTPサービスにブルートフォース攻撃を行うことなく、盗用したアカウント情報を使い一発でログインしてくるため、さらに検出を難しくしています。
そこでせめて6．の「ボット感染の活動」を検知・防御できればいいのですが、JavaScriptの難読化やボットの頻繁な変化により、それも難しいのが現状です。できることとしては、このボットが送信するサーバやFTPサービスにログインしてくるサーバのIPアドレスを、ブラックリストとして接続を拒否する設定することくらいです。
今後、アカウント情報盗用ボットはますます悪質に進化する恐れがあります。例えば、以下のような展開が考えられます。
- FTPでなくブログの管理画面から改ざんされる
→ログイン画面の認証情報を盗用されて改ざんされる - FTP以外の通信形式が狙われる
→SSHやファイル共有なども危険 - ボットが利用するIPアドレスが増える
→アクセス制御が追いつかなくなる - ボットに感染したパソコンを経由してFTPサーバに接続される
→FTPサーバへのアクセス制御が意味をなさなくなる - FTPでの正規のアップロードの瞬間に自動的にコンテンツを改ざんされる
→FTPサーバへのアクセス制御が意味をなさなくなる
やはり効果があるのは「セキュリティの基本」だが……
このように進化すると、最終的には「パソコンへのパッチを適用し、最新状態に保つ」ということが最も効果のある対策になります。しかし、Windows Updateであればまだしも、そのほかのアプリケーションを最新の状態にし続けることは大きな課題です。
そして企業のサイトで被害が出ている事例をみると、FTPサーバへのアクセス制限が施されていない事例も多数あるようです。不特定多数にFTPサービスを公開する必要がない場合には、必要なIPアドレスからのみ接続ができるようになっているか確認することをお勧めします。「まさか。そんなの大丈夫だよ」というところに限って事件は起きているのですから、これを機に確認してみてください。
余談ですが、私はオンサイト保守と称して、年に数回実家に帰省しています。この帰省中に、父親が仕事で使っているパソコン数台のパッチ適用、アンチウイルスソフトの更新、バックアップなどの作業を行っています。たまたま息子がセキュリティに関係する仕事をしていたため、父親も「セキュリティは気にしないといけないよな」と思うものの、Windows Update以外の作業は父親にとって難しいからです。これも親孝行と思って、せっせと父親のパソコンにパッチ適用をしています。もう少し頻繁にパッチ適用ができるといいんですが、なかなか難しいのが現実です。
のど元過ぎても対策忘れるな！
今回はアカウント情報を盗用するボットについてのお話でした。このボットが話題になるにつれて、2009年4〜5月にはやっていた（はずの）Confickerの話題を聞かなくなりました。ちょうど大騒ぎして、いつのまにか過ぎ去ったような印象がある新型インフルエンザのようです。
新型インフルエンザに関するニュースを見ることも少なくなりましたが、着々と全国に感染者数は増加しています。脅威は去ったわけではなく、引き続き対策は必要なのです。新型インフルエンザに限りませんが、インフルエンザの予防としては、うがいと手洗いのような「小さな対策」を日々継続していくしかありません。人間関係も日々の積み重ねが重要です。私はいざというときにいろいろな人と連携するため、今夜も飲みに行くのでした。
Profile
川口 洋（かわぐち ひろし）
株式会社ラック
JSOCチーフエバンジェリスト兼セキュリティアナリスト
CISSP
ラック入社後、IDSやファイアウォールなどの運用・管理業務をへて、セキュリティアナリストとして、JSOC監視サービスに従事し、日々セキュリティインシデントに対応。
アナリストリーダとして、セキュリティイベントの分析とともに、IDS／IPSに適用するJSOCオリジナルシグネチャ(JSIG)の作成、チューニングを実施し、監視サービスの技術面のコントロールを行う。
現在、JSOCチーフエバンジェリスト兼セキュリティアナリストとして、JSOC全体の技術面をコントロールし、監視報告会、セミナー講師など対外的な活動も行う。
- 「DNS通信」記録していますか？――万一に備えたDNSクエリログの保存方法
- Web広告からのマルウエア感染「Malvertising」にどう対処すべきか
- 中の人が振り返る「Hardening 10 ValueChain」――学びにつながった「トラブルの数々」とは
- 無慈悲な専門家チーム「kuromame6」の暗躍に負けず勝利をつかんだチームは？
- 外部リソースの活用もポイントに、「Hardening 10 MarketPlace」開催
- Hardening Projectから派生した「MINI Hardening Project」に行ってみた！
- 「これさえしておけば助かったのに……」を避けるため、今すぐ確認すべき7項目
- アップデート機能を悪用した攻撃に対抗セヨ！
- 工夫、工夫そして工夫――Hardening 10 APAC“運営”レポート
- ウイルスとは言い切れない“悪意のあるソフトウェア”
- 2013年のセキュリティインシデントを振り返る
- ここが変だよ、そのWeb改ざん対応
- きっかけは不正侵入――私がセキュリティ業界に足を踏み入れたワケ
- CMSが狙われる3つの理由
- FacebookやApple、MSまで……Javaの脆弱性を狙う攻撃の手口
- Hardening One、8時間に渡る戦いの結果は？
- そのときStarBEDが動いた――「Hardening One」の夜明け前
- ロシアでわしも考えた
- 実録、「Hardening Zero」の舞台裏
- ちょっと変わったSQLインジェクション
- 官民連携の情報共有を真面目に考える
- アプリケーションサーバの脆弱性にご注意を
- IPv6、6つの悩み事
- スパムが吹けば薬局がもうかる
- JSOCに飛び込んできた不審なメール――これが標的型攻撃の実態だ
- 東日本大震災、そのときJSOCは
- ペニーオークションのセキュリティを斬る
- 2010年、5つの思い出――Gumblarからキャンプまで
- 9・18事件にみる7つの誤解
- 曇りのち晴れとなるか？ クラウド環境のセキュリティ
- Webを見るだけで――ここまできたiPhoneの脅威
- 不安が残る、アドビの「脆弱性直しました」
- ともだち373人できるかな――インターネットメッセンジャーセキュリティ定点観測
- 実録・4大データベースへの直接攻撃
- Gumblar、いま注目すべきは名前ではなく“事象”
- Gumblarがあぶり出す 「空虚なセキュリティ対策」
- 新春早々の「Gumblar一問一答」
- 実はBlasterやNetsky並み？静かにはびこる“Gumblar”
- ECサイトソフトウェアはなぜ更新されないのか
- 狙われるphpMyAdmin、攻撃のきっかけは？
- 学生の未来に期待する夏
- 米韓へのDoS攻撃に見る、検知と防御の考え方
- 分かっちゃいるけど難しい、アカウント情報盗用ボット対策
- 狙われる甘〜いTomcat
- 表裏一体、あっちのリアルとこっちのサイバー
- 世間の認識と脅威レベルのギャップ――XSSは本当に危ないか？
- 急増したSQLインジェクション、McColo遮断の影響は
- ○×表の真実：「検知できる」ってどういうこと？
- ところで、パッケージアプリのセキュリティは？
- レッツ、登壇――アウトプットのひとつのかたち
Copyright © ITmedia, Inc. All Rights Reserved.