RSSWordPress.orgご注文はユーザの情報ですか?Tweet今回は、Flashを使い罠ページにアクセスしてきたユーザの外部サイト上のデータを取得することが出来た話について書きます。本検証は4月末には終了していたのですが諸事情により情報の公開が遅れてしまいました。した攻撃の条件は以下のようになります。・攻撃者が作成したswfファイルをターゲットのサーバにアップロード出来ること(この時、拡張子は何でも良い)・そのファイルがダウンロードされずブラウザに表示されること・ファイルがアップロードされたドメイン上に重要な情報が存在すること(CSRFトークン、ユーザの非公開情報等)シナリオvuln.moeドメインにランダムな値をCookieに付与する以下の様なページがあります。http://vuln.moe/web/other/random.php次に攻撃者は、以下の様なActionScriptのコードを書きます。Value:」という文字列が存在する行を取得します。攻撃者はこのActionScriptをコンパイルしswfファイルを作成します。この時、vuln.moeドメインにファイルのアップロード機能があるWebアプリケーションが存在したとします。(今回面倒だったのでそういったアプリケーションは作りませんでしたすいません・・・。)勿論そういった機能が無いサービスもあります。最近のサービスだと、物にもよりますがプロフィール画像アップロード機能があるサービスが多いかと思うのでこの条件は容易にクリアできるかと思います。ここで攻撃者はこのswfファイルをアップロードする訳ですが、例えば画像アップロードサービスでswfファイルをアップロードさせてくれるサービスは少ないかと思います。この時、拡張子は「jpg」でも構いません。ちなみに「txt」でも動く事を確認したのでswfファイルの拡張子は何でもいいんですかね。攻撃者は、swfファイルをevilflash.jpgという名前にリネームしてターゲットのサーバにアップロードします。evilflash.swf->evilflash.jpg尚、さっきも言ったようにファイルアップロード機能を作るのが面倒だったので今回は既にファイルがアップロードされていることにします。皆さんの脳内で上記のActionScriptはevilflash.jpgという名前になってvuln.moeドメイン上にアップロードされたということにしておいて下さいwvuln.moe/web/evilflash.jpg次に攻撃者は自分の管轄のサーバに以下のようなHTMLファイルをアップロードします。このコードは攻撃者がアップロードしたswfファイルにアクセスします。id="evilSwf"></div></body></html>ここで一度サーバのファイル構成を確認してみましょう。vuln.moe(標的のサーバ)web/other/random.php(ランダムな値をCookieに付与するPHPコード)リンクweb/evilflash.jpg(攻撃者がアップロードしたswfファイルの拡張子だけを変えたもの)リンクnootropic.me(攻撃者の管轄サーバ)poc/steal_flash.html(攻撃者がアップロードしたswfファイルにアクセスするためのhtmlファイル)リンクユーザは、vuln.moeにあるweb/other/random.phpにアクセスします。http://vuln.moe/web/other/random.phpこの時、ユーザのブラウザにはtestという名前のcookieが付与されます。私が試した際は以下の様な値のtestというCookieが付与されました。ここで攻撃者は、ユーザを自身の管轄サーバに設置したhtmlファイル(steal_flash.html)にアクセスさせます。http://nootropic.me/poc/steal_flash.htmlすると以下の様にアクセスしてきたユーザのvuln.moeドメインのCookieが出力されます。今回は表示だけですが、flashのコードを書き換えれば攻撃者のサーバに対しユーザのブラウザに出力された値を投げてやることが出来るかと思います。末尾に</div>があることから分かるようにhtmlコード自体を取得することが出来るのでCSRFトークン等の通常ブラウザに表示されることが無いデータを盗むことも可能です。この</div>に関してはあと少し正規表現を工夫することで取得しないで済むと思いますのでその辺は適当に。対策ですが、以下のレスポンスヘッダを付与することによって画像がブラウジングされずダウンロードされる為、swfのコードが実行されることはありません。filename="image.jpg"普通に画像を表示させたい場合ですが、アップロードされたファイルの拡張子チェックだけでは今回のようにswfをjpgに書き換える事で容易にそのチェックを回避することが可能です。その為、「アップロードされたファイルのマジックナンバーが不正な場合はファイルのアップロードを拒否する」などといった対策を行うといいかもしれません。あとは、ユーザのアップロードしたファイルは全く別のドメインにアップロードさせるか、サブドメインを切り、そちらにアップロードさせるという方法もあります。file.vuln.moe(ユーザがアップロードしたファイルの置き場所)vuln.moe(ユーザの重要なデータの置き場所)これで通常、クロスドメイン制約によりfile.vuln.moeドメインにアップロードされたファイルからvuln.moeの情報にアクセスをすることが出来ません。サブドメインを切る場合はcrossdomain.xmlに注意してください。以下の様なcrossdomain.xmlがvuln.moe直下にある場合はどのサブドメインからもアクセスが行われます。通常を強調したのはこういう理由です。domain="*.vuln.moe"/></cross-domain-policy>もしくは、以下の様なcrossdomain.xmlファイルがあると最悪です。いかなるドメインからもアクセスが行われます。この場合、全く別ドメインにファイルをアップロードさせても今回の攻撃が可能です。domain="*"/></cross-domain-policy>なので、管理者の方はcrossdomain.xmlの内容に問題がないか(ユーザがアップロードしたファイルが存在するドメインからのアクセスを受け付けていないか)どうかの確認をすることをオススメします。crossdomain.xmlには面白い話もあります。サイトAとサイトBが存在したとします。サイトAにはファイルアップロード機能がありませんがcrossdomain.xmlでサイトBからのアクセスを許可しています。サイトBにはファイルアップロード機能が存在し、ファイルチェックが甘く拡張子を変えただけのswfファイルのアップロードが出来てしまいます。この場合、サイトBに悪意のあるファイルをアップロードすれば結果としてサイトAに対しても攻撃を行うことが可能です。自分のサイトがファイルアップロードに対して厳しくチェックを行っていたとしても外部のサイトが脆ければ自分のサイトにまで被害が及ぶことになります。本当・・・crossdomain.xmlの記述は慎重に(と言っても外部サイトのファイルアップロードのチェックが緩いかどうかなんて実際にファイルをアップロードしなけりゃ分かりませんね)。ところで大変無知で申し訳ないんですが、この攻撃の名前は何て名前なんですかね。Scripting)とか?是非、何か名前が欲しいところです。名前が無ければXSASでwとにかくXSSやSQLインジェクションとは違い、日本語はおろか英語の情報もほとんど無い攻撃手法でした。今回の攻撃は、その気になればDOMの操作なども出来るんじゃないかと考えています。皆さんも是非色々試してみてください。CTFのような競技にも問題で使えるんじゃないかと思いました。KinugawaMasato様のブログでは、以下の様にFlashに関連する攻撃が紹介されています。よるクロスオリジンの情報奪取これは本ブログで紹介している攻撃手法とは異なり、攻撃難度の高いものですが非常に興味深いものです。Flashはまだまだ奥が深く、今後は他の人が更に掘り下げてくれるんじゃないかと期待しています。