Kintsuのウェブサイトは復旧、ただしユーザーには引き続きウォレットを接続しないよう勧告
Kintsuのウェブサイトは復旧、ただしユーザーには引き続きウォレットを接続しないよう勧告
Monadブロックチェーン上に構築されたリキッドステーキング・プロトコルのKintsuは、フロントエンドが攻撃を受けた疑いがある中、公式ウェブサイトを復旧したと報じられている。しかし、プロジェクトチームは正式なセキュリティ確認を発表するまで、kintsu.xyzへのアクセスやウォレットの接続を控えるよう、引き続きユーザーに警告している。
今回のインシデントは、分散型金融（DeFi）において、ますます重要になっているリスクを浮き彫りにした。スマートコントラクト自体に変更が加えられていなくても、侵害されたウェブサイトによって、ユーザーが悪意のあるトランザクションへ誘導される可能性がある。
ウェブサイトが復旧しても、インシデントが終わったとは限らない
Kintsuは、ドメインが復旧し、再びプロジェクト独自のインフラを指す状態に戻ったと発表した。しかし、ドメインネームシステム（DNS）のキャッシュは、すべてのインターネットサービスプロバイダーや地域で同時に更新されるわけではない。
そのため、一定期間は、一部のユーザーが悪意のあるバージョンのウェブサイトへ誘導され続ける可能性がある。チームによると、このリスクはドメインが修正された後も約1時間続く可能性があり、公式に安全が確認されたとの発表を待つようユーザーに呼びかけている。
この点は非常に重要だ。ある場所ではウェブサイトが正常に表示されたとしても、すべてのユーザーが同じインフラにアクセスできているとは限らない。DNSの伝播、ブラウザのキャッシュ、ネットワークレベルのキャッシュによって、アクセス状況にばらつきが生じる可能性がある。
プロジェクトに関する最新情報を確認する際は、Kintsuが認証済みの公式コミュニケーションチャネルだけを利用し、ウェブサイトが復旧したように見えることを安全の証拠とみなさないようにすべきだ。
疑われているフロントエンド攻撃では何が起きたのか？
セキュリティ企業のBlockaidは、Kintsu、Flap、Stonkbrokersなど複数の暗号資産関連ウェブサイトに対する、進行中のフロントエンド攻撃を検知したと警告した。
この警告によると、影響を受けたウェブサイトには、StepDrainerツールキットに関連する悪意のあるスクリプトが読み込まれるよう改変が加えられていた。これらのスクリプトはウォレット接続の手順を操作し、デジタル資産の移転を促すよう設計されたページへユーザーを誘導する可能性があった。
この攻撃では、必ずしも不審なアプリケーションのダウンロードや、シードフレーズの入力が必要だったわけではない。危険が生じるのは、ユーザーが見慣れた「Connect Wallet」ボタンをクリックし、その後、悪意のあるページが表示するトランザクションや署名リクエストに応じた時点だった。
フロントエンドへの攻撃が特に発見しにくいのは、このためだ。ウェブサイトは通常どおりのブランド表示、レイアウト、ナビゲーションを保ったまま、正規のウォレット操作だけをひそかに有害なものへ置き換えることができる。
「Connect Wallet」は無害な操作ではない
多くのユーザーは、ウォレットの接続を単純なログイン手続きだと考えている。しかし実際には、ウォレットを接続することでアドレス情報が公開され、分散型アプリケーション（dApp）とウォレットのインターフェースとの間に通信経路が確立される。
より深刻なリスクが始まるのは、dAppがユーザーに次のような操作を求めたときだ。
- トークンの使用許可（allowance）を承認する
- 見慣れないメッセージに署名する
- 内容が不明確なトランザクションを承認する
- 知らないアドレスへ資産を送金する
- セッション終了後も有効な権限を付与する
悪意のあるウェブサイトは、こうしたリクエストを見慣れた表現や洗練されたユーザーインターフェースで表示することがある。承認してしまうと、攻撃者が特定のトークンを移動できるようになったり、ユーザーを誘導して資産の直接送金を承認させたりする可能性がある。
そのためユーザーは、よく知られたウェブサイト上に表示されたリクエストだから安全だと決めつけず、ウォレットに表示されるすべての確認画面を個別に検証する必要がある。
Kintsuユーザーに推奨される対応
Kintsuが明確なセキュリティ確認を発表するまで、ユーザーは次の対策を取るべきだ。
-
当面の間、
kintsu.xyzにアクセスしない。
DNSやブラウザのキャッシュの影響により、復旧したドメインであっても接続先が一貫しない可能性がある。 -
Kintsu、Flap、Stonkbrokersにウォレットを接続しない。
インターフェースが通常どおりに見えたり、明らかな警告なしに読み込まれたりする場合でも同様だ。 -
見慣れない署名リクエストは拒否する。
ウェブサイトが「続行するために必要」と主張していても、それだけを理由にトランザクションを承認してはならない。 -
トークンの承認状況と権限を確認する。
攻撃が疑われる期間中にウォレットを接続したり、トランザクションを承認したりした場合は、オンチェーン上の権限を確認し、不要な許可を信頼できる権限管理ツールで取り消すべきだ。 -
インシデント対応とリカバリーフレーズを切り分ける。
シードフレーズや秘密鍵を、ウェブサイト、サポートフォーム、ブラウザ拡張機能のプロンプト、ダイレクトメッセージなどに入力してはならない。ウォレットのリカバリーフレーズが流出した可能性がある場合は、新たに生成したウォレットへ資産を移す必要が生じることがある。 -
認証済みの公式発表を確認する。
プロジェクトのドメイン、ソーシャルメディアアカウント、コミュニティチャネルはいずれもなりすましの対象になり得る。緊急の指示に従う前に、アカウントが本物であることを確認すべきだ。
イーサリアム財団のウォレットセキュリティに関するガイダンスでも、予期しない署名リクエストや未知のアプリケーションには注意するよう推奨している。
DeFiユーザーにとってのより大きな教訓
今回のKintsuのインシデントは、分散型金融のセキュリティがスマートコントラクトの監査だけにとどまらないことを示している。ユーザーはコントラクトコード、バリデーターのリスク、プロトコルガバナンスに注目しがちだが、フロントエンドも重要な攻撃対象の一つだ。
分散型アプリケーションは、次のような複数の構成要素に依存している可能性がある。
- ドメイン登録とDNS設定
- ホスティングプロバイダーとデプロイパイプライン
- JavaScriptライブラリとサードパーティ製スクリプト
- ウォレット接続プロバイダー
- 告知に使用されるソーシャルメディアアカウント
これらの層のいずれか一つが侵害されるだけでも、基盤となるブロックチェーンが通常どおり稼働している状態で、ユーザーが影響を受ける可能性がある。
今回のインシデントは、トランザクションのシミュレーションと人による確認が依然として重要であることも示している。ウォレットに表示されたリクエストは、それを生成したウェブサイトの名前だけで判断するのではなく、実際に関わるコントラクト、関数、送付先、金額に基づいて確認すべきだ。
このセキュリティモデルにおけるハードウェアウォレットの役割
ハードウェアウォレットは、秘密鍵を通常のオンライン環境から隔離することで、保護をさらに強化できる。しかし、悪意のあるトランザクションを自動的に安全なものへ変えることはできない。ユーザーがトランザクションの詳細を確認しないまま承認や送金を実行すれば、ハードウェアウォレットであっても、そのトランザクションに署名してしまう可能性がある。
Monadのようなネットワーク上でDeFiプロトコルを利用するユーザーにとって、OneKeyのようなハードウェアウォレットは、より広範なセキュリティ戦略の一部となり得る。最も効果的なのは、秘密鍵の隔離に加えて、ドメインを慎重に確認し、付与する権限を最小限に抑え、リスクレベルごとにウォレットを使い分け、内容が不明確または予期しないリクエストには署名しないという対策を組み合わせることだ。
最終的なポイント
Kintsuのウェブサイトが復旧したことを、セキュリティインシデントの終息と受け止めてはならない。プロジェクトがフロントエンドおよび関連インフラの安全を明確に確認するまで、ユーザーはkintsu.xyzへのアクセスを避け、ウォレットを接続せず、見慣れない署名リクエストを拒否すべきだ。
DeFiに参加するユーザーにとっての教訓は明快だ。見慣れたウェブサイトだからといって、トランザクションの安全が保証されるわけではない。ドメインを確認し、ウォレットに表示されるすべてのリクエストを精査し、トークンの権限を必要最小限に抑え、予期しない緊急性を危険の兆候として捉えるべきである。
