MFAはどのようにハッキングされるのか——防止のための戦略

多要素認証(MFA)の利用は増加していますが、効果的なセキュリティツールとして機能させるには正しい実装が不可欠です。ここでは、よくあるMFA攻撃とその脅威モダリティから組織を守る方法を紹介します。

 多要素認証(MFA) がセキュリティ面で大きなメリットをもたらすことはよく知られていますが、依然として実装が不十分で、断片的かつ一貫性を欠いたまま導入されているケースが目立ちます。これがMFA本来のセキュリティツールとしての有効性を損ない、ユーザーに追加の作業負担を強いる結果にもなっており、MFA普及を妨げる要因の一つとなっています。

MFAを回避する巧妙な手口を伝えるニュースが頻繁に報じられていることも、状況を後押ししていません。たとえば、クラウドキーやSSHアクセスの詳細情報を突き止めたAIを悪用したフィッシング攻撃の実例や、Claude Codeを悪用したAIベース攻撃の別の事例などが挙げられます。最も高度なセキュリティ対策を講じているはずのベンダーでさえ無傷ではいられません。2023年に発生した一連のOkta攻撃では、GitHubのソースコードが盗まれ、サプライチェーンが汚染され、サポートポータルまで侵害される事態となりました。

とはいえ、パスワードレス方式の普及と高度化のおかげで、MFAの各種手法 は以前より使いやすくなっています。ここ数年、GoogleやMicrosoftといった大手ベンダーが従業員・顧客双方に対してMFA導入を義務化してきたことで、IT運用部門は認証方式の強化を促され、あらゆるアプリケーション全体で包括的かつ継続的な認証を実現しようという機運が高まっています。 

注目すべきは、攻撃者が企業のコンピューティングインフラのあらゆる側面に弱点を見出しているという事実です。問題の一因は、現代の一般的な認証ワークフローが複雑であることにあります。ユーザーはWebポータル、スマートフォンアプリ、AIへの問い合わせ、あるいはAPI経由でアプリケーションにアクセスします。接続経路も、ローカルネットワークやVPNを通じて、さまざまなエンドポイント、OS、ブラウザを使って行われます。そのため、MFAの導入状況を検証する企業は、MFAコードが傍受されうるあらゆる状況や場所に対して、細心かつ継続的な警戒を払う必要があります。

MFAの回避・悪用手法

手法  ネットワーク モバイル アプリケーション ワークフロー ブラウザとCookie
疲労攻撃 認証・アクセスポリシーの隙  プロンプト爆撃、認証・アクセスポリシーの隙  プロンプト爆撃 プロンプト爆撃、認証・アクセスポリシーの隙  プロンプト爆撃、認証・アクセスポリシーの隙
ソーシャルエンジニアリング 悪意あるプロキシサーバー、リアルタイムフィッシング中継 ビッシング、SMSフィッシング、SIMスワップ MFA非対応アプリ、偽サイト、TOTP中継 コンセントフィッシング、アカウント復旧の悪用 マン・イン・ザ・ブラウザ、コンセントフィッシング
認証トークン/Cookieの窃取 中間者(MITM)攻撃 認証アプリのフィッシング 悪意あるMFAソフトウェア セッションハイジャック セッションハイジャック、パス・ザ・クッキー
脆弱な認証の標的化 信頼済みIP/デバイスの偽装操作 パスワードの使い回し、FIDO/生体認証の欠如 脆弱なアカウント復旧、MFA非対応アカウント、IMAP/POPメールアクセス 過去の認証・ログイン情報の悪用、MFAへのブルートフォース セッションハイジャック、パス・ザ・クッキー、マン・イン・ザ・ブラウザ、コンセントフィッシング

MFA疲労攻撃

MFA疲労攻撃とは、通常はSMSのプッシュ通知を通じて大量の認証リクエストを立て続けに送りつけ、ユーザーが根負けしてリクエストを承認してしまうまで続ける攻撃手法です。これにより攻撃者にアクセス権が渡ってしまいます。2022年のUberで起きた事案がまさにこの例です。

これは、SMSが長年にわたり非常に安全性の低い第二要素チャネルとみなされてきた数ある理由の一つであり、PayPalが2026年にSMSベースのMFAを廃止したことからも、依然として脅威であり続けていることがわかります。

これらの攻撃は「プッシュ爆撃」や「プロンプト爆撃」とも呼ばれ、モバイル経由の悪用に限った話ではありません。MFA疲労攻撃は、認証やアクセス制御ポリシーの隙を突く形でも成立します。皮肉なことに、組織がMFAを多用すればするほど、MFA疲労攻撃が成功する可能性はかえって高まってしまいます。

攻撃者は、ソーシャルエンジニアリングと フィッシング攻撃 を組み合わせても攻撃を仕掛けます。SMSを使う手口(スミッシング)や音声通話を使う手口(ビッシング)を通じて認証ワークフロー全体を混乱させ、ユーザーを騙してMFAトークンを渡させるのです。

パンデミック後のリモートワーク利用の増加や、ワールドカップのようなイベントによるユーザー行動の変化も、攻撃者に悪用されがちです。Arctic Wolfは自社ブログで 次のように記しています。「ソーシャルエンジニアリングとMFA疲労攻撃を組み合わせることは、偽りの信頼感を生み出すため、脅威アクターにとって効果的な手法となり得ます」

こうした複合攻撃では、ユーザーを偽サイトやリアルタイムフィッシング中継、プロキシサーバーに誘導してワンタイムパスコードを取得するケースも多く見られます。モバイル認証アプリを狙う場合には、SIMスワップを利用してワンタイムコードを攻撃者の携帯電話へ転送させる手口も使われます。これは、通信事業者のカスタマーサポート担当者に対して自分こそが正規の電話番号の所有者であると信じ込ませ、SMS経由で認証メッセージにアクセスするという手法です。

さらに最近では、アカウント復旧やパスワードリセットのフォールバック機能を悪用してMFAによる保護を回避する手口も確認されています。

認証Cookieの窃取

攻撃者は、認証Cookieやその他のトークンを盗み出すことでMFAセッションを侵害することも可能です。これはいくつかの方法で実現されます。偽のログインページを設置したり、中継プロキシや 中間者攻撃・マン・イン・ザ・ブラウザ 型プロキシを利用してMFAコードを傍受・取得したりする手口です。

一例として、昨年発覚したJoomlaの侵害事案が挙げられます。多くのウェブサイトはセッションの非アクティブ時間制限を設けていないため、攻撃者は既に認証済みのエンドポイントを利用し、Cookieを盗んでMFAを回避することが可能でした。KnowBe4の研究者らはレポートの中で次のように述べています。「認可プロセスには、そのアクセス制御トークンを現在保持している者が正規のユーザーなのか、あるいはそもそも正しく認証を経ているのかを確認する手段がありません。この重要な事実こそが、ハッカーによるMFA侵害にしばしば悪用されているのです」

脆弱な認証の標的化

MFAを利用していないユーザーや、弱いパスワードを使っているアプリケーションを標的にすることも、コンピューティング環境全体にわたって見られるよくある脅威モダリティです。MFAの導入は進んでいるものの、依然として普及率は完全とは言えず、攻撃者はそうした無防備な場所やユーザーを見つけ出し、それに応じて標的を定めています。

数年前、Akiraランサムウェアの脅威アクターは MFAが設定されていないCisco VPNを使う組織に侵入し、ブルートフォース攻撃によってユーザーの認証情報を取得していました。2021年のColonial Pipeline攻撃まで遡ると、アナリストたちはMFAが稼働していないレガシーVPNで使われていた単一のパスワードが侵害の原因であったことを突き止めています。

かつて管理者が使用していたものの現在は使われていないサービスアカウントや、退職者が使っていたまま放置されているアカウントを悪用する手口も、この種の侵害でよく見られる侵入経路です。他にも、すでに認証済みのIPアドレスやデバイスを悪用したり、携帯電話網に直接攻撃を仕掛けたり、MFAコードを傍受するためのプロキシサーバーを設置したりする事例もあります。

MFA攻撃を防ぐための戦略

これらの悪用手口を踏まえると、MFAのセキュリティを確保するには細部への配慮が欠かせません。ここでは、MFA戦略を確実に成功させるためのヒントをいくつか紹介します。

1. 何を守ろうとしているのかを理解する

まず、セキュリティチームは、侵害から守るべきリソースが何であるかを理解する必要があります。CISAのファクトシートによれば、「たとえば、サイバー脅威アクターは組織のデータにアクセスするため、メールシステムやファイルサーバー、リモートアクセスシステムを標的にすることが多く、同時にActive Directoryのようなアイデンティティサーバーの侵害も試みます。これが成功すれば、新規アカウントの作成やユーザーアカウントの乗っ取りが可能になってしまいます」とのことです。

CISAは、MFA保護の対象として真っ先に FIDO プロトコルに対応したシステムを選ぶことを推奨しています。これには、ハードウェアキーの利用、生体認証コントロールの強化、そして特に機密性の高いアプリケーションに対するパスワードレスアクセスの導入が含まれます。

CISAのこのファクトシートが公開されたのは3年以上前のことですが、筆者としては、その提言だけでは不十分だと感じています。より優れたMFAは、企業全体で導入されるべきものです。

生体認証プロバイダーのToken.comでCEOを務めるKevin Surace氏はCSOに対し次のように語っています。「私たちはMFAへ移行しましたが、攻撃者もそれに合わせて移行してきました」。つまり、企業のセキュリティ管理者もまた、対策のレベルを引き上げる必要があるということです。

Surace氏は次のように述べています。「生体認証を伴わないMFA手法も存在しますが、それらは本人確認を保証するものではなく、単に『所持』を確認しているに過ぎないため、安全性はやや劣ります。短期的には機能しますが、それは最終的な解決策ではありません。今後は、Zoomや銀行取引のようなサービスにおいても、本人確認のためにリアルタイムの生体認証が求められるようになっていくでしょう」

その一例が、トークン窃取やセッションハイジャックといった高度なMFA回避手法に対抗するためにMicrosoftが導入した条件付きアクセスとリスクベース認証 です。これは、同社がアイデンティティセキュリティの強化に継続的に取り組んでいることの表れと言えます。

2. 認証をアダプティブ(適応型)にする

次に、すべての認証はリアルタイムかつ継続的なリスクベース評価であるべきで、ユーザーがその時々に行っている行動に応じて、セキュリティ要件を自動的かつ動的に引き上げる仕組みでなければなりません。

ユーザーがログインする一瞬だけアクセス制御を行うという従来のやり方は、それに応じて置き換えていく必要があります。 MFAをアダプティブ認証プロセスに組み込んだ製品 は数多く存在し、これを先述の強化手法と組み合わせることができます。たとえば、銀行口座に新しい振込先を追加しようとする際にパスワードレス認証を要求する、といった具合です。

3. アクセス権限を厳格に管理する

これに付随する取り組みとして、ユーザーおよびアプリケーションのアクセス権限を注意深く評価し、頻繁に見直すことも重要です。

ITセキュリティ担当者は、従業員が業務遂行に必要な最小限のデータにのみアクセスできるようにする必要があります。しかし、役割や職責は変化していくため、これを常に徹底するのは簡単ではありません。それでも、これまでの経験からすると、過剰にアクセス権限を付与されたまま、その後の監査や権限縮小が行われないユーザーが数多く存在するのが実情です。

4. MFAワークフロー分析を定期的に実施する

これまで挙げてきたポイントはすべて、MFAワークフロー全体の分析の一環として位置づけられるべきものであり、これ自体は決して目新しい話ではありません。Akamaiの Gerhard Giese氏は2021年のブログ投稿でこの点を指摘しており、MFAが必ずしも クレデンシャルスタッフィングを防げるわけではないと述べています。

Giese氏はさらに、ITマネージャーに対して次のように呼びかけています。「認証ワークフローとログイン画面を再点検し、Webサーバーの応答を詳しく調べることで攻撃者が有効な認証情報を割り出せてしまわないかを確認してください。また、ボット管理ソリューションを導入し、攻撃者の作業を容易にしてしまわないようにすべきです」

5. パスワードリセットのワークフローを見直す

歴史的に見落とされがちな側面の一つが、パスワードリセットのワークフロープロセスであり、だからこそ攻撃者に狙われやすい標的となっています。

Mitnick Securityは自社ブログの この投稿 で次のように述べています。「驚くべきことに、2FAのリセットパスワードプロセスに二段階目の検証を設けていないウェブサイトが数多く存在します。あるいは、MFA自体は提供していても、ユーザーに利用を義務付けていないケースも見られます」。より優れたMFAの導入に加え、ログイン失敗回数の制限やパスワードの使い回し防止策を講じることも有効です。

6. 価値の高い標的のセキュリティを確保する

最後に、攻撃者にとって価値の高い標的となりうるユーザーを洗い出し、評価する必要があります。

CISAはレポートの中で次のように述べています。「どの組織にも、追加のアクセス権限や特権を持つ、サイバー脅威アクターにとって特に価値の高いユーザーアカウントがごく少数存在します」。具体例としては、IT・システム管理者、顧問弁護士、人事担当マネージャーなどが挙げられます。MFA導入プロジェクトの初期展開フェーズでは、こうしたグループを優先的に対象とすることを検討してください。

MFA技術は、企業セキュリティの重要インフラの一部であるべきです。最近相次いでいる攻撃事例に加え、政府・民間双方の専門家からの呼びかけも踏まえれば、より賢明な実装に向けたさらなる後押しとなるはずです。

翻訳元: https://www.csoonline.com/article/570795/how-to-hack-2fa.html

本記事は csoonline.com の記事を翻訳・要約したものです。