やったこと - l0.cm

Download Report

Transcript やったこと - l0.cm 

エンコーディングと
セキュリティ
徹底調査
- 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が起こる
<script src=http://victim charset=***></script>な
どで中身を読み出す
ポイントは普段使われないエンコーディングも攻撃
者側で指定できること
変わりものがサポートされていると中身を有効に読み出せ
る形になるかもしれない
開発者がすべきこと
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
結果
多数の普段使わないエンコーディン
グがサポートされていた
正式名とエイリアスの一覧
http://l0.cm/encodings/list/
ブラウザごとのサポートの一覧
http://l0.cm/encodings/table/
注：
l0 = L Zero
Chromeの例(計52個)
Big5
ISO-2022-JP
Big5-HKSCS
ISO-2022-KR
BOCU-1
ISO-8859-1
CESU-8
ISO-8859-10
EUC-JP
ISO-8859-13
EUC-KR
ISO-8859-14
GB18030
ISO-8859-15
GBK
ISO-8859-16
HZ-GB-2312
ISO-8859-2
IBM864
ISO-8859-3
ISO-2022-CN
ISO-8859-4
iso-2022-CN-EXT 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
_autodetect_krIBM00924 IBM290 IBM871
KOI8-U
asmo-708
IBM01047 IBM297 IBM880
ks_c_5601-1987 x-cp20001
x-iscii-pa
Big5
IBM01140 IBM420 IBM905
macintosh
x-cp20003
x-iscii-ta
cp1025
IBM01141 IBM423 IBM-thai
Shift_JIS
x-cp20004
x-iscii-te
cp866
IBM01142 IBM424 ISO-2022-JP Unicode
x-cp20005
x-mac-arabic
cp875
IBM01143 IBM437 ISO-2022-KRUnicodeFEFF
x-cp20261
x-mac-ce
csiso2022jp
IBM01144 IBM500 ISO-8859-1 US-ASCII
x-cp20269
x-mac-chinesesimp
DOS-720
IBM01145 IBM737 ISO-8859-13 UTF-7
x-cp20936
x-mac-chinesetrad
DOS-862
IBM01146 IBM775 ISO-8859-15 UTF-8
x-cp20949
x-mac-croatian
EUC-CN
IBM01147 IBM850 ISO-8859-2 Windows-1250 x-cp21027
x-mac-cyrillic
EUC-JP
IBM01148 IBM852 ISO-8859-3 Windows-1251 x-cp50227
x-mac-greek
EUC-KR
IBM01149 IBM855 ISO-8859-4 Windows-1252 x-cp50229
x-mac-hebrew
GB18030
IBM037
x-chinese-eten
x-iscii-or
GB2312
IBM857 ISO-8859-5 Windows-1253 x-ebcdic-koreanextended x-mac-icelandic
IBM1026 IBM860 ISO-8859-6 Windows-1254 x-ia5
x-mac-japanese
HZ-GB-2312
IBM273
IBM861 ISO-8859-7 Windows-1255 x-ia5-german
x-mac-korean
IBM00858
IBM277
IBM863 ISO-8859-8 Windows-1256 x-ia5-norwegian
x-mac-romanian
IBM278
IBM864 ISO-8859-8-IWindows-1257 x-ia5-swedish
x-mac-thai
IBM280
IBM865 ISO-8859-9 Windows-1258 x-iscii-as
x-mac-turkish
IBM284
IBM869 Johab
Windows-874
x-iscii-be
x-mac-ukrainian
IBM285
IBM870 KOI8-R
x-chinese-cns
x-iscii-de
x-user-defined
余談
一通りみてもやはりUTF-7が凶悪
一般にエスケープの必要がない文字列だけであらゆる文字
を表現できる
エンコーディング絡みのバグがあった際に真っ先に使える
サポートしているのは現在IEのみ
IE11でもまだサポート…
(Microsoftいわく12では削除を検討中とのこと)
IEはUTF-7が圧倒的に危険なため他の考えられる手法を脆弱
性と呼ぶ段階にない…
+ADwAcwBjAHIAaQBwAHQAPgBhAGwAZQB
yAHQAKAAxACkAPAAvAHMAYwByAGkAcAB0
AD4-
やったこと
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
\
0xA179
< と U+F877
0xA178
> と U+F877
x-mac-chinesetrad
0x80
\ と U+F87F
x-mac-japanese
0x80
\ と U+F87F
EUC-JP
0x8FEBBD
U+4E57 と \
x-mac-korean
Safari
(OS X)
IE
(CVE-2012-1872)
TEST-2 後続の文字を潰す
バイト値の検出
バイト列をランダムに表示する
その直後に<tag>を配置しておく
[バイト列]<tag>
<tag>の有無を確認
なければ直前のバイト列に
破壊されたと判断
TEST-2 結果の一部
ブラウザ
Firefox
(CVE-2012-0471)
charset
潰すバイト
潰すバイト数
EUC-JP
0x8F
2
HZ-GB-2312
0x7E
or
[0x80-0xFF]
1
GB2312
GBK
[0x81-0xFE][0x30-0x39]
2
GB18030
T.61-8bit
[0xC0-0xCF]
1
TEST-3 無視されるバイト
値の検出
<img>要素の途中にバイト列をはさむ
<im[0x90][0x80]g src=x>
<im[0x90][0x81]g src=x>
<im[0x90][0x82]g src=x>
……
<img>要素の有無を確認
存在すれば挟んだバイト列を無視した
と判断
TEST-3 結果の一部
ブラウザ
charset
無視されるバイト
Chrome/Safari
HZ-GB-2312
~}
or
~[0x0A]
Firefox
ISO-2022-JP
0x1B284A
X-ISCII-AS
X-ISCII-DE
X-ISCII-BE
X-ISCII-KA
IE
X-ISCII-GU
X-ISCII-PA
X-ISCII-MA
X-ISCII-TA
X-ISCII-OR
X-ISCII-TE
[0xEF][0x40-0x4B]
すべてのテスト結果
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+AG4error=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にきりかえ
Shift_JIS
<script>x="縺十";alert(1)//"</script>
同じバイト列で違う表現
脆弱性ではないけれど
charset指定の有無にかかわらず起きる
アプリ側での対応は複雑になる
HTMLの構造をcharsetが変えられても危険にならない形にする
などで一応は対応できる
セキュリティ問題が起きることの一般
ユーザの想像の難しさ
ブラウザベンダには一応問題提起として
報告
でも機能を無くしたら文字化け時に困るし…
FirefoxアドオンのNoScriptは検出可
まとめ
古くからある技術にも脆弱性はある
単純なテストで見つかる
エンコーディングを利用した攻撃は
新しい技術に対しても起きうる
Anti-XSS機能×エンコーディング
CSP×エンコーディング
今後も研究を続けていきます！