第4回まっちゃ445「インシデントレスポンスワーク EC-CUBEの事例」
2009年1月31日(土曜日)
第4回まっちゃ445「インシデントレスポンスワーク EC-CUBEの事例」
公開: 2009年2月2日19時10分頃
ロックオン福田さんとJPCERT/CCの安藤さん、佐藤さんのお話。JVN#81111541 (jvn.jp)のハンドリングについて。
※「おーい、ポスターはっといてー」という感じで、CHECK PC! のポスター (www.checkpc.go.jp)が貼り出されたり。
EC-CUBEについて
- 株式会社ロックオン / 大阪本社・東京支社 従業員約40名
- EC-CUBEはオープンソースのECソフト
- 2007/11から配布、現在では約3,000店舗が利用。毎月200店舗くらいのペースで増加。参考情報として、楽天のショップ数は24,000くらい。3,000という数字はけっこう多いと言って良い
問題の概要
- 8/27 : EC-CUBE で SQLインジェクションの脆弱性発見、管理者権限奪取可能
- 10/1 : JVN#81111541の一般公開・IPA注意喚起
- EC-CUBEはもともとPostgreSQL専用だったが、慌ててMySQL対応した際に問題が発生した
- 当時2500あったサイトが危険にさらされており、推定で数百万件規模の個人情報がいつ抜き取られてもおかしくない状態
- 元々は軽い気持ちで開発を始めたが、いつのまにか影響が大きくなっていた
問題への対応
- 慌てて公開すると、既存利用者の対応が間に合わない
- 対応を遅らせると、毎日200件程のペースでダウンロードされて脆弱なサイトが増えて行く
→JPCERT/CCに相談
対応策
- バージョンアップに紛れて改修するのはどうか? → オープンソースなので履歴ですぐに分かる
- バージョンはそのまま、ダウンロードファイルをこっそり入れ替えておくのはどうか? → ヤミ改修と騒がれて祭りになるおそれがある
EC-CUBEはダウンロードされてから利用開始まで約3ヶ月かかるので、今ファイルを差し替えてもすぐには影響が出ない。既存利用者の保護を優先するべきと判断した。
三段階に分けての告知を計画。
- 第1段階: ロックオンが把握する利用者に個別にメール
- 第2段階: 管理画面「お知らせページ」に警告を表示 (MT管理画面のように、お知らせを表示する機能がある)
- 第3段階: 一般公開
JPCERT/CCの立場としては、最終的にはメーカーの判断に合わせることになる。こうしなければいけない、というものは無い。利用者が少ない場合は段階公開ではなくいきなり公開ということも多い。
基本的には、秘匿のうちに取り扱いを進めて、パッチと共に公開という流れになる。
第1段階の対応
- 脆弱性の判明から2日後、既存利用者へメール。100～130件くらい。
- 口外しないように、とのお願い
- 当初はメール添付で修正ファイルを配布してしまい、怒られた。急遽、マル秘の認証付き告知ページを作成してダウンロードできるようにした。
第2段階の対応
- 一ヶ月後、だいたい対応が終わってきたところで管理画面のお知らせに告知。
- 構築事例一覧ページを公開していたが、これが攻撃先一覧として悪用できることに気付き、慌てて消した。
第3段階の対応
- その3日後、10月1日に一般公開。
- 誰がダウンロードしているか分からないため、管理画面公開は一般公開に近い意味を持つ。そのため、管理画面での公開から一般公開まであまり間を開けない方が良いと判断し、3日後の公開となった。
- 一時連絡では約100社に連絡。
- 24時間以内で40%程度が、48時間以内に60%程度が対応完了。その後はほぼ連絡なし
- 注意喚起しても、対応しない人はしないものらしい。
- 利用している人を把握しておくことは大切だと感じた。
IPA, JPCERT/CC を通じた公開について
- 自社発見の脆弱性を広く公開する必要があったのか? → 内容が致命的だった、自社が把握していない利用者にも周知する必要があった。
- 以前にXSSの連絡を受けたことがあったため、JPCERT/CCのことは知っていた (おそらくJVN#61543834 (jvn.jp)のこと)。
- 信頼性低下を懸念したが、結果的には悪影響はほとんどなかった。
- ダウンロードが減るどころか、むしろ増えた。この脆弱性情報を通じて初めて製品を知った人も多かったと思われる。
- 隠すのは良くない。
- 自社製品の届出自体、少ない
- 多くの場合はIPAへの届出を経由したもの。IPA経由でのハンドリングはなかなか難しい場合も……。
その後
再度、全てのソースコードを調査したところ、さらに脆弱性が発見された。
- SQLインジェクション: 1件
- XSS: 7件
- CSRF: 3件
そのため、11月に再度、脆弱性情報を公表。
最初は軽い気持ちで作ったが、世に出すのは怖い。ちゃんと相談して進めるとうまく行く。自分たちで勝手に判断して行動しなくて良かったと感じている。
質疑は省略。特定のユーザに先行公開するのは良くないのではないか、仮にするとしても、そのユーザの身元確認、NDA契約などが必要なのではないか、といったような話が出ておりました。
- 「第4回まっちゃ445「インシデントレスポンスワーク EC-CUBEの事例」」へのコメント (1件)
関連する話題: セキュリティ / メモ / SQLインジェクション
