IE/EdgeのXSSフィルターを利用したXSS

English version: http://mksben.l0.cm/2015/12/xxn.html
------------------------------------------------
2015年12月のMicrosoftの月例アップデートで修正された、Internet ExplorerとEdgeのXSSフィルターに存在した問題(CVE-2015-6144 および CVE-2015-6176)について書きます。

2015 年 12 月のマイクロソフト セキュリティ情報の概要
https://technet.microsoft.com/ja-jp/library/security/ms15-dec.aspx

修正された問題は、2015年10月に行われたセキュリティカンファレンスのCODE BLUEで詳細を伏せて発表した、IE/EdgeのXSSフィルターの動作を利用してXSS攻撃する手法の一部です。「一部」と書いたように、今回のパッチでは、報告した問題の全てが修正された訳ではありませんでした。当初、発表するつもりで作った、攻撃手法の詳細も含めたスライドを、未修正の部分を伏せて以下で公開します。

X-XSS-Nightmare: 1; mode=attack ～XSSフィルターを利用したXSS攻撃～ from Masato Kinugawa

また、以下で3つの手法のPoCを公開しています。修正され次第、他のPoCも公開します。

http://l0.cm/xxn/

詳しい原理等については資料を見てもらうとして、この記事では、ざっくりと手法に触れながら、今回施された修正方法に言及したいと思います。

1. style属性の遮断を悪用するパターン

次のような、style属性の追加によるXSSの遮断を、

</style>の閉じタグに誤マッチさせることで、閉じタグを破壊し、攻撃を成立させます。

Microsoftはこの問題に対し、style属性部の遮断時だけ、強制的にmode=blockの動作にすることで回避したようです。確かに問題は起きなくなりますが、これじゃあ、X-XSS-Protection:1の動作とはなんだったのか…、という気がします。
ただ、確実な回避策にはなっているので、ひとまずはこれでよいと思います。(実際、僕はデフォルト動作をひとまずmode=blockにすることで回避したらどうかとMSに提案していました。)

2. 文字列リテラルの遮断を悪用するパターン その1( <script src=***></script> を利用)

次のような、文字列リテラルでの、プロパティアクセス後の代入による攻撃(実際には例えば、";document.body.innerHTML="攻撃文字列"//のような形で攻撃します)の遮断を利用し、

スクリプトタグのsrcの値に誤マッチさせることで、外部リソースをスクリプトとしてロードして攻撃します。

どう修正されたかは、次の手法でまとめて紹介します。

3. 文字列リテラルの遮断を悪用するパターン その2( <link rel=stylesheet href=***> を利用)

同じく、文字列リテラルでの遮断を、無関係の文字列に誤マッチさせます。
今度は、<link>タグのhrefの相対パスの.を利用し、攻撃に繋げるという方法です。

2と3の問題のMicrosoftの修正にはびっくりしました。
プロパティアクセス後の代入の遮断時だけ、.を、これまでの#の代わりに、^(0x5E)に置換するよう変更したのです！なんじゃそりゃ～(^_^)！
確かに、この2つの問題は回避できるかもしれませんが、この修正は良いとは思えません。

JavaScriptにおいて、^は演算子です。document.locationがdocument^locationに変わってもエラーになりません。この時点で、 既存のインラインスクリプトに含まれる.をうまいこと^に変えることで、エラーを起こさずに何かおかしな動作を意図的に起こせるかもしれないことは容易に想像できます。じゃあ、.が JavaScriptの正規表現に含まれていたら、そしてそれが^に置換されたら、どうなるでしょう…？考え出すと、これならOKという気はまったくしません。

このような修正を繰り返しても、XSSフィルターを使ったXSSパズルのピースが変わっただけであり、本質的には何も安全になっていないと思います。

報告では、XSSフィルターの遮断方法はこのままじゃまずいよね、という思いも伝えられたと思っていただけに、今回のパッチの回避方法は、現在の遮断方法に危機感を持っていないとしか思えないものであり、非常に残念でした。

もう一度コンタクトし直して、そういった思いを伝え、今回、紹介を伏せた、まだ修正されていないXSSフィルターの問題が修正される時には、根本的な部分まで改善されることを期待したいと思います。

開発者の方には、資料の中でも書いた通り、引き続き、自分のサイトのすべてのページで、X-XSS-Protection:1;mode=blockかX-XSS-Protection:0のヘッダを指定することを推奨したいと思います。これがXSSフィルターによって、不本意にページを変更されることの開発者側でできる回避策になります。

AVTOKYO2015の発表資料「バグハンターの哀しみ」を公開

English version: http://mksben.l0.cm/2015/11/avtokyo2015.html
----------------------------------------------------

2015年11月14日に行われたセキュリティカンファレンス、AVTOKYO2015で発表しました。

ご存知の方もいらっしゃるかと思いますが、2013年9月、脆弱性の検査がきかっけで、ISPに自宅のインターネットを止められるということがありました。発表では、このときの詳細をお話しました。資料は以下にあります。

バグハンターの哀しみ from Masato Kinugawa

聴いて頂いた皆様、ありがとうございました。発表後、聴いて頂いた方の意見を伺い、誰がどうしていればこのような問題が起きずに済んだのかといったことを議論したりもでき、とても有意義な時間を過ごすことができました。このような機会を頂きありがとうございました。

ちなみに昨年、「バグハンターの愉しみ」という発表もCODE BLUEで行っています。今回はその対となるタイトルとして、「バグハンターの哀しみ」と名付けました。「愉しみ」の資料も以下で公開しているので、よかったらご覧ください。
http://masatokinugawa.l0.cm/2015/07/codeblue.html

次回、「バグハンターの○○み」でお会いしましょう！ (もうやりません！)

セキュリティ・キャンプ全国大会2015の資料を公開

2015年8月11～15日の間行われたセキュリティ・キャンプ全国大会2015に、今年も講師として参加してきました。使用した資料を公開します。


1. 事前学習として用意した「簡単にSOP周辺を理解するページ」
http://vulnerabledoma.in/camp2015_sop/

2. 講義に使用したスライド

SecurityCamp2015「バグハンティング入門」 from Masato Kinugawa

3. 特別コーナーで使用したスライド

CVE-2015-4483解説 from Masato Kinugawa

1つ目のスライドは、自分がキャンプの1日目に担当した「バグハンティング入門」という講義で使用したものです。講義では、脆弱性を探すときにどのような点に注目すればいいのかを過去に発見した/されたWeb周辺のバグを通して説明しました。

題材のアプリケーションには、サイボウズLiveとIEのXSSフィルターを選びました。

サイボウズLiveは、キャンプの連絡事項の伝達に使うため、参加者全員が必ず使うWebアプリケーションになります。身近に使っているアプリケーションにも脆弱性があることを感じてもらいやすいと考え、昨年に続いて題材に選びました。また、サイボウズは脆弱性の検査/報告を歓迎しているし、申請すると検査用の環境を個別に用意してくれるので、キャンプが終わった後も脆弱性を探したいと思った参加者に勧めやすいというのも選んだ理由です。だって、万が一、誤解を招いて参加者がインターネットを止められても困りますからね！

XSSフィルターについては、自分がとりわけ詳細まで把握している機能で扱いやすかったため、題材に選びました。あと、キャンプで使う演習用のPCがWindowsで、何も指示しなくてもIEなら必ず入っているため、準備が楽だったからというのもあります。

講義では、実習として、実際にXSSフィルターのバイパスに挑戦してもらいました。もちろん、実習の期間中に未知のバイパスを発見しろという無茶な話ではなくて、考慮された典型パターンからはずれると、簡単にバイパスできてしまう場合があることを知ってもらうために、意図的にバイパスできる状況を設定したものを突破してもらいました。

ちなみにXSSフィルターのバイパスチャレンジはキャンプ参加者以外の方も以下で挑戦できます。ゴールは、IE10以上(Edgeはダメです)を使ってXSSフィルターをバイパスし、alert(1)を実行することです。
日頃XSSをプレイしている人にはChallenge 1337以外は簡単だと思います。

Challenge 1
http://vulnerabledoma.in/camp2015/challenge?q=[XSS_HERE]

Challenge 2
http://vulnerabledoma.in/camp2015/challenge2?q=[XSS_HERE]

Challenge 1337
http://vulnerabledoma.in/camp2015/challenge1337?q=[XSS_HERE]


参加者には引き続き自分で回答を探してもらっているので、答えがわかっても、回答をパブリックにしないようお願いします。

問題(1と2)はかなり単純だと考えていたので、10分程度の演習時間を予定していましたが、30分以上を使っても、結局、講義中に解けたのは講師だけでした。もう少し段階的に説明するべきだったかなと、少し反省していますが、それでも講義後には、ぽつりぽつりと回答者が出始めたので、興味を持って取り組んでもらえているように思います。キャンプの準備には随分苦労しましたが、少しでも興味を持ってもらえたなら、講義をした甲斐があったと思います。

expression()とかXSSフィルターのバイパスとか、そんなの入門じゃないだろうと思うかもしれませんが、それを覚えてほしいという意図はなくて、探し方のポイントをおさえれば、そういった、人が見落としやすい部分に目を向けたり、複雑にみえる問題を解決していけるようになるということが講義を通して伝えたかったことです。


2つ目のスライドは、2日目の夕食時に行われた特別コーナー、「俺たち、高レイヤーの講師だけど質問ある？」で発表したものです。この日、ちょうど自分の報告したFirefoxの脆弱性(CVE-2015-4483)が修正されたので、どのような問題だったか、どのようにして発見に至ったかについて、自分の講義で紹介した脆弱性発見のテクニックを実際の場面で使っていることを示しながら解説しました。わかりやすく、扱うのに最適な実例だったので、Mozillaは本当にいいタイミングで修正してくれたなと思います。


参加者の皆さん、5日間お疲れ様でした。
ぜひこれから、もっと深い知識をつけ、自分の手でまだ誰も発見していない驚くような脆弱性を発見して欲しいと思います。皆さんの活躍を楽しみにしています！

CODE BLUEの発表資料「バグハンターの愉しみ」を公開

English version: http://mksben.l0.cm/2015/07/codeblue.html
--------------------------------------------------------

2014年12月に開催された国際セキュリティ会議、CODE BLUEで、「バグハンターの愉しみ」というタイトルで発表させて頂きました。先日、公式ページでスライドが公開されましたので、僕のスライドをここでも共有します。

CODE BLUE 2014 : バグハンターの愉しみ by キヌガワマサト Masato Kinugawa from CODE BLUE

他のスピーカーの方々のすごいプレゼンは以下で見られます。
http://codeblue.jp/2015/archive/2014/

講演の動画はポリシーにより公開していません。
会場の雰囲気はITmediaと@ITに書いて頂いた記事からお楽しみください。

Googleへの報告件数は世界2位：脆弱性発見のプロ「キヌガワ マサト」さんは日本人だった - ITmedia エンタープライズ
http://www.itmedia.co.jp/enterprise/articles/1412/20/news003.html

セキュリティ業界、1440度（13）：自動車、ホームルーター、チケット発券機――脅威からどう守る？ (2/2) - ＠IT
http://www.atmarkit.co.jp/ait/articles/1501/22/news008_2.html

CODE BLUEレポート：脆弱性を見つける人、対応する人、使う人、皆がハッピーになるヒントとは (2/2) - ＠IT
http://www.atmarkit.co.jp/ait/articles/1501/13/news036_2.html


僕はここ2年くらいではじめてセキュリティに関係する人と実際に顔をあわせる場に出るようになったのですが、そういった場で、やっていることの特異さから、自分の活動について多くの人に関心を持ってもらっていることに気が付きました。発表を聴いて頂いた方や資料を見てもらった方はご存知の通り、僕はここ数年間、個人で、脆弱性報酬制度を実施する企業の脆弱性を探して、その報酬を得ることを主な収入源にしてきました。近年になって、脆弱性を探すことのできる人を指す「バグハンター」という言葉も徐々に使われるようになってきた印象がありますが、それでも、バグの発見だけで生計を立てている人は世界中をみてもあまりききません。僕も気が付いたらそんな稀少種になってしまっていたのですが、そんなに自分に関心を持ってもらえているのなら、一度ちゃんとした場でありのままの職業バグハンターの姿を話してみようと思い、今回発表することを決めました。

第1回目や今回の他のスピーカーの方の難しい発表の数々を見て、自分が出ていっていいのだろうかとも思いましたが、簡単な発表であった分、技術をわからない人でもそれなりに楽しんで聴いて頂けたのではないかと思っています。そんな僕のライトな発表は、CODE BLUEのFacebookのページでは"軽妙な語り口"と表現されていて、なるほどそんな僕に配慮された絶妙な言い方もできるのかと感心しました。

発表を聴いて下さった皆様、ありがとうございました。少しでもバグを探すことの面白さをわかってもらえれば嬉しいです。
また、このような機会を与えて下さったCODE BLUE実行委員会の方々、特に代表の @_kana さん、CODE BLUEのことを教えて下さった @hasegawayosuke さん、発表内容について相談させて頂いた @takesako さんにも感謝します。

第3回目も開催されることが決まったようで、今年も面白い発表が行われることを期待しています。

第4期サイボウズラボユース成果報告会の発表資料を公開

実は昨年の夏、サイボウズラボユースという制度を利用させていただいて、3週間程度サイボウズラボのオフィスに出社していました。

サイボウズ・ラボ：人材募集：サイボウズ・ラボユース
http://labs.cybozu.co.jp/recruit/youth.html

何をしていたかといいますと、@herumi さんや @takesako さんにご指導頂きながら、アセンブリ言語をずっと読んでいました。

XSSをはじめとするWebアプリケーションの脆弱性はそれなりに知っているつもりですが、バッファオーバーフローをはじめとするメモリ関連のバグは全然理解していませんでした。

これまでも、アプリケーションが偶然クラッシュするたび、そういった方面への関心がでてきて、アセンブリを読めば何かわかるのかなあと思って、読んではみるけど、無慈悲なバイナリの羅列に圧倒されるということを繰り返してきました。

ただ、アラートがとび出すのと電卓がとび出すのはどこか似ており、その辺の何かが僕を刺激するのか、いつか脆弱性を利用して電卓を出したいとずっと思っていました。

ラボユースでは、作業中偶然クラッシュが起きたのをきっかけに、一からアセンブリ言語を勉強してみようということになりました。結局そのクラッシュはおそらく悪用できないなんだかよくわからないものでしたが、ちょっとした疑問にもすぐに答えてもらえる環境で過ごせたことで、大分前進したと思います。

また、その後、別のソフトウェアで偶然悪用可能なクラッシュが起きました。このクラッシュは最初の時点でいかにも悪用できそうなもので、電卓を起動できるかもしれないという思いと、ヤバい友人に実際に電卓の起動ができることを見せてもらったことで、急激に僕の関心が加速しました。
そこからの学習スピードは自分でも驚くほど早いものでした。ついには自分の手で実際のアプリケーションの脆弱性を使って電卓を起動できたことは大きな感動でした。

僕も数々の失敗をしてきましたが、やっぱり人生は偶然のクラッシュに転機があるものなんだなあと思います。(深み)

さて、昨日はそのラボユースの締めということで、成果を発表してきました。以下が資料です。



メモリの状態を観察するのは自分もそれほど慣れていないので、自分の頭の中を整理するようなつもりで動きのあるスライドにしました。また、これで、わからない人にもなんとなく雰囲気がつかめる作りにしたつもりです。

ただその分スライドの枚数が多くなってしまったので発表では焦って最初から大分早口になってしまいました。聴き苦しい発表であったと思いますが、聴いて頂いた皆様、ありがとうございました。

到底人に説明できるほど理解していると思えないので、勘違いしている部分や荒い部分があるかもしれません。それなら、こういう方法でも突破できるんじゃね？みたいなバイナリアンのご意見ご感想お待ちしております。


他の皆様の取組み、発表も素晴らしかったです。
何をやれという訳でもなく、やりたい人の好きなことを支援してくれるサイボウズラボユースという制度は研究支援の理想的な形だと思います。

参加させて頂きありがとうございました。
サイボウズ(報奨金)にもラボにもお世話になりっぱなしです。

SECCON全国大会カンファレンスの発表資料を公開しました

2014年3月1-2日に行われたSECCON 2013 全国大会のカンファレンスで、cybozu.com Security Challengeで発見した脆弱性について発表させて頂きました。

cybozu.com Security Challengeは、サイボウズが2013年11月に実施した、同社が提供するアプリケーション「kintone」の実際の脆弱性を発見する賞金付きコンテストです。
ご存知の方はご存知の通り、このコンテストで優勝しました。

頂いた表彰状です。

優勝賞金は、1,038,960円を頂きました。 

一部で話題になりましたが、このパネルにおかしいところが4件あるそうなので、まだ間違い探しをトライしていない方は探してみてください。

資料は以下に公開しました。

見つけた脆弱性について(cybozu.com Security Challenge) from Masato Kinugawa

どうぞご覧ください。全体的に内容は易しめです。 

拙い発表を聴いて下さった皆さま、ありがとうございました。

コンテスト参加者の皆さま、お疲れ様でした。修正された問題はぜひ共有してください。

伊藤さんをはじめ、サイボウズの皆さま、初めての試みにもかかわらずスムーズな対応で、楽しみながら安心して脆弱性を検証することができました。このような素晴らしいコンテストを実施してくださりありがとうございました。

海外では、セキュリティ問題の報告に対し報酬を支払う取り組みが大分活発になってきていますが、日本ではまだあまり行われていません。サイボウズの取り組みをきっかけに、日本でも盛り上がってくることを期待しています。

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日更新： スライドのリンクが変更されていたので修正しました。