mixi脆弱性報告制度で報告した脆弱性のうち、報告したけど評価対象外になったものをまとめます。

報告したけど評価対象外だった脆弱性

1.ショッパーズアイ コードインジェクション

報告日:2014年3月31日
評価結果連絡:2014年4月8日 弊社において既知の脆弱性であると判断、よって脆弱性報告制度の対象外

※追記:この脆弱性は現在は対応済みです。mixiさんに問い合わせて脆弱性対応済みであることを確認してから記事を公開しました。

※2014.4.16 23:00 本記事の反響がやたら大きくなってしまったのでコメントを追加します。
もともと本エントリはmixiさんの不正な判定を告発するとかそういう意図は全くなく、「超面白かった脆弱性検査の記録」という以上の意味はありませんでした。(あとこんだけ検査したんだぜーという自己PRと)

私がこの脆弱性を報告したのは、報告制度の最終日(3/31)間際だったので、最後の駆け込みで大量の報告が上げられていて、mixiさんのマンパワーが単純に足りなかった状況だったのではないかと思います。
また、報告日時が日曜深夜だったので、週末に誰かが(私より先に)同様の脆弱性の報告を上げていたけど、月曜まではmixiさんに認識されていなかった、というようなことだったのかもしれません。(推定ですが)

いずれにせよ、mixiさんは私の他の脆弱性報告では高額な賞金をルール通りきっちり払ってくれてますので、この件だけ出し惜しみするとは思えないため、「既知」というのが具体的にどういう状況だったのか分からないながらも、正当な判断だったんだろうなと思っています。


報告内容:
ショッパーズアイのマイページ
https://www.shoppers-eye.jp/mypage/recruit
の「募集中の調査案件」の検索フォームで、「キーワード」欄のエスケープがされておらず、プログラムに任意のコードを差し込めるコードインジェクション脆弱性があり、system関数によりOSコマンドがコールできた。



現象の詳細としては、このキーワード欄でシングルクォート入力時の挙動がおかしく、下記のような挙動が見られた。

'+ → システムエラー
'+' → OK (結果0件)
'+'a → OK かつ 検索画面のキーワードの内容が「a」になる
'+'1'+' → OK かつ 検索画面のキーワードの内容が「1」になる

また、下記のような挙動があることも分かった。

'+sleep(10)+' → 時間がかかった上でシステムエラー
'+sleep(100)+' → かなり時間がかかった上でタイムアウトエラー

当初これはSQLインジェクションだと思っていて、何らかのDBのsleep関数が呼ばれていると思い、色々なデータベースの関数を試して見たが、どうも他に呼べるデータベース系の関数がないので、もしや・・・と思い、下記を試したところ、20秒sleepをしているような挙動があった。

'+system("/bin/sleep 20")+'

これはSQLインジェクションではなくてコードインジェクションということが分かったが、sleepだと決め手に欠けるので、システムに害をもたらさないで、確実にOSコマンドが呼ばれていることを証明するには・・・と考えて下記入力を試したところ、「MailSubject」というタイトルの「1」という内容のメールが指定のメールアドレスに届いた。
そのため確実にsystem関数の実行が行われているということで報告した。

'+system("/bin/echo 1 | /bin/mail -s MailSubject <自分のメールアドレス>")+'

この脆弱性は、mixi脆弱性報告制度の一番高額な例(「リモートから、ウェブサーバー上で、任意のコードが実行可能」)に当てはまるので、かなり緊張しながら結果を待ったが「弊社において既知の脆弱性のため対象外」とのことだった。



2.ショッパーズアイ DOS攻撃を容易にする仕様

報告日:2014年3月31日
評価結果連絡:2014年4月8日 弊社において既知の脆弱性であると判断、よって脆弱性報告制度の対象外

報告内容:
ショッパーズアイの振り込み履歴のページにて

https://www.shoppers-eye.jp/mypage/history?pp=50&year=2014

というURLのyearパラメータをいじって過去の年にすると、ページ上のプルダウンでの選択できる年が増えるが、これに下限が設定されていないため、例えば

https://www.shoppers-eye.jp/mypage/history?pp=50&year=-9999

などのように指定すると、-9999年~2014年までのプルダウンが生成される仕様だった。


ここで、巨大なマイナス値

https://www.shoppers-eye.jp/mypage/history?pp=50&year=-999999999999999999999999999999999999999999999999999

を指定したところ、長くレスポンスを待たされた後、「proxy error」の画面になったので、おそらくサーバ側処理で大量のプルダウンリストが生成されて落ちてしまったと思われたため、DOS攻撃を容易にする仕様として報告したが、やはり「既知の脆弱性と判断」よって「報告制度の対象外」だった。

mixi脆弱性報告制度で報告した脆弱性をまとめてみます。

※以前報告した脆弱性4件の解説はこちらにあります。
(書いたときに脆弱性の詳細をぼかしすぎたので明確な形に書き直しました。)
今回はそれ以後報告した脆弱性についてです。

今回評価された脆弱性報告

1.youbride 認証が不十分なバグ

報告日:2014年3月1日
対応完了連絡:2014年3月18日
評価結果連絡:2014年3月24日 報酬額 ¥125,000(Amazonギフト)

mixiの子会社、株式会社Diverseが運営している「youbride」という婚活支援サイトで、登録した会員情報の変更メニューで、メールアドレス変更画面のパスワード入力欄が、実際には機能していなかった。

メールアドレス欄に、任意の変更先メールアドレスを入れ、パスワード欄に正しいパスワードでなく、「a」とか「1」とか適当な値を入れても、変更先のメールアドレスに、メアド変更用リンクが書いてあるメールが送信される仕様だった。



このページはパスワードによる認証でCSRFを防ぐ仕組みだったが、そのパスワード認証が機能していないため、メアド変更画面へPOSTを行うCSRF攻撃で、youbrideにログイン中のユーザのアカウントから、攻撃者の指定した任意のメアドに、メールアドレス変更確認メールを送信させることが可能となってしまっていた。
その後、入手したメアド変更用URLを何らかの手段で再度そのユーザーに踏ませられれば、その人のメアド(=ログインID)が変更できてしまい、その後攻撃者がパスワード再設定を行うことでアカウントを乗っ取ることが可能だった。(IDが攻撃者のメアドに変わっているから、パスワード再設定用アドレスはそのメアドに送られてくる)

URLをユーザーに踏ませる方法としては、たとえば上述の不正なPOSTを行うページの裏で素早くメール受信処理をしてメールアドレス変更URLに遷移するような攻撃用スクリプトを書く、ソーシャルな手段でメール等で踏ませる、などがあると思うが、報告ではそこまでの実証はせず、可能性を示唆したのみで報告した。

2.YYCの特定のURLでXSS

報告日:2014年3月14日
対応完了連絡:2014年4月7日
評価結果連絡:2014年4月9日 報酬額 ¥125,000(Amazonギフト)

mixiさんから最初にいただいた報奨金(前回のやつ)でwin7マシンとAndroidスマートフォンを購入したので、勉強も兼ねてmixiの開発したAndroidアプリの通信をPC上のFiddlerで覗くということをやってみた。

大半のアプリはSSLで通信をしており、不正な証明書も認めてくれなかったので通信を覗き見ることはできなかった。(Androidアプリの脆弱性検査の手法がよく分からない。今後の課題)

しかし、これも株式会社Diverseがやっている出会い応援サイト「YYC」のアプリが、ある通信だけはHTTPで特定のURLにアクセスを行っていて、そのURLを調べて見たところ、POST値をエコーバックする箇所があったので、試して見たところIEのコンテンツ解釈でHTMLと誤認させてのXSSを仕掛けることが可能だった。

問題のあったURL:
http://yyc.co.jp/api/app/member/boot_app

このページにアクセスすると、下記のようにJSON形式でレスポンスが返ってくるが、「.apikey」というPOST値があると、レスポンスのapikeyの値にそのまま反映される仕様だった。

{"response":{"success":false,"accept_time":"2014-04-14 01:28:15","errors":["error.no_api_key"],"code":"-4","apikey":"<ここに値が反映される>"}}

レスポンスヘッダに「Content-Type: application/json;」が付いているのでIE以外のブラウザではHTMLタグがタグとして解釈されない形だったが、IEはIE6~8でデフォルト設定だとContent-Typeヘッダを無視してコンテンツの内容を解釈するので、下記のようにpathinfoとして「a.html」を付けてIEがHTMLだと誤認するようにし、「.apikey」にscriptタグを投げ込むようなHTMLを書いてIETesterのIE8でPOSTしたところ、スクリプトが有効に動作したので報告した。(IETesterのIE6とIE8で動作を確認した)

<form method=post action="http://yyc.co.jp/api/app/member/boot_app/a.html">
<input type=text name=".apikey" value="yycapp&lt;script&gt;document.write(document.cookie);alert(1);&lt;/script&gt;">
<input type=submit name="submok" value="submit">
</form>




3.ショッパーズアイ メールのテスト送信機能のXSS

報告日:2014年3月26日
対応完了連絡:2014年4月8日
評価結果連絡:2014年4月9日 報酬額 ¥125,000(Amazonギフト)

ミステリーショッパー事業の「ショッパーズアイ」の会員情報変更画面の中に、自分のメールアドレスを変更する画面があり、そこに「テスト送信」というリンクがあり、そこで指定のメールアドレスにテストメールを送信できる仕組みになっている。

テスト送信の画面は、普通の遷移ではパラメータもPOST値も何もない形だったが、いったんテストメールを送信した後に、画面をリロードすると、何故かメールアドレスがGETパラメータとしてURLに付き(そういうLocationヘッダが発行される)、外部からメールアドレスが自由に指定できるようになり、しかもパラメータで渡したメールアドレスが全くエスケープされていなかったので、XSSが可能だった。

問題のあったURL:
http://www.shoppers-eye.jp/mypage/user/testmail

テストメールを一度送信し終わった後にリロードすると下記のようにURLが変化した。

http://www.shoppers-eye.jp/mypage/user/testmail?email=<登録したメールアドレス>&mail_type=pc

これを下記のように変化させてアクセスしたところ、普通に画面上でスクリプトが実行された。

http://www.shoppers-eye.jp/mypage/user/testmail?email=<script>alert(1)</script>&mail_type=pc





その他現在確認中のものなど。

※「XXXX」になってる箇所は、確認取れ次第更新していきます。

「報告制度の範囲外」ということで無効になった脆弱性報告(いつの間にか報告制度の対象外になってたやつ)

対応未確認なので公表できない。mixiさんに対応が完了したか確認中。対応済みであれば詳細公開。

  • XXXX にてオープンリダイレクタ脆弱性 (報告日:2013年12月8日)
  • XXXX にてdataストリームによるXSS脆弱性 (報告日:2013年12月8日)
  • XXXX のXXX機能のCSRF (報告日:2014年3月24日)

「既知の脆弱性」ということで無効になった脆弱性報告

問い合わせたら対応済みとの事だったので、次のエントリで詳細書きました。

現在対応待ち

mixiさんに報告して対応連絡がまだ来ていないもの。評価未確定なので報奨金の可能性が残っている。対応未確認なので公表できない。

・XXXX でDOS攻撃を容易にする仕様(システムに大きい負荷を簡単にかけられる仕様) (報告日:2014年1月14日) → いったん対応報告来たけど報告時の説明が悪く漏れがあったので再対応していただいている
・XXXX オープンリダイレクタ脆弱性 (報告日:2014年3月17日)
・XXXX ソーシャルな手順によるXSS(セルフXSS) (報告日:2014年3月30日)


現状こんな感じ。

最近のEC-CUBEの脆弱性で私が発見したやつが結構あるので、ロックオン様が公開しているEC-CUBEの脆弱性リストに発見者とJVN iPediaとIPA注意喚起へのリンクを加筆して一覧表を作ってみました。

基本自分用資料ですが、ロックオン社の脆弱性情報とJVN iPediaとの対応表になっているので、CVE等を調べたいときに使えるかもしれません。

下表の★マークが私の見つけた脆弱性です。
参考:EC-CUBE脆弱性リスト(ロックオン公式)
(2013-05-22より前の脆弱性については私が関わっていないので省略します)

情報公開日対象バージョン危険度タイトルJVN iPedia発見者IPA注意喚起
2013-05-222.11.0以降(2.11.0 ~2.12.3)カート画面でのXSS脆弱性、及びセッション固定の脆弱性JVNDB-2013-000041bogus.jp 東内 裕二 氏
2013-05-222.11.0以降(2.11.0 ~2.12.3)お届け先複数指定画面でのXSS脆弱性(IPAに報告し忘れ)
2013-05-222.11.0以降(2.11.0 ~2.12.3)パスワードリマインド機能における不適切な入力確認の脆弱性JVNDB-2013-000044株式会社システムフレンド
2013-05-222.11.0以降(2.11.0 ~2.12.3)一部環境における、管理画面の不適切な認証に関する脆弱性JVNDB-2013-000043
2013-06-262.12.4 以前ディレクトリトラバーサルの脆弱性JVNDB-2013-000061
2013-06-262.12.4 以前クロスサイトスクリプティングの脆弱性JVNDB-2013-000064ゲヒルン株式会社 平澤 蓮 氏
2013-06-262.11.0以降(2.11.0 ~2.12.4)クロスサイトスクリプティングの脆弱性JVNDB-2013-000063ゲヒルン株式会社 石森 大貴 氏
2013-06-262.11.2以降(2.11.2 ~2.12.4)コードインジェクションの脆弱性JVNDB-2013-000062
2013-06-262.12.0以降(2.12.0 ~2.12.4)ディレクトリトラバーサルの脆弱性JVNDB-2013-000065株式会社システムフレンド
2013-08-292.12.0以降(2.12.0 ~2.12.5)Windowsサーバー環境における、ディレクトリトラバーサルの脆弱性JVNDB-2013-000081
2013-11-192.11.0~2.11.5クロスサイトスクリプティング及び、セッション情報漏えいの脆弱性JVNDB-2013-000105
2013-11-192.11.2以降(2.11.2~2.13.0)ファイルパス情報漏えいの脆弱性JVNDB-2013-000098
2013-11-192.11.0以降(2.11.0~2.13.0)クロスサイト・スクリプティングの脆弱性JVNDB-2013-000107株式会社ラック
2013-11-192.11.0以降(2.11.0~2.13.0)クロスサイトリクエストフォージェリの脆弱性JVNDB-2013-000097
2013-11-192.12.3以降(2.12.3~2.13.0)個人情報漏えいの脆弱性JVNDB-2013-000106株式会社ラック
2014-01-212.12.2 以前個人情報削除の脆弱性JVNDB-2014-000005株式会社アラタナ
2014-01-212.11.0~2.12.2個人情報漏えいの脆弱性JVNDB-2014-000006開発者
2014-11-072.13.2以前クロスサイトスクリプティングの脆弱性--
2015-10-093.0.0~3.0.3クロスサイトリクエストフォージェリの脆弱性--
2015-10-093.0.0~3.0.3個人情報漏えいの脆弱性--
2015-10-093.0.0~3.0.3ディレクトリトラバーサル脆弱性--
2015-10-232.11.0~2.13.3クロスサイトリクエストフォージェリの脆弱性JVNDB-2015-000166
2015-11-132.11.0~2.13.4クロスサイトリクエストフォージェリの脆弱性JVNDB-2015-000166-
2016-04-253.0.7~3.0.9管理画面の権限管理機能に関する脆弱性JVNDB-2016-000052
2016-04-253.0.0~3.0.9クロスサイトリクエストフォージェリの脆弱性JVNDB-2016-000053開発者
2016-04-253.0.0~3.0.9管理画面のIP制限機能に関する脆弱性JVNDB-2016-000051

・EC-CUBEプラグインの脆弱性


(プラグインは私はアイネクシオ様のプラグイン調査のページでDL数が多いものを対象に調べています。)

私が見つけたEC-CUBEの脆弱性は影響の大きいものも数件あるので、世間で広く使われている(公式HPによると推定20,000店舗以上で稼働中)EC-CUBEの安全性にかなり貢献できたのではないかと思います。

いずれ時期を見てそれなりの情報を公開しようとは考えておりますので、この記事を読んだ時点でまだ対応されていない脆弱性が残っているEC-CUBEをご利用の場合は、なるべく早めにご対応ください。
(脆弱性のおおまかな情報や修正パッチの解析などにより再現手段が解明され攻撃が発生する可能性もあります)

* 2016/08/12 最新の状況に合わせて更新しました

Powered by Blogger.
© WEB系情報セキュリティ学習メモ Suffusion theme by Sayontan Sinha. Converted by tmwwtw for LiteThemes.com.