慌てる必要はありません。Googleが恐ろしい.zipや.movドメインを提供しているからといって、世界が終わるわけではありません。

Table of Contents

慌てる必要はありません。Googleが恐ろしい.zipや.movドメインを提供しているからといって、世界が終わるわけではありません。

コメント5 月初旬、Google Domains は 8 つの新しいトップレベル ドメインのサポートを追加しましたが、そのうち 2 つ (.zip と .mov) はセキュリティ コミュニティの反発を招きました。

その理由は、もちろん.zipと.movはどちらもファイル拡張子だからです。そのため、悪意のある攻撃者がこれらのTLDを利用して、ファイルを開く代わりに悪意のあるウェブサイトにアクセスさせることで人々を混乱させるなど、様々な脅威シナリオが考えられます。

「bobbyr」という名のセキュリティ研究者が火曜日のブログ投稿で、Googleの今回の動きに伴う問題の一例を示した。彼らは、Chromeの既知の動作(Googleは修正を見送っている)を悪用することで、スラッシュとして表示されるUnicode文字(U+2215 (∕))を含むURLを作成できると指摘した。しかし、ブラウザがURLを取得する際には、この文字はスラッシュとして扱われない。

また、URL に @ 演算子を追加することで (URL スキームのユーザー情報 (RFC 3986) 部分を区切るために使用され、埋め込まれた認証がやや安全ではないためほとんどの最新ブラウザでは無視されます)、このリンクは…

https://github.com∕kubernetes∕kubernetes∕アーカイブ∕refs∕tags∕@v1271.zip

…は…として扱われます

v1271.zip

…@ 区切り文字より前のすべてがユーザー情報として扱われるためです。

結果として得られる v1271.zip ドメインは登録され、たとえば、あらゆるリクエストに悪意のある .exe ファイルで応答する Flask アプリケーションをホストするために使用できます。

このURL解析動作は、上記のURLをChromeのアドレスバーに貼り付けると明らかです。Chromeは、短縮された実際のアドレス(@記号の右側のすべて)を検索クエリとしてURLの上部に表示します。

Unicode のスラッシュ文字を含む .zip ドメインのスクリーンショット

Unicode のスラッシュ文字を含む .zip ドメインのスクリーンショット – クリックして拡大

「bobbyr」は、この手法は、Gmail の Web バージョンなどの電子メール クライアントではさらに効果的であると主張しています。Gmail では、@ 記号を非表示のフォント サイズに設定して、URL をさらに説得力のあるものにすることができます。

しかし、他のメールクライアントは異なります。例えばApple Mailは、URLのgithub.com部分をリンクとしてハイパーリンク化し、U+2215(∕)で停止します。これにより、v1271.zipドメインへの安全でないリンクの形成が意図せず阻止されます。

  • マイクロソフトはSaaSのURL拡散に対処し、ドットコムを廃止してcloud.microsoftを採用
  • ICANNはウクライナの要求に応えてロシアのドメインをすべて削除
  • 広告ブロッカーやブラウザのプライバシー拡張機能のメーカーは、終わりが近いことを懸念している
  • 契約の技術要件にあなたの名前が挙がっているなら、.tv の権利を獲得するのは簡単なはずです ― そうですよね、Afilias さん?

混乱のリスクは多少ありますが、重複する名前、ホモグリフ、その他関連する懸念事項をかなり許容している現状と比べて、それほど大きな変化ではありません。他の方も指摘されているように、.com はかつて Microsoft の世界で一般的なファイル拡張子であり、ポーランドの CC-TLD (.pl) は今でも Perl のファイル拡張子として使用されています。セントヘレナの CC-TLD (.sh) もシェルスクリプトのファイル拡張子として使用され、セルビア共和国は Rust のファイル拡張子と CC-TLD (.rs) を共有しています。

「実は悪くない」

Microsoft の主席ソフトウェア エンジニアであり、ブラウザー ラングラーのベテランである Eric Lawrence 氏は最近、.zip と .mov の登場について「実は悪くない」と述べています。

ローレンス氏は自身のブログ記事で、アプリケーションの自動ハイパーリンク機構(例えば、「VacationPhotos.zip」を対応する.zipドメインを指すリンクテキストに変換するメールクライアントなど)にリスクが存在する可能性があることを認めています。しかし、これは特に興味深い、あるいは起こりそうな攻撃ベクトルではないと主張し、これらの特定のドメインをアプリのハイパーリンクルーチンから除外するのが良いかもしれないと示唆しています。

ローレンス氏はまた、既に分かりにくいURLが.zipや.movによってさらに分かりにくくなるのではないかという懐疑的な見方を示した。「URLは既に非常に分かりにくく、ユーザーが頭の中で正しく解釈することを期待するのは、様々な面で損をすることになる」と彼は主張した。

最後に、彼は新しいTLDには、レジストラにとってより厳格なセキュリティデフォルト設定を備えた新しいドメインを展開できるという潜在的な利点があると考えています。.zipと.movは、ブラウザにデフォルトで安全なTLSを自動的に使用するよう指示するHTTPS Strict Transport Security(HSTS)プリロードリストに含まれる40のTLDに含まれていると彼は指摘しています。

Google はThe Register 宛ての電子メールでも同様の意見を述べ、不正使用の可能性は認めながらも、そのリスクは周知の事実であり、管理可能であると主張した。

「ドメイン名とファイル名の混同リスクは新しいものではありません」と広報担当者は述べた。例えば、3Mのコマンド製品はcommand.comというドメイン名を使用しており、これはMS-DOSや初期のWindowsでも重要なプログラムとして使用されている。

アプリケーションにはこれに対する緩和策(Googleセーフブラウジングなど)があり、これらの緩和策は.zipなどのTLDにも適用されます。同時に、新しい名前空間により、community.zipやurl.zipなどの命名の機会が広がります。

Googleはフィッシングやマルウェアを深刻に受け止めており、Googleレジストリには.zipを含むすべてのTLDにおいて悪質なドメインを停止または削除する既存のメカニズムが備わっています。今後も.zipをはじめとするTLDの利用状況を監視し、新たな脅威が出現した場合は、ユーザーを保護するために適切な措置を講じます。®

Discover More