HIPS verses Anti-Executable

Not sure if anything like this has been discussed on Wilders before, but here we go.

I'm just wondering what people's thoughts are with regards to HIPS and Anti-Executable programs. What is the big advantage of a HIPS over an Anti-Executable? If an unknown executable is unable to even start/run, wouldn't that provide you with bullet-proof protection alone? Where would the HIPS play any additional role?

arran also made an interesting point about controlling the behaviour of trusted applications. With regards to security vulnerability, what is the advantage of doing this? If you've trusted your executable, shouldn't you allow it to run freely? Sure, that executable should NOT be able to start/run other executables - Anti-Executable programs prevent this from happening too (default-deny).

So what are people's thoughts on this? Rmus has clearly shown us that Anti-Executable programs are pretty much bullet-proof, and I'm finding this to be the case too. I've tested quite a few malware, and nothing seems to be able to bypass the default-deny of the Anti-Executable.

I guess one specific question I have is whether anything can modify your computer dangerously without using an executable process (and thus would bypass the Anti-Executable). Thanks for any thoughts.

 

With a program such as Faronics Anti-Executable, you would turn off the protection to install a program. During the installation process, other executable files - - .sys, .dll -- will install. You need to leave AE off until all of the files have installed. Once AE is turned back on, all of the executable files will be added to the White List, so that the new program will indeed be able to start/run these other executables.

For convenience, executable file types are classified into two categories:

• binary - .exe, .dll, .ocx, .sys etc
  
  
• script - .vbs, .js etc

I don't know about other Anti-Executable programs, but Faronics AE blocks only binary executable files, not scripts. Theoretically, a script file -- .vbs etc -- could do damage.

I haven't seen this method used in exploits in a long time.

By the way, these scripts refer to files executed on the hard drive or flash drive, not scripts embedded in web pages, which are controlled/interpreted by the browser.

----
rich

 

MD blocks script files from running.

 

with regards to using AE2 or a HIPS I guess it depends on if you want to control the behavior of trusted apps.

I personally need a HIPS to stop my igzones program from terminating age of conqerors. I agree its not a security issue but more of a inconvenience when this happens.

I also like to have file and folder rules to prevent programs from reading sensitive files, like Admuncher which it always tries too and I don't know what information it sends out on the internet.

 

Far more detailed alerts on what the executable is attempting to do during the installation process, and granular control for the user in what she/he wants to allow. But is this an advantage? Well, it depends entirely on what the user wants to see, the number of alerts their willing to deal with, and perhaps most importantly, their technical level of understanding of what the alerts actually mean.

He might be refering to trusted appplications like explorer.exe, rundll32.exe, cmd.exe, svchost.exe, and other Windows processes and services which often have tremendous influence on other process. Mostly the influence is not only harmless but also necessary, but malware could attempt to enlist these trusted processes as part of their viral-infesting routine.

For most people, the answer is yes. For the minority who want absolute control over everything...no. They may see something like: "Process abc.exe is attempting low level access to disk", and this could be construed as malicious, so they have, theoretically at least, a chance to kill the installation process at that point.

Absolutely they are. After all, and this has been stated many times by others in this forum, if it can't execute it can't harm.

Sorry, I don't know. I think Rmus has answered this regarding scripts?

 

with preventing scripts from running this could be a way, I haven't personally got around to testing it yet but maybe some one else can? XP antispy hardening tool.

 

also another reason to use HIPS. some programs such as google earth like to create unwanted child processors such as googleupdate.exe.

bottom line is if you are happy with your Trusted programs running Riot and doing as they please then you don't need a HIPS and Anti Executable is for you.

 

We could probably be very well defended with just 2 Apps

AntiExe App

AntiScript App


* AE Apps *

Antiexecutable - http://www.faronics.com/html/antiexec.asp

Winsonar - http://digilander.libero.it/zancart/winsonar.html

Trustnoexe - http://www.beyondlogic.org/solutions/trust-no-exe/trust-no-exe.htm


* AS Apps *


Script Defender - http://www.analogx.com/contents/down...d/Freeware.htm

-

With SD you can block all manner of scripts like VBS. etc etc. Plus you can also add in whatever you else want such as .BAT.COM etc etc

Whenever an included extension trys to launch it will instantly intervene and block it, and ask you if you want it to run or not.

I've been using it for years, and it works every time. Uses NO resources except when blocking, and then hardly any, and only until you allow/deny.

When i was on 98SE i relied on Winsonar + Script Defender to help protect me, along with properly securing IE6 + the OS. I can honestly say they NEVER ever let me down. I used to daily seek out and try to run all sorts of bad stuff, including Rootkits + Trojans etc etc. Not even one of these got through EVER. The only times they did was when i purposely disabled the Apps to see what would actually happen. And one other time when i allowed a new to me App install without first scanning etc it.

So based on my personal experiences with those two Apps, i'd say the're a pretty rock solid combination together. I'm seriously thinking about going back to this setup, with just a Firewall too.

-

ssj100

If you go to the SD www you can download a test .VBS script to run. It already comes included with the SD App.

 

HIPS
What I like about HIPS , is that I can alert me if a program trusted by me is installing a driver file.
If I didn't expect a driver file , *.sys file , then that's a possible malware.

AE
AE's do not block malicious scripts , but then they aren't meant to.
If you look at attack vectors , & malware in the wild ..
1)
USB attack vector -> I never heard of it.
Expect its not used much these days.
2)
Browser attack vector -> Yes.
2.1)
However browser's are designed to run scripts and not to access a local system. Its only when a browser is exploited that scripting is a problem in terms of accessing a local system.
2.2)
Malware in the wild tends to have exe's associated with them even if the attack is partially script based.

The main reason I like AE is the "feeling secure" , bring security back to risk and emotions.I can understand it 100%.
Its a whitelist of the exe and dll's on my system.

When I read about this exploit and that proof of concept... I find that it needed a exe on my system at some point, and then its no longer an issue.

 

​

I've had Script Sentry running in the background since mmm crikey 2003 or something ... it has never flagged me once in all that time to say something is wrong. Just flags when I click on a reg key to warn me. Interestingly OA hips doesn't flag for when a reg file is added.

AppGuard is much along the same lines as Faronics anti exe? I was watching the review for it from remove-malware.com on youtube. Seems quite an interesting app.

 

Sure, but it isn't just 92 year old grandmas who prefer simplicity

IMO, it is easy enough to "tune" a HIPS to behave with the simplicity of a AE, or set it up to alert on absolutely anything and everything it's capable of detecting, if this latter "paranoid" approach is desired. So, if cost is similar to an AE and the user has the ability to figure out the HIPS, I'd say the HIPS is the best approach, since it affords some additional options the AE might not contain.

 

There is also the option of using the app called "Process Guard"

 

I'm not 100% sure on that.
Senario is :
AE is turned off.
I trust the application I'm installing.
But it might have been corrupted by malware, bad download site or my mistake to trust it !.
So Its a unexpected driver in a program that I'm installing.

Can be tested in sandboxie , which is what I use.

 

But most HIPS have a "Learning mode" or "Install mode" to make this update process very easy, especially if the user mitigates the alert activity by fine-tuning it to alert only on new executables attempting to launch.

 

I think you can configure Script Defender to block any files you want.

 

Yeah it gives a double warning also, which is quite handy if you accidently execute a reg file. There is a customizing function where you can add further extensions for it to monitor but I haven't really looked into this - it's really one of those apps you forget you even have running.

 

Please search the forums for discussions of Script blockers such as Script Sentry and Script Defender for inherent weaknesses against certain types of exploits.

Regarding these script exploits, it might be well to consider how they work. We are not talking here about browser scripts, rather, script files such as .vbs.

First, they have to get onto your hard drive somehow. The initial question that should come to mind is, How would a malicious .vbs or other script file get downloaded onto my hard drive in the first place, and why would I click to execute it?

1) There is the classic example of the Love.vbs worm which arrived as an email attachment.

Ask yourself: Are my policies and procedures regarding email and attachments secure and robust so that I would not execute such a file in the first place?

2) Remote Code Execution: Autorun.inf file on a USB drive

Ask yourself: Are my policies and procedures regarding USB secure and robust so that such a file could not execute? Specifically,

• do I avoid the use of U3 smartdrives (flash drive)?
  
  
• do I avoid letting someone else's USB drive connect to my computer?

3) Remote Code Execution: Macros in MSOffice Documents

Ask yourself: Is macro protection enabled in MS Office applications? Under what circumstances would I open someone else's Office document?

You may think of other scenarios that could trigger a script exploit. But if you cover these bases with secure policies and procedures, it may turn out that you don't need any added security product for protection.

----
rich

 

Whats the problem with U3 smart drives? And isnt disabling autorun.inf enough to deal with usb related threats? Thanks.

 

Wow, SD is so powerful it provides protection even AFTER its been uninstalled!

 

Its funny you should say that, cos I have been looking at a post you contributed to back in 2008 on here and seems like Script Sentry failed. I will go have another look through.

 

You can configure your HIPS to act like a no pop-ups default-deny. And as arran pointed out, I like the HIPS finetuning controls of the behaviours of your trusted applications.

Here is the analogy of Anti-executable versus HIPS:
Just like you can configure your browser to block all javascripts globally or on per-site basis like what NOScript gives, this set-up is akin or parallels what Anti-executable does, but I prefer the finetuning controls of a local proxy/webfilter like Proxomitron, as I can allow friendly javascripts, and disallow evil and nasty as well as those nosey javascripts and the latter is like HIPS in the finer controls that it provides.

 

Did you Remove Incercepts before uninstalling?

Only U3-type flash drives will execute an Autorun.inf file. If you don't use such a drive, even if infected from another's computer, the autorun.inf file will not execute and you will see it plus some malware when you view the contents of the drive.

These script blockers work by modifying the Shell/Open/Command value of the file type in the Registry, to point to the blocking program instead of the script engine. This means that the blocking program controls the Windows File Association for that file type, so that when you d-click on the file, the blocking program intercepts the call.

This is fine for victims who click on malicious files, but will not prevent the command prompt or the script engine being called directly in an autorun.inf file from executing the malicious script file. Hence, the uselessness of such programs to protect against the trickiest types of script exploits - those by remote code execution. Anyway, if you've got firm polices for USB, even this is a No-Threat and you don't need a separate program.

I've got screen shots in past threads discussing these programs.

Not if the autorun.inf file launches a script file type rather than a binary file type.

EDIT: it would depend on what the particular anti-executable program covers. Faronics AE does not cover scripts except .bat in version 3.


----
rich

 

I found the discussion.

https://www.wilderssecurity.com/showthread.php?t=203483&highlight=script+sentry

 

* Script Defender *

Whatever you include when you CHOOSE to click Install Intercepts whilst you have SD installed, must be returned to their original state if you uninstall it. It's simply done by launching SD and just clicking on Remove Intercepts



This is something that obviously has been overlooked by some of the responses so far.

-

You can also make your OS much more secure by locking it down further, as i have been ding since 98SE days. There is an extra Zone that can be enabled in IE Options, but it's not for the browser, as the other Zones are. It's identical to the Internet one, but for your computer, actually called My Computer

You can disable and/or set to prompt all sorts of potentially vunerable vectors such as - ActiveX, Scripting, Java, Iframes etc etc just like you can for IE. This works even if you don't use IE. It doesn't take long to do, and all for free too ! Here's how



How to Enable the My Computer Security Zone in Internet Options - http://support.microsoft.com/kb/315933

 

Yes. Hopfully, knowledgeable people would not permit that to happen, and would help others set up secure policies and procedures regarding USB.

It has prevented all of the exploits and tests I've run with it disabled.

----
rich