[Edit: 7/29/15, fixed the URL to the Conficker document]
The purpose of this blog is to aid VirusScan Enterprise administrators in understanding and using the Access Protection feature, so that you can yield full benefit from this valuable feature and be confident in using it to protect your environment.
First, a scare-you-to-death warning :
It's not that bad, really. You'll see.
I do enjoy these little conversations we share. Fear not, dear reader, because although the warning is absolutely real it is only dangerous inasmuch as precautions are not taken, common sense replaced by reckless abandon - a bit like driving a car, you could die out there but you drive nonetheless and perhaps without thought of the ever-present dangers. So shall it be with Access Protection; become familiar with it, use it well and it shall protect you, and any dangers will be of little concern.
Second, know that anything you do with Access Protection - if harmful to the device - can be undone. It may be painful to undo, depending on the rule(s) being enforced - worst case scenario is you'll have to boot the device to Safe Mode to make changes - but the rule(s) can still be undone. Remember that.
VirusScan uses a link driver, mfehidk.sys, that tells the operating system it wants to be notified whenever certain activities occur - this covers a range of internal activities the operating system performs, including file actions and registry actions, and more. The link driver works in conjunction with content drivers who are in charge of further processing for the relevant activities they are interested in; for example, mfeavfk.sys processes any file/folder actions, and mfeapfk.sys processes any registry actions. For example, when mfehidk.sys receives information about a File activity, it passes the details off to mfeavfk.sys for further processing.
This is why whenever a BSOD occurs, we (and Microsoft) will almost always see McAfee code in the stack - specifically, mfehidk.sys is present. Why? Because it is interested in all kinds of actions being performed by the operating system, and so when an action leads to a BSOD it's very likely our driver is present, not because it's at fault (as some might have you believe) but simply because it was an interested party in that particular action which also happened to BSOD the system.
FYI: When our content drivers are present in a BSOD, the ones that do the additional processing (mfeavfk.sys, mfeapfk.sys etc.), that's a more telling piece of evidence that our software is involved in and possibly responsible for the BSOD.
The content drivers process the activity that is occurring, which will include references to the following types of objects and describe how those objects are being accessed...
|These are objects used by Microsoft Windows to describe, in a friendly way, subsystems that help make up the operating system. And VirusScan provides the feature "Access Protection" as a means to monitor these objects and intervene when a Rule (that we, or that you provide) is violated. Intervention means we can stop the attempted operation before it completes, or allow it and tell you about it, or both stop the operation and tell you about it. In the user interface this translates to the "Block" and "Report" settings, which you can specify for eachAccess Protection rule.|
If it isn't clear, you can enable the "Report" option only and use it as a way to create a rule (or enable an existing one) to see what would happen in your environment if you were to enable the "Block" option. When the rule is violated we will tell you about it but do not block, thus not interfere with the process who is violating the rule. With that information you'll gain an understanding of "Who is violating the rule" (there could be many different processes in your environment) and whether that is a behavior you wish to STOP, or whether some violators should be permitted a.k.a. excluded from the rule, and thus you fine-tune the rule to your environment that you may one day enable the Block option without interfering with excluded processes (approved applications).
With each object type there is an associated manner in which the object can be monitored. When you craft a rule yourself you can choose any/all of the relevant access options:
- Files & Folders, can be monitored for READ, WRITE (modify), CREATE, EXECUTE, and DELETE.
- Registry, can be monitored for WRITE, CREATE, DELETE operations. READ cannot be blocked - maybe I'll explain why some day.
- Ports, are a little different - you define the direction of communication you want to monitor (INBOUND or OUTBOUND), the port range, and the protocol (TCP or UDP).
... We can then compare the activity against the defined Access Protection rules, and make a decision on whether a rule is being violated or not. Notice that Access Protection does not make a determination based on virus definitions, it makes the decision based on the observed activity (or behavior) and whether that behavior is in violation of a rule. For that reason, you cannot have an Access Protection "False Positive" - if we say a rule was violated by an entity, it's because that entity violated the rule. Period.
When a violation occurs, an internal message is constructed and sent to our user mode process responsible for ePO event generation and logging, MFEANN.EXE.
All McAfee default rules are stored in a content file called VSCAN.BOF. This file is versioned and the version is reported to ePO when properties are collected; known as the BOC package, originally "buffer overflow content" but its purpose is much wider than that. We typically update the VSCAN.BOF with patch releases, sometimes we'll use the Update site, or we may even use a DAT update package and bundle it in with the DATs.
- When you add an AP rule of your own, the new rule is stored in the ePO database (if ePO managed) and written to the Windows registry on client machines (via policy enforcement, if ePO managed). The VSCAN.BOF file is not modified.
- When you modify a McAfee default rule, the entirety of the rule's new definition is stored in the ePO database (if ePO managed) and written to the Windows registry on client machines (via policy enforcement, if ePO managed). The VSCAN.BOF file is not modified. However, from that moment onward, You are the owner of the contents of that AP rule. McAfee can no longer modify it, because your customized changes will always supersede any updates we make to the VSCAN.BOF content.
I own What now?
Access Protection rules are loaded in memory in this order -
- Read VSCAN.BOF
- Read Windows Registry, "AccessProtectionUserRules" is a REG_BINARY with details of any added or modified AP rules.
- Read Extra*.rul file from disk
The load order explains the previous point, why You become the owner of an AP rule once it has been modified from its default.
See also: KB84087
The original intent of this feature was to provide a simplistic mechanism that allows an Administrator to *SQUISH* a malware outbreak. By means of crafting a rule, or through enabling one of our default rules, an unwanted behavior in the environment can be promptly given a Cease & Desist order, and a sigh of relief can be felt by all.
It did not take long for usage in the field to extend to much more than that. Using Access Protection as a means of application control: blocking the execution of 3rd party EXE files, preventing the access to certain unwanted multimedia files; or using it as a Firewall; or using it as a means to "spy" on User activities to collect evidence on inappropriate use of company resources. It really is an awesome feature, with marvelous potential and these are just some ways creative thinking types sought to use it - but that wasn't the original intended use case . There are better and more appropriate solutions for enforcing those kinds of restrictions, and folks can be disappointed to see their requests for additional enhancements go unrealized.
Nevertheless, we have made improvements to Access Protection over time, typically with each Patch release something about the feature is made shiny. For example, additional security mechanisms have had to be added in response to certain malware attack vectors that could and would render the product inert. Even further were changes that became necessary to thwart 3rd party DLL injection, because once a DLL loaded into one of our trusted processes that foreign code could basically do whatever it wanted, unchecked (because it was within a trusted process). So, Access Protection has had its own growing pains over the years and customer environments have had to adapt... or maybe opted to avoid the upgrade? Because if so, that would be disadvantageous.
AP wins... Practicality!
(If you heard a Mortal Kombat voice read that, you're awesome.)
This feature should always be enabled in your environment; without AP your VSE installation is vulnerable to new malware, which could render the entire product practically worthless in seconds. It's a one-round match when going up against malware opponents; and if you lose and later seek a rematch, you could be at a strong disadvantage.
3 groups of rules need to be enabled minimally, and they are enabled by default, FYI. They are:
- Monitoring permissions on protected folders
- Prevent termination of McAfee Services
- AP Rules
These are in their own groups because of the way they are implemented -
- The first is not an Access Protection rule, and is not configurable. This enforcement occurs deep within the kernel, with no logging mechanism permissible; it blocks attempts to change permissions on protected file/folder objects.
- The second is not an Access Protection Rule either, but it is a setting you can configure. Enabling this option changes the Security Descriptor list (DACL) for "Who is allowed to manipulate McAfee services", and because it's not a rule there can be no process exclusions added to it. Also, since it's not a rule, any violations are not recorded because it is not VSE that is enforcing the restriction: it is enforced by Windows itself.
- The 3rd group is made up of multiple AP rules that we enabled by default - these you can add processes to exclude, except for this first one in the list as exclusions are not relevant for it:
- Prevent hooking of McAfee processes2
- Prevent termination of McAfee processes
- Prevent modification of McAfee files and settings
- Prevent modification of McAfee Agent files and settings
- Prevent modification of McAfee Scan Engine files and settings
2 This rule was introduced to restrict 3rd party DLL injection occurring for our scanner processes, McShield.exe and Scan32/Scan64.exe. We need to guarantee that these processes have not been tampered with in order to ensure their scan results can be trusted and depended on. Consequently, a number of field-related incidents have been reported involving legitimate 3rd party software applications that, frankly, behave like malware (but Windows probably limits their options for implementing their functionality). These compatibility issues are solvable - usually - and often require working with our Support team. KB74176 and KB73521 both describe common symptoms tied to 3rd party DLL injection.
In case you didn't read it earlier, when you modify any AP rule, you become the owner of that rule - no further changes to that rule by Intel Security will have any effect (unless we modify that rule for you).
Modifying AP rules is a necessity for some environments, because of reliance upon a 3rd party applications that violate AP rules. One solution would be to engage that other vendor and seek updated code that no longer behaves in a manner that violates the rule, or, you can use the built-in Processes to Exclude functionality and basically white-list the 3rd party process (or processes) from the specific rule(s). Just remember, once you do that, your changes override any future modifications we release in VSCAN.BOF.
You can test and verify your modification is effective because the process that was violating the rule will no longer violate the rule.
Some of you understand the effective limitation where many of our Access Protection rules have Processes to Exclude already defined, and in those lists of exclusions are many process names; meaning, any process matching that name will be excluded from that rule, and that process name could be malware. Some of you have also noticed at times we reference processes with a fully qualified path, usually our own process; we do this because we can, and it does make the exclusion more secure.
Specifying full paths to process names should be done with care, because A) the User Interface has a limited number of characters it allows and if you're dealing with a 32-bit and 64-bit environment you might be having to specify the same process name twice, e.g.
C:\Program Files\etc\MyProcess.exe and
C:\Program Files (x86)\etc\MyProcess.exe. And B) if it's a Port blocking rule only specify a full path if you have the latest Patch installed (5 and beyond).
Notice we enable select AP rules only by default, yet more are provided. We formulated almost all our rules many years ago and so it's likely that portions of the rules and how they are defined are no longer valid or do not effectively provide the kind of protection levels it used to. Any rules that you modify, or create, or if you use any of the non-standard rules intended for "Maximum Security" environments, it is advisable to ensure they continue to work as you expect. It may be necessary to add additional processes to the Processes to Exclude lists for certain rules - this is especially pertinent if you have introduced new software to the environment, or even updated existing software and it has introduced new processes for their application.
An example of this is, if you have adopted McAfee Agent 5.0 then it has introduced 3 new processes: MASvc.exe, MACmnSvc.exe, and MACompatSvc.exe; making it necessary to exclude these process names for a number of VirusScan's Access Protection rules. "But, it's not necessary; they are not violating any AP rules" you might say - well, OK you got me ; thankfully our software has a backdoor for McAfee code so we can avoid Access Protection's watchful eyes... but, that backdoor is easily closed: See KB84087 for more details about what can happen. It's the sort of issue you'd wish you tested for, and discovered, prior to pushing out changes to the environment.
Bypass Access Protection
I wanted to say a little more about the backdoor I mentioned. It works through a Trust relationship that McAfee processes establish with a ruling entity we call the VTP service (McAfee Validation and Trust Protection). McAfee processes that acquire Trust are able to perform actions upon objects protected by Access Protection, and not require an exclusion in the Processes to Exclude for that rule. Nifty right? But, that Trust can be lost. Whenever an upgrade occurs that includes replacing MFEVTPS.EXE, such as a patch update for VSE or for our HIPS product or any other product sharing that VTP code, the replacement causes any prior Trust relationships that existed to be dropped. Processes that once were trusted must reacquire Trust or risk violating AP rules and getting blocked; typically, that requires services to be restarted - or simply, reboot (easy to say, at least). We exclude our own processes from AP rules because that Trust can be lost, and the exclusion then works as a backup method to avoid triggering rules.
This is the crux of the problem described in KB84087.
Sometimes a certain malware may become quite prolific in the field, such that persons within Intel Security may publicize ways to use Access Protection to help prevent and contain the threat. Here's an example which discusses Conficker: https://kc.mcafee.com/corporate/index?page=content&id=KB60909. It's a very comprehensive document; leveraging Access Protection is only a part of the whole solution.
You may feel confident crafting your own AP rules to block behaviors you know could never occur in your environment for legitimate reasons.
Keep in mind we have other AP rules you can enable which were intended to block behaviors we know are suspicious, but they're not enabled by default because we know not all environments subscribe to conservative ideals of safe computing - there are also legitimate applications on the market who behave just like malware, so, only the most basic or critical of AP rules are enabled by default.
"Be safe on the road" your parental unit might say when you were heading out in the car, even though you were an expert driver by your own reckoning. So too, we want you to use Access Protection safely despite what proficiency level you feel you already have. Adding custom AP rules that block unwanted behavior will help get your business from A to Z but you should still be aware of dangers.
A quick example of a really bad rule to add, is one that blocks All Processes from EXECUTING files that match this criteria: C:\Windows\System32\*.EXE. Very bad indeed. This would result in one of those Have-to-boot-to-Safe-Mode recovery plans because you're telling VirusScan to prevent critical operating system processes from launching, which will cause Windows to shutdown immediately.
If you're uncertain what an AP rule will do in your environment, configure the rule to Report only.
Then, for a time, monitor the events which show the rule is being violated. (A description of all VSE events can be found here: McAfee KnowledgeBase - Complete list of Event IDs for VirusScan Enterprise).
Access Protection events in warn mode will say "would be blocked" for the Action, letting you know the rule is in Report mode only at this time.
You must assess whether the process that would be blocked really should be blocked, or not. And if not, you need to add that process to the Processes to Exclude for that rule.
Rinse and Repeat those steps until you're satisfied only the intended processes to be blocked are the ones violating the rule - then, enable the Block option.