Software applications that run in Microsoft Windows environments can inject code into a process that isn't their own. Although this behavior is similar to that of malware, it's also a built-in mechanism for Microsoft Windows. This mechanism allows software developers to provide a richer computing experience for the user.
We've encountered numerous software applications with legitimate reasons to load DLLs into our processes. Although we try to block these DLL load attempts, technical limitations allow these injections to sometimes succeed. An alternate response is then needed to allow ENS to continue to operate normally. This situation leads 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 our processes. It also includes the third-party DLLs described in the Problem statements below.
Background:
Our software considers third-party DLLs that have injected into our processes as untrusted. In other words:
We didn't write their code.
We don't know what their code does, or what it can do.
We don't 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 process. So, if there's malicious activity, it looks like our software performs malicious operations. Allowing third-party DLL injections into our processes isn't acceptable. We've taken measures using our Access Protection (AP) technology, also known as Arbitrary Access Control, to secure against third-party DLL injections. We've also implemented a Validation and Trust Protection (VTP) framework. This framework secures against scenarios where an injection might have occurred.
How we use VTP:
The VTP service, MFEVTPS.exe, is a critical service that performs inspections of DLLs and running processes, including our processes, that interact with our 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 our code needs to make sure that the acting process or object is trusted, or both.
When our processes initialize, the VTP service is used to validate that we're loading trusted code. We use AP or AAC to make sure that we load only trusted DLLs.
As stated above, only our 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 returns "untrusted," that object is cached as untrusted. If an object is 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. We can also reset the cache via the DAT, when needed. By 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 is "trusted."
Examples:
A third party injects our process. We don't 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 our process fails to load it.
A valid DLL file is cached as "untrusted" incorrectly, and subsequent attempts to load it are denied.
All these examples can cause the affected 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 AP or AAC:
AAC replaced AP. 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 aren't exposed yet are still in effect. We consider these 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's trying to be carried out, steps in, and asks the following:
What's the process name?
What object is the process accessing?
What's the process trying to do to that object?
Is this operation allowed, yes or no?
"No" means that we block it. If "Report" is enabled, we log it and send an event to the ePO server. "Yes" means that the action is permitted.
Our private rules include more criteria, such as the following:
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 ours 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 processes from accessing objects. As indicated in the Background statement above, this outcome is expected.
Problem
1
A third-party process is blocked from accessing our protected files or processes. The third-party process receives error code 5, which means ACCESS_DENIED. This behavior is expected and doesn't imply a problem with the software.
A third-party process that loads our DLLs is blocked from accessing other 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 processes.
Problem
2
A process fails to start properly. For example, you're unable to start the ENS console despite installation logs indicating success.
A process is running, but is only partially operational. For example, ENS loads successfully, but indicates that other services aren't running properly; yet the applicable service is running.
An installation of a product fails and tries to roll back, which might also fail, leaving remnants of a failed installation attempt.
A process is blocked from accessing other files or folders belonging to a different product. For example, McScript_InUse.exe, which belongs to TA, is blocked from accessing ENS folders.
Cause
At a high level, the cause is as follows.
Processes load DLLs, which contain code that's executed. All this work is done by the process using threads. A third-party DLL is one that isn't built via a vendor, which in this case, is us or Microsoft. When our process loads a third-party DLL, that process is "injected" by the third-party DLL, which implies that it now contains third-party functions, and can execute the third party's code. The result is that the process can now perform operations that it's never intended to do. There's also no awareness of what those actions might be because it isn't our code. But, the third-party code is active and resides within our 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
1
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 tries to inject into it. The information is sent to ePO via an agent event, which is processed at the ePO server. It's then populated to the ENS Common policy.
When you see that certificates are populated in the ENS Common policy, it's an indication that untrusted third-party software exists in the environment. This software is actively trying to load DLLs into our processes. If they succeed, their presence inside our processes leads to the Problem statements described above.
From the ENS Common policy, there's an option that allows the administrator to control whether client systems trust or don't 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 processes that are impacted via a third-party DLL injection. To have more control over applications that inject into our processes, customers are urged to migrate to ENS.
Solution
2
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 our 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's 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 can impact ENS functions.
For each identified injector and corresponding digital certificate, if we deem that specific certificate trustworthy, the tool automatically updates ENS to trust the certificate. If the tool doesn't 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's 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's 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 is found, and we can't trust it.
Event ID 1095 indicates that an injector is found, and we can trust it automatically.
This identification is perhaps the most difficult undertaking of the entire process. The reason is because the method to collect this information depends on whether you're experiencing symptoms that affect product behavior. See the sections below on collecting data when there are "No adverse symptoms" and "Adverse symptoms."
No adverse symptoms:
Use Process Explorer, available from Microsoft.
Run the tool as an Administrator.
Select the 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 the disk. If there are multiple locations, note them all.
Use Windows Explorer to locate that DLL on the disk, and access its Properties.
See Obtaining the .cer File below.
Adverse symptoms:
When 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 process that's 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 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 perform Option 2 to identify the third-party untrusted DLLs. Obtaining the .cer file isn't needed if you use 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 isn't digitally signed and there's no option for us to trust this vendor's code. You must contact the vendor and request that they provide a 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 use Option 1 above, and no further untrusted DLLs are found, no further action is needed.
For untrusted and signed DLLs, we expect that the digital certificate for that DLL appears in the ENS Common policy. In this case, see"Solution 1." Use the ENS Common Options policy to manually trust the certificate if either of the below holds true:
The certificate hasn't appeared in that policy.
You want to move the process along in a more predictable manner, after you've 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's an industry standard for identifying released software. In cases where vendors can't or don't comply, Technical Support can help you. You need to provide any unsigned DLLs that MfeSysPrep.exe identifies as injectors, and the MfeSysPrep log that shows the injection. Using this information, we consider adding the unsigned DLL within the MfeSysPrep utility, to help with issues such as failing ENS installations due to the presence of the third-party application. It doesn't 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
Related Information
Security implications of trusting a third-party digital certificate:
There are security implications that you accept by trusting a third-party certificate:
You accept that any code signed by the third-party certificate will be trusted to interact with our processes, files, registry, and all other 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, also need to be trusted to achieve the same results.
