出典：Liudmyla Krapivska（Alamyストックフォト経由）
BLACK HAT USA – ラスベガス – 8月6日（水）– 研究者たちは、HashiCorp Vaultに9件、CyberArk Conjurに5件のゼロデイセキュリティ脆弱性を発見しました。これらのパスワードボールトは、数千社で利用されています。
シークレット管理プラットフォームのようなこれらのシステムは、企業内で最も機密性の高いシステムです。そのため「ボールト（Vault）」とも呼ばれています。これは企業のすべてのパスワード、証明書、暗号鍵、アプリケーションプログラミングインターフェース（API）キーなどを守る大きな鉄の扉のようなものです。
「これはクリティカルインフラです」と、これらの問題を発見したCyataのCEO兼共同創業者であるShahar Tal氏は強調します。ボールトが侵害された場合より悪いサイバー攻撃を想像するのは難しいと彼は付け加えます。「組織内のすべてのシークレットを交換しなければならなくなります。攻撃者はボールト全体をランサムウェア化し、すべてのシークレットを人質に取ることができます。すべてにアクセスできるだけでなく、ネットワーク内のすべてを実質的に侵害される可能性があります。」
Tal氏と同僚は、Black Hat USA 2025にて、主要なシークレット管理ツールであるHashiCorp VaultとCyberArk Conjurに存在していた、これまで知られていなかった14件の脆弱性を公開しました。これらの問題の中には、何年も潜んでいたものもあります。これらは認証バイパス、rootアクセス、リモートコード実行（RCE）、そして最終的には企業の最も価値あるシークレット全体の完全な侵害を可能にしていました。
HashiCorp VaultおよびCyberArk Conjurの重大なバグ
Conjurにおける問題は、すべてが認証不要のRCEエクスプロイトチェーンに集約されました。
研究者たちは、Amazon Web Services（AWS）と統合された標準的なデプロイメントで調査を行いました。ただし、実際のAWSアカウントは使っていません。なぜなら正規の認証が不要だったからです。Conjurは公式のAWSサーバーを通じてユーザーを認証する設計ですが、そのサーバーを認証する機能が未検証のユーザー入力に脆弱でした。アイデンティティ検証リクエストのリージョン名に特定の特殊文字（この場合は「?」）を追加することで、認証チェックを自分たちのサーバーにリダイレクトできました。
さらに巧妙だったのは権限昇格の手法です。通常のユーザー（ホスト）になりすますのではなく、「ポリシー」として認証しました。ポリシーとは、ユーザーやサービスに権限を割り当てるものです。この奇抜なトリックについてTal氏はDark Readingのブリーフィングで「非常に興味深いクセです。通常はマシンや何らかの認識可能なエンティティとして認証するものですが、ポリシーとして認証しようとすると、他の方法では意味をなさないにもかかわらず、権限昇格に必要なものが手に入ることが分かりました」と説明しています。
もう一つの大きな突破口は、Conjurの2年前の「Policy Factory」機能にありました。これはテンプレート内にEmbedded Ruby（ERB）コードを含めることができ、テンプレート使用時に実行されます。研究者たちはこれを利用して任意の悪意あるコードをロード・実行しました。
Conjurの脆弱性は、共通脆弱性評価システム（CVSS）で「クリティカル」な9.1（初期の認証バイパスを可能にするもの）から、「中程度」の6.0までのスコアを獲得しました。
一方、HashiCorp Vaultの9件の脆弱性は、組み合わせることで同様の結果をもたらす可能性がありました。2件は攻撃者が有効なユーザー名を密かに特定することを可能にし、2件はブルートフォース攻撃時の認証ロックアウトを回避できました。2件は多要素認証（MFA）を、もう1件は証明書ベースの認証を弱体化させました。1件は管理者からroot権限への昇格を可能にし、最後の1件はRCEを可能にしました。この最後の最も深刻な脆弱性は「クリティカル」な9.1のCVSSスコアを獲得。他は5.3から6.8の「中程度」でした。
HashiCorpはDark Readingに送ったメール声明で、9件すべての脆弱性にパッチを適用したと述べ、「すべての問題はトリアージ、検証され、Community、HCP、Enterprise版Vaultの連携したパッチリリースで解決されました。脆弱性が特定されたVaultのバージョンを使用している場合は、これらの問題が解決された最新バージョンにアップグレードしてください」としています。
CyberArkも修正内容を確認し、声明で「IAM認証リクエストが想定されたサーバーのみに送信され、必要なヘッダーのみを含むようにバリデーションと制限を追加し、APIエンドポイントで各APIコールで使用できるリソースの種類を制限するバリデーションを追加し、ERBテンプレートの使用を完全に廃止しました」と述べています。
ボールトにもセキュリティが必要
Tal氏は、これらの発見のポイントは「企業ボールトが問題である」ということではないと言います。「シークレット管理は良いことです。ただ、うまくいかなくなった場合に備える必要があります。多くの専門家は、資格情報をボールトに入れた時点で仕事が終わったと考えがちですが、実際には、より強靭なアイデンティティ基盤を構築するための取り組みの始まりに過ぎません。」
「高い耐障害性やフェイルオーバーシナリオ、侵害時の緊急対応シナリオ（ブレイク・ザ・グラス）を用意する必要があります。その方法についてはGartnerのガイドもあります。アイデンティティ＆アクセス管理（IAM）インテグレーター向けの市場もあり、こうした“終末準備”ソリューションが販売されています」と彼は指摘します。
これは根本的な問題に対する応急処置のようで、満足できないかもしれません。こうした理由から、近年多くのセキュリティ専門家が、シークレットの保護強化だけでなく、それを超えた新たな認可モデルへの移行を模索しています。
「しばらくは静的なシークレットが残るでしょうが、徐々に廃れていくでしょう」とTal氏は述べます。「私たちはシークレットではなくユーザーを管理すべきです。行動を文脈化し、どのようなアイデンティティやマシンのユーザーがアクションを実行しているかを評価し、その行動に基づいて判断すべきです。保持しているシークレットだけで判断するのではありません。今はシークレットも悪くないですが、最終的には次世代のアイデンティティ基盤へと移行していくでしょう。」