このブログは、Proofpoint Protect Globalで、多要素認証 (MFA) を回避する一般的手法について解説した内容をまとめたものです。このカンファレンスでは、MFA をすり抜ける新しい脆弱性について説明し、Microsoft 365/Azure の開発環境と実稼働環境、メール、メールルール、クラウドアプリなどへのフルアクセスを攻撃者がどのように悪用するかも説明しました。また複数のアイデンティティ プロバイダー (IdP) ソリューションのテストを通して、Okta と OneLogin の脆弱性を検証しました (これらのセキュリティ問題は解決済)。このブログでは、MFA をすり抜ける手法を技術的に解説します。
WS-Trustにたどり着くまでの道のり
MFA の回避手法について多くのプロトコル、アプリケーション、ディレクションを調べたところ、1つ注目すべき点がありました。
Skype for Business (SfB) は広く利用されているアプリケーションですが、これがサーバーや IdP とどう通信しているかをテストしたところ一貫性が欠如していたのです。一部の IdP のシナリオでは、MFA が常時有効になっている場合でも、Skype for Business ログイン時に MFA の実行が求められませんでした。これは危険な信号です。そこで、使用されているプロトコル、実装方法、エンドポイント間のデータフローについて掘り下げて調べました。私は Skype for Business プロトコルやこの分野には精通していなかったのでこの作業には何日もかかりました。
プロセスへのコード インジェクション、スニッフィング、暗号の一部解読などを試したところ、Skype がユーザーとコミュニケーションしテナント情報を抽出するトークンを、MFA なしで取得することに成功しました。そこで私は、トークンのオリジンとフローの調査を始めました。Skype はトークンをどのように取得し、どうやって MFA を回避できたのかを確認したかったからですが、その結果 WS-Trust プロトコルとアクティブ エンドポイントにたどり着きました。
WS-Trust プロトコルとは?
ウィキペディアによると、WS-Trust は WS-Security の拡張機能を提供する WS-* 仕様および OASIS スタンダードで、セキュリティトークンの発行/更新/検証をし、また安全なメッセージングのための参加者間の信頼関係の確立/評価/仲介をします。
Web Services Security (WS-Security、WSS) は SOAP の機能強化を記述したもので、Web サービスのセキュリティに用いられます。Web サービス仕様の一部で、OASIS が規格を発表しました。このプロトコルはメッセージの完全性と機密性を保持するための仕様を含み、Security Assertion Markup Language (SAML)、ケルベロス、X.509 などのさまざまなセキュリティトークン規格の通信を可能にします。この主な目的は、XML 署名と XML 暗号化を用いてエンドツーエンドのセキュリティを提供することにあります。
これらのプロトコルについては非常に多くの情報が提供されているので、ここではこの攻撃の理解に必要な情報だけをご紹介します。WS-Trust はアクティブ エンドポイントで用いられます。WS-Federation はパッシブ エンドポイントで用いられます。アクティブ エンドポイントは通常、レガシー プロトコルの認証に使用されます。パッシブ エンドポイントは通常、ブラウザや最新クライアントに用いられます。一般的に、これらのエンドポイントは IdP 側にあり、ログイン検証を行います。
通常の対策では保護が不十分
“The best way to protect your account from malicious authentication requests made by legacy protocols is to block these attempts altogether.” —Microsoft
(レガシープロトコルからの悪意あるアカウント認証要求を阻止するには、これらを完全にブロックしてしまうことがベストです。—Microsoft)
この MFA 回避は通常の対策では防げません。Azure でレガシープロトコルを無効化しても、攻撃者は最新の認証にピボットできるので効果がありません。ピボットすると、Azure は、このセッションは最新の認証方法でログインされたとみなします。このため管理者も、このセッションは MFA を通しているので安全だと勘違いしてしまいます。
WS-Trust （2007年3月に承認） は MFA を考慮に入れて設計されていないので、MFA のネイティブサポートはしていません。そのため IdP は MFA 用にソリューションを開発 (または MFA をブロック) しなければなりません。
新しい脆弱性を使って MFA を回避する攻撃
この攻撃は主に以下のような方法で行われます。
- エンドポイント アドレスを検索
- IdP に直接 SAML リクエストを送信
- SAML V1 トークンを取得
- Microsoft サービスを使って最新のトークンに変換
- OAuth 2 トークン\Cookie を使用してアカウントを完全に制御
たとえば、「アリス」が Microsoft 365 で旧友の「ボブ」にメールを送信したいとします。(注: Microsoft 365 テナントは、IdP が提供する、MFA が有効化されたフェデレーションおよび SSO サービスを使用します。) アリスは自分の認証情報を Microsoft 365 に送るのではなく、outlook.office.com にアクセスしてログインします。そうするとそのログイン情報は IdP に転送され、パッシブ エンドポイント経由で認証されます。アリスが正しい認証情報を提供した後、MFA での認証を行います。すると Microsoft 365 に戻りログインできます。
次に脆弱性が悪用される例を説明しましょう。オスカーはアリスのアカウントからボブにメールを送信しようと企んでいます。そこでまずオスカーは、フィッシングでアリスの認証情報を盗みます。その後、outlook.office.com にアクセスするのではなく、ユーザー名とパスワードのみを含み、ヘッダーを加工したリクエストをアクティブ\レガシー エンドポイントに送ります。これが脆弱性の影響を受けたエンドポイントだった場合、IdP は Microsoft フェデレーションに有効な SAML 1トークンを返します。オスカーは、以下に説明される方法でこのトークンを最新トークンにピボットします。そうすると MFA で認証したように見せかけて、アリスとしてログインしてメールの送受信ができるようになります。
次にオスカーはアリスの Azure アカウントを悪用してソースコードを盗み、また「悪意のある」サードパーティ (OAuth) アプリをインストールします。そうするとアリスがパスワードを変更しても永続的にアカウントを悪用できるようになり、MFA も必要なくなります。
攻撃フローの詳細
以下は、攻撃者による典型的な SAML リクエストの例です。
イメージ1: 攻撃者による SAML リクエスト
必要な情報はユーザー名とパスワードだけです。残りの情報は、攻撃者が Microsoft オンライン フェデレーション全体へのアクセスを要求する間 (以下の「調査」で説明) に簡単に入手できます。
認証情報確認後に WS-TRUST エンドポイントから攻撃者に送られるリプライ例を以下に示します。
イメージ2: WS-Trust エンドポイントからのリプライ
email@domain.com には署名付トークンが与えられ、最新トークンにピボットできるようになっています。
SAML 1トークンを最新トークンにピボットするには POST リクエストをhttps://login.Microsoftonline.com/login.srfに送ります。そうすると ESTSAUTH という Cookie が取得でき、それを使って、ブラウザへの Cookie インジェクションで Microsoft フェデレーションにアクセスできるようになります。
偵察
この脆弱性は簡単に調べられ、また自動化も容易です。たとえば、エンドポイント アドレスは認証情報がなくとも簡単に手に入ります。https://login.microsoftonline.com/getuserrealm.srf?login=demo@somedomainname&xml=1 の demo@somedomainname を必要なドメイン名で置き換えるだけです。
クエリ結果は以下のようなものになります。
イメージ3: DNS クエリ スクリーンショット
STSAuthURL は私が攻撃できたアクティブ エンドポイントで、Protect Global Conference でのプレゼンテーションでご紹介したものです。
その他の脆弱性
IP スプーフィング
X-MS-FORWARDED-CLIENT-IP をリクエストヘッダーとして用い、エンドポイントの IP 制限を回避できることがあります。
一部の組織では、ユーザーの IP アドレスをもとにして、VPN を使用しているかを確認しています。VPN 利用の IP レンジは静的で、偽造できないと想定しているからです。VPN の IP アドレスを信じると、MFA がすでに実行されていると勘違いしてしまうことがあります。偽のヘッダーを無視する機能を持たない IdP は、上記のようなヘッダーを使えば騙すことができます。
Proofpoint Protect Conference でこの攻撃のデモをお見せしました。このデモでは IdP 側で IP の許可リストを127.0.0.1 (localhost) のみに制限しました。理論上、この設定はローカル IdP マシン外のユーザーにはエンドポイント アクセスをブロックできるはずですが、ヘッダーを用いてこれを回避することで、MFA なしでアカウントへのアクセスに成功しました。
攻撃者はエンドポイントの IP 制限がどうなっているかをなぜ知ることができ、またどうやってそれを取得するのか、不思議に思われる方もいるでしょう。彼らは認証情報をフィッシングするときに一緒にセッション IP も抽出して保存し、後で攻撃に使用するのです。
エンプティ ユーザー エージェントとオプションの欠如
私の調査では、あるケースでは IdP はアクティブ エンドポイントを無効にするオプションを提供しておらず、またあるケースでは無効にしても攻撃の阻止には不十分でした。エンプティ ユーザー エージェントでリクエストを送ったところ、対策を回避でき、無効化された WS-Trust アクティブ エンドポイントにアクセスできました。これは開発環境でテストしたものです。このバグは実稼働環境では発生しないとのことでした。
スラッシュで可能に
実稼働環境では、エンプティ ユーザー エージェントではプロセスを実行できませんでしたが、何時間か試したところ他のバグが見つかりました。実稼働環境のエンドポイントアドレスの末尾にスラッシュを加えると、無効化されていてもレガシー環境に入れたのです。
ログの不在
WS-Trust エンドポイントへの直接アクセスは IdP のログに記録されないことがあります。 その場合、セキュリティシステムも専門家も攻撃を捕捉できません。
こういった攻撃は自動化が可能であり、アカウントの乗っ取りに1秒もかからないため注意が必要です。
攻撃フローの概要
攻撃は、Python コード、postman、またはカスタムヘッダーと本文で POST リクエストを送信するツールを用いて行われます。そして上記で発見した脆弱性のある WS-Trust エンドポイントに、カスタムペイロード (ユーザー名とパスワードを含む) が送られます。
脆弱なエンドポイントは MFA を求めることなく SAML 1トークンを返します。攻撃者はこのトークンを取得し、リクエストにヘッダーを追加し、以前入手した Web サイトに送信します。
Microsoft は有効なトークンを受け取ると、ESTSAUTH という Cookie を提供します。この Cookie をブラウザ、または関連する自動化ツールで使うとアカウントを乗っ取ることができます。また自動化ツールでアカウントへの OAuth トークンを入手することも可能です。
有効な対策
- 脆弱性は必ず攻撃者に発見されます。他のセキュリティ対策が突破されてしまった場合、アカウント侵害の検知と修復が役立ちます。
- トークンのソースの追跡は調査に役立ちます。
- 設定が正常に機能していることを再確認してください。
- 可能な場合は X-Forwarded-For ヘッダーを無効化してください。
- レガシーはあくまでもレガシーなので、可能な限り使用しないようにしてください。
- MFAは、クラウドセキュリティで効果はありますが、万能ではありません。攻撃者はこのような脆弱性や、以前のブログで説明したその他の方法を必ず見つけます。一旦発見すると、彼らはそれを自動化して武器化し、その後ずっと、さまざまな組織への侵入に利用します。セキュリティの強化には、有効なクラウド セキュリティ ソリューション スイート (脅威検出に強い CASB など) と MFA の併用を推奨します。
さらに詳細：
ソリューションの詳細については、以下のCASB スタートガイドホワイトペーパーを参考にしてください。
- CASBスタートガイド：CASBによる保護（入門編）
- CASBスタートガイド：シャドーITの影
- CASBスタートガイド：クラウドの課題を乗り越える
- CASBスタートガイド：CASBと進めるクラウドの明るい未来
本ブログは英語版ブログ「Technical Deep Dive: Vulnerabilities Bypass Multi-Factor Authentication for Microsoft 365」の翻訳です。