Upload
alyssa-clarke
View
54
Download
0
Embed Size (px)
DESCRIPTION
エンコーディング と セキュリティ 徹底調査. - XSS Allstars from Japan -. Masato Kinugawa. 自己紹介. 脆弱性発見者 ( フリー ). 調べた経緯. エンコーディングに関わるセキュリティ問題が頻繁に発見されている 日本でははせがわようすけ氏による研究が有名 が、網羅的に調査したという報告はきいたことがない 手法は少しずつでてくるが … 他は安全? ➡ がっ つり全部自分で見てみよう!. 収穫の一部. Chrome/Safari - PowerPoint PPT Presentation
Citation preview
エンコーディングとセキュリティ徹底調査
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× エンコーディング
今後も研究を続けていきます!