Classical HIPS also poor against zero day exploits

An interesting thought came in my mind. I will use CIS HIPS as an example.

The strongest component of CIS is Defence Plus that is supposed to mitigate new malware, exploits etc etc.

I have noted a very interesting thing yesterday. Since release of CIS v 5 three windows exploits were discovered. Sadly Comodo defence plus is helpless against all these exploits.

1- .lnk explot
2- dll execution exploit
3- zero day UAC byapss exploit

Some HIPS with custom/ specific settings/ rules can intercept .lnk exploit and dll execution exploit but these settings are practically useless and a nightmare in day to day use of your PC.

Very interestingly a sandbox like sandboxie and geswall will protect against all these exploits by design( I said by design as latest geswall version has some bugs that make it impractical against .lnk explot).

Pls post your thoughts. Thanks

 

You're right Aigle. In general. classical HIPS have been pretty poor versus these zero days, whereas sandboxes and policy based HIPS have proven more successful. But it probably just reflects the nature of the solutions - classical HIPS have to work with what's built into the o/s (they are dumb and just report what they see) whereas sandboxes and policy based HIPS can enforce their own stricter rules. So to me, it's sort of understandable.

 

Does anyone know if ProcessGuard will stop the above 3 zero day exploits? ProcessGuard works differently than most HIPS. It works like a deny by default policy. It works almost like an AE.

 

Fascinating post!

Does anyone know whether Appguard protects against such exploits?

 

Process Guard performs pretty much the same as all the other classical HIPS. On the LNK vulnerability it failed, as did all the other classical HIPS. Same sort of story with the dll exploit. Sandbox/policy HIPS/Virtualisation type apps did much better and generally were a pass with both of these. The UAC bypass is a bit different in that it needs a payload to deliver it, so if the payload is in the form of an executable any decent HIPS should block the initial execution.

 

Appguard failed in the testing I saw. However, it has had a significant makeover and a new version is due soon, so it could be a much stronger solution to these sort of things now. It's surprising because I would have expected Appguard to perform in a similar way to a policy based HIPS and block these much more effectively.

 

I do believe the new version of Appguard will protect against these type of attacks, but we will have to wait until it is released for testing. It is my understanding the ability to block .dll, and .bat items has been added as well as the addition of memoryguard. I will post this question over at the beta thread concerning what extentions have been added as protected.

 

Time to drop CIS. Windows FW is fast and for someone like you easy to setup. You could apply Safe-Admin UAC hardening (only elevate signed programs) and 1806 download tweak in combo with Chrome.

With CTM and GeSWall you put enough muscle in the defense.

 

1- .lnk exploit

The link exploit is essentially a clever means to trigger something to launch. It does not in and of itself deliver a payload.

AppGuard contains the exploit. The exploit still would cause the affected Windows component to alter registry keys in the manner documented because AppGuard would NOT restrict that Windows component. And, AppGuard would NOT prevent the "trigger" of the exploit when someone mouses over just such a short-cut in Windows Explorer.

So, on containment, AppGuard prevents a guarded application from placing a malicious LNK file into system space. It either suppresses an executable or script launch from user-space, or it automatically guards the executable allowed to launch in user-space per policy (i.e., the new "Medium" setting, which I believe was the default setting in beta3 but not called "Medium").

2- dll execution exploit

AppGuard assumes that applications created by people and exposed to stuff from the Internet or elsewhere will eventually be compromised. Thus, its eponymous name (hope I spelled that correctly) AppGuard. So, rather than worry about what DLLs are run within the context of one of the applications, by guarding the application, we prevent the DLL from doing harm. And as some of you may known, "Privacy Mode" can further restrict that compromised application from accessing documents in designated folders. Further, MemoryGuard can prevent it from injecting code or writing into the memory of another process. And there's something else that we may throw into the December release if we get the approval from upper management next week. This approach is not perfect. However, its simplicity yields practicality and is quite effective per the vast majority of relevant vectors. If folk here believe there are major gaps remaining, in this context, please let me know. I've asked our engineers to brief me and upper management on additional attack vectors that we might consider pursuing in 2011. So, what you raise here, may be raised there.

3- zero day UAC byapss exploit

I'd appreciate some clarification on this one.


Well, thanks for the question. I hope my hasty answer is clear.

Cheers,

Eirik

 

Thanks for the answer Erik! After reading your post it sound like a good HIPS could block possible workarounds that the above 3 attacks pose to Appguard. That is if the above 3 attacks can bypass the upcoming release of Appguard at all.

 

Check f.i. --http://68.233.235.195/kmax/security-uac.aspx.htm-- and --http://web17.webbpro.de/index.php?page=advanced-analysis-of-the-2010-11-24-local-windows-kernel-exploit--.

 

Baserk, you may have to PM Erik to let him know you posted a question for him here. He usually only checks Appguard threads. He posted in this thread because i asked him to. He may not see your question.

 

tested the POC (zero day UAC byapss exploit) on real machine (W7 64 bit). Comodo sucessfully blocked it....

Proactive Config set + Sandbox set to Untrusted + Disabled FileSystem & Registry Virtualization.

Above config is the one i use it daily.


Thanks,
Harsha.

 

But in CIS' default config the POC is not blocked. It bypasses CIS.

 

Yes. Its only bypassed at default settings..

Lets see if there will be anyimprovements on Default Protection level in v5.1
It would be nice to see how other classical HIPS stands - OA,Malware Defender

Thanks,
Harsha.

 

Thanks for the clarification. I cannot look at this until later. I may need to grab an engineer to look. Sorry for the slow response, I'm swamped!

 

Interesting use of the word "only" in that statement!

 

what about bufferzone pro against zero day exploits

 

Aigle,

I think you made a clear point. With current OS-ses having a Admin/LUA boundery warning (UAC) and internet (IE and Chrome) and service programs (acrobat X) moving to low rights (so they can't touch user = medium rights processes), the added value of classical HIPS are deminishing.

Host intrusion is based on a user (the owner of the PC) defined policy (who is allowed what). Since the OS allready has got this protection mechanism it pays off to add a completely different defense layer, like virtualisation or total isolation of vulnarable processes.

That is why I think in practise your current setup with CTM + CIS5 + GW will be as strong as CTM + GW on your windows7 PC.

With GW you put an extra prevent-intrusion layer around the threatgates. With CRM you have an extra post-infection layer around the your OS-partition.

 

Bufferzone doesn't prevent. If all goes well the exploits will run in BZ contained environment.

 

You can make sure something installs inside by:

https://www.wilderssecurity.com/showpost.php?p=1792526&postcount=35

https://www.wilderssecurity.com/showpost.php?p=1792527&postcount=36

https://www.wilderssecurity.com/showpost.php?p=1792528&postcount=37