cancel
Showing results for 
Search instead for 
Did you mean: 
epository
Level 10

HIPS signatures for Application Whitelisting still triggering on exempted Digital Signatures

All,

I decided to give Application Whitelisting a try in our environment.

After several weeks, I created a policy with a fair number of exceptions include a 6010 and 6011 rule that had about 15 digital signatures...these were added as both "Executable" and "Target Executable".

With that rule and a few others, I was able to get my number of HIPS events down from 44k per day to about 1k per day; however, I am still getting 6010 &  6011 events from a couple servers where the Executable and Target Executable are both Microsoft Signed Code...things like cmd.exe and mstsc.exe

I set logging to Debug but it just spits out so much info....I can see the violations, but no reason why...it merely says "AllowEx=False"...its doesnt seem to be triggering on all signed code, just some.

I have used the clientcontrol.exe for a couple commands like

clientcontrol.exe /log 0 4 to get the except_db file to generate and I have pored over that.

I also used clientcontrol.exe /exportconfig <PATH> 4 to get the list of exceptions.

The only think I can kind of see is that it appears the except_db.exe goes thru all the .exe's on a computer and determines whether they are exempt or not based on whatever exception criterial you have created.

It also appears to go to your "Trusted Programs" list and creates a list of those as well and denotes what signatures they are exempt for.

So, in my case, neither spuchostservice.exe or cmd.exe show up in the except_db file leading me to believe something is amiss...how to fix it, I have no idea.

I am hoping someone out in EPO-land can tell me the reason for the except_db file and what I should be looking for.

0 Kudos
10 Replies
greatscott
Level 12

Re: HIPS signatures for Application Whitelisting still triggering on exempted Digital Signatures

Take a look in the Digital Signer Paths that you have added. Some will list the state as  "ST=WASHINGTON, C=US", and some will list it as "S=WASHINGTON, C=US". Could be a discrepancy here. And if i remember correctly, one will take care of both, but I cannot recall...

0 Kudos
McAfee Employee

Re: HIPS signatures for Application Whitelisting still triggering on exempted Digital Signatures

greatscott wrote:

Take a look in the Digital Signer Paths that you have added. Some will list the state as  "ST=WASHINGTON, C=US", and some will list it as "S=WASHINGTON, C=US". Could be a discrepancy here. And if i remember correctly, one will take care of both, but I cannot recall...

That shouldn't be an issue here.  See:

KB72290 - Host Intrusion Prevention 8.0 Extension normalizes digital signer data ("S=" is normalized to "ST=")

0 Kudos
petersimmons
Level 12

Re: HIPS signatures for Application Whitelisting still triggering on exempted Digital Signatures

I realize that it is possible to do some whitelisting with Host IPS. However, this is definitely not the product you should try this with. McAfee Application Control uses a model that is MUCH simpler than what was in HIPS. It is the difference in managing lists versus managing the rules for how a list changes. While this is a "supported' path that you are on, I have to respectfully and politlely say that I think it is nuts and a complete waste of time. It will consume between 10X and 100X more time to try this with Host IPS than it requires with MAC. If you were one of my customers directly (I have named accounts) I'd be having an intervention with you to help convince you to try this with the proper product.

0 Kudos
epository
Level 10

Re: HIPS signatures for Application Whitelisting still triggering on exempted Digital Signatures

Well, my employer is the DOD and they have mandated this.

I dont really understand what you mean by being able to do "some" Whitelisting....because if it isn't whitelisted, it is blocked.

And why add the feature to HIPS if it is not the right product to be doing Application Whitelisting?

With HIPS 6010 and 6011 exceptions, I have managed to knock down our number of events from 44k to about 1k per day with maybe a total of 30 exemptions.

I dont really have a choice in the matter because we dont have the McAfee Application Control license or software supplied by DISA so......

I am just trying to figure out how I can make the product I have access to work.

If this is not the right product, then please inform the DOD that this task will be a huge time-waster for its employees because I have been troubleshooting this last 2% of exceptions for a few weeks now and the McAfee documentation on this leaves quite a bit to be desired.

0 Kudos
petersimmons
Level 12

Re: HIPS signatures for Application Whitelisting still triggering on exempted Digital Signatures

We didn't "add" the ability to Host IPS. it has been there since we bought it years ago. In fact, in later versions the GUI interface was completely removed. We purchased Solidcore several years ago and it provides vastly superior management of application control. What is in Host IPS will require several people to maintain on a regular basis and will provide inferior capabilities when it comes to determining if you accidentally placed the wrong item on the list. If I knew a way to convince the government to stop wasting my money I would. It really does require 10-100X the effort to maintain. That wasn't an exxageration at all. You will NEVER be done and will constantly fight getting whitelist complete.

You are really using the wrong product here. This is the one you want to check out:

http://www.mcafee.com/us/products/application-control.aspx

As a commercial/enterprise person I probably lack the clearance or the contacts to help you with any "informing". There are other agencies that do use that product and there are definitely a lot of public companies that do.

0 Kudos
greatscott
Level 12

Re: HIPS signatures for Application Whitelisting still triggering on exempted Digital Signatures

I can sympathise with epository, and also concur with Peter. IPS shouldn't be used this way, and I severely doubt we will ever locate true positive data for a blocked application via 6010/6011. But as epository stated, some of us are hamstrung by requirements to use it, so we will. Tuning it is near impossible with any large environment, and our hopes of ever rolling these signatures to blocking is close to 0.

0 Kudos
epository
Level 10

Re: HIPS signatures for Application Whitelisting still triggering on exempted Digital Signatures

Here are some log excerpts...i am still in logging mode as I cannot seem to get these exemptions to work and to go live would basically hose a bunch of servers.

Event.log

Violation logged for spuchostservice.exe

9    1384173192    127.0.0.1        0    0    4    6010    2    0    0    2013-11-11 15:33:10    Program    domain\sharepoint.svc      C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCHOSTSERVICE.EXE  

Hipshield.log

Executable Exemption - all signed code

11-12 11:52:57 [07828] DEBUG:              Type=0

11-12 11:52:57 [07828] DEBUG:              Path=**\**

11-12 11:52:57 [07828] DEBUG:              Descr=Signed MS Windows Component Publisher MOPR sig

11-12 11:52:57 [07828] DEBUG:              Signer=CN=MICROSOFT WINDOWS COMPONENT PUBLISHER, OU=MOPR, O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US

11-12 11:52:57 [07828] DEBUG:              Hash=00000000000000000000000000000000

Target Executable Exemption - to all signed code

11-12 11:52:57 [07828] DEBUG:              Path=**\**

11-12 11:52:57 [07828] DEBUG:              Descr=MS Corporation MOPR Signed Code

11-12 11:52:57 [07828] DEBUG:              Signer=CN=MICROSOFT CORPORATION, OU=MOPR, O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US

11-12 11:52:57 [07828] DEBUG:              Hash=00000000000000000000000000000000

11-12 11:52:57 [07828] DEBUG:              Type=3

HIPShield Log of additional Exemption - had to make this to try to fix the issue of the Sharepoint service being logged as a violation

11-12 11:52:57 [07828] HRC INFO: Called HrcAddPolicy Id=HRC_EXCEPTION[5], Mode=HRC_APPEND[1]

11-12 11:52:57 [07828] DEBUG: Local Exception Details: active=1, blocked=0

11-12 11:52:57 [07828] DEBUG:              markForMerge=0, adminRule=1

11-12 11:52:57 [07828] DEBUG:              readonly=1, markForDelete=0

11-12 11:52:57 [07828] DEBUG:              createdManually=0, numAdvDetails=0

11-12 11:52:57 [07828] DEBUG:              groupName=none

11-12 11:52:57 [07828] DEBUG:              groupSid=none

11-12 11:52:57 [07828] DEBUG:              osUserName=none

11-12 11:52:57 [07828] DEBUG:              includeAllProcesses=0, numExecDetails=2, pExecDetails=0x03ea345a

11-12 11:52:57 [07828] DEBUG:              excDesc=X-6010-Generic Application Hooking Protection - MS Corp MOPR signed spuchost to spuchost

11-12 11:52:57 [07828] DEBUG:              createdTimeStamp=none

11-12 11:52:57 [07828] DEBUG:              modifiedTimeStamp=none

11-12 11:52:57 [07828] DEBUG:              sigNum=6010, ruleId=0, ruleVersion=0

11-12 11:52:57 [07828] DEBUG:              includeAllSignatures=0, includeAllUsers=1

11-12 11:52:57 [07828] DEBUG:              Type=0

11-12 11:52:57 [07828] DEBUG:              Path=**\SPUCHOSTSERVICE.EXE

11-12 11:52:57 [07828] DEBUG:              Descr=MICROSOFT SHAREPOINT FOUNDATION SANDBOXED CODE EXECUTION HOST SERVICE

11-12 11:52:57 [07828] DEBUG:              Signer=CN=MICROSOFT CORPORATION, OU=MOPR, O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US

11-12 11:52:57 [07828] DEBUG:              Hash=00000000000000000000000000000000

11-12 11:52:57 [07828] DEBUG:              Type=3

11-12 11:52:57 [07828] DEBUG:              Path=**\SPUCWORKERPROCESSPROXY.EXE

11-12 11:52:57 [07828] DEBUG:              Descr=MICROSOFT SHAREPOINT FOUNDATION SANDBOXED CODE EXECUTION WORKER PROCESS PROXY

11-12 11:52:57 [07828] DEBUG:              Signer=CN=MICROSOFT CORPORATION, OU=MOPR, O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=U

Hipshield.log gibberish

k11-12 11:53:01.078 Debug: 0x4,bcc OpenProcess: pid 0xb04 access 0x1fffff for 0x1c48,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCWORKERPROCESSPROXY.EXE

i11-12 11:53:01.086 Debug: 0x268,10b8 Post_LdrLoadDll actual load HIPHandlers64.dll

i11-12 11:53:01.086 Debug: 0x268,10b8 hookKevlarAPIs - COM setup thread is not needed

i11-12 11:53:01.086 Debug: 0x268,10b8 HcApi initialized part 3.

i11-12 11:53:01.086 Debug: 0x268,10b8 MfeFhe - initialize done: 0x0.

s11-12 11:53:01.086 Debug: 0x33c,1ff0   Inject: remote thread in PID=0x268 done with code 0x00000000

k11-12 11:53:01.363 Debug: 0x4,1318 Executable flags 0x110011d \DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SHELL32.DLL

s11-12 11:53:01.363 Debug: 0x33c,c38   Inject: remote thread in PID=0x1890 done with code 0x00000000

i11-12 11:53:01.363 Verb : 0x1890,1318 1 HBO entry for module C:\windows\system32\SHELL32.dll (6.1.7601.18222) (ad662b34b161198b9d66a564edda7d43) did not match any of 26 hash(es)

i11-12 11:53:01.363 Debug: 0x1890,1318 hookKevlarAPIs - COM setup thread is not needed

i11-12 11:53:01.363 Debug: 0x1890,1318 HcApi initialized part 3.

i11-12 11:53:01.363 Debug: 0x1890,1318 MfeFhe - initialize done: 0x0.

k11-12 11:53:01.575 Debug: 0x4,1db8 OpenProcess: pid 0x1c48 access 0x100000 for 0xb04,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCHOSTSERVICE.EXE

k11-12 11:53:01.575 Debug: 0x4,1db8 OpenProcess: pid 0x1c48 access 0x100000 for 0xb04,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCHOSTSERVICE.EXE

k11-12 11:53:01.575 Debug: 0x4,1db8 OpenProcess: pid 0x1c48 access 0x100000 for 0xd18,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCWORKERPROCESS.EXE

k11-12 11:53:01.575 Debug: 0x4,1db8 OpenProcess: pid 0x1c48 access 0x100000 for 0xd18,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCWORKERPROCESS.EXE

k11-12 11:53:02.080 Debug: 0x4,bcc OpenProcess: pid 0xb04 access 0x101400 for 0xd18,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCWORKERPROCESS.EXE

k11-12 11:53:02.080 Debug: 0x4,bcc OpenProcess: pid 0xb04 access 0x101400 for 0xd18,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCWORKERPROCESS.EXE

k11-12 11:53:02.080 Debug: 0x4,bcc OpenProcess: pid 0xb04 access 0x1fffff for 0x1c48,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCWORKERPROCESSPROXY.EXE

k11-12 11:53:02.575 Debug: 0x4,1db8 OpenProcess: pid 0x1c48 access 0x100000 for 0xb04,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCHOSTSERVICE.EXE

k11-12 11:53:02.575 Debug: 0x4,1db8 OpenProcess: pid 0x1c48 access 0x100000 for 0xb04,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCHOSTSERVICE.EXE

k11-12 11:53:02.575 Debug: 0x4,1db8 OpenProcess: pid 0x1c48 access 0x100000 for 0xd18,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCWORKERPROCESS.EXE

k11-12 11:53:02.575 Debug: 0x4,1db8 OpenProcess: pid 0x1c48 access 0x100000 for 0xd18,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCWORKERPROCESS.EXE

k11-12 11:53:03.043 Debug: 0x4,48 , Eid matches:

k11-12 11:53:03.043 Debug: 0x4,48     0 -<Microsoft><Valid> -path <SYSTEM> -hash * -desc * -sdn *

k11-12 11:53:03.043 Debug: 0x4,48 Eid 86

k11-12 11:53:03.103 Debug: 0x4,cac OpenProcess: pid 0xb04 access 0x101400 for 0xd18,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCWORKERPROCESS.EXE

k11-12 11:53:03.103 Debug: 0x4,cac OpenProcess: pid 0xb04 access 0x101400 for 0xd18,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCWORKERPROCESS.EXE

k11-12 11:53:03.103 Debug: 0x4,cac OpenProcess: pid 0xb04 access 0x1fffff for 0x1c48,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCWORKERPROCESSPROXY.EXE

i11-12 11:53:03.169 Debug: 0x260,6a4 RPC: Hooking functions for interface: 367abb81-9844-35f1-ad32-98f038001003

k11-12 11:53:03.575 Debug: 0x4,1db8 OpenProcess: pid 0x1c48 access 0x100000 for 0xb04,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCHOSTSERVICE.EXE

k11-12 11:53:03.575 Debug: 0x4,1db8 OpenProcess: pid 0x1c48 access 0x100000 for 0xb04,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCHOSTSERVICE.EXE

k11-12 11:53:03.575 Debug: 0x4,1db8 OpenProcess: pid 0x1c48 access 0x100000 for 0xd18,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCWORKERPROCESS.EXE

k11-12 11:53:03.575 Debug: 0x4,1db8 OpenProcess: pid 0x1c48 access 0x100000 for 0xd18,C:\PROGRAM FILES\COMMON FILES\MICROSOFT SHARED\WEB SERVER EXTENSIONS\14\USERCODE\SPUCWORKERPROCESS.EXE

k11-12 11:53:03.943 Debug: 0x4,ce8 OpenProcess: pid 0xbd8 access 0x1400 for 0x114,C:\WINDOWS\SYSTEM32\SMSS.EXE

Message was edited by: epository

I ended up adding additional 6010 & 6011 exceptions which seem to be working, but if I have to do this for all the stray 6010 & 6011 events, my exceptions list is going to be huge. on 11/25/13 5:45:52 AM CST
0 Kudos
epository
Level 10

Re: HIPS signatures for Application Whitelisting still triggering on exempted Digital Signatures

This may be solved.

When I created the mass Digital Signatures exception, I edited the "File Description" to describe which signature it was.....it turns out this is one of the matching parameters so...oops.

Anyhow, went back into my policy and removed all text from the File Description field and cleaned it out....resaved...and now my number of incidents has plummeted.

Its good news.

lrock
Level 9

Re: HIPS signatures for Application Whitelisting still triggering on exempted Digital Signatures

@epository Interested in how things are going. I have put in several hours working on a Whitelist for HIPS 8 / Servers using a list of exe from each Server via:

Dir /B /S *.exe>>drive\path\data.txt

applying these to 6010 and 6011.

Part of DoD, I also am not able to use McAfee Application Control at this time. That being said, we are also experimenting with Microsoft AppLocker for our workstations which has worked well so far in testing.

Curious - in following the McAfee HIP's 8.0 DoD Methodology document, It's suggested that I create exceptions by path and not for every exe alone.

example:

instead of making an exception for every exe in system32, do

c:\windows\system32\*.exe

If your using the method also, do you find this to work well?

Example:

c:\Windows\Installer\{*}\*.exe

Thanks

Lrock

0 Kudos