はじめに：進化するID攻撃の脅威
ID攻撃の領域は常に進化しており、その中でもOAuth 2.0のデバイス認証フローを悪用したフィッシングは特に巧妙な手口として注目されています。本記事では、Microsoft AzureとGoogleという二大プロバイダーにおけるOAuth 2.0の実装が、この攻撃の有効性にどのように影響するかを比較分析します。デバイスコードフィッシングは、正規の認証プロセスを悪用するため、従来のフィッシング対策をすり抜ける可能性があり、その脅威は看過できません。
デバイスコードフローとは？
デバイスコードフロー（またはデバイス認証グラント）は、キーボードやウェブブラウザのような従来の入力機構を持たないインターネット接続デバイス（IoTプリンター、スマートTVなど）を認証するためのOAuth 2.0の機能です。このフローでは、ユーザーは以下の手順で認証を行います。
- デバイスがデバイスコードを要求して認証プロセスを開始します。
- ユーザーは別のPCやスマートフォンでウェブブラウザを開き、提供されたデバイスコードと自身の認証情報（ユーザー名、パスワード、MFAコードなど）を入力します。
- 認証が完了すると、デバイスはアクセストークンを取得し、クラウドサービスへの接続が可能になります。
この機能は非常にニッチであり、一般的なユーザーが日常的に使用するものではありません。しかし、攻撃者はこのような特定の機能の隙を突き、初期アクセスベクトルとして悪用します。
Microsoft 365におけるデバイスコードフィッシング
デバイスコードフィッシングは、ソーシャルエンジニアリングを駆使して、ユーザーを騙し、正規のデバイスコードログインページで認証させることで、攻撃者がアクセストークンを不正に取得する手法です。Azure環境での攻撃手順は以下の通りです。
- 攻撃者は、認証なしでAzureのデバイスコードAPIからデバイスコードを要求します。
- 攻撃者は、被害者をデバイスコードログインページに誘導し、コードを入力させる巧妙なフィッシングメールを作成します。
- 被害者は、正規のMicrosoftのインフラストラクチャ（例：
https://microsoft.com/devicelogin）でデバイスコード、ユーザー名、パスワード、MFAコードを入力します。 - 被害者が認証を完了すると、攻撃者はデバイスコードAPIを監視しており、生成されたアクセストークンとリフレッシュトークンを取得します。
この攻撃の最も危険な点は、正規のMicrosoftのインフラストラクチャとAPIを悪用するため、ユーザーがフィッシングサイトと見分けにくいことです。さらに、攻撃者は初期リクエスト時にリソースとクライアントIDを指定することで、生成されるトークンの権限範囲を制御できます。特に、Microsoftの「Family of Client IDs」と呼ばれる公開されているクライアントIDを利用することで、攻撃者はGraph APIへのアクセス権を持つトークンや、最も強力な「Primary Refresh Token」を窃取し、被害者になりすましてメールの読み取り、ファイルのアクセス、デバイスのテナントへの参加など、広範な操作が可能になります。
Googleの実装：攻撃の有効性への影響
Azureでのデバイスコードフィッシングの強力さを理解した上で、GoogleのOAuthデバイスコードフローの実装が同様の脅威をもたらすのかを検証します。驚くべきことに、Googleの実装はAzureとは大きく異なり、攻撃の有効性を大幅に制限しています。
Googleのドキュメントによると、デバイスコードフローでサポートされるスコープは非常に限定的です。例えば、Google Driveのファイル権限スコープは「このアプリで使用する特定のGoogle Driveファイルのみを表示、編集、作成、削除する」というように、権限が極めて狭く設定されています。YouTubeのyoutube.readonlyスコープに至っては、アカウント乗っ取りに繋がるような悪用はほとんど不可能です。
さらに、GoogleではAzureのような公開されているクライアントIDが存在しないため、攻撃者は自身でGoogle Workspaceアプリケーションを作成し、OAuth 2.0を設定してクライアントIDを取得する必要があります。これにより、攻撃者の匿名性は失われ、追跡が容易になります。また、強力な権限を要求するアプリケーションは、公開および検証プロセスを経る必要があり、これも攻撃者にとって大きな障壁となります。
結論：実装の違いがセキュリティに与える影響
OAuthデバイスコードフローは、その設計上、入力制限のあるデバイスの認証を容易にするためのものです。しかし、Microsoft AzureとGoogleの異なる実装は、この機能が悪用された際のセキュリティリスクに大きな差を生み出しています。
- Microsoft Azure： 攻撃者は正規のインフラストラクチャとAPIを悪用し、リソースとクライアントIDを制御することで、非常に強力なアクセス権を持つトークンを窃取可能です。特にPrimary Refresh Tokenの窃取は、広範な被害をもたらす可能性があります。
- Google： サポートされるスコープが厳しく制限されており、攻撃者が取得できる権限は非常に限定的です。また、クライアントIDの取得に手間がかかるため、攻撃の敷居が高くなっています。
この比較から、OAuth 2.0の仕様自体に問題があるわけではなく、各プロバイダーの具体的な実装がセキュリティの脆弱性を生み出すかどうかの鍵を握っていることが明らかになります。企業やユーザーは、利用しているIDプロバイダーのOAuth実装の詳細を理解し、適切なセキュリティ対策を講じることが不可欠です。
元記事: https://www.bleepingcomputer.com/news/security/oauth-device-code-phishing-azure-vs-google-compared/