Más contenido relacionado La actualidad más candente (20) Similar a とある脆弱性の永い議論 (9) 10. Copyright (C) Cybozu,Inc.
CSRF対策の報告 燃焼度 ★★★☆☆
▌CSRF対策されていない箇所の指摘が同一の方より40件以上着信
CSRFトークンが付与されていない事によって、被害者が罠リンクをクリックして意図せ
ずに処理を実行させられてしまう脆弱性
掲示板サイトへの投稿、メール等
広告のようにクリックを誘導するURL
(被害者が利用するサイトの設定変更を行うURL)
被害者が利用するサイト
非公開設定になっている記事が
いつの間にか公開設定に…トークンがあれば防げる！！
10
16. Copyright (C) Cybozu,Inc.
PDF Formcalc Attack の報告 燃焼度 ★★★★☆
▌PDF Formcalc Attack とは
PDFファイルがアップロードされているオリジンで任意のリクエストを発行できる攻撃
被害者が利用するサイト
クリックを誘導するようなURL
攻撃用のPDFが埋め込まれたサイト
PDF 内に書かれた スクリプト によって、
任意のリクエストが発行される！
任意のリクエスト
参考文献：
https://dl.dropboxusercontent.com/u/13018058/poc/appsec.pdf
PDF - Mess with the web @ Alexander Inführ
16
17. Copyright (C) Cybozu,Inc.
Adobe 社 への問い合わせ
クロスオリジンでリクエストを送信できる問題（CVE-2014-8453）は修正済
http://jvndb.jvn.jp/ja/contents/2014/JVNDB-2014-005928.html
関連
ベンダー 同一オリジン内でリクエストを送信できる点
については脆弱性としていません
From our perspective, website owners must realize that PDF is active content, and
serving user-uploaded/malicious PDFs from a non-throwaway domain is effectively
an XSS (just like hosting an arbitrary/malicious HTML).
© Adobe 社
17
18. Copyright (C) Cybozu,Inc.
TLM で脆弱性とするか議論
▌脆弱性として認定しないことに決定
• ファイルを自由にアップロードできる Webアプリケーション全般に発生する
PDF ファイルを表示する Adobe Reader の問題
• ログインできない外部のユーザーからは攻撃可能なPDFファイルをダウンロードする
URLは推測困難
技術会議(TLM)
全開発責任者が参加
ただ情報としては不穏なので、社内での対策
したほうが良さそう
18
20. Copyright (C) Cybozu,Inc.
TLM で脆弱性とするか再議論
▌認定するか？
• バグハンターの意見も一理ある
• 異なるオリジンにファイルを格納することで緩和策になる
▌認定することに決定！
20
技術会議(TLM)
全開発責任者が参加
認めてしまって長期的な課題として
対処しましょう
26. Copyright (C) Cybozu,Inc.
RFD の報告 燃焼度 ★★★★★
▌Reflected File Download(RFD) とは
攻撃者の入力値を含む Web ページからのレスポンスを指定したファイ
ル名でダウンロードさせ、ユーザがそれをクリックすることでダウン
ロードしたファイルを実行させる攻撃
引用：http://www.tiger1997.jp/report/activity/securityreport_20141114.html
© Reflected File Downloadの問題(タイガーチームセキュリティレポート)
▌RFDの条件
1. Reflected -ユーザーの入力した値がレスポンスに反映される
2. File – URL に任意の文字列を追加でき、尚且つ正常にロードされ
る
3. Download -ダウンロードが可能であり、上記 2 つの要素がダウン
ロードしたファイルに反映される
引用：https://shhnjk.blogspot.jp/2015_12_01_archive.html © RFD 2015(Hack Patch!)
26
28. Copyright (C) Cybozu,Inc.
TLM での議論開始
▌TLM で認定するべきかどうか質問される
開発
サイボウズ製品では実行ファイル
の添付が可能。RFD によって
脅威は広がっていないのでは？
トリアージ
他の脆弱性と組み合わせることにより、
リスクが増加する可能性がある。
28
30. Copyright (C) Cybozu,Inc.
TLM で再議論
▌トリアージメンバーからの説明
• 製品の特性として、脆弱性を利用しなくても実行可能な形式でアップする
ことが可能
• ファイルのアップを自由に行えない企業では、テキストファイルに見せかけて
ファイルをアップロードし、罠用のURLを渡すことで攻撃可能
▌結論
そもそも Reflected はクエリパラメーター等で直接ファイルの中身を操作できな
ければいけないのではないか？
例)https://www.google.com/s;/ChromeSetup.bat;/ChromeSetup.bat?q="||calc||
30
32. Copyright (C) Cybozu,Inc.
TLM で再々議論
▌結論としては、脆弱性と認定して改修することに決定
• “ユーザーの入力した値”については限定しない
→ 外部からの入力値を箇所ごとに調べるにはコストが大きい
• ファイル名が任意に変更されること自体は望ましい挙動ではない
• 可用性(A)の侵害については評価しない
32
Notas del editor 役割としては、PSIRT、Product Security Incident Response Team ですが、Incident は別チームで対応しています。
I が抜けると誤字を疑われるのでそのまま PSIRT としています。
製品の脆弱性を検出したり、様々な場所で検出された脆弱性を集約したり、脆弱性情報を公開たりしています。
◇ 検出
セキュリティテスト
ソフトウェア属性管理
◇受付
脆弱性の評価
◇公開
・不具合公開サイトでの脆弱性情報の公開(2016年8月から全製品の脆弱性情報公開場所を集約)
・IPAへの脆弱性関連情報の届け出
・脆弱性を報告いただいた方の謝辞掲載
◇その他
報奨金制度
・問い合わせ対応
・お支払い金額の連絡や手続き
検証環境提供プログラムの運営
・受付対応
・メンテナンス対応
前のスライドの「脆弱性情報の受付」は弊社内で検出した脅威・脆弱性はもちろんですが、
外部のバグハンターからの問い合わせも含みます。
弊社内で、開発・運用・QAで検出する脅威に加えて
外部のバグハンターから脅威のお問い合わせをいただいております。
それによって、社内では検出できないような未知の脅威を発見できることができます。 未知の脆弱性をより早く発見し、改修することを目的として、脆弱性報奨金制度を運用しております。
2014 年の制度開始から、徐々に脆弱性の認定数や報奨金のお支払金額は減少しています。
開始当初は、XSSやSQLiなどの典型的な脆弱性がほとんどでしたが、
現在は典型的な脆弱性の報告は減少し、
Black Hat や AppSec などで報告された事例をサイボウズ製品で横展開して報告されるケースが増えてきました。 脆弱性の報告がどんなふうに認定されているか？と、時間がかかるポイントを説明します。
バグハンターからの報告があると、メールの受付担当者が受付を行います。(スライド進める)
報告は、脆弱性の判定や評価を行うトリアージメンバーに連絡されます。(スライド進める)
トリアージメンバーは、脆弱性が製品で再現できるかを確認し、脆弱性が与える影響を評価します。
脆弱性が与える影響について評価でき、脆弱性が再現できれば受付担当者に連絡します。(スライド進める)
受付担当者は、報奨金額と脆弱性の影響度をバグハンターに連絡します。(スライド進める)
再現出来ない場合には、バグハンターに再現方法について確認する事がありますが、
この流れが最短で脆弱性認定・金額確定できる流れです。
(スライド進める)
長引くケースは、他のベンダーの製品が絡むものだったり、サイボウズ製品の脆弱性とするかどうか判定が難しい報告です。
(スライド進める)
他のベンダーに問い合わせを行う場合は、やり取りに時間がかかります。
(スライド進める)
(スライド進める)
サイボウズ製品の脆弱性とするかどうか、トリアージメンバーだけでは判断できない場合
TLM(スライド進める)という、開発責任者との議論の場で方針を決めます。
ここでも、経緯の説明や脆弱性とするかどうかの相談に時間がかかります。(スライド進める)
この相談のほとんどは kintone を使ってオンラインで行います。
バグハンターから、TLMの相談で想定していなかった影響を指摘された場合は更に時間がかかります。(スライド進める)
サイボウズの脆弱性として判断すると決まった後は、影響の評価を行います。
評価事例のない脆弱性については、どのように評価するかについても時間がかかります。(スライド進める)
こうして、バグハンターの方に報告するのですが。(スライド進める)
内部の状況が見えているわけではないので「何だサイボウズ。評価の連絡遅すぎるだろう。」と思われてしまうのです。。
と言いつつ、少ない人数で切り盛りしていて、他の業務との兼ね合いで時間がかかってしまうのが一番の原因だったりもしますが…。 今回は、その中でも脆弱性として認定するかどうか決定するまでに時間のかかった事例を紹介します。
燃焼？炎上ではなくて？と思った方もいるかもしれません。
最初は炎上にしようかなと思ったのですが。
意味を調べてみたら、(スライド進める)
炎上は「不祥事の発覚をきっかけに、非難が殺到する事態または状況を差す」とのこと。
別に、不祥事とか非難殺到しているわけでもないですし。
弊社としてはバグハンターの方々と良い関係を築けているし築いていきたいと思っています。
というわけで、他の燃えてそうな言葉で良いものがないかなと探したところ(スライド進める)
「燃焼」の
(スライド進める)
「力の限りを尽くすこと」を見てこれだと言うことで、時間のかかった事例を燃焼度として図ることにしました。
こちらの3つの事例を燃焼度としてランク付けしていきます。
認定・評価に尽力したものは、ここに挙げたものだけではありませんが今回はこの 3件をピックアップして紹介します。 次にCSRF 対策に関する報告です。こちらは、
2016-05-08 ～ 2016-06-01 1カ月
2016-04-13 ～ 2016-07-13 3カ月
の、計 4か月ほどの対応になりました。
CSRF とは、例えば掲示板サイトに攻撃者がクリックを誘導するような罠のURLを投稿します。
被害者がそのリンクをクリックすると、被害者が使っているサイトに対して予期せずに設定の変更をさせられてしまうようなものです。
リンクをクリックすることで設定を変更にされないようにトークンを付けて対策を行いますが、(スライド進める)
同一の方よりトークンを付けるべき箇所を40件以上ご報告いただきました。 報告いただいた中には、CSRFトークンをつけなくても良さそうな箇所があったため、
製品としてCSRFを対策する箇所をどこにするか議論しました。
具体的には、ログイン処理やデータやユーザー認証を変更するような処理を対策することとしています。
認定しない処理としては、ログアウト処理や、通知の既読処理などGETで副作用的にデータの変更がある処理や、UIの状態を保持するためのデータを変更する処理が該当します。
対策範囲をバグハンターに連絡し、一部が脆弱性として認定できないことを納得いただけました。
これでめでたしめでたし。(スライド進める)
とおもったら…。
------
脆弱性に対する対策が必要な個所（Scope）
データに変更を及ぼす処理について、CSRF 対策を必要とします。
CSRF 対策が必要となる API の例
ユーザーのログイン
サーバー内データおよびユーザーの認証を変更するAPI
脆弱性として認定しない理由
以下の処理はサーバー内データを更新する処理ではありますが、 攻撃による被害が想定されにくいため、脆弱性として認定しません。
ログアウト処理
GETで副作用的にデータの変更がある API（例：通知の既読処理）
UI の状態を保持するためのデータを変更する API（例：フォルダの開閉処理） ※ アクセス権に関連する設定を除く 別のバグハンターから、自分にも CSRFの判断基準について情報をいただけないかと問い合わせをいただきました。(スライド進める)
バグハンターの方々の情報収集力すごいです。
しかし、すでに脆弱性を報告いただいたバグハンターには連絡していますが
このまま、個別にご連絡していくと公平性を書いてしまうことになります…。(スライド進める) 全てのバグハンターの方が平等に脆弱性の認定情報を参照できるようにガイドラインを作成することになりました。
現在は 4件のガイドラインを公開しております。
ただ、このガイドライン…
どこに公開するか、誰が公開するか、どんなふうに公開するかの調整に長く時間をいただいてしまい…
公開までに、3ヶ月かかってしまいました。
ご連絡頂いたバグハンターの方には、ご迷惑をおかけしました。 と、時間はかかりましたが。
無事ガイドラインの公開によってCSRF対策範囲の問題を解決することができました。
また、ご連絡いただいたおかげで制度の公平性にもつながりましたので、ご要望も制度の改善にとっては大事なお問い合わせです。(スライド進める) 次は、PDF Formcalc Attack という、脆弱性の報告についてです。
こちらは、認定には至りませんが影響の大きい攻撃手法として JVN にて テクニカルアラート が公開されています。
https://jvn.jp/ta/JVNTA94087669/
弊社の対応としても、 2016-02-15 ～ 2016-11-18 9カ月 となかなかの燃焼度でしたので★4としております。
PDF Formcalc Attack は、PDF ファイルがアップロードされているオリジンで任意のリクエストを発行可能な攻撃です。
被害者が、利用しているサイトで罠サイトに誘導するようなURLをクリックした場合、(スライド進める)
攻撃用のPDFが埋め込まれたサイトが開き、(スライド進める)
PDF 内に書かれたJSによって任意のリクエストが発行されます。
--------
◇ 参考情報
「PDF FormCalc Attack」はAdobe社が開発した演算言語であるFormCalcを利用した攻撃手法で、 APPSEC EU 2015でAlexander Inführ氏によって公開されました。
PDF –Mess with the web
https://2015.appsec.eu/wp-content/uploads/2015/09/owasp-appseceu2015-infuhr.pdf
その他参考資料
Multiple PDF Vulnerabilities - Text and Pictures on Steroids
http://insert-script.blogspot.jp/2014/12/multiple-pdf-vulnerabilites-text-and.html Adobe 社に問い合わせたところ、
クロスオリジンでリクエストを送信できる問題（CVE-2014-8453）はAdobe社によって修正されているが、 同一オリジン内でリクエストを送信できる点については、Adobe社より、脆弱性としないという見解をいただきました。 この問い合わせ内容と併せてTLMでPDF Formcalc Attack を弊社製品の脆弱性として扱うかどうかを議論しました。
結果として、脆弱性として認定しないことになりました。
理由としては、弊社製品に限らず、ファイルを自由にアップロードできるようなアプリケーション全般で発生するもので、
PDF ファイルを表示するAdobe Reader の問題だからということと、
ログインできない外部のユーザーからは攻撃可能な PDF ファイルをダウンロードするようなURLは推測困難だからという点です。
ですが、情報としては社内での対策が必要な物として対応することになりました。 TLM での決定をバグハンターに伝えたところ(スライド進める)
同一オリジンへの攻撃は、Adobe社にとっては仕様になるため、サイト側での対応を行うべきだとご指摘頂きました。 指摘いただいた内容を持って、再度 TLM で議論したところ
認めて長期的な課題として対処することになりました。
コンテンツを分離しても、formcalcで分離された添付ファイルをダウンロードし放題なので、程度問題
緩和策：
コンテンツを分離する 評価をどうするか、トリアージチームで議論しXSSと同様の攻撃となるためXSSの指標に沿って評価し、
バグハンターに連絡しました。(スライド進める) しかし、評価結果について多方面から
XSS とは攻撃方法が異なる脆弱性のため、別途評価するべきとご指摘をいただきました。 再評価したところ、非常に影響度の高い脆弱性となり、TLMで再度議論になりました。
社内で調査したところ、formcalc については、Adobe Reader Plugin が有効になっている場合に発生するものとわかりました。
非互換な仕様変更に伴うユーザーへの説明コストが高く、ユーザーにとっても負担が大きい。特にオンプレミス版では別オリジンの設定を行うことが困難。
再現する環境の条件が限定的（他社製品の利用が前提となる）
この二点から脆弱性としての認定を取り下げることとしました。
PDF fromcalc Attack の影響については、大きいものであることは変わらないため、
制限事項として弊社からガイドラインを公開し、ユーザーにはAdobe Reader Plugin は無効化することを推奨をアナウンスすることとしました。 PDF fromcalc Attack について、JPCERT/CC へ注意喚起を掲載してほしい旨を相談しました。
JPCERT/CC では、JVN(Japan Vulnerability Notes)に対して、事故があった場合や、ベンダ等から報告される影響度の高い攻撃手法等を掲載(注意喚起)することができます。
無事、注意喚起が公開されました。 今回のように、認定しないからと行って脅威にならないとは限らないものもあります。
脆弱性として認定しない場合でも、利用するユーザーにとって脅威になる攻撃はあり、サイボウズ内だけではなく JPCERT/CC のような公的機関と連携している企業との連携も大事です。 次に RFD という、脆弱性をご紹介します。
こちらは、2016-02-04 ～ 2016-03-17 13カ月ほど時間がかかりました。
Reflected File Download 略して RFD です。
攻撃者の入力値をが含まれる レスポンスを、指定したファイル名でファイルをダウンロードさせて、
ユーザがファイルを開くことで任意のコマンドを実行させる攻撃です。
RFD は、Reflected File Download の三つの要素が条件となります。
Reflected -ユーザーの入力した値がレスポンスに反映される
File – URL に任意の文字列を追加でき、尚且つ正常にロードされる
Download -ダウンロードが可能であり、上記 2 つの要素がダウンロードしたファイルに反映される
-----
◇ 定義 (1) Reflected some user input is being “reflected” to the response content. This is used to inject shell commands. -> 何らかのユーザーの入力値がレスポンスコンテンツに反映される。これは Shell コマンドをインジェクトするために利用される。 (2) Filename the URL of the vulnerable site or API is permissive, and accepts additional input. This is often the case, and is used by attackers to set the extension of the file to an executable extension. -> 脆弱なサイトのURL や API は許容的で、追加の入力を受け入れる。これは多くの場合、攻撃者がfileの拡張子を実行可能な拡張子に変更することに利用される。 (3) Download the response is being downloaded and a file is created “on-the-fly” by the Web browser. The browser then sets the filename from (2). -> レスポンスがダウンロードされることで、ブラウザによってファイルは「on-the-fly」で作成される。ブラウザはファイルネームを (2) に変更する。
◇ 参考情報
Reflected File Download a New Web Attack Vector
https://drive.google.com/file/d/0B0KLoHg_gR_XQnV4RVhlNl96MHM/view
Reflected File Download - A New Web Attack Vector (SpiderLabs® Blog)
https://www.trustwave.com/Resources/SpiderLabs-Blog/Reflected-File-Download---A-New-Web-Attack-Vector/
Reflected File Downloadの問題(タイガーチームセキュリティレポート)
http://www.tiger1997.jp/report/activity/securityreport_20141114.html
RFD 2015(Hack Patch!)
https://shhnjk.blogspot.jp/2015_12_01_archive.html 動作を確認し、トリアージメンバーで評価を行います。
弊社は、脆弱性を CVSS を使って評価しています。
CVSSは、FIRSTが主幹となって策定しているオープンな評価手法です。
CIA の評価をダウンロードされた後の実行内容まで評価するかどうかで議論になりましたが、特に問題なく評価完了し
脆弱性をプロダクトに連絡しました。 評価の連絡後、TLM で RFD についての質問がありました。(スライド進める)
RFD の脆弱性を評価するまでは、特に脆弱性を認定するかどうかの議論場がなかったため
トリアージ担当が四苦八苦しながら評価しておりました…。
RFD をきっかけに、TLM で判断の難しい脆弱性については議論することになりました。
質問に対して、バグハンターより連絡を頂いていたリスクについて説明します。(スライド進める)
------------------------------
◇ 脅威となるシナリオについて
RFD単体ではなく、他の脆弱性と組み合わせることにより、リスクが増加する可能性があります。
下記の記事に記載されている手法を参照し、
https://www.trustwave.com/Resources/SpiderLabs-Blog/Reflected-File-Download---A-New-Web-Attack-Vector/
RFDでダウンロードさせたファイルを、SOPを無効にして立ち上げたChromeで実行させ、Cookieの盗み出しを行う攻撃が
サイボウズ製品で実行可能という報告をいただいています。 TLM 上での議論の結果、
RFDの脆弱性によって、DLされたファイル（＝攻撃用ファイル）がもたらす影響については評価せず、
予期しないファイル名でダウンロードされてしまう点をRFDとして評価することとなりました。
具体的には、I の
・予期しないコンテンツが挿入されたファイルの生成
・本来ダウンロードするファイルのファイル名を詐称
と A の
・意図せず大容量のファイルをダウンロードさせられる可能性
が対象になります。
(スライド進める)
こちらの内容で評価をバグハンターに連絡しました。 ところが、バグハンターへの報告後、RFD について再議論が発生しました。
トリアージメンバーから、何を脆弱性とするかについて説明を行います。
トリアージメンバーからの説明とは、違う観点で決着がつきました。 バグハンターに、報告いただいたうちの幾つかは認定できない旨を連絡しましたが、(スライド進める)
Reflected は「何らかのユーザーの入力」で、クエリパラメータに限定されるものではない旨ご指摘をいただき再々度の議論となりました。 TLM での議論で、Reflected のユーザーの入力した値をどこまでとするかを議論となりました
サイボウズ製品ではURL以外にもユーザーの使い方によっては攻撃者が入力しやすいフィールドあります。
他社製品との連携等でどのように入力が行われるか不明なため、Reflected については満たされる可能性があります。
しかし、個々で評価を行う場合にはコストが大きくなります。
また、Filename に関しては、任意にファイル名を変更される事自体は望ましい挙動ではありません。
その為、RFD を満たしたものについては、脆弱性として認定することとなりました。 バグハンターへ評価をご連絡し、(スライド進める)
対応完了の了承を頂きました。(スライド進める)
-----
サイボウズの対応方針
ファイルダウンロードの共通仕様をContent-Disposition: attachmentの場合はファイル名を必須とすることに変更する
ファイル名をUTF-8からsjis-winに変換して、変換できずに代替文字（〓）に置き換えられる文字が発生する場合は、 filename を notitle.拡張子 または、代替文字置き換えとする
RFD の問い合わせは長い時間がかかりましたが、ファイルに関する製品の共通しようの取り決めにつなげることが出来ました。
燃焼系の脆弱性に関するご紹介は以上です。 弊社では、来年も引き続き脆弱性報奨金制度を運用していく予定です。
また、セキュリティエンジニアの採用も行っております。ご応募お待ちしております。
