Microsoft Authenticator の Phone Signin は AiTM に耐性があるか

# はじめに
前回「FIDO2 がフィッシング耐性がある認証 (MFA) と呼ばれる理由」(https://qiita.com/narisho/items/200f757f16e51a0bef6a) というタイトルでブログを書きましたが、その中で個人的に勘違いしていたことがもう一つあったのでついでに共有したいと思います。
結論から言うと、Microsoft Authenticator の Phone Signin も AiTM に耐性があるだろうと思っていたのですが、実際に試してみると耐性がないことが分かりました、という話です。

# "Phone Signin" とは
Entra ID で MFA をセットアップする際に Microsoft Authenticator を利用することが一般的だと思います。パスワードを入力して、プッシュ通知に応答して・・という流れのやつです。

実は、もう少し手を加えることで (Microsoft Authenticator アプリで "電話によるサインインを有効にする" をタップすることで) パスワードの入力を省略し、パスワードレス認証にすることができます。
https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-passwordless-phone

Microsoft Authenticator の Phone Signin を有効にする際、Entra ID へのデバイス登録が求められるのですが、これはおそらく Entra ID の証明書をデバイスに登録し、Entra ID がデバイスの身元を確認できるようにするためだと思われます。
このような動作から、「認証フローの中で証明書認証をしているのだろう=プロキシ出来ないのだろう」と勝手な思い込みをしていました。

# AiTM の耐性をチェックする
下記のドキュメントによると、Microsoft Authenticator の Phone Signin はフィッシング耐性がある MFA とはみなされていません。

https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strengths#built-in-authentication-strengths
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/563573/f6c33905-8964-e9a6-3310-91d14e4faa86.png)

今まで「証明書認証なのになぜ？」と思っていたので実際に試してみました。
結論としては、パスワード入力後に実施される一般的な MFA と同様に、攻撃者のプロキシ サーバーを経由せずに Phone Signin の認証プロセスが行われるため、バイパスが可能でした。
(スマホ側の通信は確認していないので分かりませんが) Phone Signin のバックエンドでは証明書認証を行っているのかもしれませんが、攻撃者のサーバーを使用せず行われてしまうと正常に認証が完了してしまいます。

```mermaid
sequenceDiagram
    participant MFAEndpoint as MFA エンドポイント
    participant Victim as 被害者ユーザー (デバイス、ブラウザ)
    participant AttackerProxy as 攻撃者のプロキシサーバー (login.attacker.com)
    participant EntraID as Entra ID (login.microsoftonline.com)

    AttackerProxy->>Victim: フィッシングなどで login.attacker.com のリンクを踏ませる
    Note over Victim: リンクをクリックする
 
    Victim->>AttackerProxy: GET https://login.attacker.com
    Note over AttackerProxy: リクエストの書き換え
    AttackerProxy->>EntraID: GET https://login.microsoftonline.com
 
    Note over EntraID: ログイン ページの生成
    EntraID->>AttackerProxy: ログイン ページ (login.microsoftonline.com)
    Note over AttackerProxy: レスポンスの書き換え
    AttackerProxy->>Victim: ログイン ページ (login.attacker.com)
 
    Note over Victim: ユーザー名を入力
    Victim->>AttackerProxy: POST https://login.attacker.com (ユーザー名)
    Note over AttackerProxy: リクエストの書き換え
    AttackerProxy->>EntraID: POST https://login.microsoftonline.com (ユーザー名)
 
    Note over EntraID: 既定の認証が Phone Signin になっている
    EntraID-->>MFAEndpoint: MFA チャレンジ リクエスト
    MFAEndpoint->>Victim: MFA チャレンジ
 
    Note over Victim: MFA 応答
    Victim->>MFAEndpoint: MFA 応答
    MFAEndpoint-->>EntraID: MFA チャレンジ完了通知
    EntraID-->>Victim: 認証完了通知
 
    Note over Victim: 自動遷移
    Victim->>AttackerProxy: POST https://login.attacker.com
    AttackerProxy->>EntraID: POST https://login.microsoftonline.com
 
    Note over EntraID: セッション Cookie 発行
    EntraID->>AttackerProxy: セッション Cookie (login.microsoftonline.com)
    Note over AttackerProxy: セッション Cookie 入手
    Note over AttackerProxy: セッション Cookie 利用
    AttackerProxy->>EntraID: Microsoft 365 などへアクセス
```

パスワードがネットワーク上を流れないのでパスワードは流出しませんが、経路的にはパスワードを入力してから MFA チャレンジするフロー (前回のブログで説明したフロー) とほとんど同じであり、MFA のバイパスが可能であることが分かりました。

# 強いて言うなら・・
Phone Signin とパスワード＋MFA では最終的に Cookie を発行するために POST するエンドポイントが異なることが分かりました。

パスワード＋MFA で認証を行う場合は下記のように https://login.microsoftonline.com/common/SAS/ProcessAuth に対して POST してセッション Cookie を受け取ります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/563573/e8688a1a-aa9c-696e-64b0-7031c9239bba.png)

一方で、Phone Signin をする場合は https://login.microsoftonline.com/common/login に POST します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/563573/8d2a4ca2-7a7c-db3b-4500-7fcb3b03ef01.png)

このような動作上の違いから、世に出回っている攻撃ツールの一般的な構成では Phone Signin に対応していない状態になっていることが多いだろうと想定できます。(パスワードだけ、もしくはパスワード＋MFA の構成の方が、Phone Signin よりも一般的なので)

例えば、「/common/SAS/ProcessAuth のレスポンスに含まれる Cookie をキャプチャする」のように攻撃ツール側で設定されている場合は /common/login はスルーされて Cookie がキャプチャされないはずです。
だったら両方対応すればいいじゃない？と思いますが、/common/login は MFA 前にパスワードを POST する時にも使用するような一般的なエンドポイントでもあるので、/common/login のレスポンスをキャプチャしようとするとそれはそれで問題が出てきて面倒なことになります。

なので、パスワード＋MFA の構成よりは攻撃が成功する可能性は少しだけ低くなるかもしれません。

しかし、Phone Signin に対応させるようにチューニングを行えば (/common/login のレスポンスをキャプチャするように構成すれば) Cookie を窃取することが可能ですので、やはりソーシャル エンジニアリングと組み合わせたりすればセッションが乗っ取られてしまう可能性が高い、という結論になります。

# まとめ
前述の Microsoft のドキュメントでは Phone Signin はフィッシング耐性がある MFA という扱いにはなっていませんが、それでも「パスワードレス MFA」という区分けになっており一般的な MFA よりは強度が高いということになっています。

ドキュメント内に理由は書いていませんが、ネットワーク上をパスワードが流れないことや、デバイスが Entra ID 上で管理されていることが保証されていることなどが理由ではないかと思います。

Phone Signin はパスワードレスであるためユーザビリティも高く、一般的な MFA よりも強度が高いので、もし Microsoft Authenticator で MFA を行っている方はあと一歩足を延ばして Phone Signin をお試しいただくことをお勧めします。(私も使ってます！)