Electrum 4.8.3、Bitcoin(BTC)ウォレットの取引すり替え脆弱性を修正、悪意あるサーバー対策
Electrumは10月24日(土)、Bitcoin(BTC)ウォレットの4.8.3を公開した。悪意あるサーバーが未確定取引をすり替えて資金を盗む脆弱性に対応し、未確定取引の署名検証を必須化。旧バージョンのユーザーには即時アップグレードが呼びかけられている。
4.8.3が塞いだサーバー側の隙間
軽量型
Bitcoin (BTC)ウォレットのElectrumは10月24日(土)にバージョン4.8.3を公開し、悪意あるウォレットサーバーが過去の全リリースに存在する脆弱性を悪用していたことが開発陣の調査で確認されたとして、ユーザーに即時アップグレードを呼びかけた。この脆弱性はGitHubセキュリティ勧告GHSA-6jp4-8v48-cc5vに文書化されており、手口が非常に特殊だ。乗っ取られたサーバーは、ユーザー自身の支払いのうちの一つを静かに盗み取り、攻撃者へ送金する取引と入れ替えたうえで、所有者がその不正な取引に署名して承認するのを待つ。理論上の弱点ではなく実際の悪用が進行していたため、リリース告知には「今すぐアップグレードせよ」という警告が添えられた。Electrumは取引履歴、手数料の見積もり、支払いのブロードキャストを外部サーバーに委ねる軽量ウォレットだ。この設計はクライアントを小型に保つ一方、各サーバーにユーザーの見る情報への実質的な影響力を渡してしまう。確定した取引はElectrum自身が検証するが、旧バージョンは未確定の取引の一部について署名を確認せずに受け入れていた。この相違は、Segregated Witnessが解決を狙ったマレービリティ問題に端を発するもので、攻撃者はまさにこの隙間を突いた。敵対的なサーバーは正当な支払いを横取りしてブロードキャストを妨げ、資金を攻撃者の管理下のアドレスへ送る偽の取引に差し替える。差し替えられた取引の署名は無効だったが、ウォレット上では通常の未処理支払いと表示され、画面上に警告は一切現れなかった。なお、今回の問題はウォレットソフト側の不具合であり、ブロックチェーンの合意ルールには手を触れていないため、ビットコインの価格やチェーンの運用に影響は及んでいない。それでもこの発見は、クライアント層におけるBitcoinウォレットセキュリティの重要な教訓となる。旧バージョンのユーザーは、アップグレードを終えるまで未処理の支払いを警戒するよう指示された。
罠が顕在化したのは、ユーザーが不足した支払いの手数料をRBF(Replace-By-Fee、未確定取引を高い手数料率で再送信できる仕組み)で引き上げようとしたときだった。本来の支払いが上書きされる代わりに、被害者は気付かないまま置き換え後の取引に署名し、自分の資金を攻撃者へ移す承認を与えてしまう。欺瞞はさらに巧妙だった。攻撃者は受け取り用アドレスの末尾4文字が標的アドレスと完全一致するアドレスを生成しており、横に並べて見比べる程度の確認では不正が見抜けない。報告された偽取引の一つには、手数料がゼロに設定されたものまであった。これは被害者に手数料調整を促し、盗難の最終工程を完了させるための餌とみられる。開発陣には2件の非公開報告が届いた。10月11日、ユーザーのdannydeezyが取引の入れ替えを報告したが、その時点では手数料引き上げ機構との関係は十分に解明されていなかった。続く10月18日、ユーザーのRaju-K12が手数料引き上げを承認した後に資金を失ったと報告し、2件目の報告で攻撃が理論でなく実践的に機能することが判明した。修正はコミット90fe308として投入され、ウォレットの資金を使う未確定取引はすべて署名検証を必須とした。無効な署名を持つ偽取引は、ローカルの取引履歴に記録される前に拒否される。4.8.3以前のユーザーは、更新をelectrum.orgからのみダウンロードし、暗号署名を検証すべきだ。アップグレード前の間は、手数料調整時を含め署名の前に毎回宛先アドレスと金額を確認するよう開発陣は助言している。なお、信頼できる自己運営のElectrumサーバーにのみ接続していたユーザーは、このサーバー型攻撃に最初からさらされていなかった。今回の一件が残す皮肉は明白だ。秘密鍵の保護を目的に作られたウォレットが、所有者の意図しない支払いに対して完全に有効な署名を要求させられる可能性があった。
パッチ後も残るサーバー信頼の課題
今回追加された制御は狭いが本質を突いている。ウォレットの資金を使う未確定取引は、クライアントが保存する前に検証済みの署名を必ず伴わなければならなくなった。攻撃チェーン全体が、軽量クライアントのユーザーの多くが目にしない信頼関係の上に成立していた。履歴とブロードキャストを自分で管理しないサーバーに委ねているからだ。この意味で、今回の事故はユーザーが意図しない支払いに署名させられるリプレイ攻撃の親類といえる。実用面での教訓は、サーバー選択とセルフカストディに帰着する。自己運営サーバーのユーザーは無傷だったという事実は、信頼ではなく検証を唱えるビットコイン・マキシマリズムの主張に新たな材料を加えるだろう。また、規模の大きい保有者ほど、Tangem Mobile Walletのようなハードウェア型の選択肢へ傾く可能性がある。それ以外のユーザーにとって、アドレス末尾4文字の照合と4.8.3の署名検証ルール、この2つの習慣が隙間を閉じる鍵となる。
AIによって生成され、AIによるレビューを経て、COINOTAGの編集監督のもとで公開されました。

