Black Hat Japan 2008 未踏の文字コード×セキュリティを開拓長谷川陽介氏

　2008年10月9日に開催されたBlack Hat Japan 2008で、「趣味と実益の文字コード攻撃」というテーマでネットエージェント株式会社の長谷川陽介氏が発表した。長谷川氏はアプリケーション側の文字コード処理に関するバグを利用したり、文字コードや文字を巧みに操作することで、Webアプリケーションなどに対して攻撃を行うことが可能だと示した。

●Unicodeへの移行期に起きている混乱

　Unicodeは世界で使われる全ての文字を使える文字コードという発想で作られたもので、日本では従来はEUC-JPやShift_JISなどの文字コードが使われていたが、徐々にUnicodeに移行している。その移行期である現在、従来の文字コードとUnicodeとの差違がセキュリティ的な問題を生んでいる。

　安全な文字列の確認や危険な文字列の検出といった、文字列を比較して処理するというセキュリティの基本処理において問題が起きる可能性があることを指摘した。

　UTF-8では、同じ文字を冗長な形式で表すことができるという特徴がある。たとえば、「/（スラッシュ）」という文字は「0x2F」で表されるが、2Byteの冗長な表現で記述すると「0xC0 0xAF」と記される。3Byteなら「0xE0 0x80 0xAF」といった具合だ。これらはすべて同じ文字「/（スラッシュ）」を表す。

　2000年頃にはこのUTF-8の冗長な表現を利用した脆弱性、MS00-057「正規化エラーによる、ファイルへの誤ったアクセス権の適用」というIIS4.0、5.0に対する脆弱性があり、一時期は話題となった。この脆弱性は8年も前のものであり、すでに化石となった攻撃手法のはずだった。

　しかし、2008年8月にCVE-2008-2938「Apache Tomcat UTF-8 Directory Traversal Vulnerability」という、UTF-8の冗長表現を利用したディレクトリ・トラバーサルの脆弱性が発見された。そしてこれは、8年前に起きたMS00-057とほとんど同じUTF-8の冗長表現が原因で起きていたのだ。

　こういった冗長な表現は現在はUTF-8の仕様で禁止されている。もし、UTF-8を実装する必要に駆られたときには、自前でUTF-8を実装するべきではない。

　また、UTF-8には大文字と小文字の扱い方の差違や、文字の分解や合成機能による見た目が同じだがバイト列が異なる表現といった特徴がある。そのため、文字列を検査した後に文字コードを変換したり、正規化を行わないことが望ましいと長谷川氏は述べる。

●サーバー側とクライアント側で文字コードの解釈が異なることもある

　文字コードの問題はアプリケーション側だけでなく、ブラウザ自身の問題によっても起こる。

　有名なものにはUTF-7を利用したクロスサイトスクリプティングの脆弱性がある。たとえば、Webページのcharsetが不明瞭なとき、そのページ内に「+ADw-script+AD4- alert(1) +ADw-/script+AD4-」といった文字列が含まれている場合、Internet Explorerは自動的にUTF-7だと解釈してしまう。すると、先ほどの文字列がクライアント側ではJavaScriptの実行命令だと解釈されてしまうのでクロスサイトスクリプティングが発現してしまう。これは、サーバーとクライアント間でcharsetの解釈が異なることが原因で起きている。

　また、先の例と同様のUTF-7の解釈の差違を使った攻撃で、JavaScriptでデータを扱う際によく使われるJSONを奪うことができてしまうJSONハイジャックも可能になる。HTTPレスポンスヘッダにcharsetがない場合、攻撃者がJSONの一部をコントロールすることが可能になり、これによってJSON内のデータを操作することができてしまうこともある。

　これを防ぐためには、ブラウザが理解できるcharsetをHTTPレスポンスヘッダに明記することや、JSONの前に「while(1);」を記載するといったことが必要になる。

●文字コードを巧みに使い、見た目で騙す

　「1 (イチ)」と「l （エル）」をコンピューターで表示したとき、その見た目は似ていることが多い。こういった似ている文字はUnicodeにはかなりの数が存在する。

　たとえば、UTF-8には「/（スラッシュ）」に似た文字として「ディビジョンスラッシュ(u+2215)」という文字がある。これを使って「http://example.co.jp?t.example.com/foo/bar」というようにURLを書くと、一見して「http://example.co.jp」というドメインに見えるが、実は「http://example.co.jp?t.example.com」までがドメイン名だといった騙し方が可能になる。
(※註：URL内?箇所に、スラッシュに似たディビジョンスラッシュがある)

　またUnicodeの制御文字の中に「Bidi」という双方向機能がある。たとえば、「U+202E (Right-to-Left Override;RLO)」というBidiを使うと、文字列の一部を通常とは逆の右から左に並べることができる。

　このRLOを使って「this-(U+202E)txt.exe」というファイル名にすると…

【執筆：株式会社トライコーダ上野宣 ( http://www.tricorder.jp/ )】

【関連記事】
Black Hat Japan 2008 特別インタビュー
ダン・カミンスキーに聞く、DNS脆弱性が示唆するものこれから来るもの(1)
https://www.netsecurity.ne.jp/3_12304.html
Black Hat Japan 2008 特別インタビュー
ダン・カミンスキーに聞く、DNS脆弱性が示唆するものこれから来るもの(2)
https://www.netsecurity.ne.jp/3_12341.html
Black Hat Japan 2008 GIF＋JAR＝GIFARファイルでドメインベースの信頼は破
壊される　ネイサン・マクフィーター氏
https://www.netsecurity.ne.jp/3_12364.html
──
※ この記事は Scan購読会員向け記事をダイジェスト掲載しました
購読会員登録案内 http://www.ns-research.jp/cgi-bin/ct/p.cgi?w02_ssw