Unicode Normalization Attacks: When "admin" ≠ "admin" 🔤

隠れた文字エンコーディングの危険性を理解する

デジタル世界では、見た目がすべてではありません。ユーザー名の “admin” は画面上では同じに見えますが、実際には全く異なるUnicode文字で表現されている可能性があります。これにより、セキュリティフィルターを回避し、偽のドメインを作成し、アカウント乗っ取りを可能にする高度なサイバー攻撃の扉が開かれます。Unicode正規化攻撃の世界へようこそ。視覚的な類似性が悪意のある意図を隠しています。

Unicode正規化攻撃とは？

Unicode正規化攻撃は、多くの文字がUnicode標準内で複数の方法で表現できる事実を悪用します。Unicodeは、ほぼすべての書き言語をサポートする普遍的な文字エンコーディングシステムで、149,000以上の文字を含みます。これらの文字の多くは見た目がほぼ同じか非常に似ていますが、全く異なるコードポイント（コンピュータが文字を識別するための数値）に割り当てられています。

最近のAndroidのセキュリティ脆弱性CVE-2024-43093は、これらの攻撃の実世界への影響を示しています。このゼロデイ脆弱性は、標的型攻撃で積極的に悪用され、Unicode正規化の誤りにより、ファイルパスフィルターを回避し、敏感なディレクトリへのアクセスを防ぐことに成功し、ローカルの権限昇格を引き起こしました。

核心の問題：複数の表現方法

根本的な問題は、Unicodeが文字の等価性をどのように扱うかにあります。Unicode標準は、次の2つのタイプの等価性を定義しています：

正準等価性：見た目と意味が同じ場合、異なるエンコードでも正準的に等しいとみなされます。

互換性等価性：より弱い形で、文字が抽象的に同じ意味を持ち、状況に応じて表示が異なる場合があります。

これらのバリエーションを標準化するために、Unicodeは4つの正規化形式を定義しています：

• NFC (正規化形式：正準合成)：正準的な等価性を用いて文字を合成
• NFD (正規化形式：正準分解)：正準的な等価性を用いて文字を分解
• NFKC (互換性正規化形式：互換性合成)：互換性の等価性を用いて合成
• NFKD (互換性正規化形式：互換性分解)：互換性の等価性を用いて分解

この脆弱性は、アプリケーションが正規化前にセキュリティチェックを行ったり、システムの異なる部分で不一致に正規化したりする場合に発生します。

実世界の攻撃ベクトル

1. UnicodeバイパスによるSQLインジェクション

最も危険な応用の一つはSQLインジェクション攻撃です。Unicode文字の ‘FULLWIDTH APOSTROPHE’ (U+FF07) は、NFKDまたはNFKC正規化を使用すると標準のアポストロフィ (U+0027) に正規化されます。アプリケーションが正規化前に標準のアポストロフィをフィルタリングしている場合、攻撃者は全角バージョンを注入し、フィルターを回避しつつ、正規化後に悪意のあるアポストロフィに変換されます。

攻撃シナリオ例：

オリジナルクエリ: SELECT name, bio from profiles where name like '%chloe%'
攻撃者入力: chloe%uff07 UNION SELECT username, password from users -- 
正規化後: SELECT name, bio from profiles where name like '%chloe' UNION SELECT username, password from users -- %'

この攻撃は、Unicode文字を利用してSQLインジェクションを防ぐ入力フィルターを回避しますが、正規化後には危険なSQL構文に変わります。

2. クロスサイトスクリプティング（XSS）の悪用

類似の脆弱性はXSS防止にも影響します。’SMALL LESS-THAN SIGN’ (U+FE64)や’FULLWIDTH GREATER-THAN SIGN’ (U+FF1E)などの文字は、標準のHTMLタグ区切り文字をブロックするフィルターを回避しつつ、正規化後に<や>に変換され、JavaScriptのインジェクションを可能にします。

攻撃者は次のような入力を送信する可能性があります：

＜img src=x onerror=alert(123)＞

フィルターは標準の<img>タグをブロックしますが、全角Unicodeの同等文字は通過し、正規化後に実行可能なHTMLに変換されます。

3. パストラバーサルとファイルシステム攻撃

2025年、研究者はDNN（旧DotNetNuke）に影響を与えるCVE-2025-52488を発見しました。この脆弱性はUnicode正規化を利用してファイルパスのセキュリティチェックを回避します。攻撃者はUnicode文字U+FF0E（全角ピリオド）やU+FF3C（全角リバースソリッドスラッシュ）を使ったファイル名を作成し、最初の検証を回避しますが、正規化により標準のピリオドやバックスラッシュに変換されます。

これにより、\\example.com\share.jpgのようなUNCパスが作成され、攻撃者制御のサーバーへのWindows SMB接続を引き起こし、NTLM資格情報の漏洩の可能性があります。この攻撃は、DNNの開発者がこの種の脆弱性を防ぐために防御的なコーディングを実装していたにもかかわらず、正規化がセキュリティ検証後に行われることで回避の余地が生まれた点で特に巧妙です。

4. ユーザー名の混乱によるアカウント乗っ取り

Unicode正規化は、ユーザー名の衝突攻撃を引き起こす可能性があります。システムがUnicodeユーザー名の登録を許可し、登録とログインの異なる操作で一貫して正規化しない場合、攻撃者は見た目が同じアカウントを作成できます。

セキュリティ研究者は、SMTPサーバに対するIDNホモグラフ攻撃を実証し、’a’を’á’（アキュートアクセント付きのa）に置き換えることで、あるアカウント向けのパスワードリセットリンクを他のアカウントに乗っ取られる例を示しました。これにレスポンス操作を組み合わせると、完全なアカウント乗っ取りにつながります。

IDNホモグラフ攻撃：ドメイン名の欺瞞

Unicode攻撃の最も顕著な現れの一つは、国際化ドメイン名（IDN）です。IDNホモグラフ攻撃は、多くの異なるスクリプトの文字が見た目が同じであることを悪用します。例えば、キリル文字、ギリシャ文字、ラテン文字の各アルファベットには、「o」の文字があり、見た目は同じですが、それぞれ異なる音を表します。

ドメインスプーフィングの仕組み

これらの攻撃の可能性は、2001年12月にイスラエルのTechnionのEvgeniy GabrilovichとAlex Gontmakherによって最初に記録されました。彼らは、Cyrillic文字を含むmicrosoft.comのバリアントを登録に成功しました。この問題は、2005年2月にセキュリティ研究者の3ric JohansonがShmooconカンファレンスでこのエクスプロイトを実演したことで広く知られるようになりました。

特に危険な文字の組み合わせは、キリル文字のアルファベットに存在します。ターゲットドメインが「ј ѕ і а е о р с у х s」（’s’はマケドニア文字）からなる場合、攻撃者は全く異なるUnicode文字を使ったドメインを登録できます。例えば、оорѕ.comはoops.comと見た目が同じですが、全く異なるUnicode文字を使用しています。

ブラウザの防御と制限

現代のブラウザは、Punycode表示を実装しています。これはUnicode文字をASCII文字列として表現する方法です。潜在的に危険なIDNを検出すると、ブラウザはUnicode表現の代わりにASCIIのPunycodeバージョン（例：xn--n1aag8f.com）を表示します。ただし、これらの保護は一貫していません。

2017年以降、Chrome、Firefox、Operaなどのブラウザは、キリル文字だけのIDNを通常通り表示し、Punycodeに変換しませんでした。Chromeはバージョン59でIDNの制限を強化しました。

Bitdefenderの調査によると、Microsoft OfficeのOutlook、Word、Excel、OneNote、PowerPointは、IDNホモグラフ攻撃に特に脆弱であり、すべてのバージョンで国際ドメイン名を実際のASCII表記の代わりに表示していました。

IDN攻撃の普及

AkamaiのDNSトラフィックの分析により、ホモグラフ攻撃の規模が明らかになりました。32日間で6,670のホモグラフIDNがDNSトラフィックで実際にアクセスされ、平均して毎日67の新規ドメインが検出されました。さらに、調査期間中に少なくとも1つのホモグラフIDNにアクセスしたデバイスは29,071台にのぼり、毎日850台以上が初めてアクセスしています。

新たな脅威：AIとLLMの脆弱性

最近の研究では、Unicodeを利用した攻撃が人工知能システム、特にLarge Language Models（LLMs）にとって増大する脅威であることが示されています。攻撃者は絵文字、ゼロ幅文字、ホモグリフの置換、結合マークを使って悪意のある入力を隠蔽し、AIによるコンテンツモデレーションや入力検証を回避します。

この脆弱性は、LLMsの出力を処理する端末エミュレータにも及びます。LLMsがUnicode操作を通じてANSIエスケープコードを生成すると、攻撃者は端末を乗っ取り、視覚表示を操作し、隠しテキストを挿入し、クリップボードにアクセスすることも可能です。

Emoji Jailbreak

Google Cloudは、「Emoji Jailbreaks」と呼ばれる攻撃を記録しています。これは、トークナイゼーションアルゴリズムの脆弱性やUnicode正規化の変動性を悪用し、敵対的なプロンプトをLLMsに挿入するものです。これらの攻撃は、トークナイゼーションの過程を混乱させ、従来のセキュリティ制御を回避します。

検出と防止策

開発者向け

1. 早期正規化と一貫した検証

最も重要な防御策は、ユーザー入力を受け取ったら直ちに正規化し、その後にセキュリティ検証やフィルタリングを行うことです。これにより、多くのUnicode攻撃を防止できます。

# 正しいアプローチ
user_input = normalize_unicode(user_input)  # 先に正規化
if is_valid(user_input):  # その後検証
    process(user_input)

2. 厳格な文字ホワイトリストの使用

危険な文字のブラックリストの代わりに、各入力フィールドに期待される文字だけをホワイトリスト化します。例えば、ASCII文字だけを許可する場合は、それ以外のUnicode文字を拒否します。

3. 複数段階の検証を実施

処理の各段階で入力を検証し、特に正規化や変換後にセキュリティ境界を再確認します。正規化後にセキュリティチェックを行うのが原則です。

4. フレームワーク固有の特性に注意

Windows上の.NETを使用する場合、ファイルシステム操作にはリスクが伴います。File.ExistsやSystem.Net.HttpRequest、System.Net.WebClientなどの関数は、攻撃者制御のパスを指定するとSMB接続をトリガーし、NTLM資格情報を漏洩させる可能性があります。コードの監査が必要です。

5. 不審なパターンの監視

異常なUnicode文字の入力を検知するためにログを取りましょう。特に以下のような文字列に注意します： - 全角文字 - 結合ダイアクリティカルマーク - ゼロ幅文字 - 複数スクリプトの混在

組織向け

1. 事前ドメイン登録

ブランドを偽装し得るホモグラフドメインを事前に登録しておくことが推奨されます。IDNは文字セットが限定されているため、組み合わせは有限で予測可能です。

2. メール・Webフィルタリング

IDNホモグラフや疑わしいUnicodeパターンを検出・隔離するメールフィルタリングを導入しましょう。メールクライアントには、すべてのIDNのPunycode表記を表示させる設定も有効です。

3. ユーザー教育

URLを確認し、ブラウザのアドレスバーを見てから入力する習慣をつけさせましょう。2025年のフィッシング被害は平均4.88百万ドル、米国では1,022万ドルに達しており、AIによるフィッシング攻撃も年率1,265%増加しています。ホモグラフの偽装は重要な脅威です。

4. 多要素認証の導入

すべてのシステムに多要素認証を実装し、資格情報の盗難を防ぎましょう。仮にホモグラフ攻撃で資格情報を奪取されても、MFAが追加の防御となります。

5. 証明書の監視

証明書透明性ログを監視し、不審なドメイン登録を検知します。攻撃者は有効なTLS証明書を取得し、HTTPSを使用したホモグラフドメインも増加しています。

エンドユーザー向け

1. URLを慎重に確認

入力前にアドレスバーを確認し、次の点に注意しましょう： - 異常な文字やダイアクリティカルマーク - Punycode表記（xn--で始まる） - ドメインの綴りのわずかな違い

2. URLを手入力

銀行や重要なサイトにアクセスする際は、リンクをクリックするのではなく、URLを手入力しましょう。タイポスクアッティングはユーザーの誤りに頼りますが、ホモグラフ攻撃は慎重なクリックでも成功します。

3. ブラウザのセキュリティ機能を利用

最新のブラウザのフィッシング保護機能を有効にし、IDNホモグラフ検出を強化しましょう。ブラウザは常に最新に保ちます。

4. 信頼できるサイトをブックマーク

頻繁にアクセスする重要サイトはブックマークしておき、ホモグラフ偽装のリスクを排除します。

高度な防御：AIシステム向けUnicodeサニタイゼーション

「Black Box Emoji Fix」は、LLMシステム向けの革新的な防御手法です。この方法は、NFKC（互換性合成）を用いた包括的なUnicode正規化、グラフェムクラスター分析、多層フィルタリング技術を統合し、Unicodeを利用したインジェクション攻撃を無効化します。

このアプローチは、次の段階で機能します： 1. 危険なUnicode文字を含むグラフェムクラスターを安全な文字列に置換 2. 設定によって絵文字を除去または置換 3. トークン爆発攻撃を検出するためのカスタマイズ可能なトークナイザの導入 4. Unicodeカテゴリ分析に基づく拡張フィルタリングの適用

Unicodeセキュリティの未来

国際化がインターネット全体に拡大する中、Unicode攻撃は進化し続けます。グローバル言語のサポートとセキュリティの維持の間には常に緊張関係があります。今後の課題は次の通りです：

AIと機械学習のターゲット：LLMsの普及に伴い、Unicodeを利用したプロンプトインジェクションや jailbreak技術が進化します。

IoTデバイスの脆弱性：処理能力の限られたIoTデバイスは、一貫性のないUnicode正規化を行い、新たな攻撃面を生み出します。

サプライチェーンのリスク：サプライヤーや顧客、パートナーの通信を狙ったホモグラフ攻撃は、ビジネスメール詐欺の高度化につながる可能性があります。

ゼロ幅・不可視文字：攻撃者はゼロ幅結合子やゼロ幅非結合子などの不可視Unicode文字を利用し、悪意のあるペイロードを隠蔽します。

結論：視覚層での警戒

Unicode正規化攻撃は、国際化とセキュリティの交差点における根本的な課題です。Unicode文字の視覚的類似性は、グローバルなコミュニケーションに役立つ一方で、文字の一致やフィルタリングに依存するセキュリティシステムにとっては危険なものとなります。

これらの攻撃から身を守るための重要な教訓は次の通りです：

1. 見た目を信用しない—常にプログラム的に正規化と検証を行う
2. 正規化前に検証—未正規化の入力に対するセキュリティチェックは無効
3. 複数の表現が存在することを想定—任意の文字には多くのUnicodeの等価表現がある
4. 防御を重ねる—単一の対策だけでは不十分
5. 情報を常に更新—新たな攻撃技術はUnicodeの進化とともに出現

開発者、セキュリティ専門家、エンドユーザーを問わず、「admin」が常に「admin」とは限らないことを理解することが重要です。Unicodeの世界では、見た目と実際のコードポイントは異なる場合があり、その差異が重大なセキュリティ侵害の入り口となり得ます。

見た目が同じでも、裏に隠された違いが深刻なリスクをもたらすことを忘れずに。視覚的な欺瞞に対抗するには、認識と警戒心、そしてコードポイントの深い理解が必要です。サイバーセキュリティの世界では、見た目だけに頼るのは危険です。

---

キーワード: Unicode正規化攻撃, ホモグラフ攻撃, IDNスプーフィング, サイバーセキュリティ, SQLインジェクション, XSS攻撃, アカウント乗っ取り, フィッシング, ドメイン偽装, 文字エンコーディング脆弱性, LLMセキュリティ, Unicodeセキュリティ, 国際化ドメイン名, Punycode, CVE-2025-52488, NTLM資格情報窃盗, パストラバーサル攻撃