ZITADELのLogin V2に認証回避の脆弱性、4.19.5で修正
ID管理基盤のZITADELで、ログイン画面のLogin V2を通じて、認証なしにアカウントを乗っ取られるおそれがあります。自社でZITADELを運用していて4.0.0以降を使っているなら、バージョンを確認して修正版へ更新してください。あわせて、まだ認証手段を一つも設定していないユーザーがいないかを洗い出しておくと、被害の範囲を絞れます。
急ぎ度: 早めに
CVSS v3は7.4、v4は9.1で、認証なしにネットワーク越しで悪用でき、修正版4.19.5が出ているためです。
関係があるか
ZITADELの4.0.0以降を自社で運用し、Login V2でユーザーをログインさせている組織が対象です。従業員向けの社内ID基盤や、自社サービスの顧客認証にZITADELを使っている場合も同様です。
| 製品 | 影響を受ける版 | 直った版 |
|---|---|---|
| ZITADEL | 4.0.0以上、4.19.5未満 | 4.19.5 |
確かめ方
- 1稼働中のZITADELのバージョンを確認し、4.0.0以上4.19.5未満に当たるかを見ます。コンテナで運用しているなら、使っているイメージのタグが手がかりです。
- 2管理コンソールで、パスワード、passkey、外部IdP連携のいずれも未設定のユーザーがいないかを確認します。招待したまま初回設定が済んでいないアカウントなどが当てはまりやすいでしょう。
- 3Login V2を実際に有効にして使っているかを、ログイン画面の構成や設定から確認します。
何が起きたか
ZITADELのログイン画面Login V2に、認証を経ずにアカウントを乗っ取られる脆弱性が見つかりました。まだ認証手段を一つも持たないユーザーのアカウントが狙われます。
Login V2が本人確認の途中経過を示すために使うverificationCheck cookieを、外部の第三者が偽造できてしまうことが原因です。ベンダーのアドバイザリによると、このcookieはユーザーIDとブラウザーのフィンガープリントから計算でき、正しい値を作られてしまいます。分類はCWE-565です。
偽のcookieが通ると、そのアカウントに最初の資格情報を設定できます。パスワードの設定、passkeyの登録、外部IdPの連携のいずれかが可能で、これで本人になりすませます。
攻撃の流れ
-
1
対象を選ぶ
認証手段をまだ一つも持たないユーザーのアカウントを狙います。
-
2
cookieを偽造
ユーザーIDとブラウザー情報から、有効なverificationCheck cookieを作ります。
-
3
資格情報を設定
パスワード設定、passkey登録、外部IdP連携のいずれかで、最初の認証手段を登録します。
-
4
アカウント奪取
登録した認証手段でログインし、本人としてふるまいます。
どう悪用されるか
認証は不要で、ネットワーク越しに攻撃できます。利用者に何かを操作させる必要もありません。一方で攻撃の複雑さは高いと評価されており、誰でも簡単に成功する種類ではありません。
対象は、パスワードもpasskeyも外部IdP連携も持たないユーザーに限られます。すでに何らかの認証手段を設定済みのアカウントは、この経路では狙われません。
成功すると、攻撃者は対象ユーザーとしてログインできます。評価では機密性と完全性への影響が大きく、可用性への影響は低いとされています。ZITADELが社内システムやSaaSのログインを担っているなら、乗っ取られたアカウントの権限がそのまま連携先で使われます。
今すぐやること
-
1
稼働中のバージョンを確認する
本番、ステージング、検証環境を含め、ZITADELが動いている場所をすべて洗い出し、4.0.0以上4.19.5未満のものを特定します。
docker ps --format '{{.Names}}\t{{.Image}}' -
2
4.19.5以降へ更新する
対象環境を修正版に更新します。まず外部から到達できる環境を優先し、更新後はログインが通ることを確認します。
-
3
認証手段を持たないユーザーを洗い出す
パスワード、passkey、外部IdP連携のいずれも未設定のユーザーを一覧にします。不要なアカウントは無効化か削除を検討し、必要なものは更新後に本人へ初期設定を促します。
-
4
身に覚えのない登録がないか調べる
公開日以前の期間を含め、監査ログでパスワード設定、passkey登録、外部IdP連携の履歴を見ます。本人の操作と合わないものがあれば、該当ユーザーの資格情報を失効させ、本人の確認を経て再設定してください。
背景
ZITADELは、ログインやユーザー管理、外部IdPとの連携を一手に引き受けるID管理基盤です。社内の複数のシステムやSaaSが、ここでの認証結果を信頼して動きます。そのためIDの乗っ取りは、ZITADEL単体の被害にとどまらず、連携先すべてへの入口になります。
今回の問題は、サーバーが作ったcookieの値を、改ざんされない形で守れていなかったことにあります。cookieの値が計算で再現できるなら、持ち主しか持たないはずの証拠として使えません。しかも狙われるのは、最初の資格情報を設定する場面です。ほかの認証手段がまだないため、本人かどうかを突き合わせる手がかりが乏しく、検知もしにくいと考えられます。
よくある質問
Q.すでにパスワードやpasskeyを設定済みのユーザーも、更新前に対処が必要ですか。
Q.CVSS v3とv4で点数が違うのはなぜですか。
まだ分かっていないこと
- 実際の攻撃で悪用されたかどうかは、公表された情報からは分かっていません。ベンダーのアドバイザリ（GHSA-84fg-x5h4-w8xv）で更新を確認してください。
- Login V1を使っている構成への影響、ベンダーが運用するクラウド版への影響と対応状況、更新できないときの回避策は、公表された情報からは分かっていません。アドバイザリや公式の告知を確認してください。
この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 直った版 |
|---|---|---|---|
| zitadel | zitadel |
4.0.0 以上 4.19.5 未満 |
4.19.5 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
ZITADEL 4.0.0 before 4.19.5 contains an authentication bypass vulnerability in the Login V2 UI that allows unauthenticated attackers to set the first credential of users lacking any authentication method. Attackers can compute a valid verificationCheck cookie from the user ID and browser fingerprint to set a password, register a passkey, or link an identity provider, taking over the account.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- web github.com
- web vulncheck.com
- web nvd.nist.gov
- web github.com