CMSが狙われる3つの理由：川口洋のセキュリティ・プライベート・アイズ（45）
今回のコラムでは、ラックのセキュリティ監視センター、JSOCでもたびたび観測しているCMSを狙った攻撃の状況とその対策について解説します。
狙われるCMS
皆さんこんにちは、川口です。前回のコラムではJavaの脆弱性を悪用した攻撃を取り上げましたが、その攻撃経路として正規のWebサイトが悪用されるケースがあります。
ラックのセキュリティ監視センターJSOCでは、正規のWebサイトがハッキング被害に遭う際にCMS（Content Management System）の脆弱性が悪用されているケースを複数観測しています。今回のコラムでは、そのCMSを狙った攻撃の状況とその対策について解説します。
主なCMSが攻撃対象に
JSOCで観測している攻撃は以下のようなCMSに対して行われています。いずれも、一度は名前を聞いたことがあるのではないでしょうか。
WordPress
Joomla!
Movable Type
MODx
Moodle
e107
Drupal
Zen Cart
osCommerce
もちろんこれら以外のCMSに対しても攻撃は行われていますが、利用者が多いことから、特にこれらのCMSに対する攻撃は多い傾向にあるようです。
そして、これらのCMSに対して、以下のような手法で攻撃が行われています。
OSコマンドインジェクション
SQLインジェクション
Remote File Inclusion
管理画面の認証回避
任意のファイルのアップロード
なお、Zen Cartの脆弱性を狙った攻撃については、以前の私のコラムでも取り上げましたが、現在もZen Cartを狙った攻撃は継続しています。
攻撃者の狙いはシステムへの侵入です。システムに保存されている重要な情報を盗み出したり、前回紹介したような悪意ある攻撃コードをWebサーバに埋め込み、二次攻撃、三次攻撃につなげる足がかりとして、CMSが狙われているのです。
CMSが狙われる3つの「ワケ」
ではなぜ、数あるアプリケーションの中でCMSが攻撃の被害を受けているのでしょうか。それにはいくつかの理由があります。
- オープンソースソフトウェアであり、ソースコードの参照が可能である
- ホスティングサービスの環境では容易にアップデートできない
- 攻撃の検知、防御が難しい
1つ目の理由は、攻撃対象となっているCMSの多くはオープンソースソフトウェアであるという点です。
一般的にオープンソースのソフトウェアは「多くの目にさらされているから問題も発見しやすい」と認識されています。ApacheやBINDのように多くのユーザーがいるソフトウェアならば、この法則はある程度当てはまると考えています。
しかし、CMSとなるとどうでしょうか。ユーザーでかつソースコードにまで目を通すエンジニアの数となると、ApacheやBINDと比べてかなり少ないのが現状でしょう。
一方、攻撃者にとってはソースコードを参照することで脆弱性を特定し、攻撃手法を確立することが容易です。この点は、明らかに攻撃者にとって優位に働く要因になっています。こうして攻撃手法を手に入れた攻撃者は、脆弱性情報が開発者に認知される前に脆弱なサイトに対して攻撃を開始するため、脆弱性が一般に認知されるプロセスまでもが変わってしまいます。
多くの場合、脆弱性情報の公開は以下のようなプロセスになっています。
しかし、オープンソースのCMSでは以下のようなプロセスになっている事例も多く発生しています。いわゆる「ゼロデイ攻撃」の状態です。
このプロセスは、オープンソースであればCMSに限った話ではありません。ただ、弊社が対応した事例では、CMSに多く発生しているようです。
さらにやっかいなことに、非常にマイナーなCMSが攻撃の対象になるケースもあります。お客さまからの相談を受けて初めて、特定業種でのみ使用されているCMSの存在を知るケースもあります。
先日から報道されているFacebookやAppleに対する攻撃事例のように、特定業種を狙いたい動機を持つ攻撃者にとって、特定業種で使用されるCMSの脆弱性は非常に「おいしい」存在となります。
ホスティング環境におけるアップデートの困難さ
CMSが被害を受ける2つ目の理由は、ホスティングサービス環境にあるCMSが容易にアップデートできないためです。
多くのホスティングサービスでは、ユーザーへの付加価値として「CMSが簡単に使えること」をうたっています。人気の高いWordPressやMovable Type、Zen Cartなどが使えるようになっているホスティングサービスも多いようです。
ここで問題となるのは、これらのCMSに脆弱性が発見された場合、ホスティング事業者がバージョンアップを行うのか、ユーザーがバージョンアップを行うのかということです。多くの場合、ホスティングサービス事業者がバージョンアップすることになりますが、ユーザー環境全体に影響が及ぶため、すぐに作業ができるとは限らないでしょう。
ホスティング事業者が提供するCMSを利用するユーザーは、その脆弱性は誰の責任で対応するのか、事前に把握しておいた方がよいでしょう。自分で管理できないものは最初から使わないのも賢い選択です。
CMSに対する攻撃の検知、防御が困難
CMSが攻撃の被害を受ける3つ目の理由は、攻撃を発見しにくいことです。CMSの脆弱性情報が公開されていればまだましな方で、先ほども書いたように、脆弱性情報の公開前に攻撃を受けるケースや、セキュリティサービスを提供する我々も知らないCMSが攻撃対象となる場合にはどうしようもありません。
また、ホスティング環境を契約してCMSを利用しているユーザーの中には、予算や技術的な問題からセキュリティ監視を実施していない場合も少なくありません。ホスティング事業者自身がセキュリティ監視サービスを提供しているケースもありますが、まだ広く普及しているとは言い難い状況です。
さらに、技術的な問題もあります。OSコマンドインジェクションやSQLインジェクションであれば、攻撃の通信パターンをシグネチャ化して、IDS／IPS／WAFで検知、防御可能です。しかし、管理者画面へのアクセスや特定パターンでのファイルがアップロード可能な脆弱性などはシグネチャ化が難しく、攻撃が行われていることを認知できません。環境によってはHTTPSが使用されており、SSL復号機能がないセキュリティ製品ではシグネチャがあっても検知、防御できません。
CMSを利用する場合の注意点
このように「脆弱性の見つけやすさ」「環境による対策の難しさ」「発見のしにくさ」の3点から、CMSに対する攻撃の被害が発生しています。そこで、CMSを利用する場合には以下のような対策をお勧めします。
- できる限り最新バージョンのCMSを利用する
- CMSのプラグインの脆弱性にも注意する
- フリーで公開されているテンプレートやテーマファイルにも同様に注意を払う
- インストール時に使用したファイルで不要なファイルが残っていないか確認する
- 管理画面にアクセスできるIPアドレスを制限する
- 管理画面にログインするユーザーのパスワードを強固なものに設定する
- IPSやWAFで攻撃を防御できる対策を併用する
今回はCMSに対する攻撃を取り上げました。今後も新たなソフトウェアが登場し、普及すればそれが攻撃対象になることでしょう。最新のセキュリティ情報の交換のために、セキュリティ関係者と今日も飲みに行くのでした。
著者プロフィール
川口 洋（かわぐち ひろし）
チーフエバンジェリスト
CISSP
ラック入社後、IDSやファイアウォールなどの運用・管理業務を経て、セキュリティアナリストとして、JSOC監視サービスに従事し、日々セキュリティインシデントに対応。
チーフエバンジェリストとして、セキュリティオペレーションに関する研究、ITインフラのリスクに関する情報提供、啓発活動を行っている。Black Hat Japan、PacSec、Internet Week、情報セキュリティEXPO、サイバーテロ対策協議会などで講演し、安全なITネットワークの実現を目指して日夜奮闘中。
2010年〜2011年、セキュリティ＆プログラミングキャンプの講師として未来ある若者の指導に当たる。2012年、最高の「守る」技術を持つトップエンジニアを発掘・顕彰する技術競技会「Hardening」のスタッフとしても参加し、ITシステム運用に関わる全ての人の能力向上のための活動も行っている。
Copyright © ITmedia, Inc. All Rights Reserved.