検索
連載

ここが変だよ、そのWeb改ざん対応：川口洋のセキュリティ・プライベート・アイズ（47）

IEのゼロデイ攻撃で最初のトリガーとなった「Web改ざん」。改ざんされた後の対応次第では、被害をさらに広げてしまう結果になりかねません。今回は、筆者が見かけた「いまいちイケてない」インシデント対応を紹介します。

Share
Tweet
LINE
Hatena
「川口洋のセキュリティ・プライベート・アイズ」のインデックス

連載目次

エポックメーキングな出来事だったIEのゼロデイ攻撃

　皆さんこんにちは、川口です。気が付けば半年もこのコラムからご無沙汰しておりました。あちこちで「最近は書かないんですか？」と聞かれてしまい、期待していただいている方には申し訳ない気分でいっぱいです。言い訳をすると、仕事も少し変わり、Hardening One Remixをやり、セキュリティキャンプをやり、出張三昧が続き……と目まぐるしい生活を送っていました。

　そんなこんなの生活を送っているうちに、Internet Explorer（IE）に存在したゼロデイ脆弱性を狙った事件が発生していました。私がセキュリティを意識するようになって14年経ちますが、今回の事件は、私の歴史の中の新たな1ページとして刻まれました。

　この事件に関して私が危機感を持ったのは、以下の点でした。

  • IEという業務でよく使われるソフトウェアのゼロデイが使用された
  • 多くのセキュリティ保護機能をすり抜けていた
  • 攻撃コードの配布はアクセス元のIPアドレスによって制御されていた
  • 日本のWebサイトを悪用し、日本の組織を狙った攻撃だった

　特に、IEのゼロデイが、日本の組織に対してこれほど用意周到に投入されたことが衝撃的でした。

【関連リンク】

いわゆる「水飲み場攻撃」に管理者はどう対応すべきか

http://www.atmarkit.co.jp/ait/articles/1310/10/news145.html

日本における水飲み場型攻撃に関する注意喚起

http://www.lac.co.jp/security/alert/2013/10/09_alert_01.html

水飲み場型攻撃に関する対策について

http://www.lac.co.jp/security/alert/2013/10/09_alert_02.html


7つのイマイチな対応事例

　このインシデントは「Web改ざん」が最初のトリガーになっています。Web改ざんというインシデントは今に始まったものではありませんが、比較的よく聞くインシデントであるだけに、中には誤った対応や不十分な対応をしている事例があります。

　そこで今回は「7つのイマイチなWeb改ざんインシデントの対応事例」をご紹介します。

（1）改ざんされている事実を認知できない、または非常に時間がかかる

　外部からWebサイトの改ざんを指摘された際に、簡単な確認だけ行い、「改ざんの事実なし」として放置されている事例が少なからず発生しています。

　攻撃者は、アクセスしてきたクライアントの「アクセス元IPアドレス」「Referer」などをチェックして、目当ての対象からのアクセスのみに攻撃を仕掛け、攻撃対象外のクライアントには正常なコンテンツを返すように設定している場合があります。もし外部からWebサイト改ざんの指摘をされた場合には、以下のような複数の手段で確認することをお勧めします。

  • Webサイトのログイン履歴を確認する
  • Webサイトのコンテンツをマスターデータと比較して確認する
  • Webサイトを参照する際は「万が一、未知のウイルスに感染してもいい端末」から確認する
  • スマホや携帯電話などの外部のネットワークから確認する
  • 複数のブラウザで確認する
  • FiddlerやFirebugなどのHTTP通信の中身を参照できるツールも併用する

（2）改ざんされた原因を調査せず、コンテンツだけ戻している

　「改ざんされたんだからバックアップから戻せばいいだろ」とばかりにコンテンツを復元して、根本原因に対処していない場合があります。

　Webサイトが改ざんされる大きな原因としては、「システムの脆弱性が悪用される」パターンと「正規のアカウントで不正ログインされる」パターンがあります。このどちらのパターンでやられたのかを把握しておかないと、再度改ざんされて被害に遭う可能性があります。原因を突き止めるとともに、以下の点も併せて確認してください。

  • CMSの設定や管理パスワードの見直し
  • FTPやSSH、RDPなどのリモートメンテナンス経路の見直し
  • 管理用端末の管理状況の見直し
  • 使用しているWebアプリケーションの脆弱性の有無の再確認
  • レンタルサーバやホスティングサービスからの脆弱性に関する告知の再確認

（3）管理用パスワードを変更していない

　「正規のアカウントで不正ログインされる」パターンでの改ざんは、Webサイト管理用のIDとパスワードが推測されたり、管理用端末に感染したウイルスによりパスワードなどが抜き取られていたりすることが主な原因です。

　改ざん事件が発生した場合には、念のためそのWebサイトで使用しているパスワードを全て変更してください。アカウントの数が多くそれが困難な場合でも、最低限、改ざんに使用されたIDのパスワードは変更してください。もちろん複雑なパスワードを設定する必要があるのは言うまでもありません。

　ときどき「IDも変更した方がいいですか？」という質問を受けることもあります。全てのIDを変更するのは現実的ではない場合も多いですが、「被害に遭ったID」や「管理者用で変更可能なID」については変更しておいた方がよいでしょう。特に、「admin」やCMSによってたびたび使われる管理者用IDが変更可能であれば、変更しておいた方がよいでしょう。

（4）パスワードを「定期変更する」という対策を取った

　「パスワードの定期変更」そのものについては賛否両論あるところですが、Web改ざんが発生した場合の対策として「パスワードの定期変更」は不十分な場合が多いです。多くの場合、管理用の端末からパスワードが漏れていたり、安易なパスワードが設定されていたりすることが原因ですので、パスワードの定期変更を実施したところで防ぐことはできません。むしろ、新たに設定されるパスワードが弱くなることの方が多いでしょう。

　もしも、複雑なパスワードを設定していた上で、ネットワーク経由でパスワードを総当たりする攻撃を心配しているのであれば、アカウントロック機能やログインアラート機能を実装する方に力を注いだ方がよいでしょう。

　パスワードの定期変更については、＠ITにて辻さんが以下の記事で説明しています。ぜひこちらも参照してください。

【関連記事】

パスワードの定期変更という“不自然なルール”

http://www.atmarkit.co.jp/ait/articles/1102/04/news117.html


（5）管理端末の保護を検討していない

　管理端末にウイルスが感染し、IDとパスワードを盗まれてしまうケースの場合、管理端末の保護も検討しなければなりません。一言でくくると「ウイルス対策をしましょう」となってしまいますが、基本的な方針は以下のようになります。

  • 使用するソフトウェアを最新のものにする
  • 不特定多数の人とのメールをやりとりする端末や多数のWebサイトを参照する必要のある端末と、Webサイト管理端末とを分離する
  • Windowsの場合、マイクロソフトが提供する脆弱性緩和ツール「EMET（Enhanced Mitigation Experience Toolkit）」を導入する

　Webサイトを所有する組織とメンテナンスを行う組織が異なる場合も多くあり、メンテナンスを行う組織では、所有する組織ほどの対策ができない可能性があることも考慮に入れておくべきです。このあたりの対応の難しさは過去のコラムに書いていますので、気になる人は参照してください。

【関連記事】

川口洋のセキュリティ・プライベート・アイズ（23）

Gumblarがあぶり出す 「空虚なセキュリティ対策」

http://www.atmarkit.co.jp/fsecurity/column/kawaguchi/023.html


（6）メンテナンス通信のプロトコルをFTPからSSHに変更しただけ

　対策として、メンテナンスに使うプロトコルを変更しただけのケースもありました。Gumblarが流行っていた2009年ごろはFTPが狙われていましたが、現在はFTPのみならずSSHも対象となっています。アカウントを盗むウイルスはSSHクライアントのみならず、その他のさまざまなアプリケーションのIDとパスワードを盗むように進化しており、プロトコルを変更するだけでは不十分ですので、注意してください。

　余談ですが、ウイルスが感染した端末からさまざまなアプリケーションのIDとパスワードを盗み出し、Webサイト改ざんだけではなく、大量のスパムメールや迷惑メールの送信を行うケースもあります。攻撃者は、盗み出したIDとパスワードを使い、正規のメールサーバを使用して（おそらくは事前に用意された）大量のメールアドレスにメールを送信しています。「不正メール送信についての報告」などと記載されたケースの多くは、ウイルスによって盗み出されたIDとパスワードを悪用されたものです。

（7）改ざん、作成された攻撃者のファイルを見逃している

　Webサイトが改ざんされた際には、該当のサーバ上にあるコンテンツをすべて破棄して、バックアップから復元することが望ましいです。しかし、コンテンツの数によっては被害を受けたファイルのみを削除、修正して対応するケースもあるでしょう。その場合、攻撃者が設置したファイルを見逃していると、再び攻撃が行われて大騒ぎになることがあります。

　特に「.htaccess」は見逃しやすいファイルです。見慣れない「.htaccess」が存在しないか注意した方がよいでしょう。そして、不正な「.htaccess」とセットで配置されることが多いのが「画像ファイルに装ったバックドアファイル」です。本来存在しないはずの画像ファイルが存在していないかどうかも、気を付けて確認するようにしてください。

【関連リンク】

Gumblar（ガンブラー）ウイルスによる新たなホームページ改ざん被害を確認（2010年の注意喚起）

http://www.lac.co.jp/security/alert/2010/03/03_alert_01.html


　また、Webサーバのコンテンツを置き換えるのではなく、Webサーバプログラム本体やプログラムモジュールに細工をするケースもあります。この場合、Webサーバのコンテンツは変更されていないため、バックアップファイルと比較しても違いがなく、被害を見逃してしまう可能性があります。（1）で解説した方法を使って確認してください。

　そして、Webサーバのプログラム本体やプログラムモジュールに細工を加えるにはサーバの管理者権限が必要であり、その場合、単にコンテンツを置き換えられるケースよりも被害は深刻です。このような改ざん被害にあった場合には、このサーバは隔離して再インストールすることをお勧めします。

【関連記事】

おさまらぬWeb改ざん被害、Apacheモジュールの確認を

http://www.atmarkit.co.jp/ait/articles/1303/25/news122.html


まとめ

　今回は比較的よく見る「Web改ざん」のインシデント対応を取り上げてみました。改ざんされた後の対処をしくじると、サイトを参照する多くのユーザーに迷惑をかけることにつながります。もし、読者の方の周りで改ざん事件が発生した場合には、このコラムを見てアドバイスをしてあげてください。日本のWebサイトが安全に運用されることを願うばかりです。

　最近はお客さまが日本酒好きの方が多く、日本酒を飲む機会が特に多くなりました。また、出張先で現地の美味しい日本酒をいただくことが出張の1つの楽しみになっています。日本酒を味わいながら日本の平和を語るために、私は今夜も飲みに行くのでした。

著者プロフィール

川口　洋（かわぐち　ひろし）

株式会社ラック

チーフエバンジェリスト

CISSP

ラック入社後、IDSやファイアウォールなどの運用・管理業務を経て、セキュリティアナリストとして、JSOC監視サービスに従事し、日々セキュリティインシデントに対応。

チーフエバンジェリストとして、セキュリティオペレーションに関する研究、ITインフラのリスクに関する情報提供、啓発活動を行っている。Black Hat Japan、PacSec、Internet Week、情報セキュリティEXPO、サイバーテロ対策協議会などで講演し、安全なITネットワークの実現を目指して日夜奮闘中。

2010年〜2011年、セキュリティ＆プログラミングキャンプの講師として未来ある若者の指導に当たる。2012年、最高の「守る」技術を持つトップエンジニアを発掘・顕彰する技術競技会「Hardening」のスタッフとしても参加し、ITシステム運用に関わる全ての人の能力向上のための活動も行っている。


「川口洋のセキュリティ・プライベート・アイズ」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る