Introducing EdgeGuard Solo Beta (zero-day malware defense)

2) thanks for the info.
3) I agree with the current implementetion; HKCU is not a critical area. For the moment the only other user security issues that comes in my mind is the schedules and the startup folder.
4) Exactly. It will provide some protection against malware that encrypts
files txt, doc, etc. or against worms that delete files like mp3,etc.
5)

Panagiotis

 

This is looking good guys. Three features I 'd like to see implemented are:

1) A right click Explorer option to run a program under Solo and/or add the program to the application list.
2) Run all programs from a set location as protected (eg. Downloads folder)
2) Set folders to be excluded from protection.

 

Considering IE7 in Vista, is this any better or worse than running IE7 with UAC/Protected Mode turned on?

 

looking nice this software , but according to the way u make it works "EdgeGuard Solo employs kernel and application level techniques to regulate file system and registry resource access" its hard to think what malware may pass it or not... for hips all deny till u aprove...to sig based software goes if it added to blacklist it will alert otherwise , u get infected.

what based twekas u add to it , its hard 2 know...

anyway if u can add at least some indicator thats show thats protection works for add software

cheers

 

When UAC is on, EdgeGuard Solo will still protect HKCU Run and RunOnce keys.

Also, as presented in the last BlackHat2008, when IE7 plug-in is implemented in compatible mode (there many including some well-known products), IE7 no longer runs in protected mode, even UAC is enabled. In such case, EdgeGuard Solo still guards IE7. This feature will be enabled in the next release.

Regards

 

Hi Pete,

could you run the same samples from the system or the programs directories?
- When you run the test with IE it failed to protect the system? This is a serious bug since it means that fails with a drive by download attack.

thanks,
Panagiotis

 

1) Good suggestion. We will consider this for our development.

2) Thanks for the suggestion. Our approach has been keep the UI very straightforward and make it set-and-forget type of protection. We will certainly consider your suggestion.


"Set folders to be excluded from protection": This is very tricky one since EdgeGuard Solo protects all directories but the user directory. One risk of opening say system32 could jeopardize the applications. Do you have an example case?

Regards

 

The above could help for programs that use ini files in their directory to store the settings and or for exluding a directory that resides in C:\Documents and Settings\All Users\Application Data\.
Another example is the subdirectories of C:\WINDOWS\system32\spool\ it could help in resolving problems with pdf printers.

Panagiotis

 

What prompted my suggestion was updating plugins in the Sleipnir browser, but I now realize that you can disable protection immediately instead of closing the program, disabling Solo and restarting so this is not such a problem after all. However, there are many programs that write to areas outside the user directory, so there may be a need for this feature in the future.

 

Wouldn't install on the real system.UAC off and Admin account.

Installed into a Vista VM and when FF is protected it won't run sandboxed.

 

Looks like it couldn't write the Start menu entries.

 

Would you please clarify what you mean by 'On Demand software'? I don't understand what this means in this context. I've asked one of the engineers to look at the rest of your post.

 

You'll need a team of engineers to figure out his posts. And possibly a linguist and a neurologist as well.

 

Guess I picked a bad time to stop sniffing modeling glue!

 

Thanks

 

Eirik,

Suggestion:

Unless, I am missing something here, but based on your description of the how the product works (and without trying it yet) .................

1) It would be better (IMHO), to guard all user applications\in user application directories, by default, rather than having to specifically include them one by one. Then allow one to easily exclude specific user applications (executables) by user application directories, should an exception be needed. Why not protect all user applications by default (perhaps have an install option that goes thru the start menu, all pgms lists and guards all of the user applications found in the start menu, pgms list, by default ?

2) Also, how about prompting when any unknown "user directory" residing user application executable is about to start executing that is not on the guard list, providing perhaps the option choices of "blocking its execution out right" and "placing in on the Guard List and allow it to execute".


Questions:

Does EdgeGuard Solo:

3) Does it protect against Drive by Downloads, when using Internet Explorer browser ??

4) Does it detect and protect aganist "dll injections" and "code injections" ??

5) Does it prevent writing to the HOSTS File ?

6) Does it prevent unapproved "outbound" communications or is a software firewall needed with it to prevent unapproved outbound communications by user applications or malware applications located in "user directories" ?

 

Thanks for the suggestions and questions Joseph.

We are seeking such ease of use improvements. Some executables should not be guarded. So, the approach must be smart enough to make the distinction.

We need to strike a balance between protecting the host from ‘drive-by downloads’ and confusing end-users with prompts to unsophisticated users regarding unfamiliar executables. Another idea along these lines is to have the tray icon indicate such an executable has been blocked. There would be within the agent GUI a window listing recently blocked executable launches from user-space. If a block had disrupted something the user was doing intentionally, such as running GotoMeeting, he/she could uncheck that item in this listing (temporarily or permanently). Ideally, this user-space launch approval would be supplemented with a hash to reduce odds of a spoof.

Not fully. We need to outright suppress such executables from launching. Presently, EdgeGuard Solo prevents such executables from persistently infesting the host. But, such executables could facilitate information disclosures or injection attacks into a targeted applications memory. We can already suppress these launches with EdgeGuard (as in enterprise, centrally managed) where use-cases are less diverse, but for self-managed agents, we need to strike that balance I mentioned. We will do this with ‘ease of use’ in mind.

No. We’ve made a trade-off favoring usability. Suffice it to say, this tends to demand great familiarity with not only the idiosyncrasies of individual applications but also the interactions among them. Ultimately, regulating these interactions complicates (false positives, etc.) the user experience. Never say never, but, our goal is to build an anti-malware solution that stops most attacks with little to no effort or confusion to the end-user.

Would you please elaborate on “HOSTS File”?

No. As we flesh out the rest of our framework, however, we will be able to do so. There’s some cool stuff ahead in this regard.

Cheers,

Eirik

 

Eirik,

I meant the HOSTS file used by Internet Explorer which is located in the system32/drivers/etc directory which a malware app could write an entry to redirect a common url address that you go to and point it to a differnt ip address.


... Two additional questions"

1. Does it prevent a guarded user application from performing a destructive low-level writing/formatting of the hard drive ?

2. Is there an option to specify which applications are allowed to write and delete files in a specific user directory, effectively making a user directory write and delete protected, from all other applications ? The purpose of this protection would be to safeguard your documents housed in a specific user doucument directory. Also, the "My Doucuments" folder should have this type of protection.
.... If not, this would be an important feature (File/Folder protection) to add.

 

EdgeGuard Solo would block any attempt by a guarded application, such as Internet Explorer, or any spawned executable by it, from writing to the HOSTS file.

I need to ask one of the engineers to provide an accurate/precise answer.

We have several approaches under consideration. Both write and read operations to user-space have risks that must be mitigated. If we fail to make the solution convenient for novice users, history suggests they may disable the feature. We must implement it accordingly.

 

I was disappointed in the products' lack of effectiveness in blocking Keyloggers. A large number of new malware are being written as vehicles for the installation and camouflage of Keyloggers on the victims computer and are frequently updated to avid detection by Clasical AV's (eg SilentBanker).

Personally I feel that if a supplementary Security application doesn't address the very thing that malware writers concentrate on, that program really has little real world usefulness.

 

We will implement a capability to block user-space executables (i.e., drive-by downloads). This will prevent new keylogger applications from running but it would not detect/block those already present.

As we continue to study approaches to address other risks such as with installed keyloggers, we will refrain from implementing them until we can do so in a manner that keeps the end-user experience simple: free of false positives and no knowledge-dependent security decisions by end-users.