Silent HIPS of the future!

why is it impossible. Download a program that doesnt require a reboot, install it and choose to sandbox it on install. The drivers installed are then run in the sandbox.

 

sandboxie block all driver load.
sandbox will be bypassed or destroied if allow driver load.

 

Really? This is news for me, AFAIK you can configure SBIE to let tools install drivers, but it won´t be in the sandbox, it will be outside, meaning that if it´s malicious, it´s basically game over, and your infected with a rootkit.

Now that I think of it, with the latest SBIE versions, sandboxed tools can load global hooks, but what if a malicious process, which isn´t supposed to have network access, attacks another sandboxed process? Then it can still bypass the firewall, not? And besides, a lot of tools won´t even function correctly if they are allowed to only modify other sandboxed processes, that´s what I meant, you can´t sandbox every behavior.

Perhaps a silly question, but what I meant was, that if a certain tool gets exploited by a BO, in most cases, the bad guys are going to want to load an executable, correct? I wonder if this can be stopped by simple process execution monitoring. Or isn´t it always neccesary to load some other process into memory? This is a bit OT, sorry about that.

OK, then it must be me, but AFAIK you first have to configure it quite precisely to reduce popups even from trusted processes, and when installing tools it´s not exactly quite. But I agree about Comodo, it´s totally out of control with the ridiculously nagging/useless alerts.

 

My answer is: totally silent will never be possible, it´s not realistic. Basically you´re dreaming of a HIPS that can spot EVERY malicious tool out there, aren´t you basically talking about perfect heuristics? And I really doubt that you are ever going to see more quite tools than TF.

Btw, you (and others) also need to see the difference between sandboxes and HIPS. Of course sandboxes are almost totally silent because that´s what they are made for, but they won´t protect you against things happening outside of the sandbox. And you know what I don´t like about sandboxes based on virtualization? It´s the fact that they won´t do anything to stop an infection inside the sandbox, I´d rather don´t get infected at all.

No browser should have "low level keyboard access", just block it.

Block changes to the hostfile?

Block task creation, or just disable the Task Scheduler?

 

defensewall is not a sandbox based on virtualization like sandboxie, it is based on policy restrictions.
yes, you are right. "they won´t protect you against things happening outside of the sandbox." defensewall is base on the idea of "'threat gateways". "threat gateways" include "Applications and processes which interact with the internet" and removeable source. malicious software have no possible to infect your system if "threat gateways" is protected by defensewall. defensewall prevents untrusted processes from modifying the executables, inter-process communications, multimedia, documents, phone databases (target for 'dialer' malware), Hosts files, adding or modifying autostart areas (both registry and file system), adding or modifying drivers/services (targeted by 'rootkits'), modifying the desktop and browser settings, plugins and extensions (IE, Firefox, Mozilla, Opera, Flock, etc.), setting global hooks (usually used by 'key loggers'), injecting their code into Trusted Processes, stealing screenshots and many other dangers.

 

Yes, I prefer sandboxes based only on policy restrictions, I don´t believe that virtualization is necessary, it will only slow things down, at least at the moment. Btw, some classical HIPS (like SSM, NG and CPF) also offer "sandboxing", the only difference is that you will have to make the rules yourself.

LOL that was quite a sum up, wasn´t it?

 

I agree . The different between defensewall and classical HIPS is Ilya has already Complete the rules setup for you.

and I like the 'attribute inheritance' and rollback of defenswall. Classical hips has no this function.

 

Can you tell a bit more about this? Is the rollback function similar to how you can clean the sandbox in, for example, Sandboxie? And yes, classical HIPS don´t have this function, but as long protected processes are not exploited, they don´t have to, not? I´m starting to get a bit confused. Of course, ThreatFire does have a rollback feature, but that covers non-sandboxed processes.

 

'attribute inheritance' ---all potentially dangerous files which are created by Untrusted Processes will be marked as 'Untrusted'. Any process launched by an untrusted process will be Untrusted as well.

The Rollback function allows you to manually cleanup the debris left behind on your hard drive by malware after an infection attempt. The Rollback List contains executable modules created by Untrusted processes.

 

Be as objectively speaking as warrants this subject but for all to get a better grip on the best possible confidence to be realized, isn't it more favorable to combine say a SandboxIE with a classical HIPS combination, or do you feel SandboxIE alone is quite to the task of preventing intrusion even though it's contained in a protected state for dismissal/delete after session reboot or just emptying the contents of the collectables in that sandbox?

Personally, i feel a HIPS can ward off entry ahead of the curve and then anything else of mischief is not able to fully make use of it's designed disruptions on a windows O/S.

Thank You

 

Actually, I stand corrected. Sandboxie can isolate services. The release notes never mentioned drivers IIRC.

How on earth is network access going to be detrimental to your system security?

Network access to steal personal info is dangerous, but fretting about network access itself alone is utterly pointless if the requesting application is sandboxed. Different sandboxes provide different ways to deal with the former; for example, here's Sandboxie's take on it: http://www.sandboxie.com/index.php?DetectingKeyLoggers

Nope, that requires a VM. But they do their job well enough, and with far less intrusiveness than a "dumb" HIPS, which makes them superior for everyday use.

Nope, not always necessary. BO exploits can be triggered by data files, such as scripts.

 

Right now Unfortunately, I don't know when I'll be able top upload updater's definitions- have some problems with my hosting provider.

 

Hi All

I was somewhat surprised about Ilya's comment:

"Key strokes encription is a "snake oil", unfortunately- just remember about "TranslateMessage" keylogging technique. If any app may get a keys input- there is always a chance malware can intercept it."

It seems to imply that KeyScrambler has no value ie the use of the term "Snake Oil". This is a surprising comment from a developer of perhaps a competing product.

I would ask Ilya these questions?

1) Is his own product completely fool proof, and has there ever been flaws identified? Indeed is there any foolproof security product?

2) Does Ilya really mean "Snake oil" which has connotations of something without value masquerading as something of great value ie KeyScrambler?

I use KeyScrambler because like many other novices I try to keep up with security issues as best I can. Indeed I welcome well founded commentary, particularly so from someone of Ilya's distinction. But I must confess to some uneasiness to his terminology about KeyScrambler. (In relation to his position as a competitor developer)

On the other hand if KeyScrambler is worthless "Snake Oil" I really would like to know?

Over to you Ilya ........


Terry
__________________

 

Hi!

Well, maybe, "snake oil" is not a 100% correct term, I just didn't find a proper definition. Yes, this will protect you from some kind of threats like AKLT implemented methods, but... Just lets take a loot at following:
1. Does key encryption protects from TranslateMessage/GetMessage keyloggers?
2. Does it protects from direct form grabbing?
3. Does it protects from direct memory data grabbing?

The answer is "no" as key encryption method is incomplete in its initial core- basic ideology. If an application can get your key input- malware, infiltrated into this app, can do that too.

Yes, maybe I'm a hard maximalist by my own nature and, thus, thinks that "some protection" means "no protection at all" and, this way, KS and ZA ForceField keyscrambling protection methods are the "snake oil" for me.

P.S. I don't think KS as a competitive product. Anyway, even if it would be a competitive product, I would never say any bad words about it with no evidence. Do you remember my history with BZ? And I never mentioned KS by myself...

 

Ilya

Thanks for your reply I am sure others will find it as interesting as I did.

Given your clarification, could I turn the questions around so that I can use your experience (and willingness to give very direct comment) to advantage as follows:

Rather than state what is not so good about the various types of AntiKeylogger software/techniques:

1) What would be an ideal combination of software that in your professional opinion is better able to deal with defeating keyloggers (including those methods methods mentioned in your reply)? So in simple terms if KeyScrambler falls short what should we novices replace it with. Before you answer this you might just reflect that you did not reply to the question about your own product in my previous post.

2) If your answer to this is simply "DefenseWall" can we really be sure that it is infallible?

Regards

Terry

 

Hi!

To be protected from keylogging, it is need to:
1. Terminate all the external-methods-based (AKLT-like) keyloggers or encrypt keystrokes.
2. Make sure there is no malicious drivers at all (don't forget about driver-based keylogging).
3. Run the clean instance of the browser (i.e., there should be no malicious add-ons, extensions, BHO's and so on).

We are talking here about the protection methodology, not about the concrete realization of it, so "DefenseWall" is not an answer here

 

Hi, my name is Qian Wang and I'm from QFX Software, the maker of KeyScrambler. Since KeyScrambler came up in the discussion and Ilya offered a general critique of keystroke encryption technology, I feel that I should respond and clarify some of the issues he raised.

First of all, I freely admit that keystroke encryption is not perfect in its current incarnation. There are definitely attacks that it does not yet protect against. One example that Ilya brought up is form stealing. It affects IE more than Firefox, Opera and Safari, but it is a threat. However, form stealing is an intrusive activity that is fairly easily detected by the majority of virus/malware scanners. Which is why we say KeyScrambler provides an additional layer of protection and we're not telling our users to get rid of their anti-virus programs. I think forcing malware into more easily detected vectors has value in itself, but we are also working on solutions to these kinds of problems, because they are not fundamentally unsolvable. Remember, keystroke encryption is still relatively new, whereas IPS technology, for example, has been around for decades.

The second point I want to make is that keystroke encryption isn't limited to browser forms. KeyScrambler protects more than just information you type into web pages. KeyScrambler Pro, for example, protects master passwords in IE and Firefox. The master passwords are not vulnerable to form stealing, but they are vulnerable to keylogging. KeyScrambler Premium protects MS Office applications, including Outlook. We are already taking KeyScrambler beyond the browser to many more applications and the list will soon increase greatly. We should not confuse browser specific vulnerabilities with shortcomings of keystroke encryption technology.

Finally, not all keystroke encryption programs work the same way. We have put a lot of thought into the design of KeyScrambler and if Ilya had tested it himself, he would see that it does indeed protect against TranslateMessage/GetMessage keyloggers, because our decryption actually happens after that level of message processing.

I think when we look at a new security technology, it's easy to confuse early implementation shortcomings with fundamental technological flaws. It's also hard for those who aren't intimately familiar with the technology to see its full potential. I think that right now, KeyScrambler provides a useful level of protection, but in the coming months, some of the things we're working on will truly show the power of the technology. Stay tuned.

If you've read this far, thank you. Thanks also to Terry for letting me know of this thread. Thanks to Ilya for starting the discussion. And by the way, Ilya, the browser hang that occurred with DefenseWall and KeyScrambler is now fixed in KeyScrambler 1.3.3.

Best,

Qian

 

And many thanks to you also qzwang for taking the time to weigh in on this subject yourself.

Some really useful and helpful information in this brief but concise response.

A HEARTY WELCOME TO WILDER'S SECURITY FORUM

 

Hi Qian!

Yes, I know- I have been notified about it. Thanks! Hope, that my little criticism will help you to bring up more powerful protection for your users.

 

Thank you EASTER. Glad you found the info useful.

 

Obviously, silent non-signature security software is the way to go. In the not too distant future, the scanning engines will be a secundary part in your "average" Norton/McAfee/Trend suite. Behav. blockers and policy-based sandboxes are a sample of what is to come.
A smart, well-behaved HIPS will be the core of NIS 2010/2011, complemented by an enhaced scanning engine (better emulation and sandbox analysis to thwart anti-emulation tricks), big whitelists, sensible integrity checking and a quiet firewall with exploit signatures/engine in its IDS (like Link Scanner).
IMO, the big challenge will be implementing protection against social engineering.

 

Thanks Ilya, I have updated DefenseWall to version 2.10 today! Thanks for fixing the cpu usage issues I mentioned earlier. Now DefenseWall is better than ever, keep up the good work and merry russian christmas!

Thanks for your detailed reply! It is very good to see a developer who is so open and interested in questions and discussions relating to their software! Good luck!

 

Thanks, but I don't celebrate _any_ christmas as I'm jew.

 

Although the Solemn rememberance celebration is now past, we trust your family was joined together for the Hanukkah!

Festival of Lights,

 

@ jp10558, I know exactly what you mean. With classical HIPS you can control all processes (trusted/untrusted) quite precisely, so if you need complete control, TF won´t help.

Let´s say some app installs a malicious BHO into your browser, then you´re still infected. But SBIE´s solution is to clean your sandbox when you´re about to browse, or just make separate sandboxes.

I don´t see how they are superior. AFAIK there is a difference between sandboxes and HIPS. Sandboxes will not warn you about stuff going on outside the sandbox. Of course, sandboxes block a lot of stuff automaticly (stuff that could compromise the real system) and virtualize or track file/registry modifications, but I can also tell my dumb HIPS to sandbox certain apps, and it won´t make a sound.

I´m not sure if you understood me correctly. My question is, what happens when a BO occurs? Will a malicious process be loaded, or can they directly modify for example the registry, or do any damage?