MFA疲労攻撃対策とその注意点:MS Authenticatorの数値2桁の入力
ゴールデンウィーク明けに、”ん、変わった?” と思ったことについてです。
2023年5月8日以降、Microsoft 365等 (Azure AD)へのサインインの際、Microsoft Authenticatorでの承認要求に “承認” のタップだけなく、数値2桁を入力する方式になりました (以前から有効にすれば使用できましたが)。
これは、MFA fatigue attacks (多要素認証疲労攻撃) の対策として展開された “数値の一致” という方式です。
![](https://jpazureid.github.io/blog/azure-active-directory/defend-your-users-from-mfa-fatigue-attacks/number-matching.png)
本記事では、MFA疲労攻撃の概要と、その対策である “数値の一致” の適用条件、また、“数値の一致” の適用後も音声通話による認証が登録されたままだと危険だという注意点(私見)についてまとめます。
対象は、一応Azure ADですが、MFAに関する一般的な話です。また、組織アカウントでなく個人利用のMicrosoftアカウントでも “数値の一致” に近い機能 (3つの数字から選択) を利用できるという意味では、業務利用、個人利用のどちらであっても共通する内容になっています。
MFA疲労攻撃とは
MFA fatigue attacks と呼ぶようです。
※多要素認証 (MFA) 疲労攻撃、別名:MFAスパム
"単純なMFA" が標的
“MFAだから安全” ではなく、単純な承認操作のみで構成されるMFAを狙った攻撃があるということです。
プッシュ通知からの承認や、音声通話への応答といった単純な操作のことです。
前者のプッシュ通知による承認要求は、従来のMicrosoft Authenticatorで採用されていた方法ですね。この承認操作の方法が今回の “数値の一致” の適用によって変わりました。
攻撃者が MFA 要求を発生
以下の前提です。
- 攻撃者は、対象のユーザアカウントに対してMFA要求を発生させることができる (例:攻撃者がIDとパスワードを入手済み※)
- そのユーザアカウントは、MFAの設定としてアプリベースの認証 (Microsoft Authenticator) を登録済み
攻撃者が、対象のユーザアカウントのIDとパスワードを不正に用いて1段階目の認証を終えると、2段階目の認証のためにMFA要求が発生します。
このMFA要求は、登録されているMicrosoft Authenticatorをインストールしたデバイス (スマホ) でプッシュ通知が発生するものです (そのスマホでプッシュ通知が許可されていれば)。
ということで、そのユーザアカウントの所有者本人のスマホにプッシュ通知が発生します。Microsoft Authenticatorでの承認操作を促すものです。
(※) Azure ADの場合は、攻撃者がIDとパスワードを既に入手済みで1段階目の認証を突破できることが前提条件になると思います。他のサービスでは、もしかするとIDを入力しただけで単純な承認操作を促すプッシュ通知が発生するサービスもある(あった)かもしれません。
承認してしまうと攻撃成立
本人はサインインしようとしていないので、当然、身に覚えのないMFA要求です。
しかし、承認操作は “承認” ボタンを押すだけです (“数値の一致” の適用前の場合)。何かの間違いで承認してしまう可能性もあるでしょう。
いったん承認すると、攻撃者はそのユーザアカウントを乗っ取ることができます。攻撃成立です。
最初のうちは、きちんと無視や拒否できていても、何回も繰り返しMFA要求が発生するうちに、判断力の低下や勘違い、あるいは誤操作を招き、承認してしまう場合もあることから、fatigue attacks (疲労攻撃) と呼ばれているのかと推察します。
ただ、Microsoftの調査によると、ユーザの約1%は最初の承認要求時に承認してしまうらしいです(参考:Defend your users from MFA fatigue attacksより、”Our studies show that about 1% of users will accept a simple approval request on the first try.”)。
危ないですね…というか、最初の要求で1%の攻撃が成功してしまうのなら、そもそも fatigue (疲労) 以前の課題のような気もしますが…。
脆弱さは、MFA要求が認証の流れ (コンテキスト) の外にある点
この攻撃手法は、Microsoftの表現を借りると、”ユーザーが一連の認証の流れ (コンテキスト) の中にいなくても、承諾を完了できてしまえる” という脆弱さを狙ったものです。
上記では、Microsoft Authenticatorを用いた承認操作の場合の例を挙げましたが、他にも、音声通話による認証 (Microsoftから電話がかかってきて、電話に出た後、”#” を押すだけ) の場合も同様に標的となります。
対策は、コンテキストの一貫
対策としては、サインイン操作とMFA認証操作が、一連の認証の流れ (コンテキスト) の中で行われることです。
具体的には、”数値の一致” について後述します。
例えば、MFA用デバイス(アプリ)に表示されたコード、あるいは、逆にサインイン操作している画面に表示されたコードを他方に入力する方法であれば、サインイン操作とMFA認証操作との間でコンテキストが一貫するので、MFA疲労攻撃の標的にはなりません。単にTOTPでも対策になります。
少し逸れますが、別の観点では、プッシュ通知のような、ユーザに承認を促す通知を無効化することでも緩和策になります。利便性は多少低下するかもしれませんが、そもそもMFAは通常、本人が自らの意思でサインインするときにのみ行います。認証体験にシームレスさを強く求めていなければ、プッシュ通知自体が不要かとも思います。
Microsoft 用語?発生状況は?
“MFA疲労攻撃” という表現を使うベンダーが、ほとんどMicrosoftだけのような気がしました。
実際、Azure ADにおけるMFAのフロー設計上の穴を狙った攻撃だと言えるので、もともとそのような穴が無い認証サービスにとっては影響ありません。
例えば、Google、Apple、Facebookあたりで (国内だとYahoo!Japan等も)、このような “プッシュ通知 → 承認するだけ” という認証方法が長期間、よく使われていたといったことは無いかと思います。いずれも、コードの入力や、ユーザに特定のアプリを開かせる等、認証のコンテキストに沿って能動的な操作が必要です。
MFA疲労攻撃のニュースとしては、Microsoftの他に、Cisco、Uberでも発生していたようです。一次情報らしきものは見つけられませんでしたが。
A relatively new social engineering technique commonly known as “MFA Fatigue” has been successfully used to compromise employee accounts at large corporations like Uber, Microsoft, and Cisco.
出典:MFA Fatigue: How Hackers Breached Uber, Microsoft, and Cisco
以下は、Azure AD Identity ProtectionでMFAが複数回失敗したハイリスクなセッションの数のグラフのようです。
![](https://jpazureid.github.io/blog/azure-active-directory/defend-your-users-from-mfa-fatigue-attacks/Karen_Walker_1-1664319621345.png)
"数値の一致 (2桁の数値の入力)" による対策
![](https://jpazureid.github.io/blog/azure-active-directory/defend-your-users-from-mfa-fatigue-attacks/number-matching.png)
上記のMFA疲労攻撃の対策として、2023年5月8日から、Microsoft 365 (Azure AD)でのMFA等の際、Microsoft Authenticatorでの承認要求で “承認” のタップだけなく、数値2桁を入力する方式になりました。
サインイン画面上に2桁の数値が表示されるので、その数値をMicrosoft Authenticatorの方に入力することで、承認ができるようになるというものです。
“承認” ボタンをタップするだけではないので、MFA疲労攻撃を回避できます。
これが、”数値の一致” と呼ばれる方式です。
自動的にデプロイ
この “数値の一致” は、2023年5月8日以降、自動的にデプロイされるので、利用者側や管理者側で、”数値の一致” を使用するための作業は不要です。
ただし、条件や注意点はいくつかあるので、順に説明します。
(注意点) 音声通話による認証が登録されたままだと危険
先に注意点です。
せっかく、”数値の一致” が適用されても、MFAの方法として音声通話による認証が登録されている場合 (既定でなくても)、MFA疲労攻撃を回避しきれていないことになります。
というのは、音声通話による認証が登録されたままだと、攻撃者は2段階目の認証方法として音声通話を選べるからです。かかってきた電話に出た後、”#” を押すだけなので、一連の認証の流れ (コンテキスト) の外でMFA要求を発生させることができる訳です。
実際、Microsoftが示したデータにおいても、Voice (=音声通話による認証のことでしょう) のMFA試行の割合が高かったようです(下図より58%)。その分のMFA疲労攻撃による脅威は、音声通話による (“#”を押すだけの) 承認をMFAの方法として登録しているユーザアカウントに対して、継続することになるでしょう。
![](https://jpazureid.github.io/blog/azure-active-directory/defend-your-users-from-mfa-fatigue-attacks/Karen_Walker_1-1664319621345.png)
管理者としては、運用状況に応じ、Azure AD側での制限や、利用者がMFAの方法として “電話” を登録しないよう (&登録があれば削除するよう) 注意喚起等を検討しても良いでしょう。
以下は、利用者自身が確認できるアカウントの管理ページ の “セキュリティ情報” の画面の例です。
![](https://jpazureid.github.io/blog/azure-active-directory/change-mfa-verification-method/figure1.png)
繰り返しになりますが、”既定のサインイン方法” をMicrosoft Authenticatorにするだけでは不十分という意味です。
"数値の一致"が適用される条件
続いて、MicrosoftのページのFAQに書かれている内容の要約と抜粋です。
基本的には、2段階目の認証として、Authenticator を用いた場合に、”数値の一致” が適用されます。他の2段階目の認証の操作には、影響はありません。
Authenticator プッシュ通知によるMFA時に適用
Authenticator プッシュ通知によるMFAが対象です。
数値の一致が適用されるのは、Authenticator プッシュ通知が既定の認証方法として設定されている場合のみですか?
はい。 ユーザーが別の既定の認証方法を使用している場合、既定のサインインに変更はありません。 既定のメソッドが Authenticator プッシュ通知の場合は、番号の一致が課されます。 既定のメソッドが他のもの (Authenticator の TOTP や別のプロバイダーなど) の場合、変更はありません。
既定のメソッドに関係なく、Authenticator プッシュ通知でサインインするように求められたユーザーに数値の一致が表示されます。 別のメソッドを求められた場合、ユーザーへの表示に変更はありません。
出典:多要素認証 (MFA) のプッシュ通知で数値の一致が認証でどのように機能するか – 認証方法ポリシー
オプトアウトは不可
オプトアウトはできませんが、前述のとおり、あくまでAuthenticator プッシュ通知によるMFA時に適用されます。
数値の一致をオプトアウトできますか?
いいえ、Authenticator のプッシュ通知の数値の一致からオプトアウトすることはできません。
出典:多要素認証 (MFA) のプッシュ通知で数値の一致が認証でどのように機能するか – 認証方法ポリシー
古いバージョンのAuthenticatorのままでは適用されない
もしMicrosoft Authenticatorをアップデートしておらず、”数値の一致” がサポートされないほどに古い場合、アップグレードするまではそのMicrosoft AuthenticatorによるMFAは不可です。
ユーザーが古いバージョンの Authenticator を実行するとどうなりますか?
ユーザーが数値の一致をサポートしていない古いバージョンの Authenticator を実行している場合、認証は機能しません。 ユーザーがサインインに使用するには、最新バージョンの Authenticator にアップグレードする必要があります。
出典:多要素認証 (MFA) のプッシュ通知で数値の一致が認証でどのように機能するか – 認証方法ポリシー
MFA以外に "数値の一致" が適用されるシナリオ
以下のケースで、”数値の一致” を使用できます。
利用者が “数値の一致” を使用するケースとしては、基本的にAzure ADのMFAまわりが該当するかと思います。パスワードレス認証の際も該当します。
- 多要素認証 (MFA)
- セルフサービス パスワード リセット (SSPR)
- Authenticator アプリの設定時における SSPR と MFA の登録の統合
- AD FS アダプター (Windows Server)
- NPS 拡張機能 (これは”数値の一致”ではなくTOTP)
なお、NPS 拡張機能では、Microsoftの説明を読む限りは、”数値の一致”ではなく、Authenticator で使用できる TOTP、その他のソフトウェア トークン、ハードウェア FOB など、時間ベースのワンタイム パスワード (TOTP) 方式をサポートするという意味のようです(参考:NPS 拡張機能に対する “数値の一致” の説明)。
まとめ
本記事では、本記事では、MFA疲労攻撃の概要と、その対策である “数値の一致” の適用条件、また、“数値の一致” の適用後も音声通話による認証が登録されたままだと危険だという注意点(私見)についてまとめてみました。
![](https://happynap.net/happynap-main/wp-content/uploads/2023/06/20230607075601.png)
![](https://happynap.net/happynap-main/wp-content/uploads/2023/06/20230607072728-300x113.png)