エンコーディングと セキュリティ 徹底調査 - XSS Allstars from Japan - Masato Kinugawa

自己紹介 脆弱性発見者(フリー)

調べた経緯 エンコーディングに関わるセキュリティ 問題が頻繁に発見されている が、網羅的に調査したという報告はきい たことがない 日本でははせがわようすけ氏による研究が有名 が、網羅的に調査したという報告はきい たことがない 手法は少しずつでてくるが…他は安全？ 　➡がっつり全部自分で見てみよう！

収穫の一部 Chrome/Safari (CVE-2011-3058) Bad interaction possibly leading to XSS in EUC-JP Firefox (CVE-2012-0477) Potential XSS through ISO-2022-KR/ISO-2022-CN decoding issues (CVE-2012-4207) Improper character decoding in HZ-GB-2312 charset (CVE-2013-5612) Character encoding cross-origin XSS attack IE (CVE-2012-1872) EUC-JP Character Encoding Vulnerability (CVE-2013-0015)(CVE-2013-3166) Shift JIS Character Encoding Vulnerability Opera(Presto) (CVEなし) Some invalid EUC-TW sequences causes read outside of allocated memory

ページ構造が期待しない形になり XSSが起こる 　エンコーディングを使った 　　　　　　攻撃おさらい ページ構造が期待しない形になり XSSが起こる <script src=http://victim charset=***></script>な どで中身を読み出す ポイントは普段使われないエンコーディングも攻撃 者側で指定できること 変わりものがサポートされていると中身を有効に読み出せ る形になるかもしれない

Content-Type: text/html; charset=*** 開発者がすべきこと Content-Type: text/html; charset=*** HTTP Response Headerでの指定を推奨

やったこと 1. 各ブラウザのエンコーディングのサ ポート状況を調査 2. サポートされているエンコーディン グをブラウザに表示させ様々なテスト 3. テスト結果を踏まえ攻撃に利用でき ないか検討

やったこと 1. 各ブラウザのエンコーディングのサ ポート状況を調査 2. サポートされているエンコーディン グをブラウザに表示させ様々なテスト 3. テスト結果を踏まえ攻撃に利用でき ないか検討

かき集めたエンコーディング名っぽい 文字列をブラウザが識別するか見る サポート状況の調査 かき集めたエンコーディング名っぽい 文字列をブラウザが識別するか見る UTF-8 UTF8 unicode-1-1-utf-8 UTF-9 … (2500個以上のエンコーディングっぽい文字列) 正式名 分類 エイリアス (正式名を指す別名) 識別不可 調査方法の詳細は: http://masatokinugawa.l0.cm/2013/03/browser-support-encodings-list.html

注： l0 = L Zero 結果 多数の普段使わないエンコーディン グがサポートされていた 正式名とエイリアスの一覧 http://l0.cm/encodings/list/ ブラウザごとのサポートの一覧 http://l0.cm/encodings/table/ 注： l0 = L Zero

Chromeの例(計52個) Big5 Big5-HKSCS BOCU-1 CESU-8 EUC-JP EUC-KR GB18030 GBK HZ-GB-2312 IBM864 ISO-2022-CN iso-2022-CN-EXT ISO-2022-JP ISO-2022-KR ISO-8859-1 ISO-8859-10 ISO-8859-13 ISO-8859-14 ISO-8859-15 ISO-8859-16 ISO-8859-2 ISO-8859-3 ISO-8859-4 ISO-8859-5 ISO-8859-6 ISO-8859-7 ISO-8859-8 ISO-8859-8-I KOI8-R KOI8-U macintosh SCSU Shift_JIS US-ASCII UTF-16BE UTF-16LE UTF-32 UTF-32BE UTF-32LE UTF-8 Windows-1250 Windows-1251 Windows-1252 Windows-1253 Windows-1254 Windows-1255 Windows-1256 Windows-1257 Windows-1258 Windows-874 x-mac-cyrillic x-user-defined

IEの例(計139個!) x-iscii-gu x-iscii-ka x-iscii-ma x-iscii-or x-iscii-pa x-iscii-ta x-iscii-te x-mac-arabic x-mac-ce x-mac-chinesesimp x-mac-chinesetrad x-mac-croatian x-mac-cyrillic x-mac-greek x-mac-hebrew x-mac-icelandic x-mac-japanese x-mac-korean x-mac-romanian x-mac-thai x-mac-turkish x-mac-ukrainian x-user-defined _autodetect_kr asmo-708 Big5 cp1025 cp866 cp875 csiso2022jp DOS-720 DOS-862 EUC-CN EUC-JP EUC-KR GB18030 GB2312 HZ-GB-2312 IBM00858 IBM00924 IBM01047 IBM01140 IBM01141 IBM01142 IBM01143 IBM01144 IBM01145 IBM01146 IBM01147 IBM01148 IBM01149 IBM037 IBM1026 IBM273 IBM277 IBM278 IBM280 IBM284 IBM285 IBM290 IBM297 IBM420 IBM423 IBM424 IBM437 IBM500 IBM737 IBM775 IBM850 IBM852 IBM855 IBM857 IBM860 IBM861 IBM863 IBM864 IBM865 IBM869 IBM870 IBM871 IBM880 IBM905 IBM-thai ISO-2022-JP ISO-2022-KR ISO-8859-1 ISO-8859-13 ISO-8859-15 ISO-8859-2 ISO-8859-3 ISO-8859-4 ISO-8859-5 ISO-8859-6 ISO-8859-7 ISO-8859-8 ISO-8859-8-I ISO-8859-9 Johab KOI8-R KOI8-U ks_c_5601-1987 macintosh Shift_JIS Unicode UnicodeFEFF US-ASCII UTF-7 UTF-8 Windows-1250 Windows-1251 Windows-1252 Windows-1253 Windows-1254 Windows-1255 Windows-1256 Windows-1257 Windows-1258 Windows-874 x-chinese-cns x-chinese-eten x-cp20001 x-cp20003 x-cp20004 x-cp20005 x-cp20261 x-cp20269 x-cp20936 x-cp20949 x-cp21027 x-cp50227 x-cp50229 x-ebcdic-koreanextended x-ia5 x-ia5-german x-ia5-norwegian x-ia5-swedish x-iscii-as x-iscii-be x-iscii-de

余談 一通りみてもやはりUTF-7が凶悪 一般にエスケープの必要がない文字列だけであらゆる文字 を表現できる エンコーディング絡みのバグがあった際に真っ先に使える サポートしているのは現在IEのみ IE11でもまだサポート… (Microsoftいわく12では削除を検討中とのこと) IEはUTF-7が圧倒的に危険なため他の考えられる手法を脆弱 性と呼ぶ段階にない… +ADwAcwBjAHIAaQBwAHQAPgBhAGwAZQByAHQAKAAxACkAPAAvAHMAYwByAGkAcAB0AD4-

やったこと 1. 各ブラウザのエンコーディングのサ ポート状況を調査 2. サポートされているエンコーディン グをブラウザに表示させ様々なテスト 3. テスト結果を踏まえ攻撃に利用でき ないか検討

過去に問題になった挙動を参考にテス トを作成 テストを実施 過去に問題になった挙動を参考にテス トを作成 {TEST1} 特定バイトが特別な文字を作る [0xBC]script[0xBE] ➡ <script> {TEST2} 特定バイトが後続の文字を破壊する <p id="abc[0xE0]"> ➡ <p id="abc[U+FFFD]> {TEST3} 特定バイトが無視される <scri[0x80]pt> ➡ <script>

テストの大まかな方法 char_fuzzと呼んでいるテスト PerlでベースのHTMLを作って各エ ンコーディング・各ブラウザでラ ンダムにバイト列を表示 表示された状態をJavaScriptで確認 ( 異常が無ければ 　リロードして繰返す )

「"&'<>\」(0x22 0x26 0x27 0x3C 0x3E 0x5C)を除いたバイト列をランダムに 表示する TEST-1 特殊文字の検出 「"&'<>\」(0x22 0x26 0x27 0x3C 0x3E 0x5C)を除いたバイト列をランダムに 表示する 特殊文字の有無を確認 あれば別のバイトから特殊文字が 現れたと判断

TEST-1 結果の一部 ブラウザ charset バイト 出現文字 Chrome/Safari （CVE-2011-3058） EUC-JP 0x8EE3 \ Safari (OS X) x-mac-korean 0xA179 < と U+F877 0xA178 > と U+F877 x-mac-chinesetrad 0x80 \ と U+F87F x-mac-japanese IE (CVE-2012-1872) 0x8FEBBD U+4E57 と \

TEST-2 後続の文字を潰す バイト値の検出 バイト列をランダムに表示する その直後に<tag>を配置しておく <tag>の有無を確認 なければ直前のバイト列に 破壊されたと判断 [バイト列]<tag>

TEST-2 結果の一部 ブラウザ charset 潰すバイト 潰すバイト数 Firefox (CVE-2012-0471) EUC-JP 0x8F 2 HZ-GB-2312 0x7E or [0x80-0xFF] 1 GB2312 [0x81-0xFE][0x30-0x39] GBK GB18030 T.61-8bit [0xC0-0xCF]

<img>要素の途中にバイト列をはさむ TEST-3 無視されるバイト値の検出 <img>要素の途中にバイト列をはさむ <img>要素の有無を確認 存在すれば挟んだバイト列を無視した と判断 <im[0x90][0x80]g src=x> <im[0x90][0x81]g src=x> <im[0x90][0x82]g src=x> ……

TEST-3 結果の一部 ブラウザ charset 無視されるバイト Chrome/Safari HZ-GB-2312 ~} or ~[0x0A] Firefox ISO-2022-JP 0x1B284A IE X-ISCII-AS [0xEF][0x40-0x4B] X-ISCII-DE X-ISCII-BE X-ISCII-KA X-ISCII-GU X-ISCII-PA X-ISCII-MA X-ISCII-TA X-ISCII-OR X-ISCII-TE

すべてのテスト結果 http://l0.cm/encodings/

やったこと 1. 各ブラウザのエンコーディングのサ ポート状況を調査 2. サポートされているエンコーディン グをブラウザに表示させ様々なテスト 3. テスト結果を踏まえ攻撃に利用でき ないか検討

更なる攻撃への応用 ブラウザのAnti-XSS機能のBypass エンコーディング切替えのSelf-XSS

Anti-XSS機能のBypass (Chrome) エンコーディング指定がな いページで回避できた！ (IE) <meta http-equiv>でエンコーディ ング指定があっても回避できた！

Chromeのケース ~}

IEのケース <meta http-equiv>でcharset指定有、XSS有のページ http://example.com?q=<meta charset=utf-7> <img src=x o+AG4- error=alert(1)>&<meta http-equiv=> <me#a http-equiv="Content-Type" content="text/html;charset=utf-8"> … <meta charset=utf-7><img src=x o+AG4-error=alert(1)> UTF-7のページになって フィルタを回避できてしまう！

エンコーディング 切替えのSelf-XSS ブラウザはエンコーディングを切 りかえるための設定を持っている

Oh 細工されたページで使うと…

<script>x="く\";alert(1)//"</script> XSSが起こる原理 UTF-8 <script>x="く\";alert(1)//"</script> Shift_JIS <script>x="縺十";alert(1)//"</script> 　 同じバイト列で違う表現 Shift_JISにきりかえ

脆弱性ではないけれど charset指定の有無にかかわらず起きる アプリ側での対応は複雑になる HTMLの構造をcharsetが変えられても危険にならない形にする などで一応は対応できる セキュリティ問題が起きることの一般 ユーザの想像の難しさ ブラウザベンダには一応問題提起として 報告 でも機能を無くしたら文字化け時に困るし… FirefoxアドオンのNoScriptは検出可

エンコーディングを利用した攻撃は 新しい技術に対しても起きうる まとめ 古くからある技術にも脆弱性はある 単純なテストで見つかる エンコーディングを利用した攻撃は 新しい技術に対しても起きうる Anti-XSS機能×エンコーディング CSP×エンコーディング 今後も研究を続けていきます！