2014年3月1-2日に行われたSECCON 2013 全国大会のカンファレンスで、cybozu.com Security Challengeで発見した脆弱性について発表させて頂きました。
cybozu.com Security Challengeは、サイボウズが2013年11月に実施した、同社が提供するアプリケーション「kintone」の実際の脆弱性を発見する賞金付きコンテストです。
ご存知の方はご存知の通り、このコンテストで優勝しました。
頂いた表彰状です。
優勝賞金は、1,038,960円を頂きました。
一部で話題になりましたが、このパネルにおかしいところが4件あるそうなので、まだ間違い探しをトライしていない方は探してみてください。
資料は以下に公開しました。
どうぞご覧ください。全体的に内容は易しめです。
拙い発表を聴いて下さった皆さま、ありがとうございました。
コンテスト参加者の皆さま、お疲れ様でした。修正された問題はぜひ共有してください。
伊藤さんをはじめ、サイボウズの皆さま、初めての試みにもかかわらずスムーズな対応で、楽しみながら安心して脆弱性を検証することができました。このような素晴らしいコンテストを実施してくださりありがとうございました。
海外では、セキュリティ問題の報告に対し報酬を支払う取り組みが大分活発になってきていますが、日本ではまだあまり行われていません。サイボウズの取り組みをきっかけに、日本でも盛り上がってくることを期待しています。
2014/03/26
OWASP AppSec APAC 2014で発表しました
OWASP AppSec APAC 2014 で、はせがわようすけさん、malaさんと一緒に、「XSS Allstars from Japan」という枠で登壇しました。3人それぞれ好きなテーマについて発表をしたのですが、僕は、2011年頃から個人的にやってきた、文字エンコーディングの調査について発表しました。
スライドは以下で公開されています。
The Complete Investigation of Encoding and Security // Speaker Deck
はせがわさんのスライドはこちら: Bypass SOP, Theft your data // Speaker Deck
malaさんのスライドはこちら: XSS with HTML parsing confusion // Speaker Deck
エンコーディングに関する様々な調査結果は以下で公開しています。
http://l0.cm/encodings/
結果に変更があり次第、更新していきます。最近もFirefox 28で大きな変更があったので既に反映させました。(@vyv03354さん、お知らせ頂きありがとうございます)
もともと誰かにみせることを前提に調査していなかったので、荒い部分もあるかもしれません。おかしなところがあれば教えてください。
以下、発表では伝えきれなかったこと、確実に伝えたいことを Q & A 形式でお送りします。
Q.
CVEがついてるものとそうでないものが混じってるけど、公開しても大丈夫なの?
A.
掲載されているものすべてが脆弱性と言えるものとは限りません。脆弱性とみなされるような問題は修正されています。
Q.
わたしは開発者です。手っ取り早く、すべきことはなに?
A.
charsetを"レスポンスヘッダで"確実に指定してください。
Q.
なぜ、"レスポンスヘッダで"すべきなの?
A.
レスポンスヘッダによる指定の方が、誤って別のエンコーディングで解釈される可能性が低くなるからです。一例をあげると、<meta http-equiv>でのみcharset指定をしていた場合、IEのXSSフィルターは、URLに「<meta http-equiv=>」といった文字を与えるとcharset指定を破壊できてしまうので、ページのcharsetが不明瞭( =ブラウザが自動で選択する )になってしまいますが、レスポンスヘッダによる指定はこの影響を受けません。
Q.
普段誰も使っていないエンコーディングを調べて意味あるの?
A.
UTF-7はほとんど使われていませんが、攻撃に利用できるとして問題になったように、危険性を考える上で、普段使われていないエンコーディングの挙動を調べることにも価値があるはずです。
その他、疑問点などありましたら言って頂ければお答えします。
OWASP AppSec APAC 2014に関わった皆様、お疲れ様でした。
スタッフの方々、撮影の不可など、ご配慮いただきましてありがとうございました。
一緒に発表したはせがわさん・malaさん、発表には不慣れですが、頼りになる2人と一緒だったので心強かったです。ありがとうございました。
同時通訳の方、しゃべるの早すぎるし、言葉が滑らかにでてこないしで、 相当大変だったと思います。発表中は通訳さんのことを考えている余裕がありませんでした…。大変ご迷惑をおかけしました。ありがとうございました。
最後に、拙い発表を聴いて下さったたくさんの方々、ありがとうございました。
このような素晴らしいイベントに関われて本当に嬉しいです。
------
2014年4月2日更新: スライドのリンクが変更されていたので修正しました。
スライドは以下で公開されています。
The Complete Investigation of Encoding and Security // Speaker Deck
はせがわさんのスライドはこちら: Bypass SOP, Theft your data // Speaker Deck
malaさんのスライドはこちら: XSS with HTML parsing confusion // Speaker Deck
エンコーディングに関する様々な調査結果は以下で公開しています。
http://l0.cm/encodings/
結果に変更があり次第、更新していきます。最近もFirefox 28で大きな変更があったので既に反映させました。(@vyv03354さん、お知らせ頂きありがとうございます)
もともと誰かにみせることを前提に調査していなかったので、荒い部分もあるかもしれません。おかしなところがあれば教えてください。
以下、発表では伝えきれなかったこと、確実に伝えたいことを Q & A 形式でお送りします。
Q.
CVEがついてるものとそうでないものが混じってるけど、公開しても大丈夫なの?
A.
掲載されているものすべてが脆弱性と言えるものとは限りません。脆弱性とみなされるような問題は修正されています。
Q.
わたしは開発者です。手っ取り早く、すべきことはなに?
A.
charsetを"レスポンスヘッダで"確実に指定してください。
Q.
なぜ、"レスポンスヘッダで"すべきなの?
A.
レスポンスヘッダによる指定の方が、誤って別のエンコーディングで解釈される可能性が低くなるからです。一例をあげると、<meta http-equiv>でのみcharset指定をしていた場合、IEのXSSフィルターは、URLに「<meta http-equiv=>」といった文字を与えるとcharset指定を破壊できてしまうので、ページのcharsetが不明瞭( =ブラウザが自動で選択する )になってしまいますが、レスポンスヘッダによる指定はこの影響を受けません。
Q.
普段誰も使っていないエンコーディングを調べて意味あるの?
A.
UTF-7はほとんど使われていませんが、攻撃に利用できるとして問題になったように、危険性を考える上で、普段使われていないエンコーディングの挙動を調べることにも価値があるはずです。
その他、疑問点などありましたら言って頂ければお答えします。
OWASP AppSec APAC 2014に関わった皆様、お疲れ様でした。
スタッフの方々、撮影の不可など、ご配慮いただきましてありがとうございました。
一緒に発表したはせがわさん・malaさん、発表には不慣れですが、頼りになる2人と一緒だったので心強かったです。ありがとうございました。
同時通訳の方、しゃべるの早すぎるし、言葉が滑らかにでてこないしで、 相当大変だったと思います。発表中は通訳さんのことを考えている余裕がありませんでした…。大変ご迷惑をおかけしました。ありがとうございました。
最後に、拙い発表を聴いて下さったたくさんの方々、ありがとうございました。
このような素晴らしいイベントに関われて本当に嬉しいです。
------
2014年4月2日更新: スライドのリンクが変更されていたので修正しました。
Labels:
Encoding,
Presentation,
Security,
XSS
2014/03/02
CVE-2014-0491: AS2の関数に存在したjar:を通じたXSS
これは、2013年11月8日に報告し、 2014年1月のアップデートで修正された、AS2の普通JavaScriptが実行できるべきでない複数の関数で、JavaScriptを実行できた問題です。
https://helpx.adobe.com/security/products/flash-player/apsb14-02.html
FlashのnavigateToURLに指定するURLで、jar:というプロトコルをURLの先頭につけると、セキュリティ制限を突破できてしまうことが、 Soroush Dalili氏によって公開されていました。( https://soroush.secproject.com/blog/2013/10/catch-up-on-flash-xss-exploitation-part-2-navigatetourl-and-jar-protocol/ )
氏の発見をきっかけに、この挙動について自分でも深く追っていったところ、手法が公開されていないもので、jar:を使ったかなり致命的な問題があることに気が付きました。
確認しただけで、少なくとも、次の関数はすべて、"jar:javascript:alert(1)" をロードするURLとして指定すると、JavaScriptを実行できていました。(※ただし、Firefox上のFlash Playerに限ります)
MovieClipLoader.loadClip
loadMovie
loadMovieNum
loadVariables
loadSound
こういうことです:
これはかなり危険な動作です。これらの関数は音声や動画再生などに使われますが、普通は任意のURLをロードできても、動画や音声を再生できるだけなので、世間で使われているFlashファイルでは、特に読み込み可能なURLを制限していないことが多いからです。 ロードするURLをパラメータからもらって、これらの関数を使ってしまったらXSS脆弱性が生まれてしまうことになります。
ExternalInterface.callのバグをずっと放置していたりするので、Adobeはもしかするとこの問題をスルーするかもしれないと思っていましたが、11~1月という、割と短い期間で修正してくれました。しかも、loadMovieなどの関数のXSSバグだけではなく、jar:を使ったすべてのハックが封印されたようです。素晴らしい。
このバグを報告してしばらくしたあと、Flashの報酬制度が発表されました…。
タイミング悪いなーと思っていたら、 後日わざわざ連絡がきて、HackerOneのThe Internet Bug Bountyを通じて、$2,000の報酬を頂きました。ここのレポートだと "Handling of jar: URIs bypasses AllowScriptAccess=never" というタイトルで掲載されていますが、( https://hackerone.com/reports/2107 ) 同時期にjar:を使ってAllowScriptAccess制限をバイパスできたバグも報告していたので、これがjar:のバグの代表としてタイトルになったのだと思います。 Soroush Dalili氏もAllowScriptAccess制限をバイパスできた問題を発見していたようで、詳細は氏のブログに書かれていますので、参考にしてください。(
https://soroush.secproject.com/blog/2014/01/catch-up-on-flash-xss-exploitation-part-3-xss-by-embedding-a-flash-file/ )
最近集中的にFlashを追っていましたが、Flashはバグが多いです。
今回のように、おかしな場所でXSSが生まれてしまったりすることもありうるので、サービス運営者は、危険になる可能性を少しでも減らすために、必要ないFlashファイルを1度整理されるといいと思います。
https://helpx.adobe.com/security/products/flash-player/apsb14-02.html
These updates resolve a vulnerability that could be used to bypass Flash Player security protections (CVE-2014-0491).
FlashのnavigateToURLに指定するURLで、jar:というプロトコルをURLの先頭につけると、セキュリティ制限を突破できてしまうことが、 Soroush Dalili氏によって公開されていました。( https://soroush.secproject.com/blog/2013/10/catch-up-on-flash-xss-exploitation-part-2-navigatetourl-and-jar-protocol/ )
氏の発見をきっかけに、この挙動について自分でも深く追っていったところ、手法が公開されていないもので、jar:を使ったかなり致命的な問題があることに気が付きました。
確認しただけで、少なくとも、次の関数はすべて、"jar:javascript:alert(1)" をロードするURLとして指定すると、JavaScriptを実行できていました。(※ただし、Firefox上のFlash Playerに限ります)
MovieClipLoader.loadClip
loadMovie
loadMovieNum
loadVariables
loadSound
こういうことです:
_root.loadMovie("jar:javascript:alert(1)")
//JavaScriptが実行される
これはかなり危険な動作です。これらの関数は音声や動画再生などに使われますが、普通は任意のURLをロードできても、動画や音声を再生できるだけなので、世間で使われているFlashファイルでは、特に読み込み可能なURLを制限していないことが多いからです。 ロードするURLをパラメータからもらって、これらの関数を使ってしまったらXSS脆弱性が生まれてしまうことになります。
ExternalInterface.callのバグをずっと放置していたりするので、Adobeはもしかするとこの問題をスルーするかもしれないと思っていましたが、11~1月という、割と短い期間で修正してくれました。しかも、loadMovieなどの関数のXSSバグだけではなく、jar:を使ったすべてのハックが封印されたようです。素晴らしい。
このバグを報告してしばらくしたあと、Flashの報酬制度が発表されました…。
タイミング悪いなーと思っていたら、 後日わざわざ連絡がきて、HackerOneのThe Internet Bug Bountyを通じて、$2,000の報酬を頂きました。ここのレポートだと "Handling of jar: URIs bypasses AllowScriptAccess=never" というタイトルで掲載されていますが、( https://hackerone.com/reports/2107 ) 同時期にjar:を使ってAllowScriptAccess制限をバイパスできたバグも報告していたので、これがjar:のバグの代表としてタイトルになったのだと思います。 Soroush Dalili氏もAllowScriptAccess制限をバイパスできた問題を発見していたようで、詳細は氏のブログに書かれていますので、参考にしてください。(
https://soroush.secproject.com/blog/2014/01/catch-up-on-flash-xss-exploitation-part-3-xss-by-embedding-a-flash-file/ )
最近集中的にFlashを追っていましたが、Flashはバグが多いです。
今回のように、おかしな場所でXSSが生まれてしまったりすることもありうるので、サービス運営者は、危険になる可能性を少しでも減らすために、必要ないFlashファイルを1度整理されるといいと思います。
Labels:
Firefox,
Flash,
Security,
Vulnerability,
XSS
登録:
投稿 (Atom)