AppGuard 4.x 32/64 Bit - Releases

Yes, it will. Anything allowed to run from user space at Medium will automatically be guarded. If you've installed it yourself into system space then no, AppGuard won't protect unless you explictly add it to the Guarded Apps list.

As regards Locked Down, there shouldn't be any tweaking needed. I run in Locked Down and it has never given me a problem. It's easy enough to revert to Medium so you wouldn't be losing anything by trying it.

 

OK, big thanks, than, but what about ROP (ROP=Return-oriented programming, right?), can AppGuard fully 100% protect against ROP, I still have difficulties (since I'm layman) in understanding what exactly ROP is.

 

Than I'll switch on Lockdown mode, but the reason why I don't do it is because of Sandboxie, I don't know if there is going to be any problems with tweaking AppGuard on Lockdown mode.

Maybe you can show me post (I think it was you who posted how Sandboxie and AppGuard can co-exist together, than there is also Malwarebytes Anti-Exploit which I really want to try, but I'm not sure if it's needed since the combo of AppGuard and Sandboxie are more than enough.
AppGuard protects against files that are run outside Sandboxie's sandbox.

 

@Barb_C any news on the beta not detecting the update?

 

Yes, AppGuard will still contain the attack, but it wouldn't prevent the browser from becoming compromised again (if a web site is causing the compromise).

 

Yes. A digitally signed application is allowed to run in Medium Level, but AppGuard prevents it from altering key registry hives and system directories.

 

No. We have not had a chance to try to recreate.

 

PEGR, you always do a better job of explaining things that I do. Thanks!

 

See post #1903 above for configuring AppGuard for use with Sandboxie. File/folder access and launch permissions can be customised independently of the protection level. File and folder customisation is more to do with whether an application has problems running with the default permissions assigned to system space and user space than it is to do with the protection level. Post #1903 contains a link to Post #1197 that deals with permissions in more detail.

The main difference between Medium and Locked Down is that Locked Down won't allow digitally signed executables to run from user space unless they are on the Guarded Apps list. Locked Down increases security but is a little less convenient, as it may interfere with automatic updating of applications from trusted publishers.

 

Okay, you asked for it. I asked the Chief Software Architect to explain the differences between EMET and AppGuard and I think he's done a good job (probably too much information).

AppGuard’s Memory Guard is completely different approach as compare to HIPS internal memory attack detection approach. EMET’s memory attack protection uses the same HIPS principles but EMET’s coverage goes beyond any known HIPS product today. Considering McAfee’s HIPS as the yardstick for HIPS, the memory attack detection is limited to detecting Buffer underflow and overflow in a running program and preventing the code execution upon detection on the underflow/overflow memory. Here is what McAfee HIPs document states on the matter:

“https://kc.mcafee.com/corporate/index?page=content&id=KB73399#Buffer Overflow Protection”

How does Buffer Overflow Protection work?Buffer Overflow Protection (BOP) monitors executables and APIs on the protected system, checking for code execution from a buffer overflow or buffer overrun. BOP does not stop the overrun from occurring, but stops code execution that occurs from that overrun. This is a common exploit method, used by malware against vulnerable applications, to gain access to data or the system and/or to further propagate itself.

Protection is accomplished by having kernel-level hooks (also known as Kernel Patching of various system tables) detour code execution through our tests for safety, before returning to their previously scheduled programming. This feature is limited in support on 64-bit platforms as its kernel allows limited patching. … You can make this BOP redundant if Data Execution Prevention (DEP) is in place.

Protection is accomplished by having kernel-level hooks (also known as Kernel Patching of various system tables) detour code execution through our tests for safety, before returning to their previously scheduled programming. This feature is limited in support on 64-bit platforms as its kernel allows limited patching. … You can make this BOP redundant if Data Execution Prevention (DEP) is in place.

Protection is accomplished by having kernel-level hooks (also known as Kernel Patching of various system tables) detour code execution through our tests for safety, before returning to their previously scheduled programming. This feature is limited in support on 64-bit platforms as its kernel allows limited patching. … You can make this BOP redundant if Data Execution Prevention (DEP) is in place.​

The short story, the “golden” standard of HIPS, McAfee HIPS, has very limited Buffer Overflow Protection. In 64-bit Windows, the protection even diminishes. For DEP enabled applications, McAfee HIPS BOP is not even relevant.

In contrast, EMET extends the memory protection with detection of Heap Spray, ROP, and many other forms of memory attacks. Though some of the issues with EMET are:

1. Increasing the level of protection can adversely affect the application compatibility.
2. Requires ongoing maintenance of the EMET configuration as applications are updated/patched.

EMET tries to cover all possible known memory internal based attacks. But EMET cannot anticipate all the possibilities, missing the 0-day ones.

When that happens, EMET’s memory protection is bypassed. There are well known exploits in the past that bypassed EMET’s memory protection and Microsoft constantly updates EMET tool to cover the missing attacks. Again, there will always be another new 0-day that any HIPS product will not be able to “catch.”

There lies the difference between AppGuard’s approach to security versus HIPS model of protection. AppGuard does NOT attempt to detect memory attacks as done by EMET or done by McAfee HIPS in a very limited buffer overflow detection. AppGuard assumes that any application will have 0-day vulnerability that will one day bypass any internal memory protection mechanisms of any HIPS product. If that happens and the application is taken over by malware and attempts to make a “lateral move” by performing code injection into another running application, or to read the memory of the other application, or to alter the memory of running of other application, AppGuard’s Memory Guard stops it. By the way, the mentioned attacks use completely legitimate Windows APIs to perform the code injection, memory alteration or memory exfiltration. So AppGuard is the last line of defense when all HIPS protections are eventually bypassed. AppGuard does NOT need to detect if there is a memory attack. AppGuard already assumes there is one and that it bypassed the protection of the operating system or the other products (HIPS/Whitelisting, etc.). Appguard ensures the compromised application cannot be used a launching pad for like moving into another running application or hopping to critical system services like login etc.

Both EMET or McAfee HIPS are consumed with detecting memory based attacks so that the application cannot be compromised. None of these products implements the AppGuard’s Memory Guard equivalent technology. AppGuard’s Memory Guard is simple, and stating that AppGuard's protections are already implemented in HIPS is a fallacy.
​

Let the discussions begin!

 

Barb_C@: I'm using your app for a first time, not everything is so clear to me.
My ProgramFilesDir is a default location, C:\ partition so all Windows apps etc. are installed on Windows partition. (I failed when tried to change path to D:\ when rebuilding install.wim, it was easier for XP) Anyway I prefer to install most software on larger D:\ partition.
No, I didn't change the path do D:\ it's too problematic to do so after windows installation.

Ok so did like you said: I removed those wrongly added apps from Guarded list, added two program files folders to protected list and then excluded it from user-space. Is it all right now?

http://iv.pl/images/90406109912620345184.jpg

08/06/14 17:28:24 Prevented process <desktop.bat | C:\Windows\System32\cmd.exe> from launching from <d:\różne\skróty sandboxie>.
08/06/14 17:26:13 Prevented process <empty sandbox.bat | C:\Windows\System32\cmd.exe> from launching from <d:\różne\skróty sandboxie>.
08/06/14 17:34:46 Prevented process <hpusbfw.exe | c:\windows\explorer.exe> from launching from <d:\exe>.
08/06/14 17:33:17 Prevented process <tfc.exe | c:\windows\explorer.exe> from launching from <d:\exe>.

I also have some batch files (not as much) in D:\Różne, like those posted above. Few of them I start them via desktop shortcut. In D:\EXE I keep many executables. Any custom rules for those folders?

Thank you for replies, much appreciated

 

When your software architect is talking about HIPS and memory attacks he is limiting the capabilities to detection of buffer underflow and overflows. I don't think this is correct. HIPS can prevent memory attacks from making lateral moves, like reading the memory of other processes or altering it.



The only problem with consumer HIPS is the way this protection is applied. By default, vulnerable applications like the browser, pdf reader or Office are treated as trusted. Hence they are allowed to do everything, so HIPS doesn't do anything against memory attacks originating from these processes. It only applies these restrictions to new processes which are not trusted, which is way too late in the game. But to say it doesn't have the ability to prevent it is wrong imho. It just doesn't do it by default, whereas AppGuard does it.

 

Yes correct, HIPS can do exactly the same as AG´s Memory Guard. And you can´t really compare anti-buffer overflow (and anti-ROP) with blocking code injection, that´s what this whole discussion was about. They are both trying to achieve two different things. The first one is trying to stop zero days in apps from being exploited, the second one is trying to stop already running malware from infecting the system.

This depends on the HIPS, in the ones that I used you can simply mark them as "Restricted", which won´t allow them to perform high risk activities, even when they become infected.

 

The thing is, there are several ways to stop exploits/payloads. EMET tries to stop them with exploit mitigations, while others use the "anti-exe" method, this means that (depending on the implementation) restricted apps are not allowed to spawn new processes, and apps that are not white-listed are not allowed to run. That´s why AG probably performed better than EMET in the test, because some exploits can bypass certain exploit mitigations provided by EMET, and then you need "anti-exe".

 

You should make d:\program files and d:\program files (x86) read only. If you want the bat files to run from d:\rozne\skroty sandboxie, then you should exclude that folder from user-space protection (same with d:\exe).

 

And that´s why hardcore testing is needed, it would be nice to know who performs the best when it comes to blocking exploits. Nowadays even security suites like Kaspersky, G Data and ESET offer dedicated "anti-exploit" modules. And tools like MBAE and HMPA have tried to outclass EMET.

Security apps like AG and EXE Radar go for a simpler approach. The question is are they good enough? I have used SSM on Win XP as my anti-exploit (anti-exe) tool for years and never got a single infection, might be luck, but who knows.

 

Fleischman, explained it nicely. When 2K/XP HIPS trusted a process due to whitelist or user action, it was allowed to do stuff, although most also controlled inter-process operations (like SSM) Containment between processes is different from containing memory operations within a process.

Problem with most anti-exe HIPS is that most of them don't look within the executable. Just look at the characteristics of an exploit kit and see that some of the intrusion steps never hit the hard disk (small 'in memory code sniplets', could even be executed as part of the meta data of a picture).

 

OK I see, I also made a comment about this, it can be a security risk, if you wrongfully trust some app, it might be able to infect the browser (with a banking trojan), and then it´s game over.

 

If I've understood you correctly, your concerns are not so much about the differences between EMET and AppGuard, which you already understand, but rather the relative effectiveness of different approaches to exploit blocking. I agree this can only be determined by testing. As I suggested to you in my reply in Post #1868 above, maybe the time has come for you to perform some testing of your own to get the answers you are seeking.

 

The issue isn't MemoryGuard. If a malicious executable is inadvertently installed into system space without being added to the Guarded Apps list, it is trusted and has full system access. If it is on the Guarded Apps list then it will run guarded and MemoryGuard will prevent it from injecting code into the memory space of other running processes.

This illustrates the need to ensure that software installers are clean before lowering the protection level to Install to run them. Even if clean, any application running from system space that shouldn't be trusted should be added to the Guarded Apps list or AppGuard won't protect it against being exploited.

 

Barb_C@: Done. It's very nice to get so much help and so fast. I'm gonna test your app in next few days. For now it seems to be very interesting and good one to describe it in my graduate for (I study IT).
Do you have any plans to make AppGuard available in other languages? I could help with polish translation.

It's cool it has no conflict with Truecrypt bootloader and AdGuard

 

..sent now...