HIPS and Leak Tests

At least one other member around here has said it does not make sense to leak test HIPS. I agree with this statement and would like to expand it.

Leak tests originated as a means to detect communication by malware by using programs that were otherwise authorized to make outbound internet connections. It originated as apost infection measure, when all else had failed. Comodo 2.4 is a good exampleof this approach.

HIPS are supposed to prevent the installation of malware. Assuming you do not give permission to some Trojan laden screen saver or weather bug, your system should remain clean.

I would have to say any HIPS that does not block every leak test is broken, not simply outsmarted by the latest thing. Its possible to intentionally allow the leak test to install and see if the HIPS blocks it by secondary means. I think this makes no sense, but others may disagree.

One could say you need both. The HIPS to block drive by infections and the leak proof firewall to take care of the mistake of running Trojan applets. My view on this is if you are smart enough to respond to all the prompts this setup will give you, you will not make such a mistake in the first place. In other words, its useless duplication.

This brings me to the next question which is why bother with HIPS that monitor all sorts of stuff when something like Anti Executable will prevent any new malware from running, and has the added benefit of being able to do a baseline scan so it keeps quiet.

Actually, Comodo 3 and just about any HIPS could benefit from a baseline scan and the assumption that anything thus white listed may be started by a variety of other white listed programs, especially explorer.exe.

 

Hello,
I agree. Why bother. Use either a software anti-executable or manual anti-executable. Both work well.
Mrk

 

Have you considered it's not always possible to tell whether a program is malware or not, just by looking at it?

 

IBM=I've been moved!

Mrkvonic, other than Anti-Executable by Faronics are there any other software or manual utilities that regulate program execution without other HIPS features, and what is a manual anti-executable?

solcraft, I agree you can't always tell, but I think I know the difference between downloading from a legitimate software author's website and some junk you can find by googling "free screen savers" or worse yet a link in email. So, I can nearly always tell when I am sure to be right and the doubtful stuff I can try in a disposable VM or just forget about it.

 

And perhaps not everyone is willing, or has the system resources, to install and manage something as cumbersome as a VM.

There are many ways to analyze and guess if a file is malware; a HIPS is just one of them. Using your logic I could say that HIPS make VMs obsolete for testing malware (obviously it doesn't). That's all there is to it.

 

Use my logic for long enough and you will need medication.

I don't know what you are trying to get at, other than to waste my time.

 

Hello,

Manual ant-executable - you double-click it executes, you don't double click, it doesn't. As simple as that. Worked for me quite well these last 17 years or so.

Other than AE - Security Restriction Policies, built in, free, 0 resource hog.

Maybe others, didn't really investigate.

Mrk

 

Peter2150, that is a good point. Nothing is perfect. Probably what is good about Anti-Executable is it could be rolled out to lock down a bunch of machines sitting in front of secretaries. It simply blocks everything that has not been put there by IT, but unlike Deep Freeze allows for minor configuration changes. Perhaps this reflects my point of view that the best solutions are automatic and idiot proof. Full HIPS and leak proof firewalls throw out a lot of pop ups and never seem to completely quiet down. In an office those would be calls to the help desk and lost productivity. Obviously, as a hobby, or in an IT shop where some problems have to be solved, different criteria apply. However, it makes me wonder exactly for whom companies are developing these products that require so much user intervention.

The situation you describe is difficult because one thinks the executable is good when it is not. No telling what the circumstances were as to how it was acquired. I would take similar precautions, use a VM, or upload it to a multi engine AV after holding on to it for a week or so. Perhaps its time to put a HIPS on one of my disposable VM's.

 

There's ExeLockdown, an abandonware.
Manual anti-exec? Software Restriction Policies

 

I think the software restriction policy is what I am looking for. I already run limited user in XP/2003, and I am totally used to it. The article you linked to looks good, but I need a bit more time to go through it.

Edit:

Its done, I can't believe how easy that is & I wonder why I never ran across this gem before, thanks.

 

I doubt that; for some reason many people like to exaggerate their own eccentricity, as if to make a personal statement. But making me roll my eyes and go "this is stupid" is quite possible, though.

My point was that the arguments you pose that HIPS need not do nothing but prevent malware from running are all really quite empty when you take a closer look at them. <removed unncessary personal comment - Peter2150>

 

As I see it, the primary role of a (classical) HIPS is/should be being an anti-executable and then enforcing a system policy that goes further than what's allowed to run (i.e who launchs who, what xxx.exe can and can't do, etc)
I don't like this approach to security.

 

Exactly.

I don't like them either, but that doesn't mean they don't have their own purpose to serve.

 

Security is not a one size fits all.

People here should really come around to understanding that.

Nor is it a single product, any product from any category.

 

Yeah. What he said.

Presumably "enforcing system policy" would imply that you expect to run malware and still surivive....

 

When I started this thread I was thinking about what is it that Leak Testing actually accomplishes. I have never been a fan of leak testing as it started out as a post infection concept, to catch the malware when it phones home. There is quite a bit wrong with this, not the least of which is the malware could disable the firewall.

Subsequently Matousec started to test non firewall HIPS and now we have more firewalls like Comodo that include HIPS. Functionally the HIPS prevents installation of the leak test (or malware) in the first place, which I think is what everyone wants.

I suppose someone could test by first turning off the HIPS to install the leak test and turning it back on and see if it is blocked, but this seems plain silly. I suppose its akin to the person who installs something thinking it is OK and it turns out not to be, Does he get a second chance now. He might if he had a separate HIPS and a non-HIPS firewall with leak prevention capability.

Somewhere this veered into the territory of using HIPS to detect malware. Its not the only way, but its another tool when combined with imaging, virtual machines or something like Returnil to undo the damage done during the testing. I suppose its a good idea to disconnect your network cable while doing this. Actually I had not thought about HIPS as a detection tool prior to this thread.

Sometimes you don't know 100.00% if a file is clean. There are circumstances that would lead a reasonable person one way or the other. However, my concerns are more about drive by downloads. While its possible to make a mistake I believe that I have adequate procedures to judge things that I intentionally put on my machines. Non signature detection methods are a complex topic worthy of many discussions.

At any rate that is why I like execution prevention strategies. I find the software restriction policy so attractive because I already run LUA, its free, uses no resources, will work on a secretary's machine, and within its boundaries it is absolute. True, it, will not tell you if some free screen saver you ant to install is a Trojan, but it will tell you if a drive by download attempts to run from the cache of your browser.

So, does anyone else around here have something to say about evaluating HIPS with leak tests or even about a better or alternative way to evaluate HIPS?

 

Why not.

In fact, second chances don't come into play here, because the key thing to keep in mind is that the system has NOT YET been compromised when the prompt comes up. You either neglect or do not know this. The prompt is telling you that some process is trying to do something, and ideally the target user group of HIPS - aka people with enough know-how - will recognize the alert as unusual and potentially dangerous, deny the action, and PREVENT the infection.

 

Depends on how you define infection of course. Without some kind of smart auto rollback, chances are there will be some degree of "infection", but probably the worst effects do not occur...

 

I define "infection" as the malware successfully delivering its payload, or otherwise performing whatever malicious or undesirable actions it was designed to do. Without the payload, the malware is just a harmless file or registry key, no different from any others, sitting on my hard disk; infection has not occurred.