セキュリティ・キャンプ全国大会2017の講義資料です（Masato Kinugawaさんとの共同制作です）。
ブラウザの脆弱性とそのインパクトMasato Kinugawa, Cure53Muneaki Nishimura, Recruit Technologies Co., Ltd.
View Slide
この講義の概要Webの安全性は、サーバ側の堅牢な実装に加え、ブラウザのセキュリティモデルの上に成り立っています。ブラウザに脆弱性があると、あるサイトに書き込んだデータが他のサイトに漏えいするなどの様々な問題が生じます。ブラウザの脆弱性の多くは、実装のちょっとしたおかしな動作から見つかります。しかし、ブラウザの利用者の多くは、その動作が脆弱性であり、攻撃に悪用されうることに気付きません。脆弱性を見つけるには、そうした動作を悪用する方法を見つけ出すための「発想力」が必要となります。本講座では、そうした攻撃者の発想力を身に着けるためのポイントを学びます。
自己紹介
Masato KinugawaCure532016年より独Cure53で脆弱性診断。それ以前は脆弱性報告の報奨金で生活していた。好きな脆弱性はXSS。WebアプリケーションやブラウザのXSSに関連する脆弱性を中心に多数発見。OWASP AppSec APAC 2014、CODEBLUE(第2回、第3回)、AVTOKYO 2015で講演あり。2013年よりセキュリティ・キャンプに関わる。
西村 宗晃株式会社リクルートテクノロジーズサイバーセキュリティエンジニアリング部シニアセキュリティエンジニア国内携帯電話メーカーでのセキュリティコンサルタントなどを経て2016年より現職。リクルートグループ全社の脆弱性検査や修正支援に携わる。趣味はブラウザの脆弱性を探すこと。著書にブラウザハック（監訳）。主な講演歴にCODE BLUE 2015、AVTOKYO 2016、PacSec 2016。2014年よりセキュリティ・キャンプ全国大会講師
脆弱性探しの主なプロセス
1. 対象を決める2. 対象を深く知る3. 対象のおかしな動作を探す4. その悪用シナリオを考える
対象を決める
どのモジュールの脆弱性を探すか• ブラウザは様々なモジュールで構成されている• 数あるモジュールの中からどれを叩くかを決めることが最初の一歩• 対象を決める基準は心がときめくかどうか• その後のモチベーションに影響するので極めて重要Nishimura
ブラウザの構成要素は• 様々な観点で、心ときめくモジュールを見つけ出す• ドキュメントパーサ• スクリプト処理機能• プロトコル• マルチメディアサポート• 内包しているミドルウェア• 各種API• UI部品• ブラウズを便利にするための機能• セキュリティ機能• 他Nishimura
演習1. ブラウザのモジュールを洗い出す（10分）• 以下の観点でブラウザのモジュールを列挙してみよう（何を調べてもOK）• ドキュメントパーサ• スクリプト処理機能• プロトコル• マルチメディアサポート• 内包しているミドルウェア• 各種API• UI部品• ブラウズを便利にするための機能• セキュリティ機能• 他Nishimura
演習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
たとえばこんな方法で対象を決める
新しい機能を探す• 新しく搭載された機能は、まだ誰も脆弱性を探していない可能性が高い• 開発者向けのアルファ版を狙う• Firefox Nightly• Chrome Dev, Canary• Safari Technology Preview• EdgeはWindows 10の先行リリース版が狙い目（@shhnjk談）• 新しい機能を知る手段• Release Notes• 各ブラウザのFeature Status• 各ブラウザベンダーの技術ブログや開発者向けカンファレンスの動画• バグ管理システム（RSSで取得・ただしS/N比はあまり良くない）Nishimura
Firefox developer release noteshttps://developer.mozilla.org/en-US/Firefox/ReleasesNishimura
Linkタグでpreloadを指定できるのか！面白そうだ！調べてみよう！Nishimura
Firefox Platform Statushttps://platform-status.mozilla.org/Nishimura
Chrome Platform Statushttps://www.chromestatus.com/featuresNishimura
Mozilla Hacks – the Web developer bloghttps://hacks.mozilla.org/Nishimura
Chromium Bloghttps://blog.chromium.org/Nishimura
Chrome Dev Summit 2016 - YouTubehttps://www.youtube.com/playlist?list=PLNYkxOF6rcIBTs2KPy1E6tIYaWoFcG3ujNishimura
Google for Mobile Tokyo 2015https://www.youtube.com/watch?v=VHN2wJWi0WENishimura
古いイケてない機能を探す• こんな古い機能はイケてない• 標準化されておらず仕様が不明確なもの• 流行らなかったもの• プラグイン全般（Flash/Adobe Reader）• まともなドキュメントすらないことも多い• 古い機能を知る手段• Release Notes• セキュリティ研究者の投稿や発表Kinugawa
イケてない例：showModalDialogKinugawa
ダイアログ使用中他のウインドウは操作不可（UIに関連する問題が起きそう？）dialogArguments/returnValueプロパティを使った独自のウインドウ間のデータのやりとり（ここにオリジンの制限はあるのか？）イケてない例：showModalDialogKinugawa
Firefox サイト互換性情報https://www.fxsitecompat.com/ja/docs/Kinugawa
Mario Heiderich: "My Sweet Innocence Exposed - Eleven Reasons why we will all miss you, 'e'"https://www.youtube.com/watch?v=aeevfVXPIqoKinugawa
列挙する・列挙されたものから探す• 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
例：windowオブジェクトを見るKinugawa
HTTPLeakshttps://github.com/cure53/HTTPLeaks/blob/master/leak.htmlKinugawa
HTML5 Security Cheatsheethttps://html5sec.org/Kinugawa
IEではCSSからスクリプトを実行できるのか！CSSでどのくらい攻撃できるか見てみるかな！Kinugawa
コミット履歴から更なる気付きを得る• Gitのコミット履歴から面白そうな機能追加を探す• モバイルOSの新規機能対応（3D Touch, Spotlight, Universal Links）• 実装中の機能（Web App Manifest, GeckoView）• コミット履歴から新たな着眼点を得る• プログラマが脆弱性を作りやすそうな記述の存在（正規表現, 文字列への変数埋め込み）• 扱いの難しいサードパーティライブラリの利用（SQLite, Alamofire）Nishimura
GitHub - mozilla-mobile/firefox-ios: Firefox for iOShttps://github.com/mozilla-mobile/firefox-iosNishimura
Bug 1289687 - Support Internationalized Domain Nameshttps://github.com/mozilla-mobile/firefox-ios/commit/78be54586c9e027465d8e0da28bb42595d4ebe32Nishimura
演習2. コミット履歴から脆弱性を探す（10分）• このコミットにはどんな脆弱性があるでしょう• https://goo.gl/xo6MMV• このコードには現在のブラウザが備えるべき「ある攻撃」への対策が入っていません• IDNや国際化ドメインという単語を検索してみようNishimura
演習2の回答• ホモグラフ攻撃の対策が入っていない• 本物のサイトとよく似たURLで偽サイトに誘導するフィッシング• アルファベットの「a」とよく似たキリル文字「 а 」U+0430などが使われる• 以下は「a」がU+0430• 以下は「:」がU+0589で、「/」がU+2215Nishimura
演習2の回答• ちなみにこの脆弱性を報告した結果• IDN（国際化ドメイン）が当面は無効化されることに・・・Nishimura
コミット履歴から新たな着眼点を得るデータの保存にSQLiteを使っている！どこかでSQL Injectionが起きないかな！Swiftでは文字列リテラルに変数を埋め込めるのか！HTMLを生成してるところでXSSが起きないかな！Nishimura
SELECTやINSERTという単語でコード全体をgrep外部から渡されたパラメータがSQLクエリに展開されている個所がないか探す（このコードの例は安全）Nishimura
Bug 1317580 - Add additional deeplink support for FxAhttps://github.com/mozilla-mobile/firefox-ios/pull/2249/filesNishimura
演習3. コミット履歴から脆弱性を探す（20分）• このコミットにはどんな脆弱性があるでしょう• https://github.com/mozilla-mobile/firefox-ios/pull/2249/files• 文字列リテラルに変数を埋め込んでいる個所を探してみよう• 発生する脆弱性が分かった人は、どのような経路で攻撃できるかを調べてみようNishimura
演習3の回答• Firefox Accountsのページ上でXSSできる• webView.evaluateJavaScriptの第1引数（変数script）に任意の文字列を指定できることが原因• iOSのDeep Linkを使って、以下のURLをSafariで開けば攻撃成立firefox://?fxa=signin&[email protected]');$('.email').val('JAVASCRIPT_INJECTED!!Nishimura
Webアプリの脆弱性検査から気付きを得る• ブラウザがこう動けばアプリが脆弱になるのに、と気付くことがある• URL文字列を取得するAPIが特定の記号文字列を返すなら…• 信頼できない文字列を扱う一連の関数の動作が1つでもおかしければ…• 任意のhostヘッダを犠牲者に送信させることができたなら…• CSPが正しく機能しなければ…• 攻撃のシナリオが明確なら、対象を定めやすい• ➡ location.* プロパティが返す値• ➡ 利用されている関数の詳細な動作• ➡ ヘッダを送信できる関数の制限が適切か• ➡ CSPの実装が正確かKinugawa
Kinugawaの実例：CSPの実装不備CSPの設定の安全性を検査してほしいと仕事で依頼された際、FirefoxのCSPがsandbox化されたiframeのsrcdoc属性で機能しないことを発見。余談：報告したところ、StatusがDUPLICATEに。一体誰が報告を…？Kinugawa
Bug 1073952 - CSP can be bypassed with https://bugzilla.mozilla.org/show_bug.cgi?id=1073952Kinugawa
過去に学ぶ• 過去の修正された脆弱性の情報を見る• セキュリティアドバイザリ• 時間が経って開示されたバグ票（bugzilla.mozilla.org, bugs.chromium.org）• 報告者のブログやカンファレンスの発表資料• 過去のバグからはたくさんの有益な情報が得られる• どこに脆弱性があったのか• どんな脆弱性があるのか• どうすれば脆弱性が発生しうるのか• 報告者はどのように脆弱性を発見したかKinugawa
Mozilla Foundation Security Advisorieshttps://www.mozilla.org/en-US/security/advisories/Kinugawa
Chrome Releases: Stable Channel Update for Desktophttps://chromereleases.googleblog.com/2017/07/stable-channel-update-for-desktop.htmlKinugawa
Kinugawaがやったこと• はせがわようすけさんの資料を熟読（http://utf-8.jp）• さまざまなブラウザに起因するXSS手法があることを知る• Content Sniffing• 文字コード• 使える文字種に縛りがあるときのXSS• mXSS• それぞれを自分の手を動かして再現させた• さらに、深く調べる余地がありそうな部分を自分で調べ直した• 全ての文字コードの動作を一から調べてみようKinugawa
各ブラウザが解釈可能なcharsetの比較表https://l0.cm/encodings/table/Kinugawa
文字コードを調べてみつかったもの(一例)• 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
他にもあるよ• about: URLをひたすら解析する• ブラウザのバイナリに埋め込まれた隠しページを探し出す• about:neterror?e=nssBadCert&d=Hello%20Guys!Hello Guys!Nishimura
他にもあるよ• 利用しているサードパーティライブラリの脆弱性を探すNishimura
サードパーティライブラリの脆弱性• 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.pdfNishimura
対象を深く知る• 目的や使用用途は？• どのように使うのか？• InputとOutputは？• 対象にはどのような制限事項があるのか？• ブラウザ上でどんなことが起きてはいけないのか？• 対象が提供する機能は悪用できないか？• ブラウザのセキュリティ機構を迂回できないか？• これまで安全と見られていたWebサイトに対する新たな攻撃手段として利用できないか？Nishimura
深く知るためにどうするか• 実際に使って動かす• テストプログラムのコミットなどを参考にプログラムを書いてみる• 仕様を読む• コードを読む• コードにログを仕込んでビルドし、詳しい振る舞いを確かめる• バイナリを読むNishimura
Kinugawaedgehtml.dllのバイナリC:¥Windows¥System32¥edgehtml.dll
edgehtml.dllのバイナリC:¥Windows¥System32¥edgehtml.dllXSSフィルターの正規表現Kinugawa
演習4. XSSフィルターの反応原因を探る（20分）• Internet Explorer のXSSフィルターは次のURLになぜか反応します• https://goo.gl/WSEkgq• C:¥Windows¥System32¥mshtml.dll のバイナリから正規表現をみつけ、どの部分に反応したかを推測しよう• 正規表現は"implementation"と検索するとみつかります• また、本来ならどのような攻撃文字列を阻止するものか考え、その文字列を使って以下のページでアラートを実行してみよう• https://goo.gl/VmkebcKinugawa
演習4の回答: どの部分に反応したかKinugawa{[¥"¥'][ ]*(([^a-z0-9~_:¥'¥" ])|((i|(¥¥u0069))(n|(¥¥u006[Ee])))).+?{¥(}.*?{¥)}}"instagram(インスタグラム)"
演習4の回答: 本来遮断したいものKinugawa{[¥"¥'][ ]*(([^a-z0-9~_:¥'¥" ])|((i|(¥¥u0069))(n|(¥¥u006[Ee])))).+?{¥(}.*?{¥)}}"alert" in window //truenew Date() instanceof Date //truevar q=""in alert(1)//"var q=""instanceof alert(1)//"補足： in と instanceof 演算子について
フィルターを深く調べてみつけたもの• フィルターのバイパス• 以前までのバイパス可能なフィルタールール：Kinugawa<br/>var q=""i¥u006E alert(1)//";<br/>{[¥"¥'][ ]*(([^a-z0-9~_:¥'¥" ])|(in)).+?{¥(}.*?{¥)}}バイパスの例：(※Windows 8.1以下のIE11ではまだ古いルールが使われています。)
フィルターを深く調べてみつけたもの• フィルターの反応を利用して逆にXSSをする手法• https://www.slideshare.net/masatokinugawa/xxn-jaKinugawavar q=":";javascript: を無関係の文脈にマッチさせて攻撃する例：
演習5. Fetch APIの仕様を調べる（20分）• Fetch APIにはどのようなセキュリティ上の制限が施されているか• 仕様書（WHATWGのFetch Standard）を読んで洗い出してみようhttps://fetch.spec.whatwg.org/• これは2015年のセキュリティ・キャンプの演習問題の再掲ですNishimura
演習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
演習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
演習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
演習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
演習5の回答例• レスポンスヘッダ• 以下のヘッダは読み取り禁止• Set-Cookie, Set-Cookie2• その他のヘッダはCORSに準拠すること• エラーオブジェクト• 接続先のリダイレクト後のURLが異なるオリジンである場合、返却されるオブジェクトのURLにパスやクエリ文字列を含んではいけない• 接続先が異なるオリジンである場合、取得したデータを含めてはならないNishimura
仕様どおりに動くかを調べるだけで脆弱性が見つかる• 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
リクエストにHostやCookieヘッダを付加できるhttp://seclists.org/fulldisclosure/2017/Mar/37Nishimura
リダイレクト後のクロスオリジンURLがレスポンスボディに含まれるhttp://mov.sx/2017/04/16/microsoft-edge-leaks-url.htmlNishimura
対象のおかしな動作を探す• わずかな「いつもと違う」に目を光らせる• 設定通りの動きをしない• アドレスバーが更新されない• クラッシュ、フリーズ• 文字化け• HTMLタグが効いている• ブラウザによって動作が異なる• 一見ただのバグでも、詳しくみると悪用可能な動作かもしれないKinugawa
おかしな動作は案外わかりにくい• 問題と気付けるかどうかが重要• 例えば CVE-2012-3695• http://masatokinugawa.l0.cm/2012/08/safari-location.href.html• location.href に含まれるBasic認証情報部分がデコードして返される• 実際の利用場面を考えれば、まずい動作であることがわかりますか？https://aaa%[email protected]/https://aaa/@example.com/Kinugawa
おかしな動作を引き出す方法• 様々な要素と対象を組み合わせてみる• プロトコルスキーム (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
Kinugawaの実例• CVE-2015-4483• https://bugzilla.mozilla.org/show_bug.cgi?id=1148732• feed: を先頭に付けたhttpsのURLにPOSTリクエストを送信すると、POSTを受けたページでMixed Content Blockerが機能しない• 最初の気付きはアドレスバーから feed: が消えないことだったKinugawa
先週修正されたFirefoxの脆弱性• CVE-2017-7788• https://bugzilla.mozilla.org/show_bug.cgi?id=1073952• のsrcdoc属性にscript要素を記述すると、CSPのscript-src指定に関わらずインラインスクリプトが実行される。ただしスクリプトが動作するオリジンはsandboxoriginであり、親フレームのCookieなどは盗めない• CVE-2017-7789• https://bugzilla.mozilla.org/show_bug.cgi?id=1074642• HTTPレスポンスにHSTSヘッダが複数付いているとHSTSが効かない。サイトの構成でOriginとEdgeサーバの両方でHSTSヘッダを付けた場合、HSTSが効かない。HTTP ヘッダインジェクションでHSTSを無効化する悪用方法も考えられるNishimura
図に表すとこんなかんじCSP sandboxiframe srcdocHSTS 重複した値POST feed:Mixed Content Blocker CVE-2015-4483CVE-2017-7788CVE-2017-7789×× ×➡➡➡×××考慮されていない組み合わせからおかしな動作が起き、脆弱性が引き起こされるKinugawa
仕様とおかしな動作• 仕様そのものが攻撃の可能性を十分に想定できていないことがある• 例えば@font-face のunicode-rangehttp://masatokinugawa.l0.cm/2015/10/css-based-attack-abusing-unicode-range.html• 仕様そのものを改善する議論に発展することも• 場合によっては機能を廃止する判断が下されるかもしれない• E4X• ApplicationCacheKinugawa
演習6. CSPバイパスXSSチャレンジ（20分）• 以下のページでアラートを実行してみよう• https://goo.gl/pVqnrw• CSPのnonceに対応したChromeかFirefoxを使ってください• アラートを実行できた人：このようなバイパス手法に対処するために新しい制限が提案されています。どのような方法がありうるか考えてみようKinugawa
演習6の回答例• 正規に使われているスクリプトタグのnonceを利用• Dangling Markup Injectionにより、追加したスクリプトタグの属性中にnonceを含ませるKinugawa
提案されている新たな仕様• CSP Lv3でDangling Markup Injectionに対処する記述が追加されている• https://www.w3.org/TR/CSP/#matching-elements• "Kinugawa
見つけた動作を悪用可能なシナリオを考える• 現実のWebアプリでどう悪用できるかを示す• その振る舞いのせいで、本来は安全であるはずのサイトが安全でなくなることを示す• 実例をもとに、現行のWebのセキュリティモデルが毀損することを示す• 現実に悪用できない場合でも、最大限に悪用可能なシナリオを考えて示す• もしサイトの実装が○○なら、この動作を悪用して△△できる• 仮定が身近にありそうな例であれば、危険性を理解してもらえるNishimura
演習7. おかしな動作の悪用方法を考える（20分）• 以下のFirefox拡張（WebExtension）には、ある脆弱性があります• https://github.com/nishimunea/securitycamp2017• この脆弱性を最大限に悪用するシナリオを考えてください• シナリオには仮定を置いて構いません例：○○するサイトで、ユーザが△△した場合に、□□が起きるNishimura
演習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
演習7の回答例• 拡張のJavaScriptに着目すると、%TITLE%、%CONTENT%、という順にテンプレートへ変数が展開されていることがわかりますNishimura
演習7の回答例• タイトル（%TITLE%）にform要素を埋め込むことで、XSSを使わずとも、ページの内容（%CONTENT%）を外部へ盗み出すことができます• 以下のform要素をエンコードして、ページのtitle要素に埋め込みます%CONTENT%Nishimura
演習7の回答例• ユーザが指定した文字列をtitleに展開するサイトは数多くあります• 身近な例では、Google検索の結果画面のタイトルが悪用できます• ただし、検索結果のページ内容を盗み出してもあまりインパクトはありませんNishimura
演習7の回答例• 攻撃者がページのタイトル（title要素）に任意の文字列を指定でき、かつ、そこに盗まれてはいけない情報が含まれているサイトを探します• 皆さんは分かりますか？Nishimura
演習7の回答例• たとえばGmailを見てみましょうNishimura
演習7の回答例• 受信メールを開くと、メールのタイトルがページのtitle要素に表示されますNishimura
演習7の回答例• この画面で拡張を選択すると、HTML Injectionが成立し、ボタンが出現しますNishimura
演習7の回答例• ボタンを押すと、ページのDOM（%CONTENT%）が外部に送信されますNishimura
演習7の回答例• 送られたデータには、受信トレイにある他のメールの本文まで含まれていますNishimura
演習7の回答例• 被害者がGmailで悪意のあるメールを受信し、それを拡張で開いた場合、受信トレイに表示された全てのメールが攻撃者に盗まれる恐れがある• ここまでやれば、深刻度が中程度まで上がる可能性があるNishimura
さいごに
さいごに• 2人が実際に見つけた脆弱性を例に、脆弱性を探すための発想法を学びました• 日頃の調査・研究の積み重ねや地味な作業の繰り返し（素振り）が、あるとき、脆弱性を見つける際の閃きに結び付いているというのがポイントです• 脆弱性の探し方は十人十色です• 本日の講義では4つのメソッドを紹介しましたが、これに従う必要はありません• 自分の心がときめく対象を見つけ、自分が面白いと思えるやり方で脆弱性を見つけること。これが長い間に渡って脆弱性を見つけ続けるための秘訣なのかもしれませんNishimura
おわり
nishimunea
okunokentaro
visional_engineering_and_design
udzura
iseki
nttcom
k1low
ad5jp
megabitsenmzq
sattosan
onk
ybrliiu
kenichirokimura
thoeni
bryan
destraynor
robhawkes
mclloyd
erikaheidi
sferik
roundedbygravity
phodgson
aleyda
notwaldorf
chrisshort