Why not just AppGuard?

Thanks, I'm not sure both are needed but will give it a go too. Afterall both are ridiculously light and as mentioned earlier PFW (or other fw/HIPS like Comodo for Pegr) will give another layer that looks at system space and network traffic too for fear AppGuard misses something. Nobody has mentioned how that might happen yet though I note .

 

Apart from software installs, the main way I could see this happening would be if an unguarded application in System-Space happened to load a data file that contained malicious executable code.

AppGuard protection of System-Space depends on the list of guarded applications. Apart from a few applications that are automatically added to the list when AppGuard is first installed, System-Space applications are not guarded by default. It is up to the user to identify all relevant applications that need guarding and ensure they are added to the list. Failure to do this could leave the system vulnerable.

 

The same applies for Sandboxie etc. It is up to the user to protect the right apps I suppose. With AppGuard though launches from user space are prevented so exploitation of an unguarded apps is less likely I would think unless you routinely give unsafe apps admin privileges. Even then the exploit or data file you mention is likely to run in user space, no? It is the same with HIPS though surely where user error can lead to problems, AppGuard has no user intervention really so less oportunity for error. Browsers, e-mail and USB in my experience are guarded by default and are the big risk areas I would think (?).

Alternative views welcome.

 

Unguarded applications in System-Space can write executables to System-Space, which can in turn be launched so it would all depend on what the exploit had been designed to do. I'm not saying it's likely to happen - only suggesting a possible way that AppGuard could be breached in response to your question as to how it might happen that AppGuard misses something.

It is true that, once set up, AppGuard needs no ongoing user intervention to be effective. Silent blocking with no user intervention is definitely one of AppGuard's strong points. AppGuard does require some initial configuration and customization by the user though in order for it work properly and to get the best out of it.

Agreed. These are the main risk areas but any application that can load data files which may contain malicious executable code - document viewers, media players, etc - should also be guarded, and this will not always happen by default.

 

very true

 

Agreed but I had thought that as I'm on Win 7, apps - even from system space, run with medium rights unless you approve elevation via UAC so generally you need to allow access to write to system space (malicious silent elevation aside). I guess I'm not convinced the initial trigger for safe unguarded apps to act maliciously would not come from user space in the first place.

Having said that I had asked for potential gaps which you have highlighted very eloquently so I'm very grateful for that and I am looking at some (light) way to plug that potential (if not likely) threat.

Thanks again

 

I think you're right regarding Windows 7 but I'm still on Windows XP, which isn't as secure. Some of the points I raised were more of theoretical interest than of practical concern though. The security model behind AppGuard seems very well thought out so I would be surprised if anything nasty were able to bypass its defenses in practice.

 

Is Explore.exe a guarded application?

What about msiexec.exe?

Thanks,

-rich

 

No. By default only Windows OS items guarded are:

Microsoft Register Server
Windows Command Processor
Windows host process (Rundll32)

 

I ask because .msi files (Microsoft Installer) files can be malicious, and if system executables Explorer.exe and/or msiexec.exe are not guarded, I wonder how AppGuard would deal with these files if malicious.

Some references:

1) clamscan - scan files and directories for viruses
clamd.conf(5) - Linux man page:
clamd.conf - Configuration file for Clam AntiVirus Daemon
http://linux.die.net/man/5/clamd.conf

2) From a Microsoft technet blog earlier this year:

http://blogs.technet.com/b/fdcc/arc...valent-to-granting-administrative-rights.aspx

One concern I had about AppGuard when released is (if I understand correctly) that it seems to be the responsibility of the user to configure what applications to guard, which could be a real burden for most users:

Whereas an approach (such as Anti-Executable v. 2) that watches for (guards) all unauthorized file types by default, doesn't care what a program does, as long as the file it attempts to execute is authorized (white listed):



My questions are,

1) If this .msi file attemped to launch from user space, even though by a system executable, would AppGuard block?

2) If not, you can argue that you can set up the OS to prevent malware writing to systems folders, but isn't this protection in addition to AppGuard?


You didn't list the Windows script editor as guarded by default. Does this mean that a VBS file could be used to launch an executable?
In the past this has been done by trickery via email, and via web exploits.

To demonstrate, I use a test VBS file and an executable with spoofed file extension:



Now, you can argue that it's easy to disable the Windows Script Host,



but then that would protection added to that of AppGuard, which pertains to this thread topic.

Two questions,

1) Does AppGuard have something else to block malicious VBS scripts?

2) If the executable attempted to run from user space even though by a system executable (windows script host - WSH) would AppGuard handle the situation?

Thanks,

-rich

 

I'm not sure about Explorer.exe but my experience is that access to msiexec.exe gets blocked by AppGuard unless the protection level is set to Install. Some AppGuard users (including me) reported that Windows Automatic Updates were failing because access to the Windows Installer was automatically blocked by AppGuard, even though msiexec.exe is not in the list of guarded applications. This appears to be one of AppGuard's automatic internal protections.

The solution was to set the AppGuard protection level to Install then manually reapply the updates. I think part of the point of the Trusted Publishers list is to enable signed executables from Trusted Publishers to install updates without first having to set the protection level to Install.

AppGuard does requires some initial configuration to set up the list of applications located in System-Space that should be guarded. That said, AppGuard protects against all User-Space exploits automatically by default, and this is not dependent on the guarded applications list. Any attempt to exploit an unguarded application located in System-Space would fail if the exploit also involved a launch from User-Space as part of the attack.

Executables in User-Space will either be denied from launching, or launched guarded (not allowed to write to System-Space), depending on a combination of the AppGuard protection level (Medium, High, or Locked Down) and whether or not the executable is signed by a trusted publisher. The only exception where an executable would be allowed to launch unguarded (allowed to write to System-Space) from User-Space would be if it were a signed executable by a trusted publisher and the protection level were set to Medium.

I agree that an anti-executable would also be beneficial, as it will monitor all executables by default, closing a potential gap in AppGuard. The weakness of an AE though, as you say, is that once execution has been allowed, the application can then do what it likes. If on Windows 7, do you think UAC in conjunction with AppGuard would be enough, or is there still a case for a separate AE program to run alongside AppGuard?

Where AppGuard really scores is in applying further restrictions to programs that should be run, but which also need to be restricted. In this respect, it is similar to DefenseWall and GeSWall, but also has the advantage of being able to run on 64-bit systems. I tend to think of AppGuard as being a bit like LUA, but stronger than LUA with additional protections not found in LUA.

Except when the protection level is set to Install or Off, AppGuard automatically denies the execution of scripts.

 

Thanks for your very detailed and informative post. I see that AppGuard has become very robust. Well, it always was, as I found out when intially testing it. There were some weaknesses (DLL protection) which has been added, and the configuration now seems to permit a very secure lockdown.

As to whether it can be used without other protection really depends on each individual user's peace of mind, it seems to me. Protection can include both user policies and procedures, and products.

For example, I've always contended that with a properly configured firewall and browser, most remote code execution exploits don't get out the gate, so to speak. So, most of us already have added protection. (I consider the firewall and browser to be security products)

That leaves the social engineering attack vector, which is defended mostly by user policies and procedures, and if a user is tricked into permitting installation of some malware, of course at that moment the security levels are reduced and the user becomes infected. This is no reflection on the product, for it would happen no matter which security product was in place.

I don't have Windows 7 and have never tested UAC, so I can not answer this question.

Without specific testing, I don't find it wise to speculate, nor go on some one else's opinion.

Also, others' tests involving a specific product, say AppGuard, are always suspect in my mind, since I can't know from a distance how the user has configured the product.

A good example is the recent tests showing how Windows XP machines were infected just sitting there, being connected to the internet with no protection except the Windows Firewall. Say what?

Well, in digging around, MrBrian, who posted the link to the tests in another thread, discovered that the Windows Firewall was configured with Services (such as Messenger) with open ports. How about that!

So, if someone tests UAC with Windows 7 + AppGuard and reports an exploit got through, I would want to know specifically how each of those was configured. What levels was UAC set to? Was an ungarded application involved, for example, so that an exploit ran and elevated privileges or used some other trickery to bypass UAC?

In such a case, it wouldn't be fair to say that AppGuard + UAC are weak. Too much room for user error.

So, if you are able to test some exploits with that set up, you will determine for yourself how robust that set up is.

regards,

-rich

 

Thanks to those who contributed to the thread particularly Pegr and Rmus. It is the level of scrutiny I was hoping to get. Much appreciated.

For completeness I just want to say in answer to the question 'Why not just AppGuard?' for me there is no compelling reason but I will add a Firewall that is easier to configure (for me at least) than the Win 7 built in one, some form of secure DNS, keep UAC on max, continue to use OD/on-line scanners, light virtualisation and VM's if in any doubt about what I need to reduce protection to install.

For info for others who want more I've found most FW/Hips combo's (OA, Outpost, Comodo & PFW) work Ok with AppGuard on Win 7 x 64 at lock-down as does WSA if you add the exe's to the memory guard list. I had problems with any traditional AV I tried and most disappointingly for me SBIE.

Cheers