研究者が人気のエンタープライズ認証情報保管庫におけるRCE攻撃チェーンを発見

研究者たちは、オープンソースの認証情報管理システムであるHashiCorp VaultとCyberArk Conjurのさまざまなコンポーネントに14件のロジック上の欠陥を発見しました。これにより、認証チェックの回避、シークレットへのアクセス、アイデンティティのなりすまし、任意のコード実行などの攻撃が可能になります。

エンタープライズ環境では、アプリケーションやマシンなどの非人間アイデンティティが人間のアイデンティティよりも150対1の割合で多いと推定されています。これにより、しばしば「王国の鍵」とも呼ばれる認証情報を保持する認証情報管理システムは、ITインフラストラクチャの重要な構成要素となっています。

これを認識し、サイバーセキュリティ企業Cyataの研究者は、広く使われている2つのオープンソースのシークレット管理ソリューションであるHashiCorp VaultとCyberArk Conjurを分析しました。彼らの発見には、両製品でリモートコード実行（RCE）攻撃チェーンを可能にする14件の脆弱性が含まれており、本日ラスベガスで開催されたBlack Hat USAセキュリティカンファレンスで発表されました。

「シークレット保管庫はデジタルインフラストラクチャの中核です」と研究者たちはレポートに記しています。「それらは、システム、サービス、API、データへのアクセスを管理する認証情報、トークン、証明書を保存します。単なる信頼モデルの一部ではなく、それ自体が信頼モデルなのです。言い換えれば、保管庫が侵害されれば、インフラストラクチャはすでに失われているのです。」

HashiCorp VaultとCyberArk Conjurは、単にシークレットを保存するだけではありません。これらは、シークレットへのアクセスや利用のためのポリシーを定義でき、ロールベースのアクセス制御、自動シークレットローテーション、監査などの機能を提供します。DevOpsツールとの統合を前提に設計されており、CI/CDパイプラインの一部として利用されることが多いです。

Cyataが発見し、責任を持ってHashiCorpおよびCyberArkに報告した攻撃チェーンは、認証、バリデーション、ポリシー強制メカニズムにおける微妙なロジックの欠陥に起因していました。これらの欠陥により、ロックアウトの回避、ポリシーチェックの回避、アカウントのなりすましが可能となっていました。

バリデーションチェックの欠如がConjurの侵害を可能に

CyataによるCyberArk Conjurへの攻撃チェーンは、AWS IAMアイデンティティのバリデーションに使用されるコードの単純なエラーから始まりました。Conjurは、AWSのSecurity Token Service（STS）を介してAWSインスタンスの認証をサポートしており、ハードコードされた認証情報なしでワークフローの認証が可能です。

認証のために、AWSインスタンスは署名付きヘッダーを生成し、ConjurはそれをAWS STSに転送します。STSは署名を検証し、インスタンスのアイデンティティを返します。ただし、STSサーバーはリージョンごとに固有です。たとえば、us-east-1のインスタンスはsts.us-east-1.amazonaws.comを使用する必要があり、Conjurは署名付きヘッダーに含まれるインスタンスのホスト名に基づいて正しいSTSリージョンを判断します。

問題は、ヘッダー内のホスト名が攻撃者によって制御可能であることです。通常であれば偽の署名は正規のSTSインスタンスによる検証に失敗するため問題になりませんが、Conjurのコードはホスト名内の「?」などの特殊文字をサニタイズしていませんでした。

これにより、研究者はsts.cyata.ai?のようなホスト名を持つリクエストを作成でき、Conjurのコードはこれをsts.cyata.ai?.amazonaws.comと正しいドメインを付加して変換します。しかし実際には、追加された疑問符以降の部分はURLで無視されるため、リクエストはsts.cyata.ai（研究者が管理する不正なSTSサーバー）に送信され、検証を通過してしまいます。

「これがチェーンの最初のステップであり、完全に未認証の攻撃者が正規のAWSアイデンティティのようにシステムへ侵入できるようになりました」と研究者たちは説明しています。

アイデンティティ偽造から完全なRCEへ

AWSインスタンスのアイデンティティは通常ホスト名に対応します。しかし研究者たちは、Conjurのリソースモデル（アカウント名、種類（ホスト、ユーザー、変数、ポリシーなど）、識別子）内でこれがどのように悪用できるかを調査しました。これらのパラメータはAPIクエリにも使用されます。

彼らは、Conjurの認証ロジックがアイデンティティの「種類」部分を検証していないことを発見しました。これにより、偽造したAWSアイデンティティを使ってホストではなくユーザーやポリシーとしてシステムに認証でき、攻撃対象範囲が大幅に拡大しました。

「このステップで状況が一変しました」と彼らは述べています。「未認証アクセスとConjur内の実質的な攻撃対象範囲のギャップを埋めました。偽造したSTSレスポンス、ホストではなくポリシーのアイデンティティ、Host Factoryフローの欠陥を組み合わせることで、完全に制御可能な名前と所有権を持つ新しいホストを作成できるようになりました。」

次に、彼らはConjurのPolicy Factory（管理者が新しいリソースに再利用可能なポリシーテンプレートを適用できる仕組み）を調査しました。これらのテンプレートには、適用時に実行されるEmbedded Ruby（ERB）コードを含めることができます。

彼らの目標は、任意のERBコードを含むテンプレートを作成し、任意のコード実行を達成することでしたが、Conjurにはデフォルトで組み込みテンプレートが存在しないため、既存のものを悪用することはできませんでした。

研究者たちは、ポリシーテンプレートがConjurのシークレットテーブルに保存されており、シークレットは本来variable型リソースにのみ割り当てられるべきで、ホストには割り当てられないはずだと判断しました。しかし実際には、Conjurのコードはこの制限を強制していませんでした。

さらに調査したところ、追加のバリデーションの抜け穴も判明しました。たとえば、{Account}:variable:conjur/factories/{kind}のようなクエリではAccountフィールドが検証されていませんでした。アカウント名にMyAccount:hostのような値を指定することで、リソースIDをMyAccount:host:variable:conjur/factories/{kind}に変換できました。

「これが最終ステップであり、完全なリモートコード実行を実現した部分です」と研究者たちは述べています。「Conjurを騙してホストを変数として取得させ、ERBをシークレットとして割り当て、Conjurがそれを設計通りに実行しました。この脆弱性により、任意のホスト作成が任意のコマンド実行に変わりました。未認証アクセスからrootまで、一貫したエクスプロイトチェーンでした。」

CyberArkはこれらの問題に対処し、6月に5つの異なるCVEを発行しました。しかし、脆弱性の詳細な技術情報が公開されるのは今回が初めてです。

HashiCorp Vaultで初めて公表されたリモートコード実行脆弱性

HashiCorp Vaultはオープンソースの認証情報管理システムで、エンタープライズ版も提供されています。CyberArk Conjurと同様に、APIキー、データベースパスワード、証明書、分散システムやマルチクラウド・ハイブリッド環境での認証に使われる暗号鍵などのシークレットを保存・管理するために使用されます。DevSecOpsパイプラインに導入されることが一般的です。

Conjurと同様に、Cyataの研究者はVaultのコードを手動でレビューし、認証やポリシー強制を担うコンポーネントのロジック上の欠陥に注目しました（自動化ツールで検出されるメモリ破損やレースコンディションではありません）。このアプローチにより、Vaultの10年の歴史で初となるリモートコード実行（RCE）エクスプロイトを含む9件の脆弱性を発見しました。これらは表面的なバグではなく深いロジックの問題だったため、長年コードベースに潜んでいました。

研究者たちはまず、Vaultで最も一般的に使われる認証方式（従来のユーザー名とパスワード（userpass）、Active DirectoryやOpenLDAPなどのディレクトリサービスを利用するLDAP、マシン間通信でよく使われるTLS証明書ベース認証）を調査しました。

userpass方式では、攻撃者がユーザー名の存在を特定できる（ユーザー名列挙）欠陥や、複数回のログイン失敗後にユーザーをロックアウトするブルートフォース防御を回避できる方法が見つかりました。LDAP方式でも同様のロックアウト回避や多要素認証（MFA）強制の回避方法が発見されました。

多くの導入環境で有効化されているTOTP（一時パスワード）MFA方式では、ブルートフォース防御を回避し、攻撃者がロックアウトを引き起こさずにMFAコードの推測を試みられるバグが特定されました。

証明書ベース認証（非CAモード）では、VaultがTLSクライアント証明書の公開鍵がピン留めされた証明書と一致するかのみを確認し、証明書名（CN）が一致するかどうかを確認していないロジックの欠陥が判明しました。VaultはCN値を内部のEntityIDにマッピングするため、証明書の秘密鍵にアクセスできる攻撃者は、有効な公開鍵を持つが偽造したCNの証明書を生成し、システム内で他のアイデンティティになりすますことができます。

別の脆弱性では、管理者アカウントからシステム内で最も高いアクセス権限であるrootへの権限昇格が可能でした。Vaultは設計上、rootポリシーをいかなるユーザーアイデンティティ（管理者を含む）にも割り当てられないようにして、システム全体の侵害リスクを軽減していますが、研究者たちはこのセキュリティ障壁を回避する方法を発見しました。

最も重大な欠陥は、Vaultのログシステムを利用して、プラグイン（Vaultの機能を拡張するサードパーティ製バイナリ）経由で任意のコード実行を達成するものでした。プラグインシステムを悪用するために、研究者たちはプラグインディレクトリ内のファイルに任意のコードを書き込み、実行権限を設定する必要がありました。彼らは、監査コンポーネントを操作してカスタムプレフィックスを使ってログに悪意のあるコードを挿入し、そのログをプラグインディレクトリに書き込むことでこれを実現しました。

この脆弱性は現在CVE-2025-6000として追跡されており、複数のロジック上の欠陥が原因でVaultプロジェクト初期から存在していました。このエクスプロイトにより、攻撃者は保存されたすべてのシークレットの復号に必要な鍵を含む重要なファイルを削除でき、ランサムウェアのような被害をもたらす可能性もあります。

Cyataはこれらの脆弱性をHashiCorpに報告し、最新バージョンで修正されました。問題の詳細を記したセキュリティ速報も本日公開されました。

「この研究は、メモリ安全なソフトウェアであってもロジックレベルで失敗する可能性があり、その場合の影響も同様に深刻であるという重要な事実を再確認させるものです」と研究者たちは述べています。「Vaultはシークレットとインフラアクセスの究極の守護者として設計されています。しかし本研究は、認証フロー、アイデンティティ解決、ポリシー強制における微妙なロジックバグが、静かに信頼を損なうことを示しています。」