【ITニュース解説】HashiCorp Vault RCE Vulnerability Persists Despite OpenBao Patch; Coordinated Disclosure Needed for Mitigation

近年、多くの企業で利用されているHashiCorp Vaultと、その派生版であるOpenBaoという重要なシステムに、非常に危険な脆弱性が見つかった。これはRCE、つまり「リモートコード実行」と呼ばれる脆弱性で、この脆弱性が悪用されると、インターネット経由で遠隔からサーバーに不正な命令を実行させ、最終的にはシステムを完全に制御されてしまう可能性がある。HashiCorp Vaultにとっては、これは2度目のRCE脆弱性の発見であり、その深刻さがうかがえる。

この脆弱性は、セキュリティの専門家集団であるControlPlaneのエンジニアたちによって発見され、彼らは4つの異なる脆弱性を巧妙に組み合わせることで、実際にシステムを乗っ取れることを証明した。この攻撃は、認証が不要な、つまり誰でもアクセスできる入り口と、データの一貫性を保つための「Raftスナップショットポリシー」という機能の誤った設定が組み合わさることで可能になる。

具体的に攻撃がどのように展開されるのかを、段階を追って見てみよう。 まず最初の段階として、攻撃者は「認証なしのエントリーポイント」を利用する。これは、本来であればIDやパスワードで本人確認が必要なはずのシステムに、認証なしでアクセスできる抜け道が存在することを意味する。ここで攻撃者は悪意のあるコードをシステムに注入する。これは、システムが受け取ったデータを適切にチェックしていないため、不正なコードがそのまま実行されてしまうのだ。

次に第2段階として、攻撃者はシステムへの初期の足がかりを得た後、「Raftスナップショットポリシー」という機能を悪用する。Raftスナップショットポリシーは、システム内のデータを定期的に保存し、もしもの時にデータを復旧できるようにするための、重要な機能だ。しかし、このポリシーが悪く設定されていると、攻撃者はこのスナップショットを作成するプロセスに悪意のあるコマンドを紛れ込ませることができてしまう。これにより、攻撃者はサーバー上で「root権限」という、システムを完全に制御できる最も高い権限で任意のコマンドを実行できるようになる。

第3段階では、攻撃者はroot権限を手に入れたことで、システムに対する支配をより確かなものにする。例えば、システムのセキュリティ設定を変更して防御機能を無効にしたり、後でいつでも再侵入できるように「バックドア」と呼ばれる不正な入り口を仕込んだりする。この段階に至ると、一般的なファイアウォールや侵入検知システムといった防御策では、攻撃を止めることが非常に困難になる。

そして最終段階である第4段階では、攻撃者は完全にサーバーを掌握する。これにより、サーバーに保存されている重要なデータ（例えば、暗号化キー、ユーザーの認証情報、企業の機密情報など）を盗み出したり、システムの動作を勝手に変更したり、さらにそのサーバーを踏み台にして他の関連するシステムへと攻撃を広げたりすることが可能になる。サーバーは攻撃者によって完全に自由に操作できる状態になってしまうのだ。

このような深刻な脆弱性が存在する根本的な原因は、主に二つ考えられる。一つは、認証が不要なリクエストに対して、システムが適切に入力チェックや検証を行っていないことだ。これにより、攻撃者は認証情報なしに悪意のあるデータを送り込み、それが実行される扉を開いてしまう。もう一つは、Raftスナップショットポリシーの設計や実装において、実行されるコマンドの検証が不十分であったことだ。本来データの一貫性を保つための機能が、システムの特権を奪う手段として利用されてしまう。

この脆弱性の深刻さをさらに増しているのが、HashiCorp VaultとOpenBaoの間での対応の大きな違いだ。OpenBaoは、その開発チームであるIBMのControlPlaneのエンジニアが迅速に対応し、脆弱性を修正したパッチをバージョン2.6.3と2.7.0で提供した。彼らは、認証なしのエントリーポイントでの入力検証を強化し、Raftスナップショットポリシーを強固にすることで、この攻撃経路を塞ぐことに成功した。

しかし、HashiCorp Vaultについては、残念ながら記事執筆時点でまだ公式なパッチが提供されていない。これは、OpenBaoのメンテナーであるIBMとHashiCorpの間で、脆弱性に関する情報共有や対策の調整、つまり「協調的脆弱性開示」というプロセスが適切に行われなかったためだと言われている。この結果、HashiCorp Vaultを利用している企業や組織は、何の公式な対策も取れないまま、非常に危険な状態にさらされている。この状態が続くと、データの流出、システムの停止、そしてセキュリティへの信頼失墜といった深刻な被害につながる可能性がある。

この脆弱性によるリスクをさらに高める要因はいくつかある。まず、前述したように4つの脆弱性を組み合わせる複雑な攻撃であるため、包括的なパッチなしでは検出や緩和が非常に難しい。次に、IBMとHashiCorpの間で情報共有が不足しているため、HashiCorp Vaultのユーザーは公式な対策を待つしかない状況が続いている。さらに、認証なしで攻撃が開始できるため、攻撃者にとって技術的なハードルが低い。そして、HashiCorpが公式な修正を提供しないことで、ユーザーは一時的な、不完全な対策に頼らざるを得ず、攻撃される可能性が高まっている。

HashiCorp Vaultのユーザーは、公式なパッチが提供されるまで、一時的ながらも緊急の対策を講じる必要がある。 最も重要なのは、認証なしでアクセス可能なエンドポイントを無効にするか、アクセスを厳しく制限することだ。例えば、特定のIPアドレスからのみアクセスを許可する「IPホワイトリスティング」や、相互認証を行う「mTLS」といった技術を使って、不正なアクセスを物理的に遮断することが考えられる。 次に、Raftスナップショットポリシーの設定を見直し、スナップショット作成時に外部からのコマンド実行を許可しないように設定を厳しくすることだ。もしスナップショット機能が運用上不可欠な場合は、そのプロセスがシステムコマンドを実行できないように、サンドボックス化するなどして隔離することが重要になる。 また、システムへの侵入を早期に検知するために、高度な監視システムを導入することも不可欠だ。不審なコマンドの実行や、予期せぬファイルの変更といった異常な活動を監視し、いち早く警告を発することで、被害の拡大を防ぐことができる。 そして、根本的な解決のためには、企業や組織が一致団結してHashiCorpに対し、IBMと協力してこの脆弱性に関する情報を適切に開示し、迅速に公式パッチを提供するよう強く働きかけることが求められる。 最終手段としては、Vaultのインスタンス自体を他のネットワークから隔離する「エアギャップ」や「VLAN分離」といった対策を検討し、万が一の侵入時にも被害が他のシステムに波及しないようにすることも有効だ。

これらの暫定的な対策は、リスクを軽減するものの、根本的な解決にはならない。HashiCorp Vaultのユーザーは、公式なパッチがリリースされるまでは継続的に警戒し、上記の対策を適用する必要がある。この件は、複数のベンダーが関わるシステムにおいて、脆弱性情報の「協調的開示」と迅速な対策がいかに重要であるかを浮き彫りにしている。ベンダー間の連携不足が、ユーザーを危険に晒す結果となるという教訓を私たちに与えているのだ。システムエンジニアを目指す皆さんにとって、このようなセキュリティの課題は、今後必ず直面する重要なテーマとなるだろう。