はじめに
私はパスキーに出会って以来、「これこそが本来あるべき認証の姿だ」と強く感じるようになり、それ以降、積極的にパスキーを推進してきました。
そんな中、パスキーを利用していても攻撃を受ける可能性がある手法として、「デバイスコード フローを悪用したフィッシング攻撃」の存在を知り、大きな衝撃を受けました。
パスワードレス認証を推進している立場として、「パスキーを使えば安全」という説明だけでは不十分です。どのようなリスクが残されているのかを理解し、その対策まで含めて伝えなければならないと考え、この仕組みについて調査を始めました。
調べてみると、この攻撃手法は最近になって注目されるようになったものの、デバイスコード フローそのもののリスクは以前から指摘されていました。むしろ、MFA やパスキーの普及によって従来のパスワード攻撃が難しくなった結果として、攻撃者が別の経路を狙うようになったとも考えられます。
パスキーは非常に強力な認証方式ですが、だからこそその限界や周辺リスクも正しく理解しなければなりません。この記事では、デバイスコード フローとは何か、なぜ攻撃に悪用されるのか、そして Microsoft Entra ID ではどのような対策が取れるのかを整理してみたいと思います。
本記事で紹介する主な対策
- サインインログでデバイスコード フローの利用実態を確認する
- 利用ユーザーや利用アプリを把握する
- 条件付きアクセスでデバイスコード フローをブロックする
- ブロック後はサインインログで影響を確認する
- 利用者にデバイスコード フローのリスクを周知する
- パスキーだけでなく認証フロー全体を保護する
Entra ID / パスキーについての私の記事シリーズの紹介
以下のストックリストに、私が Entra ID や パスキー関連で投稿した記事がまとめられています。よろしければ、こちらもぜひ参照ください。
https://qiita.com/carol0226/stocks/3670cb8678daed11b191
デバイスコード フローとは？
デバイスコード フローは、キーボードやブラウザーを持たないデバイスでも認証を行えるようにする仕組みです。
分かりやすい例として、スマート TV や Fire TV Stick、Apple TV などで Netflix などの動画配信サービスへサインインするケースがあります。
TV のリモコンで長いパスワードを入力するのは大変です。そのため、TV に表示された QR コードをスマートフォンで読み取り、スマートフォン側で認証を完了させることで、TV 側も自動的にサインインできます。
Microsoft Entra ID のデバイスコード フローも基本的な考え方は同じです。認証を行いたいデバイスとは別のデバイスで認証を完了させ、その結果を共有することでサインインを実現しています。
本来はとても便利な仕組みですが、この仕組みを悪用するとフィッシング攻撃に利用される可能性があります。
※この画像は 本物の画像のキャプチャではありません。生成 AI によるイメージです。
Netflix 公式：自宅のテレビで Netflix にログインするための手順
https://help.netflix.com/ja/node/311830241325668
（上記より抜粋）
デバイスコード フローの悪用を理解するための例
本記事では、Netflix を例に取り上げていますが、動画サブスクサービスの多くは同様の仕組みです。
こんな経験はありませんか？
あなたは、Netflix の契約者で、会社にいます。
子供（または家族）から、自宅のテレビの認証が切れていて、Netflix 見れないんだけど...
勘のいいあなたは、「じゃあ、TV に表示されているコードを教えて」と言い、デバイスコード フローの認証をします。
すると、家族から「あ、認証された。Netflix が見られるようになったよ！」と返事がありました。
でも実は、あなたの子供は、自宅ではなく 友達の家から連絡してきていたら...
自宅ではない他人の家であなたの契約で Netflix が見れてしまうことになります。
デバイスコード フローの悪用をイメージするための例です。
なお、デバイスコード フローは決して特殊な認証方式ではありません。
Azure PowerShell や Microsoft Graph PowerShell などの管理ツールでも利用できるため、組織によっては運用手順の中に組み込まれている可能性があります。
そのため、単純に「危ないからブロックしよう」と考えるのではなく、まずは自組織で利用実績があるかどうかを確認することが重要です。
実際に Azure を利用している方であれば、知らないうちにデバイスコード フローを利用した経験があるかもしれません。
Azure を長く利用している方であれば、Azure PowerShell のログイン時に次のようなメッセージを見たことがあるかもしれません。
実は、これがデバイスコード フローです。
昔の Azure PowerShell や現在でも利用可能な一部の認証方法では、この仕組みを利用して認証を行います。
つまり、デバイスコード フローは特殊な認証方式ではなく、多くの Azure エンジニアが普段から利用してきた仕組みなのです。
公開情報：Azure PowerShell -UseDeviceAuthentication
https://learn.microsoft.com/ja-jp/powershell/module/az.accounts/connect-azaccount?view=azps-16.3.0&wt.mc_id=MVP_407731#-usedeviceauthentication
どのようなリスクなのか？
以下の記事でも紹介されている通り、デバイスコード フローの悪用は、ホテルの Wi-Fi 認証画面（キャプティブポータル）を利用した攻撃シナリオでも確認されています。
なぜ危険なのか？
例えば、出張先のホテルで Wi-Fi に接続しようとしたとします。
利用者はホテルの認証画面に従って操作しているつもりですが、その途中で Microsoft のサインイン画面が表示されることがあります。
ここで表示される Microsoft のサインイン画面は偽物ではありません。実際に Microsoft が提供する正規の画面です。
そのため、利用者は不審に思わず、パスキーや MFA を利用して認証を完了してしまう可能性があります。
その結果、利用者の認証によって、攻撃者側のクライアントが開始したデバイス認可要求が完了します。
つまり、この攻撃はパスワードやパスキーを盗む攻撃ではありません。
利用者は正規の Microsoft サイトで認証し、パスキーや MFA も正常に利用しています。それにもかかわらず利用者が認証を完了すると、攻撃者側で開始されたデバイスコード フローが承認され、攻撃者側のクライアントがトークンを取得できる可能性があります。
そのため、パスキーが破られたわけではなくても、攻撃者は利用者として Microsoft 365 や Azure にアクセスできるトークンを取得できる可能性があります。
攻撃の流れ
-
攻撃者が準備する
攻撃者は事前にデバイスコード フローを開始し、認証コードを取得しておきます。 -
利用者を誘導する
偽の Wi-Fi 認証画面やフィッシングメールなどを利用して、利用者を Microsoft のデバイスログイン画面へ誘導します。そして攻撃者が取得した認証コードを入力させます。 -
利用者が正規の認証を行う
利用者には本物の Microsoft サインイン画面が表示されます。利用者はパスキーや MFA を使って、普段通りに認証を完了します。 -
攻撃者がトークンを取得する
認証結果は利用者自身ではなく、攻撃者が開始したデバイスコード フローのセッションへ紐付けられます。その結果、攻撃者側のクライアントが、許可された範囲のアクセストークンを取得できる可能性があります。 -
不正利用
管理権限を持つ利用者が被害を受け、取得されたトークンに管理操作に必要な権限が含まれていた場合、権限変更などの深刻な影響につながる可能性があります。
Entra ID で対策するには？
ここまで見てきたように、デバイスコード フローは便利な仕組みである一方、攻撃者に悪用される可能性があります。
そのため Microsoft は、条件付きアクセス (Conditional Access) を利用して、デバイスコード フローそのものを制限またはブロックすることを推奨しています。
Microsoft Learn でも、以下のドキュメントが公開されています。
公開情報：条件付きアクセス ポリシーを使用して認証フローをブロックする
https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/policy-block-authentication-flows?wt.mc_id=MVP_407731
ただし、前章で紹介したように、デバイスコード フローは Azure PowerShell や Microsoft Graph PowerShell などで利用されている可能性があり、そのまま無条件にブロックしてしまうと、組織内の業務が止まってしまう恐れがあります。
そのため、組織テナントの場合は、いきなりブロックするのではなく、
- 現在利用されているか
- どのユーザーが利用しているか
- 本当にブロックして問題ないか
を確認してから適用することが重要です。
デバイスコード フローを実際に試してみる
デバイスコード フローは、Azure PowerShell の認証を行う手段の一つであり、正規の認証ですが、ここでは、その流れを説明しつつ、悪用される場合の 立場 を記載しています。立場を意識しながら見てください。
立場：攻撃者役
デバイスコード フローを生成します。
Connect-AzAccount -UseDeviceAuthentication
解説
Azure PowerShell からデバイスコード フローを開始すると、認証コードが表示されます。ブラウザーから https://microsoft.com/device へアクセスし、このコードを入力して認証を行います。
これは、正規の手順です。
※あえて、Connect-AzAccount を実行した PC とは別のデバイス（スマホなど）から実施してみると、デバイスをまたいで認証されていることが分かると思います。
上記で生成された URL とコードを、攻撃対象へ送ります。
※本人を騙すような内容で URL を踏んで コードを入力するように誘導したと仮定します。
フィッシングメールの例
本来、このようなメールが来たら
- 自分で開始していないデバイス認証に応じない
- メールやチャットで送られたコードを安易に入力しない
- 正規のMicrosoft画面であることだけを安全性の根拠にしない
- 表示されたアプリ名や認証目的を確認する
- 不審な場合はキャンセルし、組織の窓口へ連絡する
立場：標的となる利用者役
攻撃者からのメールを信じたことにして、リンクを踏んでメールに記載されていたコードを入力します。
※このとき、入力したコードによって、利用者の認証操作が、攻撃者側で開始されたデバイス認可要求に紐付けられます。つまり、あなたが攻撃者のセッションの認証を代わりにやってあげるということになります。
(認証画面)
正規の認証画面が開きます。
ここで、メールアドレスを入力して MFA で認証を行うか、サインインオプションを選択します。
続いて、パスキー認証 を行います。
※パスキーではなく、MFA でもテストは行えます。
(認証成功画面：認証実施側)
本来はココでおかしいと思って、キャンセルを押せば間に合います。
しかし、信じ込んでいるので 続行 を押してしまったことにします。
サインインに成功しました。
この時点で攻撃者によるアクセスが可能になる可能性があります。
立場：攻撃者役
（認証成功画面：Azure PowerShell 側）
攻撃者役も、サインインに成功しています。
攻撃者役の端末では、認証した利用者に付与されている権限の範囲で、Azure PowerShell からリソースへアクセスできる状態になります。
ここでは、条件付きアクセスによる制御を行っていないため、デバイスコード フローによる認証は正常に完了します。このあとサインインログを確認してみましょう。
サインインログで利用履歴を確認する
Microsoft Entra 管理センターで サインインログを表示します。
許可された時刻：直近の1カ月 の日付を指定します。
フィルターの追加を押して、元の転送方式 を選び デバイスコード フロー を選んで、適用を押します。
すると、以下のように デバイスコード フロー で認証されたログが表示されます。
前章のテストと時刻、ユーザー、アプリ、結果が一致するログを確認します。ほかにもログが表示された場合は、正当な業務利用か、不審な試行かを詳細情報から確認します。
ログの行をクリックすると、ログの詳細が確認できます。
今回のテスト以外のログが記録されていた場合、次の点を確認しましょう。
- 誰が利用しているか
- どのアプリが利用しているか
- 現在も利用実績があるか
- ブロックして問題ないか
条件付きアクセスで デバイスコード フロー をブロックする
以下の公開情報で解説されている条件付きアクセスポリシーの設定例です。
公開情報：条件付きアクセス ポリシーを使用して認証フローをブロックする
https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/policy-block-authentication-flows?wt.mc_id=MVP_407731
以下のように、条件 の設定で、認証フローを選びます。
条件付きアクセスの利用が初めての場合は、以下の私の記事を参照してください。
セキュリティの既定値群 と 条件付きアクセス の初回利用について
https://qiita.com/carol0226/items/51a70a561b78af567972
除外された特定のユーザー欄には、以下で解説している Break glass アカウントを指定します。
緊急アクセス用管理アカウント (Break glass) 入門： 基本構成からセオリー外の追加構成まで解説
https://qiita.com/carol0226/items/bbd69bdc907a48f0e67f
実際にブロックできるか検証してみる
条件付きアクセス ポリシーを有効化した状態で、デバイスコード フローによる認証を試してみます。
今回も Azure PowerShell の UseDeviceAuthentication を利用して検証します。
Connect-AzAccount -UseDeviceAuthentication
先ほどと同じように デバイスコード フローの認証を実施すると、以下のようにブロックされました。
ブロック後のサインインログを確認する
再度、サインインログを確認すると、失敗のログを見つけることができます。
該当の行を選択し、表示された詳細画面で 条件付きアクセス のタブを選択します。
すると、先ほど作成した条件付きアクセスのルールで、ブロックされていることを確認できます。
さらに、右側の ・・・ を押すと、詳細情報を確認できます。
条件付きアクセスによってブロックされた理由を確認することができます。
まとめ
今回調査してみて、パスキーそのものの堅牢性と、認証フロー全体を保護する重要性を改めて認識しました。
今回の攻撃で悪用されたのは、パスキーそのものではなく、デバイスコード フローという認証周辺の仕組みです。
利用者は Microsoft の正規のサインイン画面で認証を行っており、パスキーの秘密情報が漏えいしたわけでもなければ、パスキーの暗号学的な仕組みが破られたわけでもありません。
むしろ興味深いのは、攻撃者がパスキーを正面から突破するのではなく、デバイスコード フローという認証周辺の仕組みを悪用する方法を選んでいることです。
これは裏を返せば、パスワードや従来型 MFA に比べて、パスキーそのものの正面突破が難しくなっていることを示しているとも考えられます。だからといって安心してよいわけではありません。認証方式が強化されると、攻撃者が認証の周辺フローや利用者の操作を狙う可能性にも注意が必要です。
パスキーを推進する立場だからこそ、その強みだけでなく限界や周辺リスクも理解し、条件付きアクセスによる制御やサインインログの監視など、適切な対策を組み合わせていくことが重要だと感じました。
今回の事例は、「パスキーが破られた」のではなく、「パスキーを利用する前後の認証フローが悪用された」ケースだと言えるでしょう。
そして、この攻撃は Microsoft Entra ID の条件付きアクセスによって制御できることも確認できました。
まずはサインインログで利用実態を確認し、自組織における影響を評価した上で、適切な制御を検討してみてはいかがでしょうか。