アカウント乗っ取り対策：MFAが最初の一歩にすぎない理由

はじめに

多要素認証（MFA）だけでは、アカウント乗っ取りの脅威を解消できません。確かに攻撃のハードルは高まりますが、執拗な攻撃者は、利用可能なあらゆる認証要素を巧妙に回避する方法を見いだしています。MFAは認証の問題を解決するものではなく、むしろ攻撃対象領域を広げるものと捉えるべきです。認証要素が増えるたびに、新たな依存関係を持つシステム、バグや脆弱性の新たな発生源、ソーシャルエンジニアリングの新たな機会が生じます。残念ながら、多くのセキュリティ組織は、かつてネットワーク境界を捉えていたのと同様に、MFAを幅広い攻撃を防ぐ防壁と見なしています。ゼロトラストセキュリティの提唱者によって明らかにされた「安全な境界」という誤った考え方は、攻撃者がネットワーク内部の脆弱性を悪用して横方向に移動し、権限を昇格させる余地を与えていました。同様に、MFAでアカウント乗っ取りを解決できるという誤った考え方は、セキュリティ組織がMFAの弱点や、ユーザーアカウントを犯罪者による乗っ取りの危険にさらす、依然として残る多くのシステム脆弱性を認識する妨げとなります。本ホワイトペーパーでは、攻撃者がMFAを回避する手法を検証し、MFAによって、ボット対策、JavaScriptサプライチェーンの保護、コンテキストに基づくリスクの監視といった他のセキュリティ対策が一層重要になることを示します。これらの手法は、MFAがユーザーに課す負担を軽減しながら、そのセキュリティ上の利点を強化します。

MFA導入の推進要因

弱点はあるものの、MFAが今後も利用され続けるのには十分な理由があります。パスワードのみによる認証は、明らかに機能していません。

人間は、ランダムな文字が長く並んだ文字列を覚えることができません。そのため、覚えやすく推測されやすいパスワードを選ぶ、複数のアプリケーションで同じパスワードを使い回す、付箋にパスワードを書き留めるといった安易な方法を取ってしまいます。企業はパスワードの長さや複雑さに要件を設けることでこのリスクを軽減していますが、人間の記憶力には限界があります。複雑さの要件があっても、最初の文字だけを大文字にする、見た目が似た英数字を特殊文字に置き換える（Sを$にするなど）、パスワードの末尾に123のような推測しやすい数字を追加するなど、予測可能なパターンを使ってしまいます。（「パスワードの予測可能性」に関する調査結果をご覧ください。）

また、人間にはソーシャルエンジニアリングに付け込まれやすい共通の弱点があります。攻撃者に、他者への信頼、周囲に同調したいという気持ち、権威への敬意、人を助けようとする善意を利用されると、パスワードを教えてしまいます。実際、尋ねるだけでパスワードを教えてしまう人もいます。その様子は、こちらの愉快な動画「Jimmy Kimmel Live」でご覧いただけます。

パスワードベース認証にはこうした弱点があるため、政府機関や業界団体がMFAの導入を推進しています。2021年5月、バイデン大統領は、連邦政府機関に180日以内のMFA導入を義務付ける大統領令を発令しました。また、Cybersecurity and Infrastructure Security Agency（CISA）は、民間企業に対してMFAの導入を推進しています。Payment Card Industry Security Standards Councilは、Data Security Standard v4.0により、2025年3月31日までに、カード会員データへのすべてのアクセスにMFAを実装することを組織に義務付けています。

パスワードのみによる認証と比べたMFAの明確な利点を背景に導入が進む一方で、セキュリティ担当者は、MFAの欠点や、MFAによって攻撃対象領域が拡大し、攻撃者による認証制御の回避を可能にする新たな脆弱性が生じる仕組みに、これまで以上に注意を払う必要があります。

MFAによって拡大する攻撃対象領域

MFAとは、認証プロセスで2つ以上の要素を使用することです。ここでいう要素とは、以下の方法で本人であることを証明する手段を指します。

• 知識情報：パスワードや個人識別番号（PIN）など、本人だけが知っている情報
• 所持情報：モバイルデバイス、スマートカード、ハードウェアトークン、USBドライブなど、本人が所持しているもの
• 生体要素：指紋、顔スキャン、虹彩パターンなどの生体認証によって確認される、本人固有の特徴

MFAの実装方法は多岐にわたりますが、その多くは新たな攻撃対象領域を生み出すか、パスワードのみの認証に特有の脆弱性にアプリケーションをさらしたままにします。

SMSベースのMFA

MFAの実装方法は多岐にわたりますが、その多くは新たな攻撃対象領域を生み出すか、パスワードのみの認証に特有の脆弱性にアプリケーションをさらしたままにします。

最も広く普及しているMFAの実装では、SMSを使用してユーザーにワンタイムパスワード（OTP）を送信します。これにより、原理上はスマートフォンを所持していることを証明できます。通常、ユーザーがユーザー名とパスワードでログインを開始すると、アプリからテキストメッセージが送信されます。ユーザーがOTPを確認してアプリに入力すると、認証が完了し、一定期間有効なセッショントークンが生成されます。

SMSベース認証に残る脆弱性

SMSを使用して所持要素を実装しても、いくつかの重大な脆弱性は解消されません。ユーザーはOTPとパスワードをアプリケーションに入力し、アプリケーションは自身が使用するものと同じ通信チャネルを介してOTPをサーバーに送り返します。そのため、アプリケーション、デバイス、ネットワークのいずれかを侵害した攻撃者は、パスワード、OTP、セッショントークンにアクセスできます。

エンドポイントへの攻撃

攻撃者は、確立され、現在も広く使われているさまざまな手法でデバイスをマルウェアに感染させて乗っ取り、マン・イン・ザ・ブラウザー（MitB）攻撃を仕掛けます。ブラウザー内でコードを実行することで、パスワードとOTPを取得し、ユーザーになりすまして認証できます。また、認証が完了するのを待ってからセッション識別子を盗み、認証を回避してユーザーのアカウントにアクセスすることも可能です。（エンドポイントに感染するマルウェアの最近の傾向については、F5 Labsのレポート「BlackGuard Infostealer」をご覧ください。）

アプリの侵害

攻撃者は、アプリケーションをマルウェアに感染させることで、多数のユーザーアカウントを一斉に乗っ取ることができます。また、マルウェアを使って企業のインフラストラクチャを侵害するだけでなく、アプリケーションを構成するコードライブラリのいずれかを侵害し、アプリケーションデータにアクセスすることも可能です。この手法は、サプライサイド攻撃と呼ばれます。

ソフトウェアサプライチェーン攻撃では、通常、攻撃者は標的組織にソフトウェアコンポーネント（ライブラリ、フレームワーク、サービス）を提供する、信頼されたサードパーティベンダーやオープンソースリポジトリを狙います。攻撃者はコンポーネントにマルウェアを注入し、そのコンポーネントがアプリケーションに組み込まれるようにします。すべてのベンダーやオープンソースチームが、セキュアコーディングの実践に必要なスキルとリソースを備えているとは限らないため、この攻撃は効果を発揮する可能性があります。

Webアプリケーションやモバイルアプリケーションは通常、数十ものサードパーティ製スクリプトを使用しており、その多くがタグマネージャーによってページに動的に追加されるため、サプライチェーン攻撃に対して特に脆弱です。これらのスクリプトは頻繁かつ予告なく変更され、組織のコードセキュリティチェックを経ることもありません。攻撃者がこれらのスクリプトのいずれかを侵害すると、アプリケーションを完全に制御できるようになります。その結果、ユーザー入力の読み取り、ブラウザメモリ内のデータへのアクセス、ユーザージャーニーの乗っ取りによる悪意のあるアプリへの予告なしの誘導が可能になります。

Magecartなどの、こうした「サプライチェーン攻撃」により、数十万件の認証情報が侵害されています。MitB攻撃と同様に、こうしたサプライチェーン攻撃は、所有を証明するトークンをアプリケーションに入力する方式のMFAソリューションに対して有効です。これは、OTPを使用する実装の大半に該当します。悪意のあるコードはユーザー入力を読み取るため、固定パスワードとOTPの両方に加え、アプリケーションが収集するその他の個人情報や財務情報も窃取する可能性があります。

ネットワークの盗聴

SMSベースの認証では、パスワード、OTP、セッショントークンが同じネットワーク接続を介して送信されるため、この形式のMFAには、DNSポイズニング、ARPポイズニング、不正な無線アクセスポイントなどの典型的な攻撃ベクトルを利用した中間者（MitM）攻撃に対する脆弱性が残ります。

ソーシャルエンジニアリング

SMSベースのMFAを狙う攻撃の中でも特に一般的で成功率が高いものの1つは、ソーシャルエンジニアリングを利用し、リアルタイムフィッシングプロキシ（RTPP）を介してMitM攻撃を成立させる手法です。

この攻撃では、詐欺師がフィッシングメールを使ってユーザーをだまし、攻撃者が管理するサイトにアクセスさせ、認証情報を入力させます。ここまでは認証情報を窃取するフィッシング攻撃と同じですが、MFAを回避するにはもう1つ手順が必要です。ユーザーがアプリにユーザー名とパスワードを入力すると、攻撃者はその認証情報を標的のアプリケーションに転送します。すると、標的のアプリケーションはユーザーに第2要素による認証を要求します。ユーザーは信頼できるアプリケーションで認証していると思い込んでいるため、その要求を承認する可能性が非常に高く、承認ボタンをクリックするか、指示どおりにアプリへトークンを入力します。いずれの場合も、攻撃者はアプリケーションへのアクセス権を取得します。（この攻撃のデモについては、Kevin Mitnickによるこちらの動画をご覧ください。）

自動化に加え、ユーザーがフィッシング詐欺に遭いやすい傾向があるため、RTPP攻撃は大規模に成功する可能性があります。（リアルタイムフィッシングプロキシの増加に関する詳細なデータについては、「F5 Labsフィッシングおよび不正行為レポート」をご覧ください。）

SMSベース認証の新たな脆弱性

SMSを第2の認証要素として使用しても、パスワードのみの認証に存在する脆弱性の多くは解消されないうえ、アプリケーションが新たな攻撃経路にさらされます。

物理デバイスの盗難

所持情報に基づく認証に対する攻撃として最も分かりやすいのは、物理デバイスの盗難でしょう。スマートフォンを盗んだ犯罪者は、端末がロックされていても、通知に表示されたOTPにアクセスできる可能性があります。多くのスマートフォン盗難の被害者が、銀行口座から預金を失っています。

SIM（加入者識別モジュール）スワッピング

犯罪者は、テキストメッセージで送信されるOTPにアクセスするために、実際に携帯電話を手に入れる必要はありません。SIMハイジャックやSIMポーティングとも呼ばれるSIMスワッピング（https://www.darkreading.com/edge/sim-swapping-attacks-what-they-are-how-to-stop-them）により、攻撃者は、顧客向けアプリで最も広く利用されているMFA方式であるSMSベースの認証を回避できます。SIMスワップ攻撃では、詐欺行為者が、通信サービスプロバイダーによる電話番号の別の端末への移行機能を悪用します。この機能は、携帯電話の紛失時や盗難時に役立つものです。

詐欺犯はまず、オンライン調査、フィッシング、ソーシャルエンジニアリングを通じて、被害者の個人情報を収集します。次に、その情報を使って電話会社を欺き、被害者の電話番号を詐欺犯のSIMに移行させます。また、クレデンシャルスタッフィング、ブルートフォースによる推測、辞書攻撃を用いて、サービスプロバイダー上のユーザーアカウントに侵入する場合もあります。

被害者の電話サービスを掌握した詐欺師は、被害者宛てのSMSや音声通話をすべて受信するようになります。これにより、テキストメッセージで送信されるセキュリティトークンを傍受できます。

ハードウェアトークンデバイス

ハードウェアトークンデバイスは、通常は非常に小型の専用デバイスで、OTPを表示します。ユーザーは、表示されたOTPをアプリケーションに入力して認証を行います。このデバイスを使用すると、アプリケーションからユーザーへの通信を必要とせずに、デバイスを所持していることを証明できます。そのため、SMSベースの認証における主な脆弱性の1つを排除できます。

ログインのたびにOTPをユーザーへ送信する方式に依存するのではなく、デバイスは初期シード値とアルゴリズムに基づいて一連のOTPを生成します。シード値自体は、セットアップ時にデバイスと認証サービスの間で共有されます。シード値には、ログイン要求などのイベント、または60秒などの経過時間に応じて増分されるカウンターが付加されます。これらをそれぞれイベントベースOTP（EOTP）および時間ベースOTP（TOTP）と呼びます。EOTPとTOTPはいずれもハッシュベースOTP（HOTP）の一種です。これは、カウンターとシードが一緒にハッシュ関数へ渡され、一見ランダムな数字列が生成されるためです。正しく実装されていれば、この数字列から予測可能なパターンが明らかになることはありません。

ハードウェアトークンでは、テキストメッセージでOTPを送信する必要がないため、SIMスワッピングなどの手段で、ユーザーに届く前のOTPを取得することはできません。ただし、ユーザーがアプリにOTPを入力する必要があり、そのOTPはパスワードと同じ通信チャネルを使用して認証サービスに送信されるため、SMSベースの認証に存在するその他の脆弱性の大半は残ります。攻撃者は、テキストメッセージで配信されるOTPの場合とまったく同じ方法で、エンドポイント、ネットワーク、またはアプリケーションを侵害し、パスワードとOTPを取得できます。

SMSベースの認証に対する最も一般的な攻撃であるリアルタイムフィッシングプロキシは、ハードウェアデバイスで生成されたOTPに対しても同様に有効です。OTPがスマートフォンと専用デバイスのどちらに表示されるかにかかわらず、ユーザーがだまされて偽サイトにOTPを入力してしまうためです。

ハードウェアデバイスを使用すれば、ユーザーへの送信中に攻撃者がOTPを取得する可能性はなくなりますが、こうしたデバイスは侵害される可能性のあるシード値に依存しています。攻撃者は、デバイスを物理的に入手する（電子顕微鏡を使用した攻撃については「MFAをハッキングする12以上の方法」を参照）、認証サービスが使用するデータベースを侵害する、またはデバイスと認証サービスの間でシード値を合意するセットアッププロセスを傍受することで、シード値にアクセスできます。

認証アプリ

認証アプリは、ハードウェアトークンとほぼ同様に機能します。初期シードとアルゴリズムに基づいて一連のOTPを生成するため、脆弱なチャネル経由でシードを伝達する必要がありません。さらに、別のチャネルを使用してOTPを伝達することもできます。この場合、ユーザー名とパスワードの検証に成功すると、認証サービスは認証アプリにプッシュ通知を送信し、ユーザーにリクエストの承認を求めます。承認されると、認証アプリは、ユーザーがアプリケーションにOTPを入力しなくても、認証サービスにOTPを直接送信します。認証アプリと認証サービス間の通信には、別個の接続が使用されます。

別の通信チャネルを使用すると、OTPがアプリケーションに入力されることがないため、攻撃者はアプリケーションを侵害してもOTPにアクセスできません。また、パスワードとOTPはそれぞれ異なるセキュアなチャネルを介して送信されるため、ネットワーク接続を侵害して両方を取得することも難しくなります。ただし、アプリケーション自体と認証アプリが同じデバイス上で実行されている場合、エンドポイントが侵害されると、攻撃者がパスワードとOTPの両方にアクセスできる可能性があります。（Google Authenticatorを侵害するマルウェアに関するF5 Labsの「レポート」を参照してください。）

残念ながら、認証アプリではリアルタイムフィッシングプロキシの使用を防ぐことはできません。ユーザーはフィッシングのテキストメッセージにだまされ、偽サイトにユーザー名とパスワードを入力してしまう可能性があります。認証情報を入力すると、アプリケーションから認証アプリにリクエストが送信されます。ユーザーは信頼できるアプリケーションへのログイン処理中だと思っているため、そのリクエストを承認し、認証を完了してしまう可能性が高くなります。攻撃者がOTPを直接確認することはありませんが、攻撃者のプロキシが認証済みセッションを制御できるようになり、ユーザーのアカウントにアクセスできるようになります。（RTPPとプッシュ通知認証の詳細については、Hacker Newsの「フィッシングプラットフォームに関する記事」を参照してください。）

さらに、認証アプリの使いやすさが、攻撃者がソーシャルエンジニアリングによってMFAを突破する新たな手段を生み出しています。MFAボミングまたはMFA疲労攻撃では、攻撃者は認証コードを求める不正なリクエストを繰り返し送信し、標的をだまして認証コードを渡させます。通常、攻撃者は自動化ツールを使用して大量のリクエストを生成し、認証コードの入力を求める過剰な数の通知やメッセージを送り付けて被害者を圧倒します。

MFAボミングでは、ユーザーをだましてSMSメッセージやハードウェアデバイスからOTPを入力させることがありますが、ボタンを押すだけで大量のリクエストを簡単に止められるため、認証アプリに対して特に効果を発揮します。

生体認証

生体認証には、所持情報に基づく認証よりもさらに多様な実装方法があります。認証要求を開始し、そのデータを認証サービスに返す方法が数多くあるだけでなく、生体情報にも指紋から虹彩スキャンまでさまざまな種類があります。スキャンに必要なハードウェアは、ノートPCの指紋リーダーやカメラなど、アプリケーションを実行するデバイスに組み込まれている場合もあれば、別途用意する必要がある場合もあります。生体情報リーダーは、オペレーティングシステムまたは専用アプリケーションによって制御されることがあります。このように実装方法が多岐にわたるため、すべての脆弱性をモデル化することは困難です。ただし、生体認証はセキュリティが高いと評価されている一方で、明確な脆弱性も依然として存在することを認識しておくことが重要です。

実際、所有要素を回避する一般的な手法の1つであるリアルタイムフィッシングプロキシは、生体認証の回避にも同様に利用できます。ユーザーが攻撃者の管理するアプリケーションを信頼できるアプリケーションだと思い込んでログインすると、そのアプリケーションは認証情報を使用してユーザーに代わって正規のアプリケーションにログインし、生体認証の要求を発生させます。ユーザーが正規のアプリケーションで認証していると信じている限り、そのまま生体認証を行う可能性が高く、攻撃者にアカウントへのアクセスを許すことになります。（W3Cが策定したFIDO2標準のWebAuthnにはフィッシング対策が組み込まれていますが、Webアプリケーションではまだ広く採用されていません。）

エンドポイント、アプリケーション、またはネットワークの侵害によって生体認証を突破できるかどうかは、具体的な実装によって異なります。生体認証システムがアプリケーションと同じデバイス上で動作する場合、エンドポイントが侵害されると認証が破られる可能性があります。アプリケーションが生体認証プロセスを管理する場合、アプリケーションが侵害されると認証が破られる可能性があります。また、生体認証データがアプリケーションと同じ通信チャネルを介して送信される場合、ネットワークが侵害されると認証が破られる可能性があります。つまり、生体認証には、実装ごとの詳細な脅威モデリングが必要です。

生体認証には、複製やなりすましに対する特有の脆弱性があります。指紋を例に考えてみましょう。私たちは、触れたほぼすべての滑らかな表面に指紋を残しています。ドアノブにも、レストランにも、ごみにも残します。こうした表面から指紋を採取するのは容易です。刑事ドラマでその場面を何度も目にしたことがあるでしょう。指紋の複製も同様に容易で、3Dプリンターからグミキャンディまで、さまざまなものを利用できます。

その他の生体認証方式では、生体認証をどのようにスプーフィングできるかを明らかにするセキュリティ研究者と、スプーフィング対策技術を開発するベンダーとの間で、絶えず攻防が続いています。3Dマスクによって空港の顔認証装置が欺かれた事例がありますが、こうしたマスクは生体検知などの方法で検出できます。同様に、攻撃者が音声録音とディープフェイク音声合成を利用して音声認識システムを回避した事例もありますが、録音機器によって加わるわずかな歪みから、こうしたスプーフィングを検出できる可能性があります。虹彩画像でさえ、カラーコンタクトレンズや人工眼球を使って複製し、スプーフィングできますが、人間の組織と合成素材に対する光の反応の違いを利用する手法など、さまざまなスプーフィング対策技術によって検出できます。つまり、生体認証装置のセキュリティは、その時点におけるスプーフィング技術とスプーフィング対策技術の進展状況に左右されます。

たとえ隠遁生活を送り、物理的に物に触れないようにしても、攻撃者に生体認証データを盗まれる可能性はあります。攻撃者は、マルウェアやソーシャルエンジニアリング、未修正の脆弱性の悪用を通じて、これまでに数十億件ものユーザー名とパスワードを盗んできました。パスワードを保存するデータベースに侵入できるのであれば、生体認証データを保存するデータベースにも間違いなく侵入するでしょう。そして、ひとたび侵害によって生体認証データが漏えいすると、なりすましを検出できるかどうかによっては、そのデータを認証に安全に使用できなくなる可能性があります。

コピーやなりすましによるセキュリティリスクをさらに深刻にしているのは、生体認証で測定する特徴を簡単には変更できないという事実です。攻撃者にパスワードを盗まれても、パスワードは変更できます。OPTドングルや携帯電話を盗まれた場合も、交換してシードをリセットできます。しかし、攻撃者が指紋、掌紋、顔画像などの生体的特徴を入手し、それらを効果的になりすます方法を習得した場合、多大な苦痛を伴わずにこうした身体的特徴を変更することはできません。

MFAのセキュリティ強化

MFAは、単一要素のパスワードベース認証よりも優れていますが、少なくとも現在広く普及している実装形態には、依然として脆弱性があります。そのため、MFAをセキュリティ強化の取り組みの終着点ではなく、新たな出発点と捉えることが重要です。脅威モデリング、コードレビュー、脆弱性スキャン、ペネトレーションテスト、レッドチーム演習など、アプリケーションセキュリティのベストプラクティスは、これまでと変わらず重要です。脅威モデリングでは、認証とセッション管理のプロセスを構成する各要素を確認し、IDストアから物理、ネットワーク、データのセキュリティに至るまで、数多くの攻撃ポイントを考慮します。サイバー攻撃は、最も脆弱な部分を狙う可能性が高いためです。特にMFAの脆弱性を踏まえると、自動化への対策、JavaScriptサプライチェーン攻撃からの保護、リスクコンテキストの考慮という、より注意を払うべき重要な領域がいくつかあります。

ネットワークからボットを排除

犯罪者は、クレデンシャルスタッフィング、リアルタイムフィッシングプロキシ、MFA爆撃など、MFAを狙う複数の主要な攻撃を大規模に実行するためにボットを利用しています。そのため、あらゆる形態のMFAを保護するには、ボットの緩和が重要です。

In credential stuffing attacks, as defined by OWASP, criminals obtain stolen credentials from prior breaches, typically through purchase on the dark web, and test those credentials against the logins of other applications. Because billions of credentials have been exposed through breaches, criminals maximize their returns by automating the testing with bots so that they can test massive numbers of credentials. The Federal Bureau of Investigation, Securities and Exchange Commission, and New York Attorney General have issued warnings on the financial risks of credential stuffing, and the Global Privacy Assembly, an association of over 130 regulatory agencies, declared credential stuffing a global threat to privacy.

クレデンシャルスタッフィングの防止は、パスワードのみの認証と同様に、MFAにとっても重要です。MFAの目的は複数の要素を使用することですが、第1の要素を保護できなければ、残る要素は1つだけになります。攻撃者にユーザーのパスワードが知られると、2要素認証は1要素認証となり、多層防御が失われます。

さらに、犯罪者はパスワード以外もボットで攻撃するため、ボット対策が極めて重要です。実際、ボットは、MFAを突破する最も一般的な手口であるリアルタイムフィッシングプロキシ攻撃を成功させるための主要なツールです。ユーザーがフィッシングメールにだまされ、偽サイトに認証情報を入力してしまうと、攻撃者は、SMS、認証アプリ、高度な生体認証のいずれを使用する場合でも、MFA要求を生成するために、その認証情報を標的のアプリケーションへ転送する必要があります。この転送を迅速かつ大規模に行うには、犯罪者はプロセスを自動化する必要があるため、ボットからアプリケーションへ要求が転送されることになります。（ボットを使用してOTPを回避するサービスの概要については、Krebs on Securityの記事「ワンタイムパスワード傍受ボットの台頭」をご覧ください。）つまり、望ましくないボットによる認証情報の送信を防ぐことで、組織はリアルタイムフィッシングプロキシの有効性を大幅に低下させ、所持情報と生体情報の両方の認証要素をより効果的に保護できます。

犯罪者がボットを利用してMFAを攻撃するもう1つの典型的な手口が、MFAボミングです。ここでいうボミングとは、大量のログインリクエストを生成して認証リクエストを繰り返し送信し、ユーザーが誤って、または煩わしさから逃れるために承認してしまうよう仕向けることです。多数のユーザーに対して攻撃を収益化できるほど大量のリクエストを生成するには、犯罪者は処理を自動化する必要があります。つまり、サイトに届くログインリクエストもボットによって生成されます。

これらの例が示すように、MFAに対する攻撃のほぼすべては、大規模に成功させるためにボットに依存します。そのため、MFAを導入する組織は、ボット対策に真剣に取り組む必要があります。

残念ながら、多くの組織は、ボットが高度化していることや、犯罪者が検知を回避するためにボットを頻繁に改変し続けていることを十分に認識していません。それどころか、あまりにも多くの企業が、CAPTCHA、IPアドレス拒否リスト、HTTPヘッダーフィンガープリントなど、もはや有効ではないボット対策手法に依存しています。

ボットは、機械学習やクリックファームを利用した低コストのCAPTCHA解読サービスを使ってCAPTCHAを回避できるため、CAPTCHAは実際の顧客に煩わしさを与えるだけで、ボット対策にはほとんど役立ちません。ウェブで「CAPTCHA解読サービス」と検索するだけで、価格とスピードを競うサービスが少なくとも十数社見つかります。こうしたサービスについて詳しく知るには、F5のHead of IntelligenceであるDan Woodsによる記事「私は人間のCAPTCHA解読者だった」をご覧ください。さらに興味深いことに、ChatGPTはソーシャルエンジニアリングを使って人にCAPTCHAを代わりに解かせ、CAPTCHAの回避に成功しました。

WAFベースのIP拒否リストを利用してボットを緩和している組織にとっても、その対応は同様に困難です。ボット作成者に、ボット検知の回避を目的とした数千万件もの住宅用IPアドレスを提供するサービスがあります。これらはローテーション型住宅用プロキシとして宣伝されています。多くの企業ブラウザがフォワードプロキシ経由でリクエストを送信するのと同様に、ボットはプロキシにHTTPリクエストを送信し、サービス側はWebサイトやAPIへのリクエスト送信に使用するパブリックIPアドレスを継続的に切り替えます。従来、ボットは一般に、クラウドサービスなどのデータセンタープロキシを使用していました。これらは広く知られており、容易に特定できます。しかし、こうした新しいプロキシサービスでは、実際のお客さまと同じ地域の住宅用IPアドレスが使用されます。インターネットサービスプロバイダー（ISP）によるNATのため、各IPアドレスがボットと正規のお客さまの両方を同時に表す可能性があります。そのため、実際のお客さまを拒否せずに、これらのIPアドレスをすべてブロックすることは現実的ではありません。（これらのサービスがIPアドレスを取得する仕組みに関する調査については、論文「Your Phone is My Proxy」をご覧ください。）

ヘッダーの順序の違いに基づくボット検出も、ボット側がこの手法を把握しているため、もはや機能しません。実際、stealth-puppeteerやundetected-chromedriverなどの複数のオープンソースプロジェクトでは、ヘッダーを正しい順序に並べられるため、これらの一般的な自動化フレームワークを使用しながら、検出を容易に回避できます。

現在、高度なボットを検知するには、高度なシグナル収集、24時間365日の監視、機械学習に加え、ボットの改変への迅速な対応が必要です。改変を迅速に検知して対応できる専用のボット管理ソリューションを導入しなければ、犯罪者はボットを利用してMFAに対する攻撃を効率的に拡大できるようになります。

JavaScriptサプライチェーン攻撃を防御

アプリケーションが侵害されると、考えられるほぼすべてのMFAが機能しなくなります。攻撃者がアプリケーションにコードを挿入すれば、もはや防ぐことはできません。攻撃者は、認証情報やその他のMFA入力情報を取得したり、セッション識別子を窃取してセッションを乗っ取ったり、アプリケーションから直接データを流出させたりできます。一般に、最新のWebアプリケーションは、20個を超えるJavaScriptファイルで構成されています。その大半はサードパーティ製で、組織のアプリケーションセキュリティチームによるレビューを受けていません。そのため、JavaScriptサプライチェーン攻撃によってアプリケーションが侵害されるリスクは、一般に認識されている以上に高くなっています。

既存のクライアント側セキュリティプロトコルは静的すぎるため、今日の動的なWebアプリを保護できません。Content-Security Policy（CSP）は、JavaScriptサプライチェーン攻撃を防止できるようにスクリプトの動作を制限します。しかし、サードパーティベンダーがCSPの制限に反する形でスクリプトを動的に更新すると、サイトの機能が容易に損なわれる可能性があります。セキュリティポリシーに違反するスクリプトは実行に失敗することが望ましい場合もありますが、本番環境でそのような障害が発生すると、お客さまに甚大な影響を及ぼす可能性があります。（「CSPが機能しない理由」を参照）もう1つのWebセキュリティプロトコルであるSub-resource Integrity（SRI）は、サードパーティの動的コンテンツにはさらに適用しにくいものです。スクリプトが変更されるたびに、スクリプトタグのハッシュ値を更新する必要があり、予告なく変更された場合には対応できないためです。実際、SRIは、最新のアプリケーションの多くが依存している種類のスクリプト更新を防止することを目的としています。

JavaScriptサプライチェーンの脆弱性を排除する明確な制御手段がないため、組織は少なくともリスクを監視する方法を工夫して見つける必要があります。サイト上のスクリプトをより適切に文書化し、提供元と変更頻度に基づいてリスクをランク付けできます。タグマネージャーを通じて追加されたスクリプトは、リスクを評価するために定期的にレビューする必要があります。スクリプトの動作を追跡する監視ツールも利用できます。追跡には、合成監視、レポート専用モードのCSP、またはブラウザで実行されるJavaScriptベースのエージェントを使用します。

サードパーティ製スクリプトは頻繁に変更され、セキュリティレビューを実施する機会もないため、組織は、スクリプトが機密データを読み取り、信頼できないドメインに流出させるといった不審な挙動がないか、アプリケーションを継続的に監視することが重要です。JavaScriptサプライチェーン攻撃に対するこの監視がなければ、どのようなMFAを導入してもユーザーの安全を確保できません。

既知の正規ユーザーを識別し、不審な挙動には追加認証を要求

MFAの目的は、無意味なセキュリティ対策でお客さまに負担をかけることではなく、セキュリティを強化することです。状況に応じたリスクに合わせてログイン要件を調整することで、優良なリピーターにMFA要件を繰り返し課すことなく、ユーザーセッションを延長して利用をスムーズにできます。TSAがTSA PreCheckで信頼できる旅行者の手続きを迅速化するように、パーソナライズされた手間のかからない体験でお客さまを迎えられます。

コンテキストに基づくリスクには、さまざまな側面があります。

• 地理的位置：IPアドレスに基づくと、ユーザーは通常の地域からログインしていますか？
• ASN（自律システム番号）：IPアドレスに基づくと、ユーザーは自宅、職場、行きつけのカフェなどで普段利用しているISPからログインしていますか？
• デバイス：ユーザーは普段と同じデバイスからログインしていますか？
• 時間／曜日：ユーザーは普段と同じ時間帯や曜日にログインしていますか？たとえば、午前中は銀行取引、夜はゲームのためにログインしているでしょうか？
• 行動：ユーザーは普段と同じ速度で入力し、同じパターンでマウスを動かし、同じような方法でコピー＆ペーストしていますか？
• 機能：ユーザーは通常と同じ機能を利用していますか？

ユーザーに良好な行動実績があり、同じ場所、同じデバイス、同じ時間帯から、普段と同様の行動で通常の機能を使用してサイトにアクセスしている場合、ログインを求める必要がないこともあります。代わりに、継続的なサイレント認証を実施してセッションを延長し、ユーザーの利便性を高めることができます。通常とは異なるコンテキストからリスクが高いと判断される場合は、アプリケーションに適応型ポリシーを追加し、パスワードによるログインや2要素認証（2FA）を要求する、アカウントをレビュー対象としてフラグ付けする、ログインについてSMSまたはメールでユーザーに通知する、アカウントをロックしてサポートへの問い合わせを求めるなど、セキュリティ要件を段階的に引き上げることができます。

多くの場合、セッションの有効期間はコンテキスト上のリスクにかかわらず一定に設定されています。そのため、セッショントークンを持つ者であれば誰でも、セッションハイジャックのリスクが考慮されないまま、ユーザーにアクセス権限が付与されたデータへ引き続きアクセスできます。よりセキュアなアプローチは、侵害を前提として継続的に監視するというゼロトラストの原則に従うことです。セッション中にコンテキストが変化した場合は、セッションを早期に終了して追加認証を要求し、コンテキストの変化の度合いとデータの機密性に応じて認証要件の厳格さを調整します。

まとめ

「セキュリティは旅である」という常套句になぞらえるなら、MFAはその道にいくつもの分岐を生み出し、新たな選択肢を提供してきました。これらを適切に実装すれば、セキュリティを実質的に強化できます。しかし、要素の数や実装の質、コストにかかわらず、目的地までの道のりを省略できるMFAはありません。今後も「パスワードの終焉」が繰り返し宣言され、新たなMFA技術によって認証の安全性が完全に確保されるという過剰な期待が広がるでしょう。それでも、執拗な攻撃者が新技術を回避する手段は残り続けます。

重要なアプリケーションのセキュリティ強化に取り組むうえで、F5がパートナーとして支援します。F5 Distributed Cloud Servicesには、ボットを緩和するBot Defense、JavaScriptサプライチェーン攻撃を監視するClient-Side Defense、再訪ユーザーを認識してコンテキストに基づくリスクを定量化するAuthentication Intelligenceが含まれます。F5の支援により、カスタマーエクスペリエンスを最適化しながら、MFAのセキュリティ確保を支援します。詳しくは、F5 Distributed Cloud Servicesをご覧ください。また、F5のチームへのご相談は、お申し込みください。

2023年6月26日公開