LAC WATCH

セキュリティとITの最新情報

RSS

株式会社ラック

メールマガジン

サイバーセキュリティや
ラックに関する情報をお届けします。

テクニカルレポート | 

設定不備により、Azure Active Directoryの多要素認証が回避される恐れ

デジタルペンテストサービス部の小松です。

近年、リモートワークの推進や組織のゼロトラスト化に伴い、Azure Active Directory(以下、Azure AD)を認証基盤として活用する企業が増えています。Azure ADを活用することで、シングルサインオンによるアカウント管理の簡略化や多要素認証によるアカウントの保護が可能となります。

しかし、Azure ADのセキュリティ設定が適切に行われていない場合、有効にした多要素認証を回避されてしまう恐れがあります。実際にラックが提供するペネトレーションテストでは、Azure ADの設定不備に起因する多要素認証回避の問題を検出しています。

組織のAzure AD管理者は、今一度Azure ADのセキュリティ設定をご確認ください。

設定の確認が必要な組織

本記事で取り上げる問題について、該当する可能性がある組織は以下のとおりです。

  1. Microsoft 365およびAzure Active Directoryを利用している
  2. 条件付きアクセスポリシーによって多要素認証を有効にしている

多要素認証が回避されてしまう例

デバイスプラットフォームの設定不備

条件付きアクセスポリシーでは、対象とするデバイスプラットフォームを指定することが可能です。例えば、社員にWindowsとiOSを配布しており、組織内では配布している端末のみの利用が想定されるとします。このとき、多要素認証を有効化するポリシーの対象がWindowsとiOSのみに設定されていることがあります。

デバイスプラットフォームの設定不備
デバイスプラットフォームの設定不備

組織内で利用が想定される端末はWindowsとiOSのみであるため、この設定でも問題ないように思えます。しかし、デバイスプラットフォームの識別はユーザエージェント※1で行っているため 、ユーザエージェントをポリシーで指定されていないAndroidなどの端末に書き換えることによって、多要素認証を回避される恐れがあります。

※1 Conditions in Conditional Access policy - Azure Active Directory | Microsoft Docs

なお、ユーザエージェントはブラウザの機能を利用することなどによって容易に改ざんが可能です。

ネームドロケーションの危険性

条件付きアクセスポリシーでは、IPアドレスを許可リストとしてネームドロケーションに登録することで、ポリシーの適用範囲を指定することが可能です。よくある設定として、社内ネットワークのIPアドレスをネームドロケーションに登録しておき、多要素認証を強制するポリシーの適用対象外としていることがあります。これにより、社内ネットワークからのアクセスであれば、多要素認証を要求しないようにすることができます。

ネームドロケーションの設定不備
ネームドロケーションの設定不備

この設定も問題ないように思えますが、以下のようなシチュエーションにおいて多要素認証が回避されてしまう恐れがあります。

  • 他の要因によって、社内ネットワークに侵入した攻撃者による攻撃
    例えばマルウェア感染などによって侵入した攻撃者が、侵入先の端末でMicrosoft 365アカウントの認証情報を入手したとします。このとき、攻撃者はそのまま侵入先の環境からMicrosoft 365への認証を試みることにより、多要素認証を求められることなくアカウントの権限を悪用することが可能です。
  • 社内のゲストネットワークを悪用した攻撃※2
    社内にゲストネットワークが存在しており、ゲストネットワークからインターネットへアクセスする際に出口となるIPアドレスが社内ネットワークからアクセスする際と同一である場合に悪用される恐れがあります。攻撃者はオフィスに物理的に近づくことによって、ゲストネットワークに接続し多要素認証を回避することが可能です。

※2 Hacking MFA: Office 365 MFA Vulnerability Bypass - Wireless Guest Network | Secureworks

レガシ認証の存在

Azure ADにおけるレガシ認証とは、SMTP、IMAP、POPなどの古いプロトコルを使用するアプリケーションや、多要素認証に対応していないアプリケーションが行う認証のことを指します。組織内で古いシステムを使用しているなどの理由でレガシ認証が有効になっていることがあります。

レガシ認証に対しては多要素認証を強制することができないため、レガシ認証が有効になっている場合、多要素認証の回避に悪用される恐れがあります。

対策方法

セキュリティの既定値群の有効化

最も容易かつ効果的な対策は、Azure ADのデフォルトセキュリティ設定を有効化することです。日本語環境のAzure ADでは「セキュリティの既定値群」と呼ばれています。

セキュリティの既定値群の有効化
セキュリティの既定値群の有効化

この項目を有効化することにより、以下の設定が有効となります※3

※3 2019年10月22日以降に作成されたテナントの場合、セキュリティの既定値群はテナントで既に有効になっている可能性があります。
Azure Active Directory security defaults | Microsoft Docs5

  • すべてのユーザに対してAzure AD Multi-Factor Authenticationへの登録を必須とする
  • 管理者がサインインするたびに多要素認証を要求する
  • 必要に応じてユーザに多要素認証を要求する
  • Azure Resource Managerへアクセスする際に多要素認証を要求する
  • レガシ認証をブロックする

これにより、複雑な条件付きアクセスポリシーによる設定ミスを防ぐことが可能です。しかし、セキュリティの既定値群は条件付きアクセスポリシーと併用することができない点には注意が必要です。

デバイスプラットフォームおよびネームドロケーションの設定

条件付きアクセスポリシーによる多要素認証の設定を行う場合、以下の点に注意して設定を行ってください。

  • デバイスプラットフォームによる多要素認証の指定や除外を行わない(すべての端末で多要素認証を要求する)
  • ネームドロケーションによる多要素認証の指定や除外を行わない(すべての場所で多要素認証を要求する)

そもそもゼロトラストセキュリティは、守るべき情報資産および守るべき情報資産へアクセスしようとするユーザ、攻撃者のいずれもネットワーク境界の内外に存在するという考え方に基づいています。そのため、社内ネットワークからのアクセスであれば安全であるということはなく、どのような場所や端末であっても多要素認証が有効である必要があります。

レガシ認証の設定

レガシ認証は可能な限りすべてブロックすることを推奨します。しかし、社内システムがレガシ認証を使用しているなど、容易にブロックできないシチュエーションはあるかと思います。このような場合はレガシ認証を必要としているシステムおよびユーザを洗い出し、すべてのユーザのレガシ認証をブロックした上でレガシ認証が必要なユーザのみをポリシーから除外することで、必要最小限のアプリケーションやユーザにのみレガシ認証を許可するように設定してください。

レガシ認証の設定例
レガシ認証の設定例

そして、レガシ認証を必要とするシステムを多要素認証に対応したシステムに置き換えることによって、リスクを最小限に抑えることが可能です。

これら認証の設定は本来セキュリティを強化するためにあります。しかし、設定を誤ると脆弱性となるため、定期的な設定の確認や実際の挙動が意図した設定どおりになっているかの確認が重要です。

この記事は役に立ちましたか?

はい いいえ

関連記事

LAC WATCH

関連記事をご紹介します

  • 改めて狙われるVPN機器。今一度、組織内の管理状況の点検や脆弱性の対応を

  • ラックとマイクロソフトがゼロトラスト時代のガイドラインを提示~ポスト境界防御におけるSOC構築とは