Mission impossible? Malwarebytes invents software that blocks zero-day attacks

I am using premium, so far everything playing very nicely together.

 

That's the experimental forum where we are testing new techniques. That comment was about one of the new techniques blocking exploits earlier and us sometimes not catching the exception to show the alert popup. It really is nothing to worry about or that needs to be read too much into. This happens with EMET sometimes as well for ex where a mitigation might make the application crash before a notification can be shown.

MBAE is different than EMET. From my perspective more effective with some memory techniques and more complete thanks to its application behavior. Also better suited for the mass market as the techniques are adapted per application family (i.e. less conflicts and less FPs) and its install-and-forget approach.

You have the proof that it works in front of you if you care to look. It has been shown in the old ZeroVulnLabs site and youtube channel against zero-days and now with Kafeine's test against exploit kits. You can also test it yourself. I'm sure you can find old versions of MBAE and test them against newer zero-day exploits as they get integrated into Metasploit for example.

 

To all the people complaining:

1. Security wise, rich content (or code/script sniplets in data formats) is a pain in a place where the sun does not shine, because Anti-Executables, HIPS and application virtualisation solutions will allow these in memory executions (only AppGuard with its memory protection offers such a defense mechanism).

2. Containment policies (low rights sandboxes) as implemented by Microsoft, Adobe and Google reduce the attack surface (lower rights objects can't touch higher rights objects). Therefore the implementation of MBAE (using user land level hooks) is not a big concern to anybody using Windows 7 or higher.

3. Solutions like MBAE are focussed on check points which (currently known) exploits have to pass. Consider them as road blocks an exploit has to pass (the three stages of MBAE protection). The advantage is that you don't have to guard all attack points (all cross sections of a road), but a few. The cost of developing a new road (or exploit kit) evading these checkpoints is very high.

4. The single fact that solutions like MBAE exist and are made available as a free application protecting the most abused entry point (the browser) will by itself reduce malware exploits seen in the wild (when you don't believe this, just have a look on the stats of exploits in the wild and the effect of improved ASLR introduced with Windows7).

5. Higher cost of malware development requires higher returns, which lowers the business case (and the chance) of ordinary home users being attacked.

Considering the above, I don't understand the critism, regards Kees

 

Malwarebytes comes along with a solution, which offers user friendly exploit protection for the most criticial threat-gate programs like browsers and Java for free, premium costs 22,95€ for 3 PCs / 1 year. People complain. Then there is this commercial Adblocker that everyone is crazy about. Offers actually nothing that free Adblockers already don't but costs 39 to 45€ (LOL!!!) for 3 PCs / 1 year. Nobody complains at all. Go figure.

 

Couldn't have said it better!

Thank you @digmor crusher, @vojta, @Rainwalker, @Rasheed187, @FleischmannTV and @Windows_Security for putting things into perspective.

 

I´m not sure if this is true, Appguard´s memory protection doesn´t have anything to do with blocking exploits, if I´m correct.

 

Memory protection is developed to reduce the threat of memory exploitation

Can't find the test anymore, but it outclasses (early version) of EMET, but let's keep it an MBAE thread

 

Can you give a bit more info? I´ve read the AG manual, and the Memory Guard does not do anything to stop exploits, it´s just blocking apps from writing to and reading from memory. MBAE tries to stop exploits in an earlier stage.

 

read this http://en.wikipedia.org/wiki/Buffer_overflow

For instance a program defines a table (in memory) with 10 rows (to all programmers I am just using this analogy to explain). When the index is set to 11 it is outside the bounderies of this (table) definition (the 11th row), this is called an "overflow" condition. So prohibiting programs to read/write memory outside their allocated bounderies is a form of exploit protection.

 

@ Windows_Security

If you see this as a form of exploit protection, then all HIPS (since 2004) protect against this, unless I´m missing something.

I don´t see it as true exploit protection, because read/write memory protection doesn´t stop the exploit from running. You need Anti-ROP and other mitigation methods offered by MBAE and EMET for that.

 

Ask the developers or the representative frequenting this forum, there is also info on their website in regard to XP

 

What is there to ask? It´s all described quite clearly in the AG manual. Memory Guard doesn´t stop exploits from running.

@ ZeroVulnLabs

I remember that the first versions of MBAE (ExploitShield) didn´t block meterpreter and revers shell payloads, can you give a bit more info about this? Do you think that pure anti-exe apps like EXE Radar and AppGuard are able to block these payloads?

 

The important thing to note here is that if you rely only on anti-exe the exploit shellcode has already executed, so the attacker is able to run code on the system (i.e. payload). Payloads can be customized to get passed defenses. So the best approach obviously is to stop the exploit from ever running. Blocking payloads from running is a good second measure for when exploits bypass memory protections. But again an anti-exe is probably not a good measure to stop exploit payloads. As a third line of defense you can use anti-exe to block the malicious action executed by the payload in case it is a download and exec of a PE file, but there are other malicious actions that the payload can execute such as a reverse shell which will also probably bypass the anti-exe (as well as most AVs).

 

"What is there to ask?" Next you ask the developer of a different program?

Also where in the "AG manual" did you read about "pure anti-exec", AG blocks user folder executions, does not filter executables (on hash) in Windows and Program File folders. Better ask the correct developer/company or run some tests with metasploit yourself. I can assure you it is hard to bake an omelette or plant/hunt eggs with Memory Guard blocking memory reads and writes.

 

OK, so earlier versions of MBAE could only block the payload, but didn´t stop shellcode from running. And now it can block both, correct? About reverse shells, do they run only in memory, without a separate process? And is that the reason why anti-exe (most likely) can´t stop them?

 

I will try to explain: Apps like EXE Radar and AppGuard try to block exploits by blocking the payload, but they can´t block the exploit itself (memory corruption). That´s what I mean with anti-exe. Almost all "old skool" HIPS can do the same.

According to you, AG will not "allow these in-memory executions", where do you get this information from? When I read AG´s manual I come to the conclusion that AG´s Memory Guard is not blocking exploits, it´s just trying to prevent code injection. In other words, it´s doing exactly the same as Process Guard did back in 2004, it´s no new technology.

MBAE is using more advanced methods than AG, trying to stop exploits. The question is, does it also perform better than AG. It would be nice if someone could test this.

 

AppGuard’s Memory Guard is a completely different approach as compared to the traditional HIPS internal memory attack detection approach.

AppGuard assumes that all applications have 0-day vulnerabilities that will someday be exploited and any internal memory protection mechanisms of existing HIPS products will be bypassed. If that happens and the application is taken over by malware and the malware attempts to make a “lateral move” by performing code injection into another running application, or to read the memory of another application, or to alter the memory of another application (not just via code injection), 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 the attack will bypass the protection of the operating system or the other products (HIPS/Whitelisting, etc.) and AppGuard ensures that the compromised application cannot be used as a launching pad for moving into another running application or hopping to critical system services like login etc.

 

Thanks for the feedback. But I must be missing something, because I still don´t see how AG´s Memory Guard is different from other HIPS.

Other HIPS (like SpyShelter and Comodo) can also stop apps from writing to (and reading from) memory of other processes. Also, like I said many times before, this type of memory protection doesn´t stop the exploit itself, instead it´s trying to stop malicious behavior from malware that is already running on the system.

And that´s why I disagree with the statement of Windows_Security (and you), that AG offers a better, or different kind of protection than regular HIPS and sandboxes. Now that I think of it, Sandboxie will also block interprocess communication, apps running inside the sandbox can´t communicate with processes that are not sandboxed.

And back to the topic, when it comes to blocking exploits, I suspect that specialized tools like MBAE will do a better job than AG, because AG doesn´t offer advanced exploit mitigations, instead it´s using the "anti-exe" method. Not that there´s anything wrong with that, I´ve been relying on anti-exe for years. It would be nice if BRN could also offer a third party sponsored anti-exploit test, just like Malwarebytes did.

 

@Rasheed187

1. Please keep AppGuard discussion in AppGuard and Sandboxie in Sandboxie thread, this is a MBAE thread
2. Please stop comparing MBAE vs AG, you are turning this into an A vs B discussion
3. Please stop theorizing, run some test yourself

Regards Kees

 

@ Windows_Security

It´s not about A vs B, I just wanted to point out that the memory exploit protection offered by MBAE is something different than AG´s Memory Guard. And I´m currently not in a position to test tools, so it would be nice if some expert could do it.

 

this is nothing new, its what appguard and EMET can do and much better than a crippled version of MBAM anti-exploit free

 

Yes but that´s not the point, MBAE is geared toward non-expert users, it works out of the box, without any extensive configuration options.

 

What about MBAE do you think is crippled?

 

I'm referring to the free version compared with (free version of) EMET, i have no doubts the premium version offers great protection.

 

This test was done using the free version. In addition to protecting against Java exploits (which EMET doesn't) MBAE can be used by anybody who can double-click on an installer and does not require knowledge of exploits and mitigations in order to configure correctly.