2 要素認証のベスト プラクティス: 99 の問題がありますが、2 要素は 1 つではありません

2 要素認証は、リモート アクセスを保護するためのベスト プラクティスですが、やる気のあるレッド チームにとっては聖杯でもあります。複数の資格情報によって認証された正当なユーザーを装って隠れることは、環境内で検出されないようにする最善の方法の 1 つです。多くの企業は、自社の 2 要素ソリューションを間違いのないものと見なしており、攻撃者がそれらをバイパスまたはバックドアしようとする試みから保護するための予防措置を講じていません。

このブログで取り上げる手法は、レッド チームの観点から 2 要素認証を処理する単純な方法から高度な方法まで多岐にわたり、セキュリティ チームが対処すべき潜在的な可視性のギャップについての洞察を提供します。内部環境にアクセスせずに 2 要素認証をリモートでバイパスする手法と、内部環境から盗んだ情報を使用して 2 要素認証のリモート アクセス デバイスにアクセスする方法について説明します。

1) KISS – シンプルに、バカに

リモート アクセス ソリューションを侵害することは、レッド チームの最大の目標です。これは、簡単にアクセスでき、捕まるリスクが低いためです。正規のリモート アクセス ソリューションを使用しているレッド チームは、適切に認証されたセッションを装って、コマンド、コントロール、エクスプロイト、および情報漏えいのアクティビティを実行できます。さらに、レッドチームのシステムは、他の企業システムと同じセキュリティ制限または制御の対象ではありません。これは、チームが活動を妨害するウイルス対策、アプリケーションのホワイトリスト、およびその他の侵入検知ソフトウェアに対処する必要がないことを意味します。 2 要素認証は明らかに、これらのリモート アクセス ソリューションを危険にさらすことを困難にし、レッド チームに 2 要素保護を覆すように要求します。

このような困難な状況では、オッカムのカミソリ アプローチを採用し、必要な資格情報を取得するための最も簡単な方法を使用するのが最善です。完璧なトラップは、たまたま最も簡単に設定できます。

図 1 には、2 つの異なる VPN ログイン ページがあります。 1 つは企業の正規のサイトで、もう 1 つは狡猾な赤いチームが運営する偽サイトです。違いがわかりますか？

いいえ？ユーザーもできません。 Social-Engineer Toolkit (SET) などのツールを使用すると、HTML のローカル リソースの場所 (「/home/image/logo.png」) を外部参照 (「mycompany.com/home/」) に変更することで、誰でも効果的に外部ページを複製できます。 image/logo.png」）。説得力のあるフィッシング シナリオにより、被害者をビジュアル クローン VPN 認証ページに誘導し、独自の接続を確立するために必要なすべての情報 (ユーザー名、パスワード、さらにはトークン コード) を取得できます!

赤いチームが十分に迅速に行動できる場合、彼らは偽の VPN ページに送信された資格情報を取得し、それらを使用して実際の VPN への認証を行うことができます.図 2 に示すように、これは、ログインの送信を PHP スクリプトにリダイレクトすることで実現できます。PHP スクリプトは、ユーザー名、パスワード、およびその他のメタデータ (IP アドレス、HTTP ユーザー エージェント、送信時刻) をレッド チームがログ ファイルに書き込みます。監視し、ユーザーが 2 要素認証情報を提供するのを待つことができます。

レッド チームが VPN に対して認証されると、セキュリティ チームがフィッシングを検出して対応する前に、権限の昇格を試みて機密データにアクセスできます。スキャンによる内部ネットワークの偵察、被害者のユーザーがアクセスできるアプリケーションやシステムの特定、さらには LLMNR/NBT-NS スプーフィングでさえ、VPN セッションを環境の完全な侵害に変える潜在的な手段を提供します。

Mandiant Red Team は、SpiderLabs の Responder を LLMNR/NBT-NS スプーフィング ツールとして活用しています。 Responder は強力な Python ユーティリティであり、LLMNR/NBT-NS 要求に対して偽の応答を送信して、システムやサービスをだましてパスワード ハッシュや、場合によってはプレーンテキストの資格情報を提供させます。 VPN サブネット上で Responder を数分間実行すると (図 3 を参照)、多数のドメイン アカウントとパスワード ハッシュが得られます。一般的なパスワードと、複雑さの要件が低いパスワードは、ハッシュを数秒で解読できるため、レッド チームはラテラル ムーブメントと権限エスカレーションを続行するために必要なプレーンテキストの資格情報を得ることができます。

この攻撃を防ぐ方法

1. VPN ソリューションが、ユーザーごとに 1 つの認証済みセッションを強制することを確認してください。 1 つのユーザー アカウントに対して複数の同時セッション (ソース IP アドレスが異なる) を許可する正当な理由は限られています。
2. VPN 認証ログの定期的な監査を実施して、TOR 出口ノードから発生したログイン イベントにフラグを立てるなど、異常なログイン アクティビティを特定します。
3. フィッシング インシデントに対応するときは、資格情報が失われる可能性があることを真剣に受け止めてください。資格情報が失われた疑いがある場合は、影響を受けるすべての資格情報をリセットし、悪意のあるアクティビティの証拠がないかアクセス ログを確認してください。

2) 羊の皮の XSS

VPN ログイン ページは、そのイメージがユーザーの親しみやすさと安心感を呼び起こすため、貴重なターゲットです。図 1 に示すような Web ページを使用して VPN への認証を毎日行っている場合、トラフィックや Web サイトのコードを調べて、資格情報が正しい場所に移動していることを確認していない可能性があります。恐ろしいことに、実際の攻撃者はすでにこの暗黙の信頼を利用し始めており、企業の VPN ログイン ページで JavaScript ベースのクレデンシャル ハーベスターを利用していることが発見されています。

この攻撃がどのように機能するかについて説明しましょう。まず、レッド チームは、CVE-2014-3393 で説明されている脆弱性などの脆弱性を悪用して、認証ページ (または認証ページによって読み込まれるページ) にコードを書き込みます。次に、レッド チームは認証ページにコードを追加して、管理しているシステムから悪意のある JavaScript を実行し、疑いを持たないユーザーがページを読み込んで認証するのを待ちます。このようなコードの例を図 4 に示します。

被害者のユーザーは何も違いに気づきません。この小さなコードは、「https://www.evil.com」からファイル「stealcreds.js」をロードし、そのコードを正当なユーザーの Web セッションで実行します (つまり、JavaScript コードはユーザーのブラウザーのコンテキストで実行されます)。外部リソースを使用することで、フロント ページでのコードの導入を最小限に抑え、ユーザーのブラウザーがリソースを要求するたびにペイロードを動的に更新できるようにします。図 5 は、ユーザーの資格情報を侵害するために使用するコードのスニペットを示しています。

内部フレーム挿入と「https://www.evil.com/pwnd.php」へのポストバック セットアップを使用して、レッド チームは通常の VPN ログイン ページを不正に操作して、ユーザーがセッションに入るたびにユーザー資格情報を POST します。 「stealcreds.js」リソースがロードされます。レッド チームは、VPN ソリューション自体を攻撃することで、承認されたリモート アクセス ソリューションを介して環境にリモート接続している正当なユーザーになりすますことができます。

この攻撃を防ぐ方法

2 要素ソリューションへのアクセスを監視し、ユーザーに提供されるコードを定期的に検査して、改ざんが発生していないことを確認します。これを実現する 2 つの方法は、ネットワーク デバイスによって提供されるファイルを監視するファイル整合性監視ソリューションを使用することと、公共インフラストラクチャの定期的なスキャンまたは評価を実行して変更を特定することです。

3) 1.5要素認証

もう 1 つの一般的な VPN 構成は、企業 VPN に接続するための要件としての「ホスト チェック」プロセスです。通常、このプロセスでは、ホストのドメインと、ウイルス対策シグネチャが更新されているかどうかなど、いくつかの基本的な構成統計が検証されます。一部の企業は、この「ホスト チェック」プロセスを疑似 2 番目の要素 (1.5 要素のタイトル) と見なしています。ホスト インスペクションの残念な問題は、信頼できるホストに依存していることです。

「ホスト チェック」プロセスに加えて、単一要素のパスワード認証のみを必要とする VPN デバイスを使用するクライアントに対してレッド チーム評価を実施しました。 「ホスト チェック」プロセスによって検査されたすべての情報は Web リクエストで提供され、Base64 エンコーディングで最小限の難読化が行われました。図 6 は、レジストリ パスをチェックし、「正解」を示した、予想されるデータの種類の例を示しています。

「ホスト チェック」プロセスは、信頼できない可能性のあるソースからの信頼できる回答に依存するだけでなく、リクエスト内で検査しているものも提供します。少なくとも、レッド チームは、チェック中に調査された機能の変更を試みることができます。さらに悪いことに、「ホスト チェック」への応答は、検査された各要素が「正しい」かどうかを含む単純な POST でした。これは、Fiddler や Burp などの Web プロキシを使用するレッド チームにとってもう 1 つの簡単なターゲットです。

図 7 に示すように、Fiddler と Python の組み合わせを使用して POST 要求を変更し、有効なポリシー検査レポートを生成して、「ホスト チェック」をだまして承認させました。

1.5 要素認証のもう 1 つの一般的な形式は、ユーザー名とパスワードをコンピューター証明書と組み合わせて利用することです。一部の企業は、リモート アクセスを許可する前に、ユーザーとデバイスの両方を認証することを選択しています。これは良いアプローチですが、ローカルにインストールされた証明書と組み合わせて単一要素の資格情報認証を要求することはできません。攻撃者がエンド ユーザー システムへのアクセスを取得し、ローカルにインストールされたコンピューター証明書をエクスポートし、その証明書を自分の仮想システムにインストールするのは簡単なことです。

この攻撃を防ぐ方法

リモート アクセスに単一要素認証または 1.5 要素認証を使用しないでください。強力な多要素認証 (あなたが知っているもの、あなたが持っているもの、またはあなた自身のもの) のみを実装する必要があります。資格情報ベースの認証と組み合わせてコンピューター証明書を利用する場合は、クライアント側の証明書と組み合わせて多要素資格情報ベースの認証を使用するようにしてください。

4) メールは敵

多くの場合、デジタル トークンは、適切に機能するために、各ユーザーのトークンに固有の同期コードを必要とします。同期コードとアルゴリズムは、ユーザーに表示されるトークンが認証サーバーが期待するトークンと一致することを保証するものです。多くの企業は、VPN アクセスの要求が承認されたときにユーザーに電子メールで通知を送信する、IT にやさしい単純なプロセスを使用しています。これらの電子メールには、多くの場合、「シード」キーとインストール手順が含まれています。セキュリティ チームにとって残念なことに、ユーザーはこの電子メールを読み、削除するのを忘れてしまうことがよくあります。その結果、ユーザーの受信トレイに文字どおりのキーが残され、攻撃者が盗む準備ができています。

Mandiant Red Team の方法論のステップの 1 つは、電子メールの受信トレイ (ディスク上の .PST および .OST ファイルを含む) を検索して、これらのタイプの機密で有用なファイルを探すことです。ほとんどの場合、単純な PowerShell スクリプトを使用して、ユーザーのメールボックスと関連ファイルを検索し、RSA ソフトトークン .sdtid ファイルの証拠を探します。

.sdtid ファイルは、基本的にパスワードで保護された信頼性の証明書であり、ローカル ホストでデジタル (「ソフト」) トークンをセットアップするために使用できます。 .sdtid ファイルとパスワードの両方を組み合わせて (多くの場合、IT ヘルプ デスクから送信された同じ電子メールに含まれているか、ローカルのテキスト ファイルに保存されているか、ローカルのパスワード マネージャーに保存されています)、赤いチームはユーザーのソフトを複製できます。トークンを取得し、単純なキーロガーを使用してユーザーの PIN を識別します。その後、レッド チームは、正当なユーザーになりすまして、昼夜を問わずいつでもネットワークへの 2 要素認証アクセスを取得します。

この攻撃を防ぐ方法

電子メールのソフト証明書などの無害なものは、攻撃者が会社にアクセスするのに役立ちます. 「ソフト」トークンは、多くの場合、物理デバイスよりも侵害のターゲットになりやすいため、2 要素で何をどのように保護するかを決定するときは、そのことを念頭に置いてください。機密情報を使い終わったら安全に削除するようにユーザーをトレーニングします。 .sdtid ファイルと同じ電子メールにパスワードを含めないよう、または電子メールに .sdtid を含めないように、IT スタッフをトレーニングします。たとえば、.sdtid ファイルをダウンロードするには、ユーザーが Web サイトに対して認証を受ける必要があります。

5) 玄関マットの下に保管庫の鍵を置いておく

「パスワード保管庫」は、最も頑固なレッドチームのベテランでさえうめき声を引き起こすフレーズです.適切に構成されたパスワード ボールトは、環境内での資格情報の使用を制限および監視するための強力なツールです。これにより、Mimikatz や Windows Credentials Editor (WCE) などの従来のツールにパスワードがさらされることが少なくなります。結局のところ、ボールトにチェックインおよびチェックアウトするたびにすべての管理者資格情報が変更されると、パスワードをダンプするのは面倒な作業になります。

そのパスワード ボールトの前に、物理トークンを使用して多要素対応の RADIUS 認証サーバーを追加すると、赤いチームにとって真の課題が作成されます。レッド チームが一時的に有効なパスワードを取得するには、ユーザー パスワード、PIN、および物理的なトークン コードを一度に再現する必要があります。バックドアとキーロガーを介したローカル アクセスがあっても、レッド チームは、トークンが既に使用されているため、RADIUS サーバーがアクセスをシャットダウンする前にそのトークン コードを入力することができない可能性があります。

ただし、レッド チームは、現実的に実装できる最高レベルのパスワード セキュリティを回避することをあきらめるのではなく、セキュリティの基本ルールに立ち返ることができます。常にプロセスに関与する人々。ここから、セキュリティで保護されていない Windows ファイル共有の調査を開始します。

セキュリティで保護されていない Windows ファイル共有は、何年にもわたってレッド チームに役立ってきました。ほとんどの場合、セキュリティで保護されていないファイル共有をくまなく調べて、権限昇格や機密データの盗難に必要なデータの少なくとも一部を取得します。セキュリティ チームにとって残念なことに、Windows では、ドメイン内のファイルやフォルダーを非常に簡単に共有でき、ユーザーやレッド チームがそれらの共有を発見して貴重な情報を得るためにスクレイピングすることが非常に簡単になります。 PowerView の「Invoke-ShareFinder」PowerShell スクリプトは、関心のある株式の検索においてかなりのスケーラビリティを提供する優れたユーティリティです。このツールは、最近見つけた「セキュリティ」という名前の興味深い共有など、貴重な情報を発見するのに役立ちます。予想どおり、この共有は、有効なドメイン資格情報を持つすべてのユーザーが読み取ることができました。

場合によっては、図 8 に示すようなドキュメントを見ていることに気付くかもしれません。

これらのタイプのドキュメントで発見されたパスワードにより、レッド チームは認証サーバーに直接アクセスできるようになります。つまり、レッド チームは認証プロセスの動作を制御できます。 2 要素認証ソリューションの管理に使用するアカウントのパスワードを使用して、レッド チームは既存のアカウントのパスワード ボールトへのアクセスを少なくとも一時的に許可することができます。次のセクションで示すように、このレベルのアクセスでは、環境内の重要なインフラストラクチャに対するレッド チームの制御をさらに強化して、アクセスを維持し、検出を回避するための新しい手法が導入されます。

この攻撃を防ぐ方法

ローカル管理者のアクセス許可を制限することにより、ユーザーが任意の開いている Windows 共有を作成する能力を制限します。 「全員」（つまり、すべてのドメイン ユーザー）がアクセスできる場所に実際の情報を保存する理由はほとんどありません。 Active Directory グループを有利に使用して、機密情報が含まれる可能性のある厳しいアクセス制御を定義します。機密ファイルの暗号化を維持し、それらのアクセスと変更を監査するデータ損失防止 (DLP) ソリューションの実装を検討してください。 「Invoke-ShareFinder」スクリプトを使用して、1 日か 2 日で簡単な自己評価を行うこともできます。Web サーバー上の共有や企業データ共有に注意してください。

6) 二要素緊急事態

多くの 2 要素認証製品は、「緊急アクセス」コードと呼ばれるものを提供します。これは、ユーザーがトークンを紛失した後に VPN アクセスを許可するように設計された認証メカニズムであり、リモート アクセスが重要です。緊急アクセス トークン コード管理を示すスクリーンショットの例を図 9 に示します。

上のスクリーンショットが示すように、システムは認証の固定された「第 2 要素」を提供します。これは、環境への秘密のリモート アクセスを必要とするレッド チームに最適です。これらの緊急アクセス コードは、有効期限なしで構成できるため、後で環境に静かに戻ることができるため、特に危険です。

熱心なレッドチームへの注意: このアクセスを使用して独自のプロファイル/トークンを作成するのは魅力的ですが、通常、既存のプロファイルの変更よりもプロファイルの作成に関するアラートと監査が多くなります。

ベンダーのソリューションはそれぞれ異なるため、ターゲット環境に「緊急アクセス」を実装する適切な方法を決定するのは、読者の課題として残しておきます。既存のユーザーのアカウントを使用している場合、緊急アクセスだけでは不十分な場合があることに注意してください。緊急アクセス コードに加えて PIN が必要です。幸いなことに、ほとんどのベンダーは、図 10 に示すように、PIN をすばやくクリアして新しいものを設定するオプションを提供しています。

この攻撃を防ぐ方法

定期的な 2 要素アプリケーション監査を実装します。ログインするユーザー、ログイン日、ログイン元、および行われた変更 (特に変更に新しいユーザー プロファイルの作成が含まれる場合) を記録します。緊急のトークン アクセスを許可しないポリシーを適用します。 2 要素認証済みのすべてのアカウントを今すぐ簡単に監査することを強くお勧めします。

結論

ベテランのレッド チームが「安全な」セキュリティ コントロールをバイパスするために使用できる攻撃パスとベクトルは多数あります。 Mandiant のレッド チームは、最前線のインテリジェンスだけでなく、敵対者が自らの侵害で活用している最新のツール、戦術、および手順を利用しています。

残念ながら、多くの企業は、基盤となるテクノロジーを保護するために必要な手順を実行せずに、2 要素認証などのセキュリティ ソリューションを信頼しすぎています。この見落としにより、攻撃者とレッドチームは、2 要素認証の実装が適切に実装されている場合でも、その実装を妨害する可能性があります。

このブログの内容に関して、Andrew Burkhardt、Evan Peña、Justin Prosco の協力に感謝します。