Core Lightning、26.06.7以前のBitcoin(BTC)ノードへの攻撃を警告

ライトニングノードが実際の攻撃を受けている

Lightning Network向けのブロックチェーンノードソフトウェアのオープンソース実装であるCore Lightningは、26.06.7以前のバージョンで稼働するノードが攻撃者の標的になっていると金曜日に運用者へ警告し、9月22日から提供が始まっている26.06.8への更新を促した。チームの公式投稿は、旧ビルドを使い続けている全ての運用者に対し、最新リリースへの移行を遅らせないよう呼び掛けている。この警告が重く受け止められるのは、資金の置き場所にある。Lightning NetworkはBitcoin (BTC)の上に構築されたレイヤー2の決済システムで、メインチェーンの外で高速かつ低コストの送金を処理し、Bitcoin DeFiとして括られる決済活動の相当部分を担っている。 Bitcoinの価格を追う現物保有者にとって、影響の範囲はベースチェーン上のコインには及ばない。ベース層はプルーフオブワークで保護されており、攻撃の経路はあくまでペイメントチャネル側にある。自分でCore Lightningノードを運用している人だけが更新作業の対象だ。今回の警告の原因となったバグは、二つの形で運用者に損害を与え得る。最悪の場合、チャネルの閉鎖処理に不具合があるとノードの資金が相手側に渡ってしまい、その他のバグでは攻撃者がノードをクラッシュさせてオフラインに追い込める。今回の件は、今四半期におけるレイヤー2でのBitcoinセキュリティへの最新の圧力となっている。ウォレットアプリ経由でLightningを使う大半のユーザーはノードを持たず、更新はアプリ提供側が対応する。カストディアル型のウォレットはユーザーに代わってコインを保管する。この種の提供者のノードが資金を失えば、まず提供者が損失を負い、弁済の可否はその事業者独自の規約次第になる。Lightningには預金保険が存在しないからだ。セルフカストディアル型のユーザーはチャネル残高の管理権を手放さないが、提供者のノードがダウンすれば、支払いが一時的に止まる可能性は残る。

26.06.8で何が変わったのか

今回のパッチには長い経緯がある。9月16日、Core Lightningチームはユーザー資金に影響し得る問題が実験的機能に関わるとして調査中であることを明らかにし、およそ6日後に26.06.8をリリースした。リリースノートは複数の情報源から責任を持って報告された脆弱性への修正を記し、Bitcoin (BTC) Red Teamと名指しの個人・団体12件、さらに匿名の報告者を謝辞で挙げている。変更履歴は露出した個所を具体的に列挙する。送信者側のノードをクラッシュさせ得る欠陥、RESTインターフェースのメモリを枯渇させ得るリクエスト、そしてユーザー資金をペナルティとして奪い得るチャネルクローズの不具合だ。深刻度は不具合ごとに異なる。クラッシュは運用者が介入するまでノードをオフラインにするに留まる。資金を実際に動かし得るのはチャネルクローズの欠陥で、緊急性の根拠もこの案件に置かれている。開発陣は一部のテストをあえて同梱しない選択もした。運用者が更新を完了するまでの間、逆解析を難しくするためだ。運用者側の手順は短い。稼働中のバージョンを確認し、プロジェクトから最新ビルドを取得し、チャネルが修正済みコード下で再開するよう再起動する。9月22日のリリースは、今まさに起きている事態そのものを想定して書かれていたといえる。8月がその背景にある。チームは同月、AI生成のCVE(Common Vulnerabilities and Exposures)報告の大量処理に追われ、これらの欠陥を確認した2日後に26.06.7をリリースした。同じ時期、オープンソースのBitcoin決済プロセッサであるBTCPay Serverの脆弱性からLightningの認証情報が漏れ、攻撃者が資金を盗む事案も発生している。今回の攻撃者がどの脆弱性を突いているのか、開発陣の説明はまだない。

縮まり続ける更新の猶予期間

COINOTAGの読み解きは一次記録から始める。Core Lightningの投稿が確認している事実は2つ、攻撃が現に進行していることと、更新の指示が出ていることだ。被害者も金額も、突かれた脆弱性も名前がない。この沈黙こそが、現時点で記事の開かれた部分である。ノードは送金をリアルタイムに中継するため鍵をオンラインに置く。だからこそ旧版のソフトウェアは、攻撃者にチャネル資金への直接的な経路を与えてしまう。記録はもう一つ、時間の間隔を確定させる。パッチ公開からおよそ10日後に攻撃が表面化したという間隔だ。AIを活用した脆弱性探索がこの隙間をさらに圧縮していくなら、制約となるのは修正の品質ではなく、任意の立場にあるノード運用者がどれだけ速く更新を済ませるかの方へ移っていく。