パスワード、多要素認証（MFA）、有効なMicrosoft Entra IDトークンのいずれも使わずに、特権ユーザーを含む95の従業員アカウントになりすませる、重大な認証バイパスの脆弱性が確認されました。
原因は、アプリケーション独自のセッションCookie実装にある2つの欠陥です。推測可能なハードコードされた署名シークレットと、公開されているデータベース識別子を認証済みセッションのペイロードとして使用していた点です。
このアプリケーションはAzure Entra IDのシングルサインオン（SSO）を採用していました。しかし、アプリケーション側のセッション機構が別個の信頼境界を作り出し、IDプロバイダーが提供する保護を無力化していました。
このプラットフォームは、Node.js/Express、Next.js、Prisma/PostgreSQL、MSALベースのEntra ID認証、express-openapi-validatorからなる最新のスタックで構築されていました。
また、/api-docs/でSwaggerドキュメントを公開しており、251ルートに及ぶAPIの全容が明らかになっていました。
Entra IDのアクセストークンにはRS256署名が使われていました。パラメータ化されたデータベースクエリとリクエストスキーマの検証により、一般的なインジェクションや入力検証の欠陥に対するリスクも抑えられていました。
ところが、認証済みリクエストはsession_secret_exampleという名前の2つ目のCookieにも依存していました。
このCookieには、ランダムなサーバー側セッション識別子ではなく、ユーザーのCUID（データベース識別子）に署名を付けたものが格納されていました。
この値は、/api/v1/auth/meなどのエンドポイントやユーザーディレクトリAPI、さらにcreatedByやupdatedByといったオブジェクトのメタデータフィールドから取得できました。
署名付きCookieの構造は、おなじみのs:<payload>.<signature>という形式でした。署名はHMAC-SHA256演算で生成されていました。
安全な実装であれば、署名鍵はエントロピーの高いシークレットとし、ソースコードやデプロイ設定とは別の場所に保管する必要があります。ペイロードも、推測不可能なセッションIDを参照すべきです。しかし、どちらの条件も満たされていませんでした。
Resecurityが特定したこのぜい弱性は、サプライチェーンやヤード業務の調整に使われるYMSプラットフォームに対する、許可を得たテストの中で見つかりました。
パスワード不要のなりすまし
調査の結果、HMACシークレットはCookie名と同じsession_secret_exampleという文字列そのものだったことが判明しました。
研究者らは、既知のCookieのペイロードと署名のペアを使い、可能性の高い約110個の候補値をオフラインで総当たりして、このシークレットを割り出しました。
鍵が判明すれば、公開されているユーザーのCUIDを、有効な署名付きセッション値に変換できます。
アプリケーションは署名の形式が正しいことは検証していました。しかし、署名された値が正規のサーバー側セッションや直近のEntra ID認証イベントに紐づいているかどうかは、独自に確認していませんでした。
その結果、正しく署名された公開ユーザーIDが、本人であることの証明として扱われていました。
テストでは、検証した241件のユーザーIDのうち95件で、セッションの偽造に成功しました。対象となったアカウントには、オペレーションユーザー、技術者、ヤード担当者、管理者が含まれていました。
偽造したCookieにより、被害者のロールに応じた読み書きのアクセス権が得られました。管理者権限の偽造セッションでは、状態を変更するAPIリクエストを実行できることも確認されています。
さらに調査では、/api/v1/auth/meが認証済みユーザーのEntraリフレッシュトークンを返していたことも判明しました。これにより、侵害に成功した場合の影響はいっそう大きくなります。
今回の結果は、MFAやフェデレーションIDの保護だけでは、下流のアプリケーションにおけるセッション管理の弱点を補えないことを示しています。
Entra IDはユーザーを正しく認証していました。ところがYMSアプリケーションは、別途実装されたCookieを信頼できる認証情報として受け入れていました。
実質的には、この独自のセッション層が、上流のSSO、MFA、ロールベースアクセス制御、パスワードによる保護をすべてバイパスしていたことになります。
この問題は、概念的にはMITRE ATT&CKの「T1550.004: Use Alternate Authentication Material: Web Session Cookie」に該当します。ただし今回は、Cookieの窃取やリプレイではなく、偽造でした。
MITREは、セッションCookieがそれ自体で認証済みの状態を表すため、攻撃者がユーザーになりすましてMFAを回避できると指摘しています。
影響を受ける組織は、直ちにセッション署名用シークレットをローテーションし、有効なセッションとリフレッシュトークンをすべて無効化する必要があります。あわせて、APIレスポンスからリフレッシュトークンを除外し、アクセスログに異常なセッション利用がないか調査してください。
防御側は、自己完結型のIDクッキーを、暗号論的にランダムなサーバー側セッション識別子に置き換えるべきです。セッションの有効期間を短くし、機密性の高い操作にはステップアップ認証を組み合わせることも求められます。認可の判断は、検証済みのサーバー側セッション状態に基づいて行うようにしてください。
今回の事例は、アプリケーション開発チームがセッション設計を認証境界の一部として扱わなければならないことを、改めて示しています。強力なSSOも、その出力を受け取るアプリケーション層が適切でなければ、効果を発揮しません。
SOCのアラート調査を1件あたり21分短縮。即座にIOCのコンテキストを得て、迅速な対応を実現しましょう。 SOCにTI Lookupを導入する
翻訳元: https://gbhackers.com/passwordless-impersonation/
