Microsoft Windows 環境で実行されるソフトウェアアプリケーションは、自身ではないプロセスにコードを挿入できます。この動作はマルウェアの場合と似ていますが、Microsoft Windows のための組み込みのメカニズムでもあります。このメカニズムを使用すると、ソフトウェア開発者はより充実したコンピューティングエクスペリエンスをユーザーに提供できます。
弊社のプロセスに DLL を読み込むには、多くのソフトウェアアプリケーションが正当な理由で発生しています。これらの DLL 読み込み試行をブロックしようとしても、技術的な制限により、これらの挿入が成功する可能性があります。ENS が引き続き正常に動作するためには、代替応答が必要です。これにより、
MfeSysPrep.exe ユーティリティの問題が生じます。
MfeSysPrep.exeはテクニカルサポート経由で入手可能で、DLL インジェクター discovery ツールとして使用できます。このユーティリティは、サードパーティの DLL がプロセスに存在することによって発生した症状を経験する環境で推奨します。また、以下の
問題 の説明に記載されているサードパーティの dll も参照してください。
バックグラウンド:
弊社のソフトウェアは、サードパーティの Dll が信頼できないと判断しています。要約:
- コードを作成しませんでした。
- コードが何をしているか、または何ができるかはわかりません。
- 侵害され、不正に使用される可能性があるかどうかはわかりません。
このサードパーティの DLL 機能から実行された作業は、挿入したプロセスから取得したものであることがわかります。このため、悪意のあるアクティビティが存在する場合、ソフトウェアが不正な操作を実行するように見えます。サードパーティの DLL インジェクションを弊社のプロセスに許可することはできません。当社では、アクセス保護 (AP) 技術を使用して、サードパーティの DLL 挿入に対して安全を確保しています。また、検証および信頼保護 (VTP) フレームワークも実装しています。このフレームワークは、挿入が発生したシナリオに対して保護されます。
VTP の使用方法:
VTP サービス
MFEVTPS.exe は、DLL の検査と実行中のプロセス (弊社のプロセスを含む) を実行して、これらのオブジェクトが信頼できることを確認する重要なサービスです。このサービスは、Microsoft 暗号化サービス (
CryptSvc )、信用関連の API、証明書ストアとカタログファイルの状態によって異なります。これらの依存関係が不良な状態になっていると、サービスが正常に機能しない可能性があります。
ファイルの署名の詳細については、
デジタル署名の Microsoft 記事を参照してください。
- 検証チェックは、機能しているプロセスまたはオブジェクトが信用されていること、またはその両方であることをコードが確認する必要がある場合に発生します。
- プロセスの初期化時に、VTP サービスを使用して、信頼されたコードがロードされることを確認します。 AP or AAC を使用して、信頼できる DLL のみをロードするようにします。
上記のように、コードと Microsoft コードのみが暗黙的に信頼されています。
キャッシュ
- The MFEVTPS.exe 検証チェックの結果をキャッシュに格納し、将来の検証チェックのパフォーマンスを向上させます。
- 検証チェックを実行すると、キャッシュは常に最初に検査されます。
- 検証チェックで "不信用" が返されると、そのオブジェクトは信用できないものとしてキャッシュします。オブジェクトが信頼できない状態でキャッシュされている場合、キャッシュをリセットするだけで問題は解決します。
キャッシュはセーフモードで起動した場合にのみリセットされますが、ネットワークのセーフモードまたはコマンド
VTPInfo.exe /ResetVTPCache の実行によっては、この問題はありません。必要に応じて、DAT を使用してキャッシュをリセットすることもできます。キャッシュリセット後すぐに、パフォーマンスが低下する場合があります。
信頼失敗
信頼失敗とは、期待される結果が "信頼" であるにもかかわらず、"不信用"という結果になる検証チェックを意味します。
例:
- サードパーティが当社のプロセスを注入します。サードパーティを信頼していないため、プロセスが検証チェックに失敗しました。
- Microsoft カタログで署名されたファイルに無効な署名情報があります。そのため、これは検証できず、このプロセスの読み込みが失敗します。
- 有効なDLLファイルが不正に " 不信用 " としてキャッシュされ、その後の読み込み試行が拒否されます。
これらのすべての例は、正常に読み込まれない、または予期した動作が正しく実行されないなど、影響を受けるプロセスが失敗する可能性があります。これらのエラーは、信頼されていないコードへのアクセスを拒否する独自のセキュリティメカニズム (AAC) が原因で発生します。
AP または AAC の使用方法:
AAC が AP を置換しました。この技術は、Windows カーネルから動作します。ネットワーク、ファイル、レジストリ、プロセスオブジェクトなどのオブジェクトへのアクセスをブロックできます。この機能には、ブロックするものと許可するものを決定する一連のルールが含まれています。ルールは、ブロックまたは拒否する必要がある "の" または安全でない "動作を" します。ルールの多くは、ユーザーインターフェースまたは ePolicy Orchestrator (ePO) ポリシーで公開されたコントロールの下にあります。まだ公開されていないルールの一部はまだ有効になっています。製品の動作状態に重要なルールを検討しています。公開するルールは次のようにすることができます:
- 有効または無効
- レポートのみに設定します。
- 変更された他のプロセスが保護または保護対象外に追加されるか、除外されるため、特定のプロセスがルールに違反することはなくなります。
- 独自の動作ブロックルールを作成できます。この機能は、お客様の環境を保護するために、自由に利用できる最も強力なツールの1つです。
AAC の機能を簡単に説明するために、次の操作を実行しようとして、手順を確認します:
- プロセス名とは何ですか?
- プロセスはどのオブジェクトにアクセスしますか?
- このオブジェクトに対して実行しようとしているプロセスは何ですか?
- この操作は許可されていますか? はい/いいえ
"いいえ" はブロックすることを意味します。"レポート" が有効になっている場合、ログを記録して、ePO サーバーにイベントを送信します。"はい" は、アクションが許可されていることを意味します。
弊社のプライベートルールには、以下のような多くの条件が含まれています。
- このコードをだれが書いていますか? この情報を取得するには、デジタル署名を確認する必要があります。
- ベンダーのデジタル証明書を信用していますか? デフォルトでは、当社と Microsoft のみ信用しています。
追加された条件により、より多くのセキュリティが提供されます。逆に、上記のように、バリデーションチェックが失敗したり、 "不信用" の結果を出した場合、独自の保護機能により、プロセスがオブジェクトにアクセスするのをブロックすることがあります。上記の
バックグラウンド のステートメントで示されているように、この結果は期待できます。