アップデート未完了のノードがイーサリアムにもたらす脆弱性

未だに残るアップデート未完了の「古い」ノード

2019年5月、SRLabs によるレポートにおいて、実に30%か40%のノードが攻撃に対し脆弱である、という状況が浮かび上がってきた。

背景について説明しておこう。

イーサリアム・ネットワークにアクセスするためのソフトウェアクライアントとして、現時点で一般的な選択肢は、Parity Ethereum（Parity）か Go Ethereum（Geth）だ。

今年の 2月、SRLabs により、Parity Ethereum クライアントのバージョン2.2.10以下で、Parity Ethereumノードをリモートでクラッシュさせる可能性がある脆弱性が報告された。

このクラッシュは、2つのノード間でチェーンを同期している間に、整数のオーバーフローが原因で発生しうる。すべてのノードは任意の接続要求を受け入れてメインネットワークとの同期を維持するため、攻撃者は イーサリアム・ネットワークにおいて、パッチが適用されていない Parity ノードをクラッシュさせることができる、というものだ。

Gethでも44%が未更新

Parity Ethereum では、ノードをスキャンした結果、15%が2月のパッチを未適用だったという。 さらに、3月2日にリリースされたバージョンについても同様に調査し、5月2日時点で30%でパッチが未適用だった。

さらに、7%は9か月間もパッチを当てていない。2018年7月にはテストネットの脆弱性がメインネットに波及する可能性が指摘され、コンセンサス形成に関する重大な脆弱性が修正されているが、これも適用されていない、ということだ。

また、イーサリアムの根幹をなすGethでも更新に関する問題は同様に観測されている。 2か月前にリリースされたセキュリティに関するクリティカルなアップデート、これが含まれないバージョンv.1.8.20 以前のノードが約44%も残っているのだ。

更新されない理由

Gethには自動更新の機能は存在しない。したがって約44%のGethノードが脆弱という報告は、アーキテクチャの設計そのものにおける問題と言い換えてもいい。

ただし、すべてのソフトウェアに自動更新を実装すべきかどうか、という点は議論の余地がある。CCleaner や ASUSのアップデートツールのように、アップデート機能を悪用される例も出てきているからだ。

加えて、Electrumのようにクリティカルなセキュリティアップデートを装った攻撃も確認されている。結局のところ、各自が少しずつ注意を払うしかないのが現状だろう。

Parity Ethereum には自動更新の仕組みがあるものの、スマートコントラクトに紐づけられているため、アップデートの適用は複雑な手順になりがちだ。

そして、すべてのノードが常に最新の状態にあるわけではない。したがって、常時起動せず、その時々で追いつきで処理しているノードなどがあった場合、自動では適用されない。

また、スマートコントラクトを利用しているという性質そのものが、そもそもアップデートプロセスを煩雑（はんざつ）にしているという指摘もある。迅速なアップデートが適用できない場合もある、ということだ。 Parity もセキュリティアラートを出してアップデートを促してはいるが、これも効果のほどは未知数だ。

攻撃は可能か？

詳細についてはハッシュレートの多数を占めるマイナーのバージョンを分析する必要がある。しかし、現実的には難しいはずだ。

ノードをクラッシュさせることができるなどの脆弱性は単体ノードにとっては致命的だが、ネットワーク全体で見た場合、単一ノードのクラッシュによる影響は微々たるものであり、他の攻撃手法と組み合わせない限り有用性は高くない。

ハッシュレートの過半はマイナープールが握っており、彼らが報酬のために正しく動作している限り、二重支出攻撃などを行うためのコストは非常に高いままだろう。

なお、仮想通貨情報統計サイトEtherscanで直近7日間のハッシュレートを見ると、上位4つのプールが75%を占めていることがお分かりいただけるだろう。

まとめ

先日お伝えしたビットコインの事例と同様、イーサリアムでも脆弱なノードが放置されている実態が分かった。

ただちに問題につながるわけではないものの、コミュニティベースで運営されるという前提を考えると、早急な対応が望ましいだろう。 これをお読みになった読者各位におかれても、お手元でノードを運用されている場合、ご確認いただくことをお勧めする。

画像はShutterstockのライセンス許諾により使用