水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 2009年のえび日記 > 2009年1月 > 2009年1月31日(土曜日)

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契約などが必要なのではないか、といったような話が出ておりました。

関連する話題: セキュリティ / メモ / SQLインジェクション

第4回まっちゃ445「インシデントレスポンスの現場から ～事件は会議室で起きているんじゃない。現場で起きているんだ。～」

公開: 2009年2月2日17時5分頃

LAC川口さんのお話。JSOCで検出されたものから分かったいろいろな話。

クライアントを狙った受動的・標的型攻撃

狙われるクライアント

  • IE
  • Adobe Reader
  • Flash Player
  • Real Player と Quick Time (アップデートが難しかったり)

USBメモリを経由するマルウェアが増加

MSの集計によると……

  • 日本はボット感染率が低い。CCCのおかげ?
  • 海外はヤバイ : 回線が細いとパッチ・パターン更新が大変
  • なんで中国は赤でなくオレンジ? → Windows Updateできないので「悪意あるソフトウェアの駆除ツール」がそもそも動作しない?

偽アンチウィルスソフト

  • "AntivirusXP 2008"
  • 年5599円 / 3年11296円……現実的な値段
  • 最近はボットと組み合わされている。インストールすると、一日に1000個単位で謎のexeが増えたりする
  • 偽ソフトを入れると UA が変化して二度目の感染はしないようになっている。言語によって感染対象を選別したりもしている

悪のアジト

  • SQLインジェクションで埋め込まれるURLの統計
  • 次々に移転し続ける、一週間もしたら使い捨て→フィルタリングが追いつかない

中国製攻撃ツール

  • 暗黒工作組
  • サポートあり、アップデートも頻繁。6000円/月くらい。

SQLインジェクション

見つからないように考えられている。頑張るだけ報われる、達成感のあるお仕事 (お金につながる)

件数の推移
  • 2000年くらいには攻撃の理論
  • 2003年、JSOCで初検知。当時は何故こんな面倒な攻撃を行うのか分からなかった (二階の窓をやらなくても玄関が開いている状態)
  • 2005年、ニュースに
  • 2008年10月、26万件
  • 2008年12月、1500万件

撃たれない企業には来ない。過去にやられた企業や、IISを使っている企業には良く来る。その差100～1000倍ほど。

今年の年末は非常に多く、詳細レポートを出すような契約でレポートが2000～3000ページにわたり、印字に15時間というケースも。

攻撃リクエストの変遷
  • 2007年 …… ntext のみにスクリプトを埋め込む
  • 2008年 …… varchar, sysname, text, ntextが対象
  • 最近の攻撃
    • "></title> が頭につくようになって効率UP! 属性値やtitle要素内にインジェクションされても動作する
    • 既にやられているかどうかチェックする (しないと、増殖して行く)
    • マルチバイト文字を含むリクエスト
    • Cookieへのインジェクション → WAF貫通力大。インテリジェンスでない機器では検出された。:-)
    • 冗長な % を含むインジェクション → ほとんどの機器を貫通。
攻撃元

McColo がインターネットから遮断される→スパムが減った? 日本においてはあまり影響なかったかも

  • 中国→韓国にシフトしている
  • 12/10 IE7 のゼロデイ攻撃コード出現、12/14からSQLインジェクション大幅増加、12/18 IE7 のパッチりリース
  • 浅田真央がキムヨナに勝ったのが原因?
謎の文字列

謎の符号化された文字列を埋め込む攻撃

昔から韓国方面で報告。解読はされていなかった。最近日本人が解読。

この攻撃は、中国政府・中国教育機関のドメインは攻撃しないようになっている模様。

XSS

送信元は国内が中心。大規模では行われていない

UTF-7 XSS やる人なんてまずいません。なのですぐ分かる。

わざわざXSSで攻撃する人はほとんどいない (面倒、もっと簡単な方法がある)。

MySQLの攻撃

特定のファイルを削除したりする攻撃、攻撃にはフルパスが必要→どこから取得している?

MySQLのエラーメッセージにフルパスが出ている

Moodleの脆弱性

オープンソースのeラーニングプラットフォーム。SQLインジェクションの脆弱性があった。

「使用ユーザー一覧」からたどって攻撃された形跡がある。一覧に載っていたところは全員攻撃を撃たれていると思って良い

認知されていない検査によるインシデント事例

  • 脆弱性のニュースを見て、過去に開発したシステムに脆弱性がないか心配→開発会社が無断で検査を実施→検知
  • 「同業者が対策しているか知りたかった」という理由で検査

メンテナンス用PCへの攻撃

  • グローバルIPの振られたPCがあったり
  • アンチウィルスのパッチ漏れがあったり (Windows Update はしていてもアンチウィルスは忘れる)
  • 知らないマシンがぶら下がっていたり

どうするか?

攻撃者はセキュリティシステムを回避する。2ヶ月スパンで新しい手法が出てくる。

鎖は一番弱いところが切れる。開発環境がやられていたりもする。

  • 実装前の対策
  • 見える仕組み
  • 組織内の連携 (連絡したら担当者いません、なんてのは避ける)

質疑は公開して良いかよく分からないので省略。

関連する話題: セキュリティ / メモ / SQLインジェクション

第4回まっちゃ445 ライトニングトーク

更新: 2009年2月25日11時15分頃

第4回まっちゃ445に参加してみたので、まずはライトニングトークをざっとメモ。

ライトニングトーク1：「MD5コリジョンによる偽造SSL証明書について」（hitoさん）

MD5な証明書の話。

  • これはMD5の強衝突耐性が破られた話であって、弱衝突耐性が破られたわけではない。
  • つまり、同じハッシュ値を持つ2つの証明書を新しく作ることは可能だが、既存の証明書と同じハッシュ値を持つ証明書を作ることは困難。既に運用されている証明書に対して攻撃する手法ではないのだが、まともな日本語のドキュメントが出ていないため誤解されているようだ。
  • さらに通常、CAが発行する証明書のシリアルナンバーは予想不可能であるため、実際にコリジョンを起こすことは難しい。ただし、一部のCAはシリアルナンバーを連番にするなど予測可能であったため、それを利用して同一MD5ハッシュ値を持つ二つの証明書を新たに得ることが可能だった。それが問題となった。
  • 問題の本質は、一部のCAが攻撃できるような運用をしていたということと、そもそもSerial値以外にランダム値がないということ。
  • CA側での対応策は進んでいる。利用者が特に対策する必要はない。

ライトニングトーク2：「UNICODEによるXSSとSQLインジェクションの可能性」（徳丸浩さん）

今日は漢字の人。ひらがなは攻撃者モード?

  • 0x5cと0xa5の多対一の変換。多対一変換が起きるかどうかは実装依存。
    • ASPなど : U+00A5→?
    • PHP : U+00A5→全角
    • Java: U+00A5→0x5c
  • XSSはどうか? → JSの動的生成の場合のみ問題になる。動的生成するなと言いたいが……。
  • MS SQL Serverへのデータ格納時、Unicode文字データを格納する場合はnchar, nvarcharを使用する必要がある。そうでない場合CP932への変換が起こるっぽい。アクセントつき記号などが変換される。ブラックリストによるXSS対策 (たとえばはてなのCSSなど) の場合、XSS対策ルーチンを通過した後でSQL Serverに格納されてXSS、というパターンもありそう
  • 対策としては、異なる文字集合への変換を極力しない

ライトニングトーク3：「Sparkingしよう」（ゆまのさん）

MS DreamSparkの話。

  • 学生対象の無償プログラムでVisual StudioやらSQL Serverやらいろいろ使える
  • 国際学生証(ISIC)とメールアドレスが必要
  • 手続きは一分で完了。Verify→国際学生証のID入力
  • 商用利用は違反。STEM-D分野/非商用目的の調査目的に限定
  • 卒業しても使用を続けられる
  • 国際学生証は生協でもらえるほか、直接申請できる模様

MSはなにげにブラウザ+OSのVMイメージも配布しているそうな。これは便利かも。

ライトニングトーク4：「振り込め詐欺が無くならない」

振り込め詐欺の話。

  • 何故流行る? : 簡単なお仕事、初期投資が少ない、低リスクで億単位。創意工夫で頑張っただけ儲かる、やりがいのあるお仕事
  • 手口: 初期→オレオレ、その後→警察役、弁護士役などが登場する劇場型、今→ATMまで出向かせて指示、何故か振り込んでしまう。関西人は古典的な手口には強かったが、還付詐欺には良く引っかかる
  • 対策: 警察→メガバンクのATMに張り付き、出し子の写真公開。銀行→声かけを徹底、注意喚起メッセージ
  • 対策の効果は? : 警官が張り付くと、指示はプレッシャー大。効果はあり
  • 何故携帯電話? : 第三者に相談する隙を与えない。わざと小さな声で話して集中させたり。人間は、一度信用した人をあらためて疑うことはしないもの
  • ATM近辺でジャミングしたり、携帯が鳴ると注意喚起音声が流れるという対策もあるが……
  • 何故徹底しない? : 偽造カードの場合は銀行システムの脆弱性であり、銀行に責任があると考えられる。それに対し、振り込め詐欺の場合、振り込むのは振り込み者の意思であるし、銀行を介さずにバイク便で回収するパターンもあり、銀行に責任はない。
  • 振り込まれても、銀行は損しない。ジャミング→1台300万円、携帯使えないデメリットもある。どちらかというと、目新しい対策をしているというPR色が濃い。
  • 日本でフィッシング詐欺が流行らない理由 : 振り込め詐欺でどーんと儲かるから。フィッシングは頑張っても1000万くらいが限界だが、振り込め詐欺は頑張れば億に届く。

ライトニングトーク5：「ULCPCはDarwinの夢を見るか?」（yaizawaさん）

ULCPCでMacOSXを動かす話。

  • 実験機材 : MSI Wind Notebook (送料込みで44,954円)
  • インストーラ : 汎用のKalyWayと専用のMSIWindosx86がある。後者は利用者少ない、今後が不安、カーネル互換性無い部分ありなので、KalyWayを採用
  • KalyWay の DVD ブートで普通にインストール可能。ただし標準装備の無線カードは使用不能で、Dell DW-1390 / DE-1490 への換装が必要
  • アップデートはいろいろ難しいらしい。10.5.5へのアップデートはカーネルパニックが起きるので一工夫必要
  • 使い勝手 : Safari は問題ない。Mac としては画面小さい。QuickTimeに負荷をかけるとカーネルパニック
  • ベンチマーク : 初代 Mac Mini に全てにおいて負けている
  • 課題 : 10.5.6 へのアップデート、EULA対応

ライトニングトーク6：「モテエンジニアのススメ」（kawaさん＠チームチドリ）

  • モテ力 = 魅力 * 出会い数 * 行動力。イチローでも3割
  • 男と女は違う : TCP と UDP くらい違う。ポート 80 に HELO しても駄目
  • 大きな違い : 幸せのツボのサイズが違う。スイートテンダイヤモンドは男性目線→毎日少しずつが大事
  • 中身で判断して欲しい? : 不細工なツボは選んでもらえない
  • 行動あるのみ : パケットを送らなきゃ始まらない。言い訳はいらない。行動しろ!
  • で、オチは?

関連する話題: セキュリティ / メモ

最近の日記

関わった本など