Software applications that run in Microsoft Windows environments can inject code into a process that is not their own. Although this behavior is similar to that of malware, it is also a built-in mechanism for Microsoft Windows. This mechanism allows software developers to provide a richer computing experience for the user.
McAfee Enterprise has encountered numerous software applications with legitimate reasons to load DLLs into McAfee Enterprise processes. Although McAfee Enterprise tries to block those DLL load attempts, technical limitations allow those injections to sometimes succeed. An alternate response is then needed from McAfee Enterprise, to allow ENS to continue to operate normally. This situation led to the utility MfeSysPrep.exe. The MfeSysPrep.exe is available through Technical Support, and can be used as a DLL injector discovery tool. This utility is recommended for any environment that experiences symptoms caused by the presence of third-party DLLs in McAfee Enterprise processes. It also includes those third-party DLLs described in the Problem statements below.
Background:
McAfee Enterprise software considers third-party DLLs that have injected into McAfee Enterprise processes untrusted. In other words:
We did not write their code.
We do not know what their code does, or what it can do.
We do not know if it can ever be compromised and used maliciously.
What we do know is that any work done from the DLL functions of that third party appears to come from the injected McAfee Enterprise process. So, if it is malicious activity, it looks like the McAfee Enterprise software is performing malicious operations. Allowing third-party DLL injections into McAfee Enterprise processes is not acceptable. We have taken measures using our Access Protection (AP) technology, also known as Arbitrary Access Control, to secure against third-party DLL injections. We have also implemented a Validation and Trust Protection (VTP) framework. This framework secures against scenarios where an injection might have occurred.
The Validation and Trust Protection framework was introduced with VSE 8.7i. The Access Protection feature was introduced with VSE 8.0i. The underlying technology was updated in VSE 8.8 Patch 5 (or Patch 4 + Hotfix 929019). The new technology is called Arbitrary Access Control (AAC). Other McAfee Enterprise products have made similar technological transitions to adopt this shared technology, needed for securing the products against malware and untrusted entities.
How we use Validation and Trust Protection:
The McAfee Enterprise Validation and Trust Protection service, MFEVTPS.exe, is a critical service that performs inspections of DLLs and running processes, including McAfee Enterprise processes, that interact with McAfee Enterprise code, to verify that those objects are trusted. The service depends on the Microsoft Cryptographic service (CryptSvc), Trust-related APIs, and the health of the Certificate store and Catalog files. If those dependencies are in a bad state, our service might not function properly.
A validation check occurs when McAfee Enterprise code needs to make sure that the acting process or object is trusted, or both.
When McAfee Enterprise processes initialize, the VTP service is used to validate that we are loading trusted code. We use AP/AAC to make sure that we load only trusted DLLs.
As stated above, only McAfee Enterprise code and Microsoft code are implicitly trusted.
Caching
The MFEVTPS.exe caches the results of a validation check to improve the performance of future validation checks.
The cache is always examined first when performing a validation check.
If a validation check returned "untrusted," that object is cached as untrusted. If an object was cached as untrusted incorrectly, only a cache reset can correct it.
The cache is reset only when booting to Safe Mode, but not Safe Mode with Networking, or by running the command VTPInfo.exe /ResetVTPCache. McAfee Enterprise can also reset the cache via the DAT, when needed. Immediately following the cache reset, a user might experience a brief period of slow performance.
Trust Failures
A trust failure sees a validation check that results in "untrusted" when the expected result was "trusted."
Examples:
A third party injected a McAfee Enterprise process. We do not trust the third party, so the process fails a validation check.
A Microsoft catalog signed file has invalid signing information. So, it can't be verified and a McAfee Enterprise process fails to load it.
A valid DLL file was cached as "untrusted" incorrectly, and subsequent attempts to load it are denied.
All these examples can cause the affected McAfee Enterprise process to fail, such as not loading properly, or not performing its expected duties properly. These failures occur because of our own security mechanism (AAC), denying access to untrusted code.
How we use Access Protection or Arbitrary Access Control:
Arbitrary Access Control replaced Access Protection. This technology operates from the Windows kernel. It can block access to objects, such as network, file, registry, and process objects. The feature has a set of rules to determine what to block and what to allow. Rules describe "bad" or "unsafe" behaviors that must be blocked or denied. Many of the rules are under your control, exposed in the User Interface or ePolicy Orchestrator (ePO) policies. Some rules that are not exposed yet are still in effect, we consider those rules critical to the operational health of the product. Rules that we expose for you can be:
Enabled or disabled.
Set to report only.
Modified to add other processes to protect or protect against, or to exclude so we no longer block a certain process from violating the rule.
You can create your own behavior-blocking rules, making this feature one of the most powerful tools at your disposal, to secure your environment.
To summarize how AAC works, it sees an operation that is trying to be carried out, steps in, and asks the following:
What is the process name?
What object is the process accessing?
What is the process trying to do to that object?
Is this operation allowed, Yes or No?
An answer of "No" means that we block it. If "Report" is enabled, we log it and send an event to the ePO server. An answer of "Yes" means that the action is permitted.
Our private rules include more criteria, such as:
Who wrote this code? Getting this information involves looking at the digital signature.
Do we trust the digital certificate of that vendor? We trust only McAfee Enterprise and Microsoft by default.
The added criteria provides more security. Conversely, as explained above, if a validation check fails or yields an "untrusted" result, our own protections might block McAfee Enterprise processes from accessing objects. As indicated in the Background statement above, that outcome is expected.
Problème
A third-party process is being blocked from accessing McAfee Enterprise-protected files or processes. The third-party process receives error code 5, which means ACCESS_DENIED. This behavior is expected and is not a problem with the McAfee Enterprise software.
A third-party process that loads McAfee Enterprise DLLs is blocked from accessing other McAfee Enterprise processes, files, or folders. For example, Microsoft Outlook, which loads the ENS Exploit Prevention user-mode hooking DLLs, is blocked when trying to access other McAfee Enterprise processes.
Problème
A McAfee Enterprise process fails to start properly. For example, you are unable to start the ENS console despite installation logs indicating success.
A McAfee Enterprise process is running, but only partially operational. For example, ENS loads successfully, but indicates that other services are not running properly, yet the applicable service is running.
An installation of a McAfee Enterprise product fails, and tries to roll back, which might also fail, leaving remnants of a failed installation attempt.
A McAfee Enterprise process is blocked from accessing other files or folders belonging to a different McAfee Enterprise product. For example, McScript_InUse.exe which belongs to the McAfee Agent, is blocked from accessing ENS folders.
Cause
At a high level, the cause is as follows:
Processes load DLLs, which contain code that is executed. All this work is done by the process using threads. A third party DLL is one that is not built via a vendor, which in this case is McAfee Enterprise, or Microsoft. When a McAfee Enterprise process loads a third-party DLL, that process has been "injected" by that third-party DLL, which means it now contains third-party functions, and can execute that third party's code. The result is that the McAfee Enterprise process can now perform operations that it was never intended to do. There is also no awareness of what those actions might be because it is not McAfee Enterprise code. But, the third-party code is active and resides within the McAfee Enterprise process.
NOTE:Many third-party application vendors write legitimate software that applies DLL injection as a means to facilitate their product function. Many examples exist, but these names are of some vendors whose applications are commonly encountered in the corporate space: Citrix, Avecto, Lumension, Beyond Trust, and Nvidia.
Solution
ENS has a process named MFECanary.exe that runs as a child process to MFEEsp.exe, and captures digital certificate details for any DLL that attempts to inject into it. The information is sent to ePO via an agent event, which is processed at the ePO server. It is then populated to the Endpoint Security Common policy.
When you see that certificates are populated in the Endpoint Security Common policy, it is an indication that untrusted third-party software exists in the environment. This software is actively trying to load DLLs into McAfee Enterprise processes. If they succeed, their presence inside McAfee Enterprise processes leads to the Problem statements described above.
From the Endpoint Security Common policy, a checkbox allows the administrator to control whether client systems trust or do not trust the third-party certificate. The same policy enables you to manually add certificates to be trusted, using the exported certificate (.cer) of the injecting DLL.
For systems with VSE, no automated method exists to trust an injecting DLL. But, starting with the release of VSE 8.8 Patch 9, the Access Protection policy for VSE contains a Global Exclusions for Self-Protection tab. In this tab, you can exclude McAfee Enterprise processes that are impacted via a third-party DLL injection. To have more control over applications that inject into McAfee Enterprise processes, customers are urged to migrate to ENS.
Solution
Technical Support assistance:
Technical Support can also help in identifying the third party and later trusting a third-party digital certificate of signed third-party DLLs injecting into McAfee Enterprise processes. This support requires that you open a Service Request. To expedite processing, the steps to achieve these tasks are provided in this article.
Contents
Click to expand the section you want to view:
There is a utility available from Technical Support named MfeSysPrep.exe. You can run MfeSysPrep.exe standalone on any target system for DLL injector discovery, distributed through third-party tools, or deployed via ePO. The tool writes a log file locally, and sends ePO events for identified untrusted DLLs that could impact ENS functions.
For each identified injector and corresponding digital certificate, if McAfee Enterprise has deemed that specific certificate trustworthy, the tool automatically updates ENS to trust the certificate. If the tool does not discover any outstanding untrusted DLLs, no further action is needed. See the Related Information section of this article for implications of trusting a third-party certificate.
For each untrusted and signed DLL that was identified, the certificate information is captured in the log and provided to ePO in an event. The event ID is 1092 or 1095. For each untrusted and unsigned DLL that was identified, an SHA-1 and SHA-2 hash is recorded for that DLL in the log and provided to ePO in an event. Again, the event ID is 1092 or 1095.
Event ID 1092 indicates that an injector was found, and we could not trust it.
Event ID 1095 indicates that an injector was found, and we trusted it automatically.
This identification is perhaps the most hard undertaking of the whole process. The reason is because the method to collect this information depends on whether you are experiencing symptoms that affect product behavior. See the sections below on collecting data when there are "No adverse symptoms" and when there are "Adverse symptoms".
No adverse symptoms:
Use Process Explorer, available from Microsoft.
Run the tool as an Administrator.
Select the McAfee Enterprise process that has the third party DLL inside it.
Use the DLL view, or press CTRL+D, and identify the third-party DLL, noting its location on disk. If there are multiple locations, note them all.
Use Windows Explorer to locate that DLL on disk, and access its Properties.
See Obtaining the .cer File below.
Adverse symptoms:
When the adverse symptoms occur during a Windows session, there are two data points to collect. These data points must ideally be collected in parallel, that is, run both tools at the same time and capture the issue once.
Collect Process Monitor data:
Use Process Monitor, available from Microsoft.
Run the tool as an Administrator.
Start the McAfee Enterprise process that is behaving unexpectedly.
After it has reproduced the anomalous behavior, save the Procmon capture.
IMPORTANT: Save All Events and use the Native PML format.
Provide this information to Technical Support to help with identifying the third-party DLL being loaded via the McAfee Enterprise process.
After it has reproduced the anomalous behavior, run AMTrace again, now providing the option to stop.
Provide the created log to Technical Support. The log file helps with identifying the untrusted DLL.
* To reset the VTP cache:
From an Administrator command prompt, navigate to \Program Files\Common Files\McAfee\SystemCore.
Run the VTPInfo.exe utility with the parameter /resetvtpcache:
VTPInfo.exe /ResetVTPCache
Obtain the .cer file:
This procedure is needed only if you performed Option 2 to identify the third-party untrusted DLLs. Obtaining the .cer file is not needed if you used Option 1.
To access the properties of the EXE or DLL file, right-click and select Properties.
Click the Digital Certificates tab.
NOTE: If this tab is missing, the file is not digitally signed and there is no option for us to trust this vendor's code. You must contact that vendor and request they provide signed code.
Select a certificate from the Signature list that you want to trust.
Click Details.
Click View Certificate.
Click the Details tab.
Click Copy to File.
In the Certificate Export wizard, click Next.
Click Next again to accept creating a .cer file.
Specify a file name and location. For example, C:\Temp\My3rdParty.cer.
Click Next and Finish.
If you used Option 1 above, and no further untrusted DLLs were found, no further action is needed.
For untrusted and signed DLLs, we expect that the digital certificate for that DLL appears in the Endpoint Security Common policy. In this case, see Solution 1.
Use the Endpoint Security Common Options policy to manually trust the certificate if
The certificate has not appeared in that policy.
Or
You want to move the process along in a more predictable manner, after you have obtained the (.cer) file.
IMPORTANT:Before doing so, see the Related Information section of this article for implications of trusting a third-party certificate.
For untrusted and unsigned DLLs, we expect the vendor of that software to provide you with digitally signed code, as it is an industry standard for identifying released software. In cases where vendors can't or do not comply, Technical Support can help you. You need to provide any unsigned DLLs that MfeSysPrep.exe identified as injectors, and the MfeSysPrep log that shows the injection. Using this information, McAfee Enterprise will consider adding the unsigned DLL within the MfeSysPrep utility, to help with such issues as failing ENS installations due to the presence of the third-party application. It does not include applications such as antivirus software that serves the same function as ENS.
Is this application internal or publicly available?
Brief description of the software's function and purpose including the DLL submitted
Informations connexes
Security implications of trusting a third-party digital certificate:
There are security implications that you are accepting by trusting a third-party certificate:
You accept that any code signed by the third-party certificate will be trusted to interact with McAfee Enterprise processes, files, registry, and all other McAfee Enterprise-protected objects.
You accept that file activity generated by processes signed with the third-party certificate might not be scanned.
You understand that any product or code releases from the same vendor, if using the same digital certificate, automatically inherit the same allowances.
You understand that any product or code releases from the same vendor, using a different digital certificate, which also has to be trusted to achieve the same results.
