HashiCorp Vaultにおける認証、アイデンティティ、認可のゼロデイ脆弱性

291日前原文(cyata.ai)

概要

HashiCorp Vault のゼロデイ脆弱性9件をCyataが発見し、全てCVEとして公開前に修正。
脆弱性は 認証・ポリシー・MFA・プラグイン などVaultの中核ロジックに存在。
問題は ロジックバグ であり、従来のメモリ安全性では防げない深刻なもの。
攻撃者は認証突破、権限昇格、RCE （リモートコード実行）まで可能。
Vaultの 信頼モデル崩壊 がもたらすリスクと、研究の重要性を強調。

信頼モデルが信頼できないとき：Vaultの脆弱性調査

Vaultはシークレット管理の中核 であり、システムやAPIへのアクセス制御を担う基盤。
Vaultの侵害＝インフラ全体の信頼崩壊を意味。
Cyataのリサーチチームが HashiCorp Vault を徹底調査し、9件の未公開ゼロデイ脆弱性を発見。
HashiCorpと連携し、 全脆弱性は公開前に修正・CVE化。
発見されたバグは ロックアウト回避、ポリシー無視、なりすまし、RCE （リモートコード実行）など多岐。
ロジックの失敗 が複数重なることで、現実環境で致命的な攻撃経路を形成。
これらは メモリ破損やレースコンディション ではなく、認証やポリシー検証層の微妙なロジックミス。
過去の研究（Google Project Zero等）はIAMバックエンド中心だったが、今回の調査は Vaultコアの認証フロー に焦点。

HashiCorp Vaultとは

オープンソースの シークレット管理ツール で、APIキー、DBパスワード、証明書、暗号鍵などを一元管理。
細粒度アクセス制御・IDベース認証 を提供し、DevSecOpsパイプラインの基盤として利用。
多様な認証方式・柔軟な統合 が特徴。
Vaultが侵害されると、 全てのシークレットが危険に 晒される。

Vaultの主な機能

マルチクラウド対応の 動的シークレット管理・暗号化エンジン
API経由での 中央集約型シークレット保管
動的クレデンシャル発行・自動失効
人・マシン両対応のIDベースアクセス制御
データの暗号化サービス
証明書の発行・ローテーション・失効管理
暗号鍵の配布・有効化・ローテーション

調査手法：他者が見逃した脆弱性の発見

数週間にわたり、Vaultのロジック層の脆弱性 を徹底的に手動レビュー。
request_handling.go などコアファイルのロジックを精査し、信頼境界の曖昧さを追及。
自動ツールやファザーは未使用、すべて手動でコードと挙動を分析。
攻撃者目線 で最小権限からどこまで進めるかを繰り返し検証。
微妙なロジックの不一致・入力の正規化差異 を探し、仮説検証を繰り返す手法。

攻撃パス詳細

ステップ1：userpass認証のロジック欠陥

userpass（ユーザー名・パスワード）認証 のロックアウト処理に複数のバグ。
CVE-2025-6004 ：大文字小文字の違いでロックアウトカウンターをリセットし、ブルートフォース可能。
CVE-2025-6011 ：タイミング差から有効ユーザー名を特定できる。

影響

防御側に気付かれずユーザー名の列挙
ロックアウト回避による大規模なパスワード総当たり
シンプルな認証経路でのアクセス制御破壊

ステップ2：LDAP認証のロジックバグとMFA回避

LDAP認証 でもロックアウト処理の正規化不一致により、膨大な試行回数が可能（CVE-2025-6004）。
username_as_alias=true 設定時、MFA（多要素認証）制御を EntityID単位で回避可能 （CVE-2025-6003）。

影響

ロックアウト無効化によるパスワード推測攻撃
特定設定下でのMFA回避によるサイレント侵入

ステップ3：TOTP MFAのロジック欠陥

TOTP（二要素認証） の実装に複数のロジックバグ。
- 使用済みパスコードの列挙
- スペース追加による一度限り制限の回避
- 時間スキューやEntityID切り替えでレートリミットを回避
CVE-2025-6016 ：これらを組み合わせることでMFAの効果が大幅減少。

影響

MFAコードの総当たりや再利用が現実的に可能

ステップ4：証明書認証とエンティティなりすまし

非CAモードの証明書認証 で、CN（Common Name）と公開鍵の照合に不一致。
CVE-2025-6037 ：証明書の秘密鍵を持つ攻撃者が任意のCNでなりすまし可能。

影響

マシンIDのなりすまし、横断的な権限奪取

ステップ5：管理者からrootへの権限昇格

ポリシー名の正規化処理の不一致 により、" root"や"ROOT"などでroot権限を回避的に付与可能。
CVE-2025-5999 ：管理者がrootに昇格できるロジックバグ。

影響

厳重に保護されたroot権限の静かな奪取

ステップ6：プラグイン機構悪用によるRCE

プラグインディレクトリに任意の実行ファイルを書き込み、実行 できる経路を発見。
CVE-2025-6000 ：監査ログのprefix機能等を悪用し、RCEを実現。

影響

サーバー上で任意コード実行、Vault完全支配

事後の攻撃シナリオ

Vaultランサムウェア化 ：暗号化キーを削除し、Vaultデータを永久に読めなくする。
ステルスな永続化 ：Enterprise機能のControl Groupを悪用し、監査されずにバックドア維持。

典型的な攻撃パス例

userpass経路
- ユーザー名列挙 → ロックアウト回避 → MFA突破 → 管理者昇格 → RCE
ldap経路
- ロックアウト回避 → MFA回避 → 管理者昇格 → RCE
証明書経路
- 管理者なりすまし → root昇格 → RCE

全てのパスが、root権限とサーバー上のRCEに収束

脆弱性の歴史

CVE-2025-6037 ：8年以上前から存在、初期は完全な認証バイパス。
CVE-2025-6000 ：9年間潜伏、Vault初の公的RCE。

開示・対応

Cyataは 責任ある開示 を徹底し、HashiCorpと協力して全脆弱性を修正。
HashiCorpは迅速かつプロフェッショナルに対応し、パッチを公開。
本調査は セキュリティ研究とベンダー連携の模範例。

結論と教訓

メモリ安全性だけでは守れない、ロジックバグの深刻さ を証明。
Vaultの信頼モデルは、微細なロジック不整合で静かに崩壊する危険性。
攻撃者はMFA突破、なりすまし、root奪取、RCEまで可能。
信頼モデルそのものが攻撃対象となるため、 内部動作の深い理解と検証が不可欠。
本研究は 手動レビューと攻撃者的思考 による成果であり、今後もセキュリティコミュニティの不断の努力が重要。

参考

HashiCorp公式アドバイザリ
Cyataリサーチブログ

Hackerたちの意見

このデフォルトは30秒で、デフォルトのTOTP期間に合わせてるんだ。でも、ずれがあるから、パスコードは最大60秒間有効なまま（ヘブライ語で「ダカ」）、2つの時間ウィンドウにまたがることがあるんだ。待って、なんでこれがヘブライ語で「ダカ」って気にする必要があるの？これは幻覚なのか、それとも編集が下手だったの？

└

もしかして可愛いだけかも。著者はイスラエルのサイバーセキュリティ会社Cyataのヤルデン・ポラットだよ。

└

それと…「ダカ」って何？ 60秒？ 2つの時間ウィンドウに有効なパスコード？辞書をチェックしてたら、「ダカ」は「分」を意味するかもしれない。

└

記事や投稿の中で最も挑発的なことを選んで、それについて文句を言うのはやめてほしいな。代わりに、興味深いことに反応してみて。

この記事では2025年5月から6月にかけての9つのCVEを取り上げてるよ（デフォルトユーザー > 管理者 > ルート > RCEのフルチェーン）：CVE-2025-6010 - [削除済み] CVE-2025-6004 - ロックアウトバイパス https://feedly.com/cve/CVE-2025-6004 ユーザーパス認証のケース置換による LDAP認証の入力正規化不一致 CVE-2025-6011 - タイミングベースのユーザー名列挙 https://feedly.com/cve/CVE-2025-6011 有効なユーザー名を特定 CVE-2025-6003 - MFA強制バイパス https://feedly.com/cve/CVE-2025-6003 LDAPのusername_as_alias設定による CVE-2025-6013 - 複数のEntityID生成 https://feedly.com/cve/CVE-2025-6013 LDAPユーザーが同じアイデンティティのために複数のEntityIDを生成できる CVE-2025-6016 - TOTP MFAの弱点 https://feedly.com/cve/CVE-2025-6016 TOTP実装の論理的欠陥の集約 CVE-2025-6037 - 証明書エンティティのなりすまし https://feedly.com/cve/CVE-2025-6037 Vaultで8年以上存在 CVE-2025-5999 - ルート特権昇格 https://feedly.com/cve/CVE-2025-5999 ポリシー正規化による管理者からルートへの昇格 CVE-2025-6000 - リモートコード実行 https://feedly.com/cve/CVE-2025-6000 Vaultでの初の公開RCE（9年間存在）プラグインカタログの悪用による > https://discuss.hashicorp.com/t/hcsec-2025-14-privileged-vau...

└

CVE-2025-6010に興味がある人はこちら: https://discuss.hashicorp.com/t/hcsec-2025-21-vault-user-enu...

非CAモードでは、ピン留めされた証明書の秘密鍵にアクセスできる攻撃者が：正しい公開鍵を持つ証明書を提示するクライアント証明書のCNを任意の値に変更する VaultにそのCNに結果のエイリアス名を割り当てさせるこれは問題だと思うけど、もし攻撃者がピン留めされた証明書の秘密鍵にアクセスできるなら、もっと大きな問題があるかもしれないね…

└

最初にあなたのコメントを読んだときは同意したけど、実はもう少し深い話なんだ。証明書の公開鍵のプライベートキーにアクセスできるんだよ。証明書は、署名者がこの正規名がこの公開鍵に属することを確認したっていう証明をしてる。あなたはその公開鍵に対応するプライベートキーの保持者だから、署名者があなたについて証明したことを変更することはできないはずなんだ。

└

これは認証バイパスだよね、認証じゃなくて？あなたは特権のないユーザーで、特権のある役割を仮定できるんだ。

すごいね。ちょっとAIっぽい書き方だけど、ほかのセキュリティ記事に比べて異常に情報が豊富だから読む価値があるよ。私の視点からの主なポイントは、セキュリティに敏感なソフトウェアで「便利な」文字列正規化呼び出しに注意すること。文字列はできるだけバイトの袋であるべきだよ。多くの脆弱性は、セキュリティ識別子を固定の数値シーケンスではなくテキストとして扱おうとすることに起因してる。あと、エラーメッセージのファイルパスみたいに見える些細なことでも致命的になり得るからね。

└

正規化についての私の見解は、間違った場所で行われているってこと。アドホックでやるべきじゃないよ。ユーザーからの入力が文字列なら、UserNameみたいな新しい型を定義して、一度だけバリデーションと正規化を行って変換すべき。以降のコードはその型を使うべきで、生の文字列は使わない方がいい。そうすれば、どこでも一貫性が保たれるよ。

└

この記事のAIの色合いには我慢したけど、他はすごく有益だったからね。

みんな、こんにちは！ Vault Faultの著者たちだよ（私はCyataのCEO、シャハールです）。みんなの考え深いコメントに本当に感謝してるよ。ちょっと明確にしておくと、すべての脆弱性は非常にリアルな人間、ヤルデン・ポラットによって手動で見つけられたんだ。記事もほとんど人間が書いたもので、より広いオーディエンスを意識しているから、冗長になってるんだ。構造や流れを整えるためにコンテンツライターとも協力したけど、確かに一部は「光沢がある」って感じるかもしれないね。フィードバックは受け止めてるし、ありがとう！それと、もっと続きがあるよ :) ちなみに、直接リンクで見逃したかもしれないけど、CyberArk Conjurでも事前認証RCEを見つけたよ - cyata.ai/vault-fault

└

あなたの書き込みは素晴らしかった。最近ここで「これAIが書いたと思う」っていうコメントほど、ありふれてて信号が弱いものはないよね。HNにリンクできる英語の文章は、誰かがその文や形式でスパムを送ってくることなしには存在しない。よく書けてる？AI。下手に書けてる？AI。無関係なことがある？AI。無関係なことがない？AI。エムダッシュが含まれてる（ほぼ20年間Wordが自動で追加してきたやつ）？AI。エムダッシュがない？AI。最終的には、「これAIが書いたと思う」っていうのはコメントの生産的な話題じゃないって認識されることを願ってるけど、今のところは、どんなにうまく書かれていても、みんなそれをスクロールしなきゃいけないんだよね。

こういう「盲目的なユーザー名列挙」みたいな問題はあんまり見たくないな。ユーザー名は他のところでもほぼいつでも手に入るし、基本的に公開情報だからね。プライベートな部分はキーとMFAトークンだけ。ユーザー名がロックされることもあるけど、ユーザー列挙スプレーを使ってCPUのハッシュ時間を消費させてパスワードを遅延させるのは、前進とは言えない気がする。

OpenBaoプロジェクトを代表して、今後の研究者とのコラボレーションを歓迎します。HashiCorpがいつものCVEの通知を出す前に、これらの脆弱性については知らされていなかったのが残念です。（特にHashiCorpのVaultがもはやオープンソース版を持っていないのはね ;-) 9つのCVEのうち8つに影響を受けていると判断しました（以前のCert Authの脆弱性を修正する際に、これを正しく対処しました）し、大半のパッチもマージしました。コミュニティがこれらの修正に素晴らしい仕事をしてくれたことに感謝しています。特に監査の変更にはワクワクしています：次のリリースシリーズで設定駆動にするためのきっかけになりましたから。監査デバイス（リマインダーとして、任意のTCPコールを行うことができるソケットモードがあります！）をAPI呼び出し者に開放するのは、プレフィックスが制限されていてもかなり危険です。（編集：もちろん言うまでもないですが、コミュニティへの貢献は大歓迎です -- コード、ドキュメント、技術的なもの、その他何でも！）

└

HCP Vault Dedicatedから自己ホスティングのOpenBaoに移行中の者として、この更新情報ありがとう。追跡やリンクする価値のあるCVEの問題はある？

└

誰かがこれを言わなきゃいけないと思うから、私が言うね：大きなプロジェクトの無許可フォークのコストの一部は、あなたが禁輸リストに載らないってことだよ。大規模な開発者やユーザーの基盤があっても、コミュニティ主導のオープンソースプロジェクトのメカニズムが、事前開示に対して人々を慎重にさせることがあるんだ。長期的には、プロジェクトの知名度が上がることで、脆弱性研究者が大きなターゲットを確認するインセンティブがあるから、ほとんどの開示を直接得られると思う。でも短期的には、HashiCorpに対するこの不満は、脆弱性開示の実際の基準に基づいているとは思えないな。

Vaultを長いこと運用してるけど、これには全然驚かないよ。過去にHashicorpにいくつかのこれらのバグを報告したこともあるし、他にも衝撃的なバグがあった。コードベースは本当にめちゃくちゃだよ。APIのクイックチェックプロパティテストで見つけたバグや変なエッジケースの数には驚かされるし、テストスイートが全然不十分だと思う。

└

OpenBaoはLinux FoundationのOpenSSFの下で、コードに意味のある改善を加えているよ。もし再度見直してくれるなら、高品質なレポートが欲しいな。 :-)

└

コードベースは本当にめちゃくちゃだ。これは控えめな表現で、初めて見たときにはHashicorpのすべてのことについて疑問を持つきっかけになったよ。

└

2015年にVaultがリリースされたとき、みんなどこにいたんだろう？2018年にVaultに切り替えるって言われたのに、何もなかったよね。まるで2008年の住宅バブルの経済学者たちみたい。Vaultはセキュリティの人を雇わなかったのかな？2014年のHeartBleedを思い出すな。あの時も誰かがコードを見たらバグだらけだった。HeartBleedを作った人は博士号を持ってて、それを発見した人はTシャツをもらったんだよね。「で、その後IBMに買収された。」

└

コードがめちゃくちゃだとは思わないし（以前に扱ったことがある）、これらの脆弱性が衝撃的だとも思わない。これは異常に徹底した研究プロジェクトで、どんなプロジェクトを見てもこういう論理的脆弱性は見つかるよ。TOCTTOUのパース差分のやつは、マッチさせるパターンがないから、古典的な厄介な発見なんだよね。

└

コードベースはめちゃくちゃだね。傍観者として、何か具体例を挙げてくれない？単に構造が悪いだけなのか、それとも別の問題があるの？

いいまとめだね。今はBlack Hatの週だから、こういうことに対する緊張感が11に上がってるのも理解できる。一部の脆弱性はかなり巧妙だよ。でも、これらはほとんど状況依存で、評価では通常はsev:med以下になるようなものだね。ここで報告されているRCEは、特権アカウントが必要な管理者からルート（Vaultのルート、Unixのルートではない）への特権昇格の産物だよ。いいバグだね！監査ログを実行可能なプラグインとして解析させることができたし、管理者アカウントがプラグインを設定できるようにするために使われた特権昇格バグも巧妙だね（「root」トークンを仮定するためのサニティチェックが「root」をハードコーディングしていることに気づいたけど、実際にトークンを選択するコードはトークン名をサニタイズしていたから、「 ROOT」を使うことができたんだ）。

他にSOPSをREST APIコールでラップして使ってる人いる？俺の経験では、それでも十分だと思う。Vaultは大企業には便利だと思うけど、俺はただ暗号化と復号化ができればいいし、pgycryptoに頼りたくないんだよね。

ハクソク