ホモグラフ攻撃は、実在のドメインに使われている文字と見た目はまったく同じだが実際には異なる文字 - たとえばラテン文字の「a」の代わりにキリル文字の「a」を使う、といった具合の文字 - からドメインを組み立てて登録する手口であり、人が読むアドレスとブラウザが名前解決するアドレスは、まったく別のものになる。この手口が成立するのは、ドメインネームシステムが ASCII しか理解できないためであり、非 ASCII のドメインはすべて、DNS に触れる前に punycode と呼ばれる ASCII 形式へと変換され、xn-- プレフィックスが付けられる。ブラウザはそれを表示のために読みやすい形式へとデコードし直すが、まさにそのデコードの段階にこそ、この欺瞞が潜んでいる。
最近のブラウザは、明らかなケースを検知し、ラベルが疑わしい形でスクリプトを混在させている場合には生の punycode を表示するようフォールバックするようになっており、10年前には通用していた簡単な攻撃のほとんどを封じている。しかし、その保護はブラウザのアドレスバーの外には及ばない。
私は仕事柄ブランドなりすましの事例を日常的に見ているが、出来のよい偽物は、見破れる決め手に気づくまでの半瞬、今でも私の目を引く。この記事では、ホモグラフ攻撃がどのように機能するか、ブラウザの防御がどこで途切れるか、そしてそれに対して何をすべきかを扱う。あなたがまさにリンクをクリックしようとしている立場でも、なりすまされている側のドメインを所有している立場でも関係ない。短縮リンクそのものが信頼できるかというより広い問いについては、URL 短縮サービスは安全かがその領域を扱っている。この記事が扱うのは、リンクの下に実際に存在するドメインについてだ。
punycode とは何で、なぜ存在するのか
DNS は ASCII 用に作られた、それに尽きる。世界のほとんどの文字体系を構成する、アクセント記号付きの文字やキリル文字、アラビア文字、中国語の文字を、ネイティブに保存する手段を持たない。これは、ドメイン登録が英語圏以外の市場にも開放された瞬間に、現実の問題となった。
punycode はその解決策だ。RFC 3492として標準化された可逆エンコーディングであり、Unicode のラベルを、ワイヤープロトコルを一切変更することなく DNS が運べる ASCII の文字・数字・ハイフンへと変換する。ウムラウト付きのドメインを登録するドイツのパン屋も、キリル文字でドメインを登録するウクライナの小売業者も、内部的には単なる別の ASCII ラベルにすぎないため、他のドメインとまったく同じように名前解決される、実用的な国際化ドメイン名を手にすることになる。エンコードされた形式は必ず xn-- で始まり、「これは punycode であり、人間に見せる前にデコードせよ」という意味を伝える。
ここまでの話自体には、脆弱性は何もない。国際化ドメイン名は本物の、必要な機能であり、誰かが無効化すべき回避策の類ではない。問題が始まるのはその一段上、ブラウザがデコードした名前をどう表示するか決定する瞬間だ。
ホモグラフ攻撃はどのように機能するか
ホモグラフ攻撃は、ドメインが実際に含んでいる内容と、レンダリングされた後の見た目との間のギャップを悪用する。実際に見られる手口には2種類あるが、その発生頻度は同じではない。
全体スクリプト型は、標的のブランドに文字の形がたまたま似ている非ラテン文字体系で、ドメイン全体を登録する。ラベル全体が異質であるため、作るのが目立ちやすく、防御側にとっても検知しやすい。
実際に使われるのは混合スクリプト型のほうだ。必要な置き換えが1文字だけで済むからだ。novacloud.com のようなドメインを考えてみよう。ラテン文字の "o" を、見た目が同一のキリル文字 "о" (U+043E) に置き換えると nоvacloud.com になる - 形も長さも同じだが、コードポイントが異なり、エンコードすると xn--nvacloud-nbh.com になるドメインだ。ラベルの他の部分は一切変更されないため、目にはほとんど引っかかる部分がない。セキュリティ研究者はこの種のよく似た文字ペアを "confusable" と呼び、そのうちのほんの一握りでラテンアルファベットの大半をカバーできてしまう。
ドメインを登録してしまえば、あとは普通のフィッシングだ。ピクセル単位でコピーされたログインページ、なりすましリンクへ誘導する緊急性を煽るメッセージ、そして完璧に正しく見えるアドレスを疑う理由が何もない標的、という組み合わせになる。
現在、ブラウザは何をしているのか
ブラウザベンダーは何年も前に、1つのラベル内でどのスクリプトの組み合わせを許可するかというルールによって、この攻撃の簡単なバージョンのほとんどを封じ込めた。Chrome のポリシーはその IDN 処理ガイドに文書化されており、ラベル内のすべての文字が単一のスクリプトに、あるいは日本語の漢字とひらがなのように正当に併用される少数のスクリプトの組み合わせに、もっともらしく属しているかどうかを確認する。この許可された組み合わせの外でスクリプトを混在させると、ブラウザはそれをデコードせずに生の xn-- 形式のまま表示する - この攻撃の最大の武器である「完全に普通に見えるドメイン」が、あからさまにエンコードされた文字列へと戻ってしまうわけだ。Firefox もMozilla の IDN 表示アルゴリズムに記載された同様のチェックを実行しており、Safari も独自のバージョンを適用している。
これは完全な保護ではない。許可された組み合わせの中だけの文字で構成された混合スクリプトのラベルは、それでも読みやすい欺瞞的な名前としてすり抜けてしまう可能性があり、しかもこのルールはブラウザごとに個別に実施されていて、何を安全とみなすかを決める共通の権威は存在しない。
その保護が及ばない範囲
このスクリプト混在チェックは、ブラウザのアドレスバーの描画コードの中だけに存在する。URL がどこか他の場所へ移動しても、このチェックは一緒についていかない。まさにこのギャップにおいて、なりすましドメインは今なお実害を及ぼす。
最大の露出源はメールクライアントだ。メッセージは宛先が何であれ、リンクの上に任意のアンカーテキストを表示でき、ほとんどのメールアプリは confusable のチェックをまったく行わない。チャットアプリは、共有されたリンクを punycode を意識したレンダラーではなく、ページのメタデータから作られたプレビューカードへと展開する。QR コードはテキストという段階そのものを取り除いてしまう。このギャップについてはQR コードは安全かで扱っている。印刷物に至っては、目と欺瞞との間にソフトウェアの層が一切存在しない。
| チャネル | 行動前に実際の宛先を表示するか | 典型的な露出度 |
|---|---|---|
| 最近のデスクトップブラウザ | 通常は表示する（スクリプト混在ルールによる） | 一般的なブラウザでは低く、最新の状態が保たれている |
| メールクライアント | ほとんど表示しない - アンカーテキストには何でも書ける | 高い、特にモバイルのメールアプリで |
| チャット・メッセージングアプリ | ほとんど表示しない - リンクプレビューはページのメタデータを使う | 高い、リンクの展開表示が見分けられない |
| QR コード | 表示しない - スキャンするまで何もレンダリングされない | 高い、一瞬で判断が必要になる |
| 印刷物 | 決して表示しない - ソフトウェアが一切関与しない | 最も高い、技術的なチェックが不可能 |
あなたのチームが、顧客がすでに認識しているドメインの下でリンクを送っていれば、なりすました偽ドメインが、これらすべてのチャネルにわたって同時に説得力を持って模倣できる余地は大きく減る。共有ドメインや汎用ドメインからリンクを送っているなら、Elido のカスタムブランドドメインの仕組みを見るとよい。
ブランドドメインが最良の防御である理由
ホモグラフ攻撃は、親近感を悪用することで成立する - 偽造するには、認知度の高いブランドが必要だ。これは、自社の認知度の高いドメインを作ることに反対する論拠のように聞こえるかもしれないが、実際はその逆だ。あなたのオーディエンスがすでにあなたと結びつけて認識している、独自性のあるブランド短縮リンクは、彼らが不審なメッセージと見比べる基準になる。一方、汎用的な、あるいは借り物のショートナードメインは、攻撃者にひな形を与えてしまう。顧客はどのみち、それを本物のプロバイダーと区別できない。どちらも「あなた」らしくは見えないからだ。
短縮リンク用のカスタムドメインを設定するということは、送信するすべてのリンクが受信者にとって見覚えのある名前を持つということであり、それを偽造しようとする者にとってのハードルが上がる。これは、リンクを自社ドメイン経由でルーティングするという意図的で開示された選択であるリンククローキングと URL マスキングとは区別する価値がある。ホモグラフ攻撃はその逆の動きだ - 攻撃者自身の正体を隠しながら、あなたになりすます - そして、その防御策となるのは、どのドメインが本当に自分のものかについての透明性である。
実際に重要なレジストラの制御機能
保護する価値のあるドメインを所有したら、実質的な作業のほとんどを担うのは2つの制御機能であり、それぞれスタックの異なるレベルで動作する。
registrar lock（レジストラロック）は日常的に使われるほうの制御で、多くの場合 clientTransferProhibited として表示されるステータスフラグであり、自分のレジストラのダッシュボード内での通常の自動移転リクエストをブロックする。実際に使っているすべてのドメインで有効にしておくべきであり、コストは一切かからない。registry lock（レジストリロック）はもう一段上に位置し、レジストリオペレーターに直接働きかけることで、あらゆる変更・移転・削除が発効する前に、電話や安全なパスフレーズによる帯域外での手動検証を必須にする。この手間をかける価値があるのは、不正な変更が本当に高くつく1つか2つのドメインに限られ、ほとんどの企業にとっては少なくとも主要なブランドドメインがそれに該当する。
どちらのロックも、誰かがあなたのドメインとよく似たドメインを登録すること自体は防げない。それには能動的な監視が必要だ。新規ドメイン登録や公開されている certificate transparency ログを継続的に監視し、自社ブランドと見た目が近い名前を見つけたら、それを使ったキャンペーンが誰かに届く前にレジストラへ報告したり顧客に警告したりできるようにしておく。
ブランド保護ポリシーに盛り込むべきこと
なりすましの標的になり得るドメインを所有しているなら、ブランド保護ポリシーのセキュリティセクションは、チームに新しく加わった人がまずあなたに確認しなくても実行できるくらい具体的であるべきだ。
- 会社が所有するすべてのドメインに registrar transfer lock をかけ、主要なブランドドメインおよび決済やログインを扱うものには registry lock も追加する。
- 自社ブランドと見た目が近い名前がないか、新規ドメイン登録と certificate transparency ログを定期的なペースでスキャンする。一度きりのチェックにはしない。
- 主要ドメインとの類似度に応じて優先順位をつけ、正当化できる範囲でリスクの高いよく似たラベルや紛らわしいトップレベルドメインを防衛的に登録する。
- 発見した見た目そっくりの偽ドメインをレジストラに報告するための責任者とエスカレーション経路を定め、顧客から報告があった際にサポート担当者がそのパターンを認識できるよう社内向けの手引きも用意する。関連するベンダーの制御については、リンクプロバイダー選定のセキュリティチェックリストで扱っている。
誰でも実践できる検証の手順
リンクを安全にチェックするために、punycode を理解している必要はない。順番通りに行う4つのステップで、ホモグラフ攻撃が頼りにしているもののほぼすべてを見抜ける。
- まずリンクを直接クリックせずに展開する。短縮 URL の行き先を確認する方法ではそのためのツールを紹介しており、Elido 自身のリンクチェッカーも、宛先をまず信頼するよう求めることなく同じことを行ってくれる。
- その前に現れる部分ではなく、registrable domain（トップレベルドメインの直前の部分）を読む。そこは攻撃者が完全に制御しなければならない部分だ。
- 展開した生の URL、あるいはブラウザのアドレスバーに xn-- プレフィックスがないか確認する。ふつうのブランド名を期待していた場所にそれを見つけたら、いったん止まり、そうでないと証明されるまで見た目そっくりの偽ドメインとして扱う。
- 宛先サイトの証明書名を確認する。証明書はドメイン所有者に実際に発行されたものを反映しており、レンダリングされたラベルよりも説得力のある形で偽造するのがはるかに難しい。
これらのステップはいずれも、習慣になってしまえば数秒もかからず、技術に詳しくない同僚にも、このセクションを一度読む程度の時間で4つとも教えられる。
ホモグラフ攻撃とは、セキュリティの衣装をまとった表示上の問題である。punycode は設計された通りのことを正確に行っているにすぎない。欺瞞が生じるのは、ドメインの実体と、ソフトウェアが代わりに見せるものとの間のギャップにおいてだ。ブラウザはアドレスバーについてはそのギャップの大半を塞いだ。それ以外の場所では、ギャップは今なお開いたままであり、だからこそ、リンクを展開して registrable domain を読むという習慣が、どのチャネル経由でリンクが目の前に現れたかにかかわらず有効であり続ける。
ブログ関連記事
よくある質問
IDN ホモグラフ攻撃とは何ですか？
IDN ホモグラフ攻撃とは、実在のドメインに使われている文字と見た目がほぼ同じ、あるいは完全に同じに見える、別の文字体系の文字を使ってドメインを登録する手口であり、読み手は見た目だけでは両者を区別できない。典型的なケースでは、ドメイン内の1文字だけをラテン文字からキリル文字やギリシャ文字のよく似た文字に置き換える。たとえばラテン文字の a をキリル文字の a に置き換えるといった具合で、ドメインの残りの部分はまったく変更されない。置き換えられた文字は内部的に異なるコードポイントを持つため、2つのドメインは技術的には別物であり、それぞれ異なる所有者が登録・管理できる。この攻撃は純粋に見た目だけで成立するため、無名のブランドではなく、誰もが知っていて信頼している有名ブランド名が標的になる。
punycode とは何で、なぜ存在するのですか？
punycode とは、非 ASCII のドメインラベルを、ドメインネームシステムが保存・名前解決できる ASCII 文字列に変換するエンコーディングであり、RFC 3492 で定義されている。DNS が扱える文字集合は限られた ASCII のみであるため、キリル文字、アラビア文字、中国語、あるいはアクセント記号付きのラテン文字で書かれたドメインは、名前解決の前にこの形式へ変換する必要がある。エンコードされたラベルは必ず xn-- プレフィックスで始まり、これはリゾルバーやブラウザに対して、続く文字列が単なる ASCII 名ではなく punycode でエンコードされた文字列であることを伝える。ブラウザはその後、表示のために元の文字体系へとデコードし直すが、これは正当かつ必要な機能であり、それ自体が脆弱性というわけではない。
URL 内の xn-- プレフィックスは何を意味しますか？
xn-- プレフィックスは、そのドメインラベルが punycode によって生成された ASCII Compatible Encoding であることを示し、読みやすい名前が非 ASCII 文字から変換されたことを表す。プレフィックスの後に続くのはすべて、元のラベルをエンコードした形式である。たとえば xn--nvacloud-nbh.com は、1文字がよく似た文字に置き換えられた novacloud.com のように見えるドメインへとデコードされる。ふつうのブランド名を期待していた場所に xn-- 形式が表示されるのは、まさにブラウザが警告のために使う手がかりであり、それはそのラベルが、ブラウザが見た目のよいバージョンとして描画するのは安全でないと判断した形でスクリプトを混在させていたことを意味する。非 ASCII 文字を含まないドメインは決して xn-- 形式にはならないため、xn-- を見かけたら必ずもう一度確認する価値がある。
ブラウザはホモグラフ攻撃から保護してくれますか？
最近のブラウザは、スクリプト混在に関するルールを適用しており、ほとんどのホモグラフ攻撃を検知して、欺瞞的な表示の代わりに生の punycode 形式を表示するようフォールバックする。Chrome と Firefox はどちらも、ドメインラベルの文字が単一のスクリプトに、あるいは一緒に使われることが一般的な少数のスクリプトの組み合わせに、もっともらしく属しているかどうかを確認し、そうでない場合は、見慣れたブランド名に見えるものへデコードするのではなく xn-- 形式のまま表示する。これにより、もっとも単純な全体スクリプト型の攻撃が説得力のある偽物として表示されることは防げるが、攻撃者は許可されたスクリプト集合の中からラテン文字と見た目が紛らわしい文字を見つけ出すことがなおも可能である。この保護もブラウザのアドレスバーだけに厳密に限定されており、スタック内の他の部分はそれを自動的に引き継がない。
クリックする前に、リンクが見た目そっくりの偽ドメインかどうかを見分けるにはどうすればよいですか？
まずリンクを展開して、短縮版や省略版ではなく完全な宛先を確認し、その前に来る部分ではなく registrable domain（登録可能ドメイン）を読む。アドレスバーや展開ツールが、ふつうのブランド名を期待していた場所に xn-- プレフィックスを表示した場合は、そうでないと証明されるまで見た目そっくりの偽ドメインとして扱う。宛先サイトの証明書名を確認するのは有用な最終チェックであり、証明書は単に表示されているものではなく、実際に発行されたものを反映しているからだ。これらはいずれも特別なソフトウェアを必要としない。パスワードやカード番号を入力する前にこれを行う習慣を持つだけでよい。
registry lock とは何で、自分のドメインに必要ですか？
registry lock とは、ドメインレジストリのレベルで設定される制御であり、通常は電話や安全なパスフレーズによる帯域外での手動検証が行われるまで、ドメインへのあらゆる変更・移転・削除をブロックするもので、レジストラアカウントが乗っ取られた場合でもドメインの移動を防ぐ。これは、より一般的な registrar lock（レジストラロック）よりも強力な保証であり、registrar lock は自分のレジストラのダッシュボード内での通常の自動移転のみを防ぐものにすぎない。registry lock は、ダウンタイムや乗っ取りが高くつくドメインであれば、年間のわずかなコストに見合う価値があり、ほとんどの企業にとっては少なくとも主要なブランドドメインがそれに該当する。ただし、自分のドメインとよく似たドメインを誰かが登録すること自体は防げない。それは監視によって解決すべき別の問題であり、ロックで解決するものではない。
Elidoを試す
URLを貼り付けて短縮リンクを取得
登録不要。リンクは30日間有効。永久に保存するには登録してください。
Free、登録不要 · 1日あたり2件