ラベル MixedScripting の投稿を表示しています。 すべての投稿を表示
ラベル MixedScripting の投稿を表示しています。 すべての投稿を表示

2015/08/18

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

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


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


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



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




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日間お疲れ様でした。
ぜひこれから、もっと深い知識をつけ、自分の手でまだ誰も発見していない驚くような脆弱性を発見して欲しいと思います。皆さんの活躍を楽しみにしています!

2013/02/09

Twitterの脆弱性 2013

Twitterは2010年から、年ごとにTwitterのサービスのセキュリティ問題の報告者のリストを掲載しています。以下がそのページです。

https://twitter.com/about/security

幸運にも、僕は毎年載ることができているので、2013年も早速載ってやろうじゃないかということで頑張って脆弱性を探しました。結果はページを見てもらえばわかると思いますが、なんとかみつけることができました。今回みつけた問題がどんな問題だったかを書きたいと思います。2つあります。

1. analytics.twitter.com のXSS

analytics.twitter.comは、Twitterが提供するサイトオーナーのための解析ツール、だそうです。こんな具合に、ログインページのパラメータでエンコーディング処理に起因するXSSがありました。




XSSベクタに関して特に面白いことはないので、このXSSの影響について考察します。

https://analytics.twitter.com と https://twitter.com の認証は区別されており、https://twitter.comでログインしても https://analytics.twitter.com でログイン状態になることはありません。認証用のCookieの値には適切にHttpOnly属性がついており、XSSがあったとしてもJavaScriptでは取得できないようになっています。
よって、これらから考えられる通常の主な影響は、

・ analytics.twitter.comの解析ツールを利用するログイン中のサイトオーナーがanalytics.twitter.com上で不正な操作をされたり、情報を第三者に取得される
・ *.twitter.comという知名度のあるドメインを使って偽のページを表示することによる効果的なフィッシングをされる

などだと思います。

が、実はそれだけではありませんでした。Twitterは同一生成元ポリシーの制限を緩める設定をhttps://twitter.com 上でしているため、もう少し影響は大きくなります。
その設定とは、 https://twitter.com で読み込まれるJavaScriptの次の一行です。

document.domain="twitter.com";

明示的にdocument.domainを設定したページは、明示的に同じdocument.domainを設定したもう一方の*.twitter.com上のページと相互にアクセスできるようになります。

これはつまり、https://analytics.twitter.com のdocument.domainを、XSSを利用して"twitter.com"に設定すれば、https://analytics.twitter.com から https://twitter.com の内容を読み出すことができることを意味します。https://twitter.com には、ログイン状態で、Twitter上の操作を外部から制限するためのtokenも埋め込まれているので、これを取得し、任意のツイートをつぶやかせるリクエストを発行させることも可能でした。よって、解析ツールを利用するユーザーだけでなく、一般Twitterユーザーも罠ページへのアクセスだけで不正な操作や情報の取得をされる恐れのある問題だったと思います。

2. askobama.twitter.com の https/httpリソースの混在

こちらの画像をご覧ください:



httpsのページ「https://askobama.twitter.com」で、「http://platform.twitter.com/widgets.js」と、"httpで"JavaScriptを読み込んでいます。
もしこのHTTPリソースを中間者が改ざんした場合、考えられる影響はなんでしょうか。

これも先ほどのXSSと同じように、document.domainを"twitter.com"に設定する内容にしてしまえば、https://twitter.com の内容にアクセスすることも可能になります。こんな特設のページでさえも、https://twitter.com のセキュリティに穴をあける問題に直結してしまうというのはちょっと面白いですね。document.domainでアクセスする方法は、ポートとプロトコルは一致している必要があるので、そもそも askobama.twitter.com にhttpsでアクセスできるようにしなければ、https://twitter.com まで影響を受けることはなかったというのもまた面白い点です。

TwitterのSecurity Teamはこの問題に対し、慎重に「http」と「://」の間に「s」を入力することで解決しようとし、無事入力が成功したようです。


以上です!
twitter.comでdocument.domainを設定しているのには理由があるのでしょうが、結果的にサブドメインに脆弱性があった場合の影響範囲が広くなってしまっていますね。

2010年頃なんかのTwitterは、少し風変わりな文字列をツイートに入力すれば、すぐに文字化けが発生したり、XSSが生まれたりしていたものですが、あの頃とは随分変わったなと思います。僕の報告がこの数年間のTwitterのセキュリティの改善の一助になったのであれば、僕はとても嬉しいです。