Are HIPS programs TRULY effective?

Was it called PCAudit by any chance? That one can be hard to beat without either blocking the process itself or the hook it sets. It can be defeated with a well configured firewall, but you need full control over all loopback connections, and not all firewalls give you that level of configurability.
Rick

 

Well, you've made valid remarks, but unlike scanners, which tests are less likely to be discussed (I mean a file is detected, or not detected), HIPS testing imply + or - a part of subjectivity : It seems to me that you have your own view on this matter, and therefore want it to be the "real file" scenario, the only one.

However, there are some points which lead to restrain this analysis; first, there's a point you seem to have forgotten here : The app I tested, DefenseWall, doesn't work the same way as SSM at all. With most of the sandboxing apps, you do not prevent a program from starting, but you start it "sandboxed", under control. The goal is then to watch how this program is protecting the user. In fact, I think this methodology was designed especially for this session of tests, which is based on "white-list" based HIPS (some are sandbox, some not).

In such a scenario, tests made with the HIPS disabled are revelant : Will the program detect that a "new and unknow" [not on the white-list] process is running ?, and how will it deal with that program ? Will it be included in the white-list ?

That's the reason why tests were made with the HIPS disabled, AND why the test files were not blocked right when they were initialized.

By the way, there's nothing esoteric in a test made with the HIPS disabled : As you probably know, HIPS editors often advice users to DISABLE their HIPS before installing some programs. Isn't that real-life ?



Besides, this second point of your argumentation can be discussed too : Take for example a test on rootkits; use several programs, all pretending to prevent them; do you think this is serious to prevent their installers to run, to say "Hurra, the rootkit is blocked" : No ! , for this test to be a real test, you have to let them run, and then to see if the program is actually blocking it (driver installation, etc).

Let's take Process Guard : Only the full version claims to prevent rootkit; but of course, the free version could do as well IF you do not allow the rootkit to start. What happens, however, if a file you allow to run, thinking this is a legit program, tries to install a rootkit later (just a working hypothesis ). Here is the advantage of a program really able to prevent rootkits : You can run the file, but block its illegitimate attempts.

Example with FU : Nothing happens when you start it, this is when you instruct it to hide something that the rootkit behaviour is revealed :

http://img127.imageshack.us/img127/9813/fu2ua5.png


So anyway, for sandboxes programs, there's no point in discussing whether the test files are allowed to run or not. You are not prompted to allow it to run or not. This makes these test "real life" tests, period .

But even for "classical" HIPS, your real-file testing criteria would make every tests very easy to do : No need to waste time, just prevent any test files to start, et voilà ! . Wouldn't it be boring ? (Test 1 : "I didn't run it" > Passed, Test 2 : "I didn't run it" > Passed, etc) That's NOT real-life test (not even test, since you do not test anything), because you have to think that many malwares can be hidden in what you can consider as a legit file. I guess this is the presupposition on which all these tests stand on : Something as "what happens when the user runs a possible malware" ? Or what can do the program to protect when malware is run ?


Another point :

Hey, what's the difference between a file installed locally by the tester, and a file downloaded through the browser ? In both case, the file will be (should be) executed, there's strictly no difference ! The only difference can be (not always anyway) the location of the file on the computer...


Well, all that to say I think you're overvalueing the effect of some minor points of the methodology used in these tests, to draw big conclusions from minor factors.


An interesting thread on this HIPS testing matter : http://www.spywarewarrior.com/viewtopic.php?t=22210


nicM

 

Sandboxing type apps have a pretty well known testing methodology (barring some minor squabbles!), so that's not a big problem.

I guess, it depends on how you see classic HIPS. Is it more like an Antivirus, or is it a intergrity checker?

In one school of thought (HIPS as intergrity checker), you create a baseline of what is normal in your system and anything that deviates from that is flagged and stopped.

If you hold to that school of thought, it is hard to accept that HIPS can protect you if you choose to volunteerly install a piece of software (which might or might not be clean).

Unless you already know it is malware (in which case you would not install it), it is hard for you to know if any changes to the baseline are legimate or malicious. So any alerts stemming from that event are useless.

On the other hand, if you believe that your HIPS is capable of actually
detecting annomlous behavior that is indicative of malicious software independent of your baseline, than you can expect HIPS to at least warn you even after you get infected. This is similar to expecting an antivirus to detect malware even after the AV is installed after the system is alreadt infected.

This is the view of HIPS as an antivirus.

But the problem as always is this, what kinds of prompts count as a warning?
The closer your HIPS is to AV style warnings the more likely it will help..

This argument is flawed.

What if a hacker argues as following:

"Take for example a test on rootkits; use several programs, all pretending to prevent them; do you think this is serious to prevent their drivers from installed, to say "Hurra, the rootkit is blocked" : No ! , for this test to be a real test, you have to let the driver install, and then to see if the program is actually blocking it ."


You might argue of course that it is suspicious to let a driver install, but you are saying this only because you know beforehand it is a rootkit! Lots of legimate software do install drivers no?

 

Of course they do. However, I want my HIPS program to notify me whenever that happens so that I have the opportunity to discern whether such action is being done by a good process or a nasty process.

Further, there have been cases where legitimate software has tried to do something *legitimate* that I did NOT want done. When my HIPS advised me of the impending action, it thereby enabled me to stop the undesired action & kill the ostensibly legitimate software.

 

Well, I reply on that part only of your post, since I'm not sure I've understood your point on its first part. (all I could say is that there's no prompts in question anyway, for at least one of the programs tested - the one I tested. And maybe that I'm not sure this distinction is as clear as the one you made, because there's no need for an HIPS to be able to specifically recognize malicious software, in order to detect that a new process is running; for all "execution-control" HIPS, ie. If you disable it, install a new program, and reboot, the new program is supposed to trigger a prompt for execution).


About your view on this rootkit test, it doesn't make a lot of sense, because if you let the driver install (as you recommend to do), you have no chance to suceed in the prevention test : In this case, you bypass on a purpose the ability to prevent it, so what is being tested anyway If you install the driver, you install the rootkit. Nothing to test here.

Unless you're talking about detection, afterwards; which was the aim in the few rootkit tests made with the "HIPS disabled" in Kareldjag's methodology, indeed - see here. So your argument is valuable for detection, mine was about prevention (and let me repeat that my argument was just that prevention test was not revelant if the rootkit file wasn't allowed to run in the first place), but I do not see any flaw in it.



Something I would like to add : HIPS testing against malware has the feature to be difficult to be analyzed, interpreted. Most of the time, you have to make an assessment of the successful and failed actions, to decide which part is prevailing. This is another point making such test subjective per se.

I think I'll make some more tests in the near future, but will restrict it to spyware/trojan tests (live infections from crapware sites, etc), something less comprehensive than the methodology defined here by Kareldjag.


nicM

 

Some other questions in line with this for me would be. If so, are they needed by the average user? And if that is so. Would something along the lines of Arovax Shield or Winpatrol Free be effective enough? Also would using ProcessGuard Free for a HIPS program along with a stand alone Firewall and Antivirus be enough protection for the average user? The reason for these questions is because I do believe some sort of HIPS, or maybe IDS is needed today with a Firewall and Antivirus. Apparently so do a lot of Software Manufacturers as they are now adding HIPS to there products. Sunbelt Kerio Personal Firewall for example. I personally like individual programs then that way if I don't like one I can try a different one. As a matter of fact, I was thinking about trying CyberHawk after reading a fairly good review of it in one of the pc magazines in the book stores, although some people are claiming it's not that effective.

 

Nic,
I do understand what you're saying. There is a certain amount of risk involved when something new is being installed, which I'm assuming is the scenario you're referring to. Usres who like to install lots of "new toys" are at a higher risk that is hard to defend against. I run my primary system at the opposite end of the spectrum. It doesn't change much at all. I install almost nothing new on it, and what items I do are installed thru Inctrl5 so that every new file, folder, and registry change is documented. I also make a full system backup before each install, just in case I don't like the results.
I think we can agree that the source of this problem is 2 conflicting user "needs":
1, the user wants to be able to install new software, games, toolbars, etc whenever they want.
2, the user wants to be protected from all malicious installs.
I'm very limited in what I can test, running Win98, and not having access to an NT based unit that I can treat as a test bed. For that reason, my testing has been limited to SSM, which is ideal for how I approach PC security.
For the sake of discussion, lets assume a user wants to install some item he found online. He downloads it, clicks the installer, and is greeted by a prompt that "explorer wants to run something.exe". If he blocks it, he sees either an error message or nothing at all. If he permits it, he'll likely see another prompt about some executable in a temp folder, "something.exe wants to run gibberish.exe". If he's more security conscious than most, he might try to look it up and see exactly what is. If he's like most users, he'll figure "it's for what I'm installing" and click thru it. If the item he wants to install happens to be bundled software, he's presented with a series of these prompts with names that mean nothing to him. The security conscious user might continue checking on the items named in those prompts, and might even get lucky enough to have one of them identified with some malware he's heard of, and stop the install. It's equally likely he could click on a sponsored link and be told it's consumerware (a whitewashing term for adware used by a particular company).
If we move past the install prompts themselves, then we get to the other activity prompts. The user sees one for gibberish.exe wants to set a hook, with lanuage to the effect of:
The call to API function "SetWindowsHookEx" was successfully intercepted.
The hook type was WH_KEYBOARD (monitors keystrokes)
Now what will the average user do with this? If he Googles the quoted term, and clicks the first link, he ends up at MSDN, looking at information that means nothing to him. Most security conscious users would have given up looking up info about the prompts by now. The average user would have long ago. So what does he end up doing with the prompt? Chances are he'll end up permitting it. Windows Explorer and IE6 ask to set hooks like that. Since SSM alerts default to "this time only" regarding their normal behavior unless the user configured it differently, his first answer is likely to be either "allow this time" or "block this time". With a lot of apps, if you click "block this time", you'll get the same alert again and again. He'll either end up allowing it, or block it permanently. Most users I know would end up clicking allow, just to get rid of the alert. Was it the right choice? Depends on the application that's asking. For some applications, the hook is necessary for the app to work. Some ask for such a hook but don't seem to need it. Many keyloggers also set that very same hook.
Right now, I'll ask those who read this to choose how they would have answered that alert. Don't post your answer or anything like that, just a mental note. Would you have allowed it?
The wording of that alert was copied from an SSM alert on my PC.
The call to API function "SetWindowsHookEx" was successfully intercepted.
The hook type was WH_KEYBOARD (monitors keystrokes)
The application that requested it was Yahoo Instant Messenger, version 5.6 on my system. After I'd installed SSM and was setting it up, that's the alert I got when I launched Yahoo. What I find interesting here is that Yahoo IM works the same whether the hooks are allowed or not. I say hooks because it asks for a second hook on the mouse.
My point? There's no right answer unless the user knows what the requesting application is. If it's randomly named, he won't find info on it. If it's a gaming program, it might not function without it. If it's a keylogger, he just shot himself in the foot. SSM doesn't differentiate one from another. It's all treated the same. The same applies to drivers. Some are necessary. Some are malicious, and the names may or may not tell you anything.
Since I used Yahoo IM for the earlier example, I'll use it for another. When Yahoo IM is first launched, it wants to run regedit.exe, at least version 5.6 of Yahoo does on my system. Should regedit be a permitted child process of Ypager.exe, the name of the Yahoo executable trying to launch it? On my system, Yahoo works fine with no access to regedit.exe, so it's not truly necessary. Would the average user permit it? Yahoo isn't considered malicious in most circles, so the answer is probably yes. Now lets assume that a major exploit is found in Yahoo that allows malicious code to be executed thru it. Not a farfetched example by any means. How many times has Internet Explorer been patched for that very reason? If Yahoo was allowed to run regedit, adding unwanted entries or removing needed ones becomes simple, unless intercepted by SSMs registry module. Then again, regedit would normally have permission to modify the registry, right? I think it's clear where this example leads.
I won't try to speculate about other HIPS, virtualization, or sandboxing programs, how well they work, or whether they can really protect a user. I can only comment in regards to what I use, SSM. SSM will detect and intercept the new processes. It will alert to system hooks and driver installs. It will let you know if the signature of an executable is changed when it tries to start. If the modules are enabled, it will also watch the registry, start menu, Internet Explorer settings, and services. It won't tell you if any of the items being changed are necessary, beneficial or malicious. The user has to determine that. Integrating with an AV scanner is about as far as SSM goes when it comes to identifying malicious code. The behaviors it detects, hooks, drivers, registry changes, etc can be normal or malicious, depending on what's doing it. The only realistic way to get a better answer than "It depends on what it is" is to know what's making the changes. SSM will name the item, but can't tell you anything about it. To do that, it would have to rely on a database or connect to a server with that data. That would be going back to signature based security, which apps like SSM are trying to move away from.
SSM is only as good as its user. It's not suitable for those who don't know their systems. It's not a real good choice for "install-happy" users, unless they like answering prompts. Even with the learning mode, which handles the basic setup, it doesn't differentiate between system executables and malware. For users who can tell the difference or are willing to research it, it's a good choice. For users who have their systems set up as they want them, who don't install a lot of software, and want their system protected from changes, SSM is an excellent choice. SSM will protect a system from malicious code but it doesn't protect it from the actions of the user.
Rick

 

Hi Rick,

No problem, I agree with what you said. HIPS are only as good as the user behind it. What you describe is exactly what makes the difference between "classical" HIPS (misleading term, I know ) asking the user when changes occur, and all these sandbox solutions, which are using a clever way : To make the protection independant from the user, who is just here to set his sandbox when he installs it. You lose some control on processes activity, but the advantage is that user decisions are not involved later (or very few), the sandbox will just run everything coming through common infection vectors like threats (=sandboxed). This is up to the user to release programs or files from the sandboxed zone if he wishes so.

It makes you run malware when/if malwares are downloaded, whereas you can stop them dead with prompt-based HIPS (by preventing the malware file to run, or to perform some harmful changes on the system), but malwares are then supposed to be under control.

Two different ways, but nothing prevent people from using the two kind of programs together.


Btw, I've discovered InCtrl5 few weeks ago, excellent little program . I didn't find a lot of good free alternatives to it so far, unfortunately most of these programs are payware, and often very expensive .

Nico

 

I wouldn't mind looking into a sandboxing HIPS but I'm not aware of one that runs on 98. Not sure where I'd find the time to really work with one. The whole concept of sandboxing or virtualization concerns me. I have a hard time trusting the idea of containment and would wholly expect to see some of them defeated badly in the near future. When and if it does happen, I fear it will happen silently, with no visible indication or alert from any conventional security apps. If BIOS rootkits are in use by that time, the results would be very bad. That's not to say that I don't expect classic HIPS (wherever that term came from) to also be attacked. I'd just expect them to be harder to defeat when their underlying principle is "Unknowns don't run". Successfully attacking an app like SSM would almost have to be done via the ruleset, attacking something that's allowed and using it to kill the HIPS. That would really be as much an attack on the OS and the users setup skills as it would be against the HIPS itself.
I've recently installed SSM on a friends PC, an older Dell XP unit that was still on service pack 1 and still has all the useless bloat Dells come with. Still working on her about that part of it. It took me almost 2 years to convince her to let me secure her PC, which had been running with no AV (or anything else for that matter) for years and used cable internet. You know the kind, a botmasters dream. Ever run into one of those PCs that just draw your attention to it even when you're not using it? This was one of them for me. I could see it sitting on her desk, not being used for anything, but the hard drive light showing a lot of activity, way too much for normal system processes. When I finally managed to persuade her to let me put a free AV on it (the free part is what convinced her) and showed her that her PC was being used as a Zombie, she finally gave me the go-ahead to secure it as I saw fit. She had almost as many trojans on that thing as I had in my test collection. Normally I wouldn't consider installing SSM or Kerio 2.1.5 on a users PC unless they were knowlegable enough to work with them. She is definitely not computer savvy. Since I end up at her place several times a week helping her with other work (she's disabled) I agreed to handle the configuring in exchange for using her PC to better learn SSM on an XP system.
Some of the SSM prompts from an XP unit can really mess with a user. I'm used to SSM (on win98/ME) and some of the ones it gave me on that PC were enough to force me to look it up to see just what some of those processes were and whether they were really necessary. IMO, far too much of XP serves no useful purpose and does nothing but provide potential points of exploit. I can definitely see where a user could make some very bad rules or leave big gaps that can be exploited. Without either including a big configuration database for the different components and user software or connecting to an online database that serves the same purpose, I don't see how an app like SSM will become realistic for users like her. On the other hand, if they do use either one or both of those methods, SSM would become like so many other security suites, relying on definitions and/or reference/configuration files, and bloated because of it, or it would have to "call home" to find out what to do. IMO, making it reliant on a central database would weaken it and open up a whole new list of weaknesses, like attacking the server or database, denial of service attacks, etc, not to mention the hassle of keeping such a database up to date on a process interaction level. It would end up like Norton when it was over and have just as many problems. As powerful and effective as it is, SSM just isn't suitable for the typical user. For knowlegable users, like those that hang out at security forums, it's excellent.
Inctrl5 is a sweet little program. The closest I've found to it as freeware is InstallSpy. Does most of the same things as Inctrl5 but isn't as good when a reboot is needed. I haven't tried InstallSpy on web installs or exploits either since Inctrl5 covers them very well.
Rick

 

I haven't read the entire thread but I've read enough to see some of the same tired old comments being made. So I'll just add my penny...

People love to say that a HIPS can prevent a process from starting, so hey, that's a great way to stop malware. But this won't help in the case of some software, that you are intentionally installing, doing something you didn't realize it would--for example, software installing drivers or using hooks when you didn't expect it to. So, pointing out that HIPS can prevent a process from starting isn't very helpful... The real benefit can only mainly occur once the process is allowed to run.

I also saw conventional HIPS referred to as "Pop-ups O' Plenty". Well, if we're going to refer to those types of HIPS as "Pop-ups O' Plenty", let's be consistent and refer to sandbox HIPS as "What's really going on with my system?". Or, we can call "sandbox" HIPS by a more-appropriate name, "black box" HIPS. How's that?

Each type of HIPS has its advantages and disadvantages, benefits and shortcomings. Black box HIPS have their shortcomings, some very serious, and I hope their advocates know what those are...

 

I prefer "I don't care as long as my OS maintains integrity" over "What's really going on with my system?". In the case of DefenseWall (the only sandbox i'm well versed in) for instance, the curious can review the event log to see what is going on. I don't understand the "black-box" reference.

 

Well it is a great way of stopping malware isn't it?

I think that's true in some circumstances. If you were installing a notes programme or a word processor or a photo editor, you might be a bit concerned when it wanted to install a driver or service. You might think it was a bit strange when it wanted to read winlogon and attempted to terminate some processes.

Then again, if you were installing a FW, AV or AS then you wouldn't think the above was strange at all. So perhaps it's not useful in the second case but I'm sure it must help in the former case.

I agree with that for things you install yourself but not for things that try to install automatically.

 

Well, yes, sandbox HIPS are a little bit "black box" solutions, as and AV, for instance- I don't think you really know how it's heuristic works!

See, some people need control their computers activity- classical HIPS are for them. Others need just securely surf Internet and play it's game- they want control nothing. Sandbox HIPS are for them. Different people- different psycology-different types of HIPS.

As about subject- yes, HIPS (if they are quality written, don't miss quality of software with quality of it's PR!) are highly effective in malware prevention. AV/AS are not enough nowdays- 0-day malware part in growing from day to day.

 

The way I see it: a HIPS should be able to protect me against zero day "drive by" attacks. So if software with serious flaws gets attacked, the HIPS must be able to stop malware from getting installed and/or doing any damage. I´m sure experts could quite easily test which HIPS are capable of this.

Another way of how to use a HIPS is by running software and look for possible dangerous behavior. Most apps do not need to do dangerous stuff, so as soon as I see something funny I´d choose not to use a certain application.

Of course it´s best to first test software in a virtual machine or sandboxed environment, but the problem is that some malware is already able to detect that it´s not running on a real system and will act like it´s legitimate. So I hope this problem can be fixed, malware must be fooled by security tools, not the other way around of course.

And the discussion about all those alerts that HIPS give and that most people are not able to figure out how to respond to them is a non discussion to me, it´s quite obvious that you need to know a bit about computer security first. I mean you can also configure a HIPS to not show any alerts so it will silently block stuff, but what if grandma wants to download a certain app? It will not run of course.

But for me HIPS is effective, yes.