エンコーディングとセキュリティ徹底調査

Masato Kinugawa- XSS Allstars from Japan -

自己紹介

脆弱性発見者 ( フリー )

調べた経緯

エンコーディングに関わるセキュリティ問題が頻繁に発見されている日本でははせがわようすけ氏による研究が有名

が、網羅的に調査したという報告はきいたことがない手法は少しずつでてくるが…他は安全？

　➡がっつり全部自分で見てみよう！

収穫の一部

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

VulnerabilityOpera(Presto)

(CVE なし ) Some invalid EUC-TW sequences causes read outside of allocated memory

　エンコーディングを使った　　　　　　攻撃おさらい

ページ構造が期待しない形になりXSS が起こる

<script src=http://victim charset=***></script> などで中身を読み出すポイントは普段使われないエンコーディングも攻撃

者側で指定できること変わりものがサポートされていると中身を有効に読み出せ

る形になるかもしれない

開発者がすべきこと

Content-Type: text/html; charset=***

HTTP Response Header での指定を推奨

やったこと

1. 各ブラウザのエンコーディングのサポート状況を調査

2. サポートされているエンコーディングをブラウザに表示させ様々なテスト

3. テスト結果を踏まえ攻撃に利用できないか検討

やったこと

1. 各ブラウザのエンコーディングのサポート状況を調査

2. サポートされているエンコーディングをブラウザに表示させ様々なテスト

3. テスト結果を踏まえ攻撃に利用できないか検討

サポート状況の調査

かき集めたエンコーディング名っぽい文字列をブラウザが識別するか見る

UTF-8UTF8unicode-1-1-utf-8UTF-9…(2500 個以上のエンコーディングっぽい文字列 )

調査方法の詳細は : http://masatokinugawa.l0.cm/2013/03/browser-support-encodings-list.html

正式名

識別不可

エイリアス( 正式名を指す別名 )

分類

結果

多数の普段使わないエンコーディングがサポートされていた

正式名とエイリアスの一覧http://l0.cm/encodings/list/

ブラウザごとのサポートの一覧http://l0.cm/encodings/table/

注：l0 = L Zero

Big5Big5-HKSCSBOCU-1CESU-8EUC-JPEUC-KRGB18030GBKHZ-GB-2312IBM864ISO-2022-CNiso-2022-CN-EXT

ISO-2022-JPISO-2022-KRISO-8859-1ISO-8859-10ISO-8859-13ISO-8859-14ISO-8859-15ISO-8859-16ISO-8859-2ISO-8859-3ISO-8859-4ISO-8859-5ISO-8859-6

ISO-8859-7ISO-8859-8ISO-8859-8-IKOI8-RKOI8-UmacintoshSCSUShift_JISUS-ASCIIUTF-16BEUTF-16LEUTF-32UTF-32BE

UTF-32LEUTF-8Windows-1250Windows-1251Windows-1252Windows-1253Windows-1254Windows-1255Windows-1256Windows-1257Windows-1258Windows-874x-mac-cyrillicx-user-defined

Chromeの例 (計 52個 )

IEの例 (計 139個 !)

_autodetect_krasmo-708Big5cp1025cp866cp875csiso2022jpDOS-720DOS-862EUC-CNEUC-JPEUC-KRGB18030GB2312HZ-GB-2312IBM00858

IBM00924IBM01047IBM01140IBM01141IBM01142IBM01143IBM01144IBM01145IBM01146IBM01147IBM01148IBM01149IBM037IBM1026IBM273IBM277IBM278IBM280IBM284IBM285

IBM290IBM297IBM420IBM423IBM424IBM437IBM500IBM737IBM775IBM850IBM852IBM855IBM857IBM860IBM861IBM863IBM864IBM865IBM869IBM870

IBM871IBM880IBM905IBM-thaiISO-2022-JPISO-2022-KRISO-8859-1ISO-8859-13ISO-8859-15ISO-8859-2ISO-8859-3ISO-8859-4ISO-8859-5ISO-8859-6ISO-8859-7ISO-8859-8ISO-8859-8-IISO-8859-9JohabKOI8-R

KOI8-Uks_c_5601-1987macintoshShift_JISUnicodeUnicodeFEFFUS-ASCIIUTF-7UTF-8Windows-1250Windows-1251Windows-1252Windows-1253Windows-1254Windows-1255Windows-1256Windows-1257Windows-1258Windows-874x-chinese-cns

x-chinese-etenx-cp20001x-cp20003x-cp20004x-cp20005x-cp20261x-cp20269x-cp20936x-cp20949x-cp21027x-cp50227x-cp50229x-ebcdic-koreanextendedx-ia5x-ia5-germanx-ia5-norwegianx-ia5-swedishx-iscii-asx-iscii-bex-iscii-de

x-iscii-gux-iscii-kax-iscii-max-iscii-orx-iscii-pax-iscii-tax-iscii-tex-mac-arabicx-mac-cex-mac-chinesesimpx-mac-chinesetradx-mac-croatianx-mac-cyrillicx-mac-greekx-mac-hebrewx-mac-icelandicx-mac-japanesex-mac-koreanx-mac-romanianx-mac-thaix-mac-turkishx-mac-ukrainianx-user-defined

余談

一通りみてもやはり 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 で確認 ( 異常が無ければ　リロードして繰返す )

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 0x80 \ と U+F87F

IE(CVE-2012-1872) EUC-JP 0x8FEBBD U+4E57 と \

TEST-2 後続の文字を潰すバイト値の検出

バイト列をランダムに表示するその直後に <tag> を配置しておく

<tag> の有無を確認なければ直前のバイト列に

破壊されたと判断

[ バイト列 ]<tag>

TEST-2 結果の一部ブラウザ charset 潰すバイト 潰すバイト数

Firefox(CVE-2012-0471)

EUC-JP 0x8F 2

HZ-GB-23120x7E

or[0x80-0xFF]

1

GB2312

[0x81-0xFE][0x30-0x39] 2GBK

GB18030

T.61-8bit [0xC0-0xCF] 1

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

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

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× エンコーディング

今後も研究を続けていきます！