Deep in 国際化ドメイン名 Security.Tokyo #1 2023/02/22

自己紹介 影白 ● 最近の趣味 ○ React書いたり ○ ボードゲームしたり ○ ダイエット

CVE-2021-43533 URL Parsing may incorrectly parse internationalized domains （国際化ドメイン名の不適切なURLパース） Firefox 94で修正 https://www.mozilla.org/en-US/security/advisories/mfsa2021-48/

国際化ドメイン名 (IDN: Internationalized Domain Name) ● ドメインをUnicodeに拡大 ○ 日本語、ドイツ語、絵文字…… ○ 「日本語ドメイン名」などと表記されることも ● 近年では、ソシャゲ攻略サイトなどで使用例あり （○○攻略.comなど）

Unicodeはとにかく複雑 絵文字、サロゲートペア、結合文字、異体字セレクタ 言語や文化ごとの事情 ● 異言語、異文化のことは理解しにくい ● 組み文字、絵文字、筆記体　　㋿ 🉅 〠Ⓐ𝒷　 ● トルコ語やドイツ語では大文字小文字の対応が特殊な文字がある ○ I⇔ı　İ⇔i　　小さいIや、でっかいiが存在 ○ ßの大文字は「SS」

PunyocdeとUラベル、Aラベル 旧来のプロトコルとの互換性のためのアルゴリズムが規定

国際化ドメイン名の自由度 国際化ドメイン名の表記はかなり自由度が高い ● 利便性を確保するための正規化処理 ● 従来の非Unicodeなドメイン名も対象 ○ http://𝓂。ⓙⓟ → http://m.jp ○ http://⑭.₨→http://14.rs

国際化ドメインに起因する諸問題

ホモグラフ攻撃 似た字形の偽ドメイン 　　0とO　mとrn 　　Latin a (U+0041)とCyrillic а (U+0430) ブラウザの緩和策 　→文字種を混合したらAラベル表記 (根本的な解決には至っていない） 日本語同士でも区別がつかない文字 ロ口　日曰　柿杮　 引用 ：https://thehackernews.com/2017/04/unicode-Punycode-phishing-attack.html

スパムフィルタのバイパス 利用料の請求です http://evil。example.com 本文中にURLはない! 利用料の請求です http://evil。example.com 自動リンク . (U+002E)を。(U+3002)に書き換えたメールを送信 BLOCK 利用料の請求です http://evil.example.com ブラックリストに該 当あり

URLの解釈とUnicode正規化 正規化によって別のドメインと解釈 İ → i　　トルコ語の大文字iを英字iにしてはダメ 正規化によって特定文脈のメタ文字が出現 ℀ → a/c ⒈ → 1. ” → " ＇ → ' XSSやSQLインジェクションにつながらないように注意

HostSplit ホスト名の検証と不正な正規化による脆弱性 　http://evil.c℀.office.com　 ℀(U+2100)は正規化するとa / c ● 機能A: office.comのサブドメイン ● 機能B: evil.ca/c.office.com .office.comのサブドメインだと認識し、 機密情報をevil.caに送信してしまう BlackHat USA2019で脆弱性の報告があった [引用]Jonathan Birch. Host/split: Exploitable antipatterns in unicode normalization, August 2019. Black Hat USA 2019.

CVE-2021-43533 URL Parsing may incorrectly parse internationalized domains （国際化ドメイン名の不適切なURLパース） Firefox 94で修正 https://www.mozilla.org/en-US/security/advisories/mfsa2021-48/

URLパーサは本当に信用できるのか 独自のURLパーサや正規表現ではバグや考慮漏れが出やすいのは周知の事実 ● 認証部のパースや検出が不適切　[email protected] ● 終端解釈を誤る　　　　　　　　example.com\aaaa 言語公式のURLパーサや、著名なパーサを使おう →本当に大丈夫？

URLパーサは本当に信用できるのか 独自のURLパーサに不具合が出やすいのは周知の事実 ● 認証部のパースや検出が不適切　[email protected] ● 終端解釈を誤る　　　　　　　　example.com\aaaa 言語公式のURLパーサや、著名なパーサを使おう →本当に大丈夫？ 国際化ドメイン名の解釈は統一されていない オプションの指定によってはHostSplitや、予期せぬバグが存在することも 仕様が複雑すぎて、バグの検証も難しい

Q:以下のURLを、ブラウザはどのように解釈する？ http://󰬣.com http://xn--あああ.com new URL("http://󰬣.com").hostname

http://󰬣.com ChromeではU+200D(ゼロ幅接合子)を削除して処理 Firefoxは200Dを削除せずに処理 Safariはエラー xn--qq8hq8f.com xn--1ugz855p6kd.com エラー

http://xn--あああ.com

http://xn--あああ.com 　xn--bbb.com エラー 　xn--BBB.com

http://xn--あああ.com UTF-16の上位バイトが無視される！！ あ(U+3042)　→　B (U+0042) 　xn--bbb.com エラー 　xn--BBB.com

URLの解釈を誤るとどのような問題が起こるのか ……実は具体的な被害の想定が難しい ● 「xn--あああ.example.com」が入力できる場所には「evil.example.com」だって入 力できる ● 「予期しないホスト名と一致する」ことは脆弱性だが「一致しない」ことで起こる脆弱 性は少ない “example.com” !== “EXAMPLE.COM”　　←脆弱ではない ● 考えられること ○ フィッシングや検出回避 ○ ドメインが一致することを期待した処理　 →ある…？ ○ 機能間の解釈の違いを悪用する →発見が難しい 見つかりそうな箇所のアイデアがあれば教えてください。

● 絵文字をimgタグに置き換えて表示するサービス ● 絵文字を含むドメイン名の考慮漏れで、href属性の中身が破壊される ● 変な壊れ方をするとXSS等につながる危険 正常な表示 壊れた表示 ソース タ.example.com"> おまけ：絵文字の考慮漏れ

おまけ：正規化漏れ ● 正規化処理が不完全なパターン ○ 絵文字やUnicodeの処理が誤っていたり ● 🈂のような字を正規化せずにAラベルにしてしまうケース ○ ブラウザ等と解釈が異なる ○ スパムフィルタや解析サービスのバイパス ● xn--677hをUラベルにして🈂と表示してしまうケース ○ ドメインを誤認させられるかも …（？）

おまけ：不適切な変換 https://evil%FF.example.jp/ ↓不適切なUTF-8が、「?」に変換されてしまう https://evil?.example.jp/ 同様にエンコーディングの変換等で危険な文字を出力してしまう処理系も存在

まとめ ● 国際化ドメインは極めて複雑 ○ 実装はバグだらけ ○ Uniform Resource IdentifierでIdentifyできる幻想を捨てよう！ ● バグまみれでも脆弱性には直結しにくい ○ FQDNを完全一致で見ていることが多い ○ Host/Splitにだけは要注意 ■ パーサのオプション次第では普通に直撃する