多要素認証を突破する「AiTM攻撃」とは？その対策は？

はじめに

企業のセキュリティ対策として多要素認証（MFA：Multi-Factor Authentication、以降MFA）の導入が進んでいます。MFAは、ユーザ名やパスワードが漏洩した場合でも、不正アクセスを防ぐ有効な手段とされています。一方で、マイクロソフトが2022年に報告した「Adversary-in-the-Middle（AiTM）攻撃」は、MFAを回避する新たな手法として警戒感が高まっています。

本稿では、AiTM攻撃の仕組みと技術的対策を解説します。その前にまず、MFAの仕組みとそれが従来のフィッシング攻撃に対してどのように有効なのかを見ていきましょう。

従来のフィッシング攻撃とMFAの有効性

従来のフィッシング攻撃では、攻撃者が準備した偽のログイン画面に、ユーザが認証情報としてIDやパスワードを入力することで、攻撃者がその情報を窃取し、正規のサービスにアクセスすることが可能です（下図）。

図：従来のフィッシング攻撃の流れ
（※IdP：Identity Provider。Microsoft 365などのクラウドサービスへのアクセスに必要な認証情報を提供するシステムやサービス）

これに対してMFAは、追加の認証要素が必要となるため、攻撃者がIDやパスワードのみを窃取してもアクセスを完了できない仕組みです（下図）。

図：従来のフィッシング攻撃に対する多要素認証の有効性

このため、IDとパスワードのみの認証がはらむリスクを回避するには、一般的にMFAの導入が有効とされています。
では、そのMFAを回避するAiTM攻撃とはどのようなものか、次に見ていきます。

＜関連記事＞結局、パスワードの定期的な変更は必要なのか？～NISTのガイドライン草案から考える～

AiTM攻撃の仕組みと脅威

AiTM攻撃では、ユーザと正規サービスの間に攻撃者が割り込み、リアルタイムで通信を中継します。
まず、ユーザがそれと気づかずにフィッシングサイトアクセスし、IDであるメールアドレスやパスワードを入力します。フィッシングサイトは入力内容をそのまま正規サイトへリクエストします。次に、正規サイトからの多要素認証の要求をユーザに転送します。ユーザが多要素認証に成功すると、攻撃者は認証済みのセッションcookieを取得し、それを用いてサービスにログインできるようになります。

当社のリサーチでも頻繁に事例が確認されているMicrosoft 365を例にした流れは下図のとおりです。
こちらはMicrosoft 365の例ですが、他のサービスでも悪用事例が確認されています。

図：AiTMによるフィッシング攻撃の流れ

AiTM攻撃の実際の挙動を確認するため、トレンドマイクロでは以下のとおりに検証を行いました。

1. AiTM攻撃の検証

Evilginxなどのツールを用いた実証により、Google ChromeやAmazonなどに対してAiTM攻撃が可能であることが確認されました。Evilginxとは、正規のオープンソースのWebサーバ「nginx」を改変したもので、MFAをバイパスして認証情報を取得できるツールです。レッドチームによるペネトレーションテストにも使用されますが、実際の攻撃者にも悪用されていることを当社でも確認しています。なお、Evilginxで作成するフィッシング用のURLは「ルアー」と呼ばれます。

検証では、被害者（正規ユーザ）と攻撃者それぞれの端末を準備し、次のステップで行いました。

ステップ1. 攻撃者：フィッシング用の偽URL（ルアー）を生成し、そこに被害者を誘導。
ステップ2. 被害者（正規ユーザ）：偽URLにアクセスし、認証情報を入力。続いてMFA認証も完了。
ステップ3. 攻撃者：MFA認証完了後のセッション情報を窃取。
ステップ4. 攻撃者：窃取した情報を用いて、正規ユーザとしてサービスにアクセスできるかどうかを確認。

図：攻撃者端末で生成したルアーURLに、被害者がアクセスした画面（ステップ1、2）

図：ユーザ名・パスワードを入力後の画面（ステップ2）

図：攻撃者端末上で被害者のアカウントにログインが完了した画面（ステップ4）

2. AiTM攻撃の脅威ポイント

検証を踏まえたうえで、AiTM攻撃のどのような点が脅威なのかを次にまとめます。

1. MFA完了後のセッション情報を窃取可能
検証の結果、上記の操作によって正規ユーザのMFA完了後のセッション情報窃取が可能であることと、それにより正規ユーザになりすましてサービスにログインできることが可能であることが分かりました。

2. ユーザが偽サイトに気づきにくい
上記の画面からもわかるとおり、ユーザにとって画面構成や動作からは、アクセスしているのがフィッシングサイトだと視覚的に判断するのは困難です。

3. IDプロバイダ（IdP）側での識別が困難
前述のとおり、AiTM攻撃では、攻撃者が準備したサーバを用いて、リアルタイムで正規ユーザとサービス間の通信を中継します。リクエストの内容自体は正規のユーザが送信している情報です。そのため、攻撃の中継サーバからのリクエストなのか、正規のリクエストなのかを、IDプロバイダ側で識別することは技術的に困難です。

4. 攻撃ツールが公開されており、実行が容易
AiTM攻撃を行うツール等は、実はインターネット上で複数公開されています。このため、中継サーバを構築できれば比較的容易に攻撃を行うことができてしまいます。

不正アクセスに対する有効な対策とされてきたMFAが、このように脅威にさらされている―。私たちはどうすればよいのでしょうか？次に、技術的対策を考えます。

技術的対策：パスワードレス認証の導入

AiTM攻撃に対しては、フィッシング耐性のある認証方式やパスワードレス認証などが技術的に有効な対策となります。
今回は、その中でもFIDO2^※に準拠したパスワードレス認証であるパスキーを用いた認証について紹介します。パスキーを用いた認証では秘密鍵がデバイス内に保存され、通信時にはドメイン検証を行った上で署名されるため、中間者による通信のすり替えが成立しません。マイクロソフトも「パスキーはAiTM攻撃に対する最善のソリューション」として導入を推奨しています。
※FIDO2（Fast Identity Online 2、ファイド2）：パスワードレス認証の普及を推進する業界団体「FIDO Alliance」が2018年にリリースした技術規格。指紋認証、顔認証、虹彩認証などの生体情報をオンライン上でやり取りできる。パスワードを覚える必要がなくなり、またパスワード管理に伴うセキュリティリスクも回避できる。

1. パスキーの動作と有効性

パスキーは、ユーザがMicrosoft 365などのサービスにログインする際、デバイス内の秘密鍵を用いて署名を行い、正規のドメインであることを検証します。これにより、攻撃者が中継サーバを介して通信を行っても、認証が成立しない仕組みとなっています。パスキーの認証ステップは以下のとおりです。

ステップ0.キーペアの作成
パスキーの利用を申請するとアプリケーションやサービスが「公開鍵」と「秘密鍵」のキーペアを生成し、秘密鍵をデバイスに保存します。同時に公開鍵はサーバに送信され、IDプロバイダ側で保管されます。

ステップ1. ログイン試行
ユーザがサービスにアクセスし、ログインを試みるところからプロセスは始まります。通常、ユーザ名やメールアドレスなどの識別情報を入力することが求められます。

ステップ2. 認証要求
ユーザがサービスにログインする際、サービス側のサーバはユーザのデバイスに対して認証要求を送信します。

ステップ3. 生体認証などのパスワードレス認証による本人確認
認証要求に応じてデバイスで生体認証やPIN（Personal Identification Number、一般的に都度表示される数字など）コードの入力を行います。これにより、デバイスの正当なユーザによる操作であることが確認されます。

ステップ4. 署名の生成
生体認証が成功した後、ユーザのデバイスは秘密鍵を使って署名を生成してサービス側のサーバに署名を送信します。

ステップ5. 署名の検証
サーバは受け取った署名を、キーペアの公開鍵を使用して検証します。検証が成功すると、サーバはユーザの身元が確認されたとみなし、ログインプロセスが成功となります。ユーザはサービスにアクセスする権限を得ます。

＜関連記事＞パスキーとは？Apple、Google、マイクロソフトが採用する新たな認証の仕組みを解説

図：パスキー登録時の流れ（ステップ0）

図：パスキーを使用した認証の流れ（ステップ1～5）

まとめると、パスキーによる認証では、ユーザ本人だけが持っている端末や生体情報を利用します。ユーザの端末で認証が行われ、認証結果は端末内の秘密鍵で署名され、その署名がサーバに送信されます。IDプロバイダではそれを公開鍵により検証したうえで認証します。このため、AiTM攻撃が技術的に成立しない仕組みとなっているのです。

図：パスキーを有効化した場合の AiTM フィッシング攻撃の流れの想定

続いて、AiTM攻撃が成立しないことを確認するため、Microsoft Authenticatorのパスキーを有効化した状態で、次のような検証を行いました。

2. パスキーの検証結果

先ほどと同じステップで検証を行います。
Microsoft Authenticatorのパスキーを有効化し、攻撃者が準備したフィッシングサイト上で、被害者ユーザがIDを入力します。その後「パスワードの入力」画面で、「代わりに顔、指紋、PIN、またはセキュリティキーを使用する」を選択します。すると、正規のサイトでは認証待ちの画面（QRコードなど）に遷移しますが、フィッシングサイト上でエラーが表示されます（PostBackUrl^※エラー）。これは、ユーザが「代わりに顔、指紋、PIN、またはセキュリティキーを使用する」を選択した時点でMicrosoft 365にリクエストが送られており、Microsoft 365側でそのリクエストが正規ドメインからのものかどうか検証しているからです。攻撃者のフィッシングサイトからのリクエストは拒否されるため、認証ステップが先に進まず、セッション情報の窃取に至ることはありません。
※PostBackUrl：ユーザがフォームに入力したデータをサーバに送信する際、そのデータが処理された後に、その処理結果を通知する別のURLとして指定するパラメータ。データ送信先として、そのページ（URL）自体を指定する。