Driverstore updates get blocked

Every now and than a bunch of blocking events drop in my mailbox, such as:

Event: execution_denied
File (Full Path): C:\windows\system32\drivers\awon4hcv.sys
Program (Full Path): System
Registry Key:
System Name: LAPTOP10
User: NT AUTHORITY\SYSTEM

I have tried to figure out what is causing this by looking in the windows event log. After all, I would think an application that tries to update my drivers would normally log an error if it fails to do so.... Guess what: no events besides the mcafee ones:

McAfee Solidifier prevented an attempt to modify file 'C:\windows\system32\driverstore\infstrng.dat' by process C:\Windows\System32\services.exe (Process Id: 564, User: NT AUTHORITY\SYSTEM).

Basically something has updated a driver and tries to store the information in de driverstore, I assume. A pitty though that I cannot figure out what is causing this driver update. I (once again) assume it is Windows Update, as I have just ran the .lnk emergency update that came from windows update yesterday. The update itself is allowed because Windows Update is trusted, however I think the procedures that come afterwards don't.

I might want to create an extra exception for this, or maybe simply make sure I do "sadmin bu" before I run the update.

In a corporate network you could implement a workflow to centrally schedule the "sadmin bu" when whatever Maintenance Window is planned.

Conclusion: using application control == implement maintenance windows

Ehh why did outlook.exe try to execute mtail.exe?

In ePO I have created an automatic response to send an email to me of every blocked execution. So I was scrolling through my email, which always contain some of those responses. Most of them are driver updates which seem to appear because of windows update, still figuring this out, but now I noticed the execution denial for mtail.exe.

Mtail.exe is a freeware tool to open a .log file and monitor it at realtime. I use it every now and than for troubleshooting, but never installed it on my laptop.

This was the body of the email:

Event: execution_denied
File (Full Path): \\server\c$\users\erik\desktop\mtail.exe
Program (Full Path): C:\Program Files (x86)\Microsoft Office\Office12\OUTLOOK.EXE
Registry Key:
System Name: LAPTOP
User: DOMAIN\Erik

So basically Application Control on my laptop blocked outlook.exe from executing mtail.exe somewhere on a server?!?!? Looks scary!

I remember I have attached something from my desktop which was stored on that server, so that I have opened that particular location from outlook is true, but i certainly did not run mtail.exe at that point. That is: not deliberately :)

I just tried to reproduce the execution and it does not occur when I try to add mtail.exe as an attachment to an email (neither by drag&dropping nor by inserting it through outlook toolbar). It really only gets blocked this way when I click to attach a file in outlook, than browse to that directory and than richt-click mtail.exe and choose to open instead of select. That obviously is not something I think I could have done accidently, so this behaviour still is pretty peculiar: still don't have an explanation to it... If you do: please reply :)

If any such events reoccurs i'll let you know!

Trusted Users

It appeared to me I earlier misunderstood the Trusted User policy option. I thought it allowed certain users to install new applications or run unknown executables, but it does not.

Instead, a Trusted User is allowed to unlock the CLI and enable the update mode, without having to type a password.

The command:
CLI > sadmin recover

Is to unlock Solidcore. Afterwards the update mode can be initiated by "sadmin bu" (shortcut for begin-update). "sadmin recover" prompts for a password that can be set in ePO. The password prompt is thus disabled for trusted users, so they can do "sadmin bu" at any time.

Hashtab is great

During the Webinar Joe spoke about Hashtab to easily calculate a files fingerprint. It is possible to allow a file based on it's checksum (SHA-1), but how to calculate it?

Install Hashtab, than right-click the required file, and click the tab "Hash Values". Right-click the Hash Value of SHA-1, an choose Copy. Now you can paste it into ePO while creating an allowed Binary, or do it locally through the CLI. Offcourse the fingerprint can also be used to blacklist a certain file.

sadmin auth -a -c 2F6D10AF4CA263B762BA5749827017D4

Webinar by Joe McMahon

Today Mr. Joe McMahon of McAfee presented a webinar for Medusoft's customers on SolidCore products, specifically about Application Control. We recorded it and it is available for download from Medusoft's website:

Webinar Application Control.

Heatwave

Yesterday I got so frustrated with my laptop! It was in my docking station at home and at one point it started to run at high CPU usage, like continuously 100%. I watched my task manager to find out there really wasn't one application causing this but several in turn. So I started to get worried this had something to do with Application Control, which from my point of view is basically keeping an eye on every application. So first I enabled the update mode CLI "sadmin bu" (shortcut for begin-update) with no result. Than I even disabled it alltogether, CLI "sadmin disable". This required a reboot after which high cpu usage started again, so no result as well.

I couldn't figure out what was happening, so I took out the laptop from my dock, and that was when I felt it: HEAT! It was ready to bake an egg on it... After a while of working on it outside the dock the fans did their work and it cooled down. After which the CPU usage itself also turned back to like 3%. Conclusion: False Alarm :)



I have re-enabled it by CLI "sadmin enable" (both enable and disable require a reboot by the way). The software still hasn't let me down yet. You can imagine I am waiting for the moment I come across an issue but it still did not occur...

Back to work :)

Discovering the CLI

Suddenly I remembered I didn't install UltraEdit yet, my favorite text editor. I realized I came across a Command-Line Interface reference somewhere and decided to go and find out how this CLI could be used for one-time installations. And guess what: it worked out fine :)

These are the steps I took to be able to install UltraEdit:
1. Allow access to CLI (Is restricted by default, needs to be opened up using an ePO task)
2. From CLI: "sadmin begin-update". This enabled the update mode locally
3. Installed the software
4. From CLI: "sadmin end-update"

Using "sadmin help" shows instructions on the available commands, but there is also a comprehensive pdf available covering the CLI.

I am still thinking what the real risk level would be of keeping the CLI opened up continuously. I guess it is a risk that shouldn't be taken, and as opening up the CLI can only be done from ePO I guess to install new software that is not allowed fromone of the exception rules requires you to logon to ePO and open up the CLI from there.

Furthermore I found there is a bit of a flaw to installations that are distributed as an .msi, such as UltraEdit. Before I used the CLI, I tried to install it from a trusted (local) directory by double clicking the .msi. My Trusted Directory however did not have any effect because an .msi file is run by msiexec.exe, which offcourse is not stored in this trusted local directory. Application Control thus still blocked the installation.

What to do at one-time emergency installation?

Yesterday I was at-the-office and for some reason my Domain Policy kicked in and first removed my Microsoft Office installation, afterwards trying to deploy it again. The deployment failed partially ending up in a misconfigured installation. I tryed to figure out what specifically was blocked from the Windows Eventviewer and ePO. They both indeed held the blocking events. But when I used the logged info to allow the installation (again by trusted directory) after a reboot it still was blocked.

Because I had limited time at that moment I went looking for a way to temporarily disable Application Control, and found that there is quite a nice way to do so: in ePO there is a client task type named "SC: Start Update Mode" and "SC: End Update Mode". They pretty much do what they say, Update Mode being a time window in which one is allowed to make changes to the system, so after starting the update mode on my computer I was simply able to recover the Office installation and it's running smooth now.

Afterwards I offcourse "ended" the Update Mode, and I will try to find out what is a more comprehensive way to allow AD deployed software.

It Works

After the Solidifying was complete, I received a pretty decent popup message that the McAfee Administrator initiated a reboot. I could only close that message and afterwards the reboot occured.

After the reboot I logged in back onton the domain and everything seemed ok, until i received the following error:



Obviously the domain I login to, enforces a certain logonscript, which is pretty common behaviour within a domain. Because it was a script that is not a part of my local (solidified) computer, it was disallowed. This clearly is a false positive so it requires my first well thought through exception :)

When defining an exclusion rule it is important to decide what type of exclusion best fits your needs. The following types are available:
- Updater (a process that is allowed to update other processes, such as Windows Update)
- Binary (a process specified by its hash value)
- Trusted User (a local or domain user)
- Publisher (the software vendor recognized by their digital signature, eg "Microsoft")
- Trusted Directory (a certain location where only trusted files recide)
- Installer (a process that is allowed to install new software, such as Altiris)


In this particular case I have decided that Trusted Directory best suits my needs. I also see that if looking at targeted attacks the knowledge of these exclusions should only be available to a limited amount of coworkers, but that is possible in ePO quite easily.

Installed & Enabled

Ok, after obtaining the supported version of SolidCore (5.0.2.6702) for my OS (win7 x64) I have now rolled out the software to my laptop.

First of all I needed to created a deployment task in ePO, which is similar to rolling out software like VirusScan, for the ones who are familiar with ePO. But than it appeared that the software is disabled by default and will only be enabled after telling it to do so. This is different from VirusScan deployment, the downside is that you need to be aware of it and have to create another client task, the upside is that Rolling Out and Enabling can each be done in phases. Luckily a proper "Getting Started Guide" is available providing a step by step guide to properly run Application Control on the endpoints.

After enabling the software it started to "Solidify" my computer, which basically means that it created the snapshot I mentioned earlier. Apparently the software requires a reboot when the scan is complete. I have checked the box that the reboot can be performed immediately, but it is also possible to disable the automatic reboot and simply wait for the user to reboot.

At this point the software is still running. SCSRVC.exe is the process which obviously is doing the job running at 30-40% CPU time. That's quite a lot but I think this just is during the Solidifying phase. Meanwhile the McAfee Agent has reported back that my computer has SolidCore installed and is currently Solidifying my system.

I have made no changes besides the enabling of the software. So all McAfee Default policies are still active. If I am correct this will lead to a working environment after reboot, onto which nothing new can be installed. It than comes down to creating the proper exceptions offcourse, because I still need to install some stuff :)

How it works

Application Control basically is a policy-based whitelist of applications. In short the whitelist contains the fingerprints of all applications and associated .dll's etc. that are allowed to run on your computer. All undefined applications or even other versions of the allowed ones simply can not run.

Such technology is often considered to be very time-consuming to manage. And it is indeed if you would for instance build your own whitelist using integrated technology and policies in Windows. So here is where the fun starts:

After installation of the McAfee Application Control software on an endpoint, the software starts to create an index of all executables, registry, dll's and other related files that are already on the endpoint. It basically takes a snapshot of the current state the endpoint is in. Once this baseline is build, the software can be activated. Afterwards only file executions that are specifically allowed by policy, can run apart for the whitelist.

An example of a possible policy would be to define a certain executable as an updater, for instance the SMS client. That executable than is allowed to apply changes to the snapshot, so it can basically update the whitelist. Other examples are to allow a certain user to make changes, or to allow undefined executables to run only from a certain directory.

If you think of it, the way computers often are managed in an enterprise environment (golden image and than a deployment tool for changes), can be the blueprint for your application control configuration and afterwards your computers do exactly what they are meant for and nothing else.

Supported Platforms for Application Control are:

(Windows x86)
- Windows NT 4.0 - Workstation, Server, Terminal Edition with SP6a (not supported with ePO)
- Windows 2000 - Advanced Server, Server, Professional Editions with SP4 Rollup1
- Windows XP - Professional Edition with SP0, SP1, SP2, SP3
- Windows 2003 Server - Enterprise, Standard, Web Editions with SP1, SP2
- Windows Vista - Business Edition with SP1
- Windows 7
- Windows 2008 Server - Enterprise and Standard Editions with SP1, SP2
- Windows XPE
- Windows Embedded Point of Service (WEPOS)
- Windows Embedded Standard 2009
- Windows Embedded POS Ready 2009

(Windows x64)
- Windows XP Professional Edition (AMD64) with SP1, SP2
- Windows 2003 Server Enterprise Edition (IA64/AMD64) with SP1, SP2
- Windows Vista - Business Edition (AMD64) with SP1
- Windows 7
- Windows 2008 Server - Enterprise and Standard Editions (AMD64) with SP1, SP2
- Windows 2008 Server Core (AMD64) with SP1
- Windows Server 2008 R2

(Other)
- Red Hat Enterprise Linux 3/4/5
- CentOS 4/5
- SUSE Enterprise Linux 9/10
- Oracle Enterprise Linux 5
- Solaris 8/9/10

The Purpose Of This

Hi, my name is Erik. I work as a security professional for Medusoft BV in The Netherlands. Medusoft is an Elite Partner of McAfee and I have been working with anti-virus and related products for many years now.

Lately the fuz around AV has swolen and IT professionals all over the globe tend to get sceptical about the classical AV model. And they basically have every right to as well. The amount of malware that comes out on a daily basis has grown so rapidly that we all will not be able to provide enterprise wide security just with a reactive approach. Let alone the fact that more and more targeted attacks appear that simply are unique and therefor undefined in your AV definitions.

So the answer to these developments clearly would be to shift to a more proactive approach. The most likely way to protect endpoints in the near future will probably be Application Whitelisting. Such technology enables you to define specifically which applications can run and blocks the undefined.


McAfee has entered the Application Whitelisting market with the acquisition of SolidCore in 2009. Their Application Control product was already ePolicy Orchestrator (ePO) capable from the Security Innovation Alliance program that SolidCore was a part of, so the integration took place smoothly.

The problem with Application Whitelisting is that at this point nobody really has the guts to claim AV can be displaced by it. So that's when I thought: let's just give it a try.

So here is what I will do in this experiment. I have just reinstalled my HP EliteBook 8530w with Windows 7 Ultimate x64 and am running all my required business applications. That is Microsoft Office, VMWare Workstation, ehhrrr, ah yes, Internet Explorer. I have NOT installed McAfee products at all, and all Windows 7 integrated security features apart from the Windows Firewall are turned off.

I will install an McAfee Agent (v4.5) on my laptop that will connect my laptop to an online Hosted ePO Server (v4.5 Patch 2) of Medusoft, which is only configured to manage McAfee Application Control. The McAfee Agent will than install McAfee Application Control which will first make an index of my current application and than locks up my computer for any new installations except from those that I allow specifically.

And than, after my computer has been "Solidified" (i luv it), I will post regularly and everytime I get frustrated because I cannot install something or when my laptop gets infected by a virus (for Medusoft I come in infected environments all the time...)