去年の7月3日にIPAにWindows向けXAMPPのDoSの脆弱性を報告していたのですが、1年経っても開発元から一切連絡がないようなのでIPAに情報非開示依頼の取下げ申請をしてみました。3日前の9月7日にその申請が通ったので、この記事ではその脆弱性の詳細について書いてみたいと思います。言っても今回の脆弱性はURLを少し弄るだけで攻撃が成功してしまうので、PoCと言えるほどのものはないです。5.6.8がバンドルされていたWindows向けXAMPPで、幸いにもそのバージョンのインストーラーがまだ公開されているようなので時間がある人はぜひ自分の環境で試してみてください。いうURLがあるとすると、次のような形にURLを書き換えてそのURLにアクセスをするだけで再現ができます。https://vuln.jp:80スキームをhttpからhttpsに変えていることと、ポート番号として80番ポートを指定しているところがポイントとなっています。結果として、以下の動画のようにWindows向けXAMPPが再起動を繰り返します。動作を停止しました」というダイアログを閉じない限り自動再起動は行われません。7では一度でもこの脆弱性を悪用されてしまうと、サーバ管理者が対応を行うまでApacheを介してのサービス提供が不可能な状態になります。そもそもWindows向けXAMPPを使ってグローバルにサイトを公開している人はほとんどいないと思うので影響範囲は大したことがなさそうですが、このような簡単な方法でDoSの脆弱性が突けてしまうのは少し面白かったです。共有2016年5月25日水曜日Amazon.co.jpの新機能にあったXSS先日久しぶりにAmazon.co.jpにアクセスしてみると、何やら見慣れないボタンが右上に追加されていました。Amazon.co.jpを利用するときの言語を設定できる機能のようです。この機能のURLは以下のような形になっていました。http://www.amazon.co.jp/gp/customer-preferences/select-language/ref=topnav_lang?ie=UTF8&preferencesReturnUrl=%2f怪しい気配がしますね。試しに、「'」(%27)をURLの末尾に挿入して出力されるコードを確認してみます。http://www.amazon.co.jp/gp/customer-preferences/select-language/ref=topnav_lang?ie=UTF8&preferencesReturnUrl=%2f%27あっ...(察し)先ほど入力した「'」がエスケープされずに出力されてしまいました。この箇所はユーザから入力された値を適切にエスケープできていないようです。これでalertが出せそうということが分かったので、JavaScriptの構文のエラーが出ないようなコードを書いて追加で挿入します。http://www.amazon.co.jp/gp/customer-preferences/select-language/ref=topnav_lang?ie=UTF8&preferencesReturnUrl=%2f%27%3B%7D)%3B%7D)%3Balert(1)%3B(function()%7B(function()%7B%27alertが無事画面に表示されました!この問題は発見した当日にAmazonに報告をして、本日修正を完了したとの連絡をいただいています。最後に、修正が完了したあとの同機能のスクリーンショットを貼っておきます。本日確認したところ、同機能が復活していました。Policy)バイパスのPoClocal/index.htmlローカル上のSOPバイパスのPoC解説この脆弱性を発見するきっかけとなった挙動から順に解説していきます。あるPoCの内容が基点となっています。変更するとアドレスバーの表示は変わらずにブランクページに遷移する挙動が存在しました。この挙動では、スキームを変更後も変更前のオリジンからDOMの操作が可能でした。僕はこの挙動をアドレスバー偽装のトリガーに使えるかもしれないと考え、開発者ツールで検証を行ってみたところ、以下のような挙動を発見しました。ブランクページが表示されている状態となります。行ったあとのページに偽装したいページと同様の表示をさせる方法を探すことにしました。いう形にできればページの偽装も成功させることが可能と考えました。そこで、まずは以下の方法を試してみます。含まれているため、期待している形通りにURLを変更することができませんでした。上記のような記号を含めずに先ほどの形の表現が可能だと考えました。location.protocol="data"location.host="text"location.pathname="html,foo"しかし上記の方法ではダウンロード用のダイアログが表示されてしまい、ページはブランクページの状態から変更ができませんでした。Locationオブジェクトのプロパティが参照する箇所が以下のようになることを発見しました。location.pathnameでそれぞれ変更することができます。制約からは抜けられることになります。このあたりからこれらの挙動はアドレスバー偽装より重要度の高い脆弱性のトリガーになり得るのではないかと思い、別の目線で検証をしてみることにしました。その中で見つけた挙動が以下の挙動です。location.protocol="view-source"操作しているタブがクラッシュ(e10s環境ではない場合はFirefox自体がクラッシュ)普段ならバグハントでクラッシュが起きることは嬉しい現象なのですが、今回のケースでは更なる検証を阻害する邪魔な要素でしかありません。参照することでクラッシュの回避が可能なことを発見しました。用いて子ウィンドウに対して親ウィンドウのドメインとは全く関係のないドメインのview-sourceを参照させようとしたケースでも、正常にそのドメインのview-sourceの内容が表示されることを確認できました。ここで試しに全く関係のないドメインのview-sourceを参照している子ウィンドウのDOMに対して親ウィンドウからアクセスを試みたところ、なんとアクセスが成功してしまい、結果、今までの挙動をSOPバイパスの脆弱性へと結びつけることに成功しました。後日談ですが、アドレスバー偽装に使えそうな挙動に関しては最終的にページを偽装する方法を見つけることができなかったのですが、のちに偽装させる方法を発見することができ、今回の脆弱性の修正後に別途Mozillaに報告をして脆弱性として認定されました。以下は、その脆弱性が修正されたときに公開された情報です。プロトコルプロパティを通じたロケーションバー偽装また、この脆弱性の修正後に別の手法を用いることで同じような挙動を再現できることに気づき、あとはDOMへのアクセスを成功させるだけで同様の脆弱性へと結びつけられる、という段階までいっていたのですが、モチベが続かずにしばらく放置していたところ、いつの間にかその手法に使っていた挙動が防がれていました...。先日、僕が報告したFirefoxというブラウザのバグが修正され、開発元のMozillaのサイトにそのバグの概要が掲載されました。Programという自分たちが開発した製品、サービスのセキュリティ上のバグを発見してくれた人に対して報奨金を支払う制度を設けています。Programという制度は、Mozilla以外にもGoogle、Microsoft、Facebookなど様々な企業、団体が取り組んでおり、最近では日本の企業もこの制度を取り入れるところが徐々にですが増えてきています。Programで支払われる報奨金の額はバグの重要度で決まります。Mozillaの場合はその重要度が4段階に分かれており、重要度が低い順から以下のような分類になっています。低(Low)→中(Moderate)→高(High)→最高(Critical)その中で、今回僕が報告したバグはMozillaから最高(Critical)に相当する、という評価を受けまして、報奨金として5000ドルをいただくことができました。このときに見つけたバグの詳細については、近いうちに某勉強会にて発表させていただこうと思っています!2014年の7月頃から始めた情報セキュリティで、憧れのバグハンターの方を目指して今までやってきましたが、この件でようやく見習いバグハンターとして一皮むけることができたような気がします。