攻撃者は2FAを迂回します。防御する方法は？
最新NSAダンプ に詳しく記載されているのは、ロシアの諜報機関が2FAを回避するために使用しているとされる方法です（この場合、2番目の要素がコードであるGoogle 2FAです）。
これはかなり明白なスキームであり、定期的に使用する必要があると確信しています。次のように機能するようです：
- URLは、スピアフィッシングを介してターゲットに送信されます。URLは、攻撃者が制御するフィッシングWebサイトを指し、Google Gmailに類似しています。
- ユーザーは認証情報を偽のGmailに送信します。
- （仮定）攻撃者は正当なGmailに認証情報を入力し、2番目の要素が必要かどうかを確認します。
- ターゲットは正当な第2要素を受け取ります。
- Phony Gmailサイトは、第2要素のターゲットを要求します。ターゲットは2番目の要素を送信します。
- 攻撃者は正当なサイトに2番目の要素を入力し、認証に成功します。
この攻撃から身を守る唯一の方法は、偽のサイトを詐欺として発見するか、FWや脅威情報などを介してフィッシングサイトをブロックすることです。
そのような計画を防ぐための他の実用的な方法はありますか？
すべての2要素認証方式が同じというわけではありません。テキストメッセージの送信など、2FAの一部の形式は、この攻撃に対して安全ではありません。 FIDO U2Fなどの他の形式の2FAは、この攻撃に対して安全です。この種の攻撃を念頭に置いて、意図的に設計されています。
FIDO U2Fは、中間者攻撃に対して2つの防御策を提供します。
Registration-ユーザーはU2Fデバイスを
google.comなどの特定のWebサイト（ "Origin"）に登録します。次に、U2Fデバイスは登録されたオリジンからの認証要求にのみ応答します。ユーザーがgoog1e.com（フィッシングサイト）にアクセスするようにだまされた場合、U2Fは以前に登録されていないサイトからのアクセスであることがわかるため、リクエストに応答しません。チャネルIDとオリジンバインディング-U2FはTLSチャネルID拡張を使用して中間者攻撃を防止し、U2Fデバイスがそれを確認できるようにしますユーザーがWebブラウザーでアクセスしているのと同じWebサイトにアクセスしています。また、U2Fデバイスは、どのOriginが通信していると考えているかを認識しており、署名された認証応答には、Originが通信していると考えている署名が含まれています。これはサーバーによってチェックされます。したがって、ユーザーが
goog1e.comを使用していて、そのページがU2F認証を要求している場合、U2Fデバイスからの応答は、その応答がgoog1e.comとの通信にのみ有効であることを示します-攻撃者がリレーしようとした場合google.comへのこの応答では、署名されたデータに間違ったドメイン名が存在するため、Googleは何かがおかしいことに気付くことができます。
これらの機能はどちらも、U2F 2要素認証デバイスとユーザーのブラウザー間の統合を伴います。この統合により、デバイスはブラウザーがアクセスしているドメイン名（Origin）を知ることができ、デバイスはフィッシング攻撃や中間者攻撃を検出または防止できます。
このメカニズムについてさらに読む：
帯域外2FAが正しいアプローチです。これは、クライアント証明書やFIDO U2Fなど、フィッシングできない2番目の要素があることを意味します。コードまたはSMSベースの2FAモデルは、インバンドであり、クレデンシャルと同じようにフィッシングできるため、最も弱い2FAオプションです。
ほぼ誰でも使用できるので便利ですが、何よりも優れていますが、プロバイダーが提供するセキュリティを、帯域外2FAが提供するセキュリティと混同しないでください。
これは、（ブラウザの）パスワードマネージャが役立つ状況の1つです。
パスワードマネージャーはパスワードを実際のURLで保存するため、攻撃者のページに自動入力されず、提案もされません。 2ステップのパスワードトークンを漏らさないだけでなく、パスワードの漏えいも防ぎます。
この保護は、ユーザーが自分のパスワードを知らない場合でも効果があり、パスワードを入力するためにパスワードマネージャーを介してのみ対話できます。
要点は、攻撃者があなたをだましてすべての資格情報を提供することができる場合、ゲームオーバーです。関係する要素の数は関係ありません。攻撃者が制限時間内にトークンを取得して再利用することを困難にするトークンの非常に短いタイムアウトなど、公開を制限するのに役立つものがあります。ただし、バランスが適切になるのが難しい場合があるため、タイムアウトの保護は限定的です。特に、「普及」しており、SMSのような配信の遅延を許可する必要がある場合）ユーザビリティの問題（SMSの配信が遅くなり、トークンを受け取ってブラウザに入力する前にトークンがタイムアウトする場合がある国際ベースのサービスを使用してこれを確認しました）。
2FAと呼ばれるシステムの多くは、実際には2FAではありません-実際には2SA（2段階認証）です。実際の2FAでは、要素はあなたが知っているもの（パスワード）とあなたが持っているもの（トークン、多くの場合ハードウェアベース）です。 SMSを介して送信されるコードを含むスキームは2FAではなく、2SAです-実際にはトークンを持っていません-それはあなたに送信されます。それはあなたに送信されるものなので、携帯電話番号のリダイレクトなど、新しい脅威ベクトルがあります。これが、NISTが信頼できる認証プロセスとしてSMSベースのトークンを非推奨にした理由の1つです。
OP固有の質問に関して、唯一の信頼できる保護は、フィッシングページを検出できることです。 Googleはこれを試すためのchrome拡張機能をリリースしました。この拡張機能は、GoogleページではないページにGoogle認証情報を提供していることを検出すると警告します。
大きな問題は、ページが正当であることを保証するために、URLで「緑の錠前」を探すように何年も人々に教えてきたことです。残念ながら、Lets Encryptなどの取り組みにより、ドメイン検証済みの証明書を簡単に取得できるようになったため、これらのフィッシングページの多くに緑色の鍵が付いています。これは、問題がLets Encryptによるものであると言っているのではありません。これは非常に優れた取り組みです。問題の原因の1つはPKIインフラストラクチャの弱点ですが、主にユーザーの認識と理解が原因です。一般に、人々はPKIを理解しておらず、証明書がサイトにとって正当であり、サイトが正当なサイトであることを確認する方法を理解していません。さらに悪いことに、あなたが理解していても、検証を実行するのにかかるステップ/時間は、多くの場合不便であるか、非常に難しいため、人々はそれを行いません。状況を合法的に見せるための方法を見つけた包丁の悪役によって状況はさらに悪化します。たとえば、最近のエクスプロイトは、ブラウザーがURLとUnicode文字を表示する方法の弱点を使用して、アドレスバーにレンダリングされるURLを生成する方法一見正しいように見えますが、URLの実際の文字はフィッシングサイトを示しています。ユーザーはアドレスバーを見て、緑色の南京錠が表示され、URLが正しく見えるように見えます（一致をより見栄えよくするために、脳が情報を埋めてくれます！）。そのページを正当なものとして受け入れます。文字間に余計な空白が入ったり、文字の形が少し変わって見えたりすることはありません。
では、これをどのように防ぐのでしょうか。残念ながら、「これを実行すれば安全です」という単一のものはありません。一部のパスワードマネージャーは、URLが正しい場合にのみ資格情報を提供し、電子メールメッセージでURLを使用しないでください。常に自分で入力するか、作成したブックマークを使用してください。ある時点でだまされて、発生時のダメージを制限するプラクティスを採用します。つまり、サイトごとに異なるパスワードを使用し、可能な場合はハードウェアベースの2FAを使用し、実際に「高価値」サイトの証明書の詳細ボタンをクリックして、それは、証明書が誰に登録されているかを示し、システムにすべてのアップデートがあること、最新のブラウザバージョンを使用していることなどを確認します。本質的に疑わしく、大きな脅威はソーシャルエンジニアリングであることを忘れないでください。あなたは恐怖、罪悪感、報酬または罰に基づいて行動を起こす。これらは非常に効果的な動機であり、脅威アクターはそれらに依存しています。フィッシングキャンペーンは実装がはるかに洗練されてきましたが、その中心は依然として感情的な操作に依存しています。これは、何か素晴らしいものを約束したり、何か恐ろしいものを脅かしたりするものです。
最後に、私がパスワードマネージャについて言及しているためにコメントしたくなったら、コメントしないでください。はい、パスワードマネージャーにはリスクがあり、はい、いくつかは他のものよりも悪いです。ただし、一般に、適切に使用された優れたパスワードマネージャーは、通常、現在のパスワード管理プロセスよりも平均的なユーザーを保護します。はい、パスワードマネージャーが危険にさらされると、すべてのパスワードが危険にさらされます。しかし、多くの人々はパスワード管理が難しすぎると感じ、とにかくすべてのサイトで同じ、しばしば弱いパスワードを使用しています。 1つのサイトが侵害されると、すべてのサイトが侵害されます。もちろん、テクノロジーを理解し、パスワードやハッシュなどを理解している場合は、より安全なソリューションを考え出すことができますが、パスワードマネージャーの対象ではありません。両親や祖父母がパスワード管理をどのように扱っているか、フィッシングサイトを見つけたり証明書を理解したりする方法について考え、次にcfileまたは同期を介してカスタムGPGベースのパスワード管理を簡単に処理できる方法について考えます。
編集：私の応答を再読するときに、実際の2FAがますます利用可能になることを十分に強調しましたが、安全性の低い2SAを現在サポートしているプロバイダーの多くはSMSコードもはるかにサポートしていますより安全な2FA。多くの場合、U2Fを使用します（他の返信で言及されています）。Yubicoまたはduo（およびその他）のハードウェア「キー」は安価で、セットアップ/使用が簡単です。私の唯一の推奨事項は、ハードウェアを使用する場合トークン/キールート。必ず2つのキーを取得し、両方を登録して、安全な場所に1つのキーを置きます。私は1つを携帯し、もう1つは自宅の金庫に保管します。紛失/破損からの回復キーは、忘れたパスワードから回復するほど簡単ではないので、そのような状況にできるだけ入り込まないようにする必要があります。
コメントで指摘されているように、これは良い方法ではありません。
テストを完全に逆にします。
この場合、ユーザーの携帯電話が「安全」であることを信頼しているので、これを使用してユーザーを認証します。ユーザーがWebサイトにログインしようとすると、このログインに同意するように電話で要求が出されます（プッシュ通知はアプリケーションに直接送信するのが理想的です。SMSや電子メールは簡単に侵害される可能性があるためです）。 「IP x.y.z/geolocation foobarからログインしているようです-続行しますか？」
また、電話ではなくコンピュータ上に存在する証明書を提供することもできます。このように、「攻撃者」は、ユーザーを間違ったサイトにリダイレクトすることを管理するだけでは、この情報にアクセスできません。
この攻撃はフィッシングとして知られています。エンドユーザーをだまして資格情報を自由に引き渡せる場合、世界中のすべてのセキュリティは役に立ちません。
フィッシングに対する緩和策には次のものがあります。
メールサーバーは、既知のフィッシングサイトへのリンクのメールをスクラブできます。
多くの場合、メールクライアントはリンクをデフォルトで無効にし、有効にすると警告を表示します。
ユーザーは、メールにあるリンクをクリックしないでください。多くの場合、アドレスを入力する方が安全です。
ユーザーは、どこからでもリンクを介して機密サイト（銀行サイトなど）にアクセスしないでください。ブックマークを使用するか、入力します。
一部の一般的な考えに反して、ユーザーshould機密サイトにはパスワードマネージャを使用します。パスワードマネージャでは、間違ったサイトにパスワードを入力できません。
他の回答への追加として、siteがuserユーザーは、パスワードマネージャーを使用していない場合や、細心の注意を払っていない場合でも、本物のページに認証情報を入力しているという強いシグナルを受け取る傾向があります。 URLに。これは通常、ユーザーが選択した セキュリティイメージ （オプションの大規模なセットから）とユーザーが設定したテキスト文字列で行われます。ユーザー名の入力後、パスワードの前に表示されます（2つのページに分割されます）。これは完全に万能ではありません（攻撃者が単純な一括リクエストによって画像/文字列を取得するのを防ぐ必要があります）が、フィッシングに対して動作するように設計されており、フィッシングを成功させるのが少し難しくなります。攻撃者がセキュリティ画像/文字列をフェッチしようとする場合、これらのリクエストはまた、本物のサービスプロバイダーに何かが間違っているというヒントを与え、それらのリクエストがどこから来ているかについての法医学情報を提供する可能性があります。
それが実際に機能するかどうかは別の問題であり、2007年の論文の証拠は、少なくともほとんどのユーザーにとって not を示唆しています。