BTCPay Server、ホットウォレット不正流出の報告を受けてサーバー停止を要請

不正流出の報告を受け停止を要請

自社サーバーでビットコイン決済を受け付けるためのオープンソースソフトウェア「BTCPay Server」は、11月2日、複数のサーバーでホットウォレット内の資金が不正に引き出されたとの報告が相次いだことを受け、運用者にサーバーをオフラインにするよう求めた。チームは公式Xの投稿で報告を確認し、調査が完了するまでインスタンスを停止したまま維持するよう要請。具体的な手順として「./btcpay-down.sh」というコマンドを案内した。

ただし、この開示には運用者が最も必要とする情報が欠けている。損失額は公表されず、影響を受けたサーバーの数も、原因も明かされていない。特定バージョンに限定した注意喚起でもなく、修正版のリリースも発表されていないため、指示は個人店舗の導入から大規模な構成まで、現時点で稼働するすべての環境を対象とする。Lightning統合の有無も問わない。侵入経路が特定されていないからだ。取引IDも公開されておらず、損失を第三者が検証する手段は当面ない。調査の完了時期についての言及もまだない。

ホットウォレットとは、インターネットに接続されたサーバー上に秘密鍵を保管し、返金などの送金を自動処理できるようにした仕組みだ。利便性の裏側として、サーバーが侵入されればアクセスを得た者が鍵を直接握る。BTCPayの実装では、サーバー自体が保持するシードで取引に署名する方式であり、報告が指摘するのはまさにこの部分である。

10月の修正リリースと8月のLightning侵害

BTCPay Serverは設計上、自己ホスト型だ。各加盟店が自前のサーバーでソフトウェアを動かし、決済代行業者を介さずにビットコインの決済を受け付ける。この非中央集権的なモデルにより、同プロジェクトはビットコイン・マキシマリズムに関わる自己管理の陣営で長く重視されてきた。同じ構造が対応の形をも規定する。開発側は全環境へ一斉に修正を配布できず、停止と更新は運用者ごとに進む。

今回の開示は、チームがバージョン2.4.7を公開した4日後のことだった。この緊急リリースは10月29日木曜日に出され、重大な脆弱性1件と複数の中程度の脆弱性を修正している。今回の報告との関連はまだ示されておらず、すでに適用済みの修正パッチがある状態で新たな被害報告が届いた格好だ。

前例もある。8月には、バージョン2.4.2以前を狙った攻撃により、Lightning支払いノードを運用するソフトウェアLNDの認証情報が盗まれ、BTCPayに接続されたLightningノードから資金が引き出された。Lightningチャネルは独自の鍵を保持するため、認証情報の窃取によって攻撃者はチャネル残高を直接支出できた。当時チームは、BTCPay内で作成されたホットウォレットを含むオンチェーンウォレットはこの脆弱性の影響を受けないと明言し、8月の被害はLightning経路に限られていた。今回の報告で名指しされたウォレットは、まさにこの「影響なし」とされた区分に該当する。ビットコインブロックチェーン自体の問題でもない。被害はサーバー側の鍵管理に関わるもので、プルーフ・オブ・ワークの合意形成とは無関係だ。通知すべき中央事業者が存在しないため、チームが調査中に提示できる防衛策は停止コマンドのみとなる。原因の特定と修正提供までサーバーを稼働させ続ける運用者は、自己の判断と責任で行うことになる。

対応の輪郭自体が、開示内容と同じく多くを語る。8月には被害を2.4.2以前に限定し、他の運用者には適用を促すことで済んだ。今回は全バージョンが停止対象であり、開発側がまだ侵入経路を突き止められていないことを示唆する。事後分析、攻撃者の取引ID、対策の時期のいずれも未公表で、損失をオンチェーンで検証することは当面できない。保管型の侵害は時に桁違いに大きくなる。Bitwiseの最高投資責任者マット・ホーガンは、63億ドルのBinanceハッキングが長期的な価格経路を変えないと論じたこともあるが、自己ホスト型の決済ツールはリスクを自前の鍵を運用する小規模加盟店に集中させる。チームが調査結果を公表するまで、何がどこからいくつ奪われたのかは明らかにならない。