ドメイン緊急事態 EP05：2024年Squarespace DeFiドメイン大量乗っ取り事件

2024年7月、暗号資産プロジェクトのウェブサイトにとって最も危険な要素は、スマートコントラクトのバグでも秘密鍵の漏洩でもなかった。それは、ドメインを管理するレジストラだった。

その月の数日間、ユーザーが見慣れたアドレスをブラウザに入力すると——信頼していたレンディングプロトコルの公式サイト、何度も利用したブリッジのサイト——まさに目的のページにたどり着き、正確に見えるページが表示され、そしてウォレットが空になった。通常の意味でハッキングされたわけではない。パスワードが解読されたわけでも、シードフレーズがフィッシングされたわけでもない。攻撃者は単純に、ドメインそのものの正面玄関から歩き入ったのだ。その玄関は、ほとんどのプロジェクトが気づきもしなかった企業間の移行作業の最中に、施錠されないまま放置されていた。

その移行とは、Google DomainsからSquarespaceへの移行のことだ。施錠されていなかった玄関とは、Squarespaceの認証デフォルト設定だった。その結果として生じたのは、研究者の言葉を借りれば「数十億ドル規模の資産を管理する」暗号資産・DeFiプロジェクトを標的とした、組織的なDNS乗っ取りの波だった。

レジストラ移行が大規模な攻撃面を生み出した経緯

ドメインは通常、一つひとつが独立した存在として認識される——自分だけのアドレス、自分だけのコントロールパネル、自分だけのDNSレコード。しかしレジストラは膨大な数のドメインをまとめて管理しており、あるレジストラの顧客全員が別のレジストラへ移行する際には、同じ移行ロジックで、同じデフォルト設定のまま、同時に全員分のアカウントが移行される。そのロジックに存在する弱点は、個別のバグではなく、ドメイン群全体に共通する性質となる。

これこそが、2024年の事件を個々の不運な侵害が連続したものではなく、大規模イベントにした要因だ。

2023年6月、Squarespaceはおよそ1,000万件のドメイン名をGoogle Domainsから購入した。Googleがレジストラ事業からの撤退を発表したためだ。その後の約1年間、Squarespaceはこの取引で取得したおよそ1,000万件のドメイン名に関するユーザーの移行作業を進めた。移行をシームレスに感じさせるため、Squarespaceはそれぞれの移行対象ドメインに紐付いたユーザーのアカウントを、Googleが保持していたメールアドレスをもとにあらかじめ作成した。

シームレスであることこそが問題だった。ユーザーに何も要求しない移行は、ユーザーが何も証明していない移行でもある——パスワードも、身元も、メールアドレスの管理権限も。アカウントは存在し、ドメインは紐付けられ、ドメインと「最初にたどり着いた者」との間に立ちはだかるのは、移行後アカウントに対してほとんど何も要求しないログイン画面だけだった。

2024年7月の乗っ取り事件

攻撃は7月9日に始まり、その後数日間にわたって続いた。その手口は決して巧妙なものではなかった。BleepingComputerの報道によれば、Squarespaceレジストラを利用する分散型金融（DeFi）暗号資産ドメインを標的とした組織的なDNSハイジャック攻撃の波が発生し、訪問者はウォレットドレイナーを仕掛けたフィッシングサイトへとリダイレクトされた。

最初に騒動となったのは、DeFiレンディング分野でも屈指の知名度を誇るプロジェクトだった。事件を調査したセキュリティ企業Blockaidは、これらのサイトへの訪問者が、接続したウォレットから資金を抜き取るよう設計された悪意あるページへリダイレクトされていたことを確認した。偽サイトは粗雑なコピーではなかった。Blockaidによれば、これらの偽dAppはInfernoドレインキットの最新バージョンを稼働させており、ユーザーにウォレットを空にするトランザクションへの署名を誘導するよう設計されていた。

被害が確認されたプロジェクトのリストは、エコシステムの名だたる顔ぶれが並んだ。乗っ取られたのはCeler Network、Compound Finance、Pendle Finance、そしてUnstoppable Domainsだ。Compoundはメインドメインが乗っ取られてフィッシングページを表示する状態となった。Celerは攻撃を察知しDNSレコードを迅速に回復した。Pendleも同様の問題が発生し、ユーザーに対してウォレット承認の取り消しを警告した。

何が危機にさらされ、何が失われたか

ドメイン乗っ取りの残酷さは、ユーザーが習慣的に頼っているあらゆる安全確認を無効化することにある。URLを確認する。本物のサイトかどうか確かめる。鍵マークを確認する。これらのアドバイスはすべて、ドメインが正しい場所を指していることを前提としている。しかし攻撃者がドメインのDNSを支配している場合、URLは本物——プロジェクトの正規アドレス——でありながら、攻撃者のサーバーへと誘導する。南京錠のアイコンは緑色だ。アドレスバーは嘘をつかない。しかしページは罠だ。

だからこそInfernoのようなウォレットドレイナーキットは、DNSハイジャックと非常に相性がよい。ドレイナーはパスワードを盗む必要がない。被害者にウォレットを接続させ、署名させるだけでよい。そして、レンディングプロトコルの正規ドメインにたどり着いたユーザーには、トランザクションを承認することを躊躇う理由がない。フィッシングサイトは、正規ドメインが長年かけて培った信頼をそのまま受け継ぐのだ。

被害の規模はどれほどだったか。その深刻さを示す数字は、確認された盗難件数ではなく、危険にさらされたプロジェクトの数だった。Decryptが伝えたBlockaidの分析は率直だった。おおよそ228のDeFiプロトコルのフロントエンドがいまだリスクにさらされている——すべてが同じ移行アカウントの脆弱性の背後にあるからだ。実際に発生した乗っ取りは、あくまで一部にすぎない。攻撃面はGoogleからSquarespaceへの移行に乗った暗号資産コミュニティ全体に及んでいた。

経緯：移行における認証の欠陥

研究者が仕組みを再構築すると、それはほとんど恥ずかしくなるほど単純なものだった——だからこそ、大規模に危険だったのだ。

二つの設計上の選択から始まる。第一に、Squarespaceはログインしようとしている人物が実際にそのアカウントのメールアドレスを管理しているかを確認していなかった。研究者が指摘したように、Squarespaceはパスワードで作成された新しいアカウントに対してメールアドレスの確認を要求しない。第二に、移行済みアカウントはあらかじめ作成されていたがまだ誰にも請求されておらず——パスワードが設定されていなかった。そのため、正しいメールアドレスを持つ者が現れると、アカウントにパスワードがないため、「新規アカウントのパスワードを作成」するフローに直接誘導される。

この二つを組み合わせれば、攻撃の手口は自ずと描ける。移行対象ドメインに紐付いたメールアドレスは秘密ではなかった——管理者連絡先や登録者連絡先は公開されていたり推測可能だったりすることが多い。正当な所有者がログインするより先に、既知の移行済みメールアドレスを使ってアカウントを登録した攻撃者は、そのままドメインの支配権を手にした。MetaMaskのリードプロダクトマネージャーであり、この事件を解剖した研究者の一人でもあるTaylor Monahanは、この盲点を正確に指摘した。Squarespaceは、脅威アクターが正当なメールアドレス保有者より先に、最近移行されたドメインに関連するメールアドレスを使ってアカウントを登録する可能性を想定していなかった。

なぜこのような事前紐付けが存在したのか。利便性のためだ。研究者は、SquarespaceはGoogle Domainsから移行するユーザー全員がソーシャルログインオプション、つまりGoogle OAuthを選ぶと想定していたと結論づけた。このシステムはアカウントがすでに存在するかどうかにかかわらず、すべてのメールアドレスをドメインに事前紐付けした。おそらく、ユーザーがGoogle OAuthでログインすれば即座にすべてのドメインにアクセスできるようにしたかったのだろうと、研究者はThe Registerへの取材で説明した。しかしメールアドレスとパスワードによるログインパスは閉じられておらず、そのパスでは受信箱の管理権限を何ら証明しないままだった。

さらなる加速剤もあった。移行の過程で、本来この問題を防ぐべき保護機能が無効化されていた。Squarespaceへの移行の一環として、アカウントの多要素認証がオフにされていたのだ。Google DomainでMFAを丁寧に有効化していたドメイン所有者でさえ、Squarespaceに到達した時点でそのMFAは剥ぎ取られていた。解読すべきパスワードも、突破すべき第二要素も、傍受すべきメールも存在しない——移行済みで誰にも請求されていないアカウントにとって、推測可能なメールアドレスを知っていることがすべての認証だった。

対応と緩和策

暗号資産セキュリティコミュニティは、レジストラよりも速く動いた。Samczsun、Taylor Monahan、Andrew Mohawkらの研究者がその仕組みを公開し、Blockaidはまだ脆弱なフロントエンドのリストを関係プロジェクトに共有して、自分たちが危険にさらされているかどうか確認できるようにした。被害を受けたプロジェクトは、アカウントを取り戻し、DNSレコードをリセットし、悪意あるサイトに付与したトークン承認を取り消すようユーザーへ警告することに追われた。

移行済みアカウントに残る全員への即時の対処アドバイスは同じだった。攻撃者より先にログインしてアカウントを確保し、強固でユニークなパスワードを設定し、そして何より——移行によって無言のうちに削除されていた多要素認証を再有効化すること。Squarespace側は移行済みアカウントとアカウント作成フローのセキュリティ強化に取り組んだ。しかし、構造的な教訓はパッチよりも長く語り継がれるはずだ。ベンダーが移行中に無効化したセキュリティ制御は、その移行期間中、存在しない制御と同義である。

レジストラセキュリティとMFAから学ぶべきこと

Squarespaceの乗っ取り事件は、ある一社の設定ミスをめぐる話ではない。ドメインの支配権が実際にどこにあるのか、そしてブロックチェーンより上のレイヤーがいかに脆弱であり続けているかをめぐる話だ。

2024年7月を超えて広く通用するいくつかの教訓がある。

1. レジストラアカウントが信頼の真の根拠であり、スマートコントラクトではない。 被害を受けたプロトコルのいずれもコントラクトにバグはなかった。オンチェーンのコードは正常だった。攻撃者が奪ったのはドメインであり、ドメインこそユーザーが入力し、信頼し、ウォレットを接続するものだ。プロジェクトはオンチェーンで完璧であっても、DNSのコントロールプレーンが脆弱であれば、ユーザーを攻撃者の手に渡してしまう。

2. MFAは移行を乗り越えてこそ保護になる。 ここで痛ましいのは、MFAが攻撃によって無効化されたのではなく——移行の利便性として、攻撃より前に削除されていたことだ。MFAの状態を、アカウントの移行・譲渡・ベンダー変更のたびに再確認すべきものとして扱い、一度設定すれば終わりという姿勢を捨てること。

3. 「シームレス」はセキュリティとのトレードオフである。 移行がユーザーの利便性のために省略するステップは、アイデンティティが証明されないステップだ。あらかじめ作成されたアカウント、自動紐付けされたメールアドレス、確認なしのログイン——これらはすべてユーザーが感じなかった摩擦であり、摩擦こそが多くの場合、攻撃者を締め出していたものだ。

4. 推測可能な識別子は、変装した認証情報だ。 これらのドメインを解錠した「秘密」は、決して秘密でなかったメールアドレスだった。公開された識別子を知ることで支配権が得られるシステムは、なりすまし一つで侵害される。

5. レジストラの影響範囲は顧客全体に及ぶ。 レジストラのデフォルト動作が脆弱であれば、個々のドメインセキュリティはほとんど意味をなさない。デフォルトは全員に一度に適用されるからだ。ドメインをどこに置くか、そしてその管理者が認証をどのように扱うかは、オンチェーンでの意思決定と同じくらい重大なセキュリティの選択だ。

Namefiの観点

2024年の乗っ取りは、「このドメインを本当に所有しているのは誰か」と「そのドメインを管理するアカウントにログインできるのは誰か」という二つの問いの間隙で起きた。従来のモデルでは、この二つの結びつきは緩い。所有権はレジストラのデータベース上の記録であり、そのアクセスはレジストラがその週に適用している認証方式によって制御される——1,000万件のドメイン移行の最中に、その門が一時的に大きく開いていたとしても。

Namefiはこの間隙を埋めるために作られている。ドメイン所有権をDNSとの互換性を保ちながらトークン化されたオンチェーン資産として表現することで、支配権は推測可能なメールアドレスやベンダーのログインデフォルトに依存するのではなく、暗号学的に検証可能なものとなる。所有権は自分が管理するウォレットに存在し、移転は監査可能であり、「誰がこのドメインのレコードを変更できるか」という問いには、カスタマーサポートへの問い合わせではなく、改ざん耐性のある答えがある。

それはSquarespaceの移行を完璧なものにするわけではない。しかし障害の様相を変える。既知のメールアドレスを使ってアカウントを登録した攻撃者は、それによってトークン化ドメインを所有することにはならない——所有権は、半初期化されたアカウントが静かに請求できるようなデータ行ではないからだ。名前のコントロールプレーンは、それが守る資産と同等の偽造困難性を持つべきだ。2024年7月、数百の暗号資産プロジェクトにとってそれは実現していなかった。その間隙こそ、技術的に解消する価値がある。

情報源と参考資料

• Krebs on Security — Researchers: Weak Security Defaults Enabled Squarespace Domains Hijacks
• BleepingComputer — DNS hijacks target crypto platforms registered with Squarespace
• Blockaid — Squarespace Domain Hijacking Incident: Attack Report
• SecurityWeek — Hackers Exploit Flaw in Squarespace Migration to Hijack Domains
• Decrypt — More Than 220 DeFi Protocols Still 'at Risk' From Squarespace DNS Hijack
• The Register — Infoseccers claim Squarespace migration linked to DNS hijackings at Web3 firms
• Socket — Squarespace Domain Hijacks Enabled by Email Address Exploit on Migrated Accounts
• SiliconANGLE — Multiple crypto domains hijacked from Squarespace due to Google Domains migration flaw
• Cybernews — Squarespace crypto domains under DNS attack, lack of MFA to blame
• Hackread — DeFi Hack Alert: Squarespace Domains Vulnerable to DNS Hijacking
• CircleID — Security Lapses Lead to Squarespace Domain Hijacks