Malwarebytes Anti-Exploit

Win 7 SP1 x64, IE10

Downloaded the free MBAE 1.05.1.106 version today.

Tested MBAE using a test exploit at www.wicar.org; MS05-054. This is an old 2005 IE6 JavaScript onload handler exploit. It zipped right past MBAE. Was caught on the download by Emsisoft Anti-Malware file scanner.

 

I have Hitman Pro Alert RC build 152, and NOD 32 blocked all the exploits before HMPA did anything. I will test HMPA later on without the AV.

 

You guys realize that these exploits don't actually work with your up-to-date software / OS and hence there is nothing for MBAE or HMPA to block? Of course AVs detect them because they have signatures for it. Even AVs without any exploit protection would detect them.

 

You have to bear in mind that you can't test the full potential of a mitigation tool just by running a random exploit. Most of the memory corruption exploits targeting Flash, IE, etc will just be blocked when a stack pivot is performed. Even though MBAE contains additional mitigations like "generic ROP protection mitigations", "caller mitigations" and "application behavior mitigations". These will all function as an additional layer of defense.

 

Don't agree with this. It complete the download to my PC which means it was successful. I really believe MBAE should have caught this based on the following behavior:

MS05-054 Microsoft Internet Explorer JavaScript OnLoad Handler Remote Code Execution
This bug is triggered when the browser handles a JavaScript 'onLoad' handler in conjunction with an improperly initialized 'window()' JavaScript function. This exploit results in a call to an address lower than the heap.

This issue may be exploited to execute arbitrary remote code in the context of the user running the affected application. Failed exploitation attempts likely result in the application crashing.

 

@itman, I think you have a deep misunderstanding of the basic difference between reactive signature detection and proactive exploit mitigation. If you run an exploit for Windows Me/98/XP IE6 under Windows7 x64 IE10 the exploit is simply not going to trigger, ergo there is no exploit in your test environment. Even further from your posts it sounds as if you didn't even run them at all, simply downloaded them. This hints at an even bigger misunderstanding.

If anything your "test" should tell you how irrelevant it is detecting exploits by using reactive signatures.

 

Ok. Tried a different approach today.

Downloaded the test tool for Hitmanpro.Alert and used that to test both MBAE and EMET 5.1; first individually, then with both running concurrently. Used the 64 bit version of the tool since that is what my browser is. Set the EMET mitigations for the tool identical to that currently specified for iexplore.exe.

Results of the testing is EMET was more effective at blocking the exploits given in the HMP.Alert tool. EMET failed the following exploits; Null Page, Heap Spray 3 & 4, and URL Mon. MBAE failed; all the Heap Stray tests, Null Page, ROP - Winexec, and Load Library.

Since the Heap Spray test 4 was the JavaScript exploit, as far as I am concerned neither EMET or MBAE protect you.

Only thing positive is I am running iexplore.exe with all EMET mitigations enabled and have encountered zero conflict with MBAE free.

 

As mentioned earlier by @ZeroVulnLabs, you *must* have some basic knowledge of common types of attacks and how to defend against these attacks before you can compare MBAE/EMET/HMPA.
Furthermore I would like to remind you that the test tool developed by Surfright is specifically fine-tuned for HMPA and that these tests don't tell the entire story. It's wrong to write off MBAE or EMET just because a certain test might fail.

About the "Heap Spray test 4" comment you made: I don't think that you know what you're talking about. No actual JS code is being executed, this test just calls WinExec directly after it has allocated memory that mimics the allocation of JS Array objects (Correct me if I misunderstood the alert after disabling Dynamic Heap Spray in HMPA). This test lacks a fundamental component: a stack pivot. (The stackpivot mitigation in HMPA won't be triggered, correct me if I'm wrong. I didn't take the effort to look at the test tool in IDA or WinDbg) In almost all browser based attacks where an attacker has control over a vtable pointer he/she first has to create a fake stack. Otherwise an attacker won't be able to execute his/her ROP chain (and shellcode) stored on the heap. (There might be some special cases where a stack pivot is not necessary.)

The only way to test *all* the mitigations present in MBAE, EMET, etc. is by using a lot of custom PoC code, otherwise you can't test a tool's full potential. I encourage everyone who is curious about the level of protection that MBAE offers to do exactly this. ( Or you can just trust kafeine and pbust )

( Sorry for my bad English )

 

Thanks for the answer @regenpijp, I couldn't have put it better myself!

 

As far the applicability of the HMP.Alert test tool to other security software, below is a excerpt from its documentation. So I guess if you have issue with that, you should address it with Surfright.

Testing the abilities of other security software

You could also use the Exploit Test Tool to check the protection abilities of other security software, like antivirus or endpoint protection solutions designed to stop exploits or zero-day attacks. You might need to configure the third-party security software to protect the Exploit Test Tool (i.e. add the hmpalert-test.exe and hmpalert64-test.exe executables to the list of protected applications, or rename them to a filename of a known protected process e.g. iexplore.exe).

I used the test tool as a baseline to compare two products and posted the results. It's as simple as that. Whatever deviations exist, they would apply equally to both products. I do agree the heapspray test 4 is suspect since the exploit they base it on, CVE-2014-1512? was a Linux FireFox exploit. I can find no reference to CVE-2014-15123 that Surfright refers to in its documentation.

I do intend to do further testing with Metasploit as time permits and will post my results.

As to the tests the tool employs, they appear to me to be straight out of the Metasploit database.

 

The HMPA Exploit Test Tool has been used in the past by other people to compare MBAE/EMET/HMPA and I have to admit that it's a nice tool for demonstration purposes, but not for review purposes. Just use actual POC/exploit code if you want to test the full potential of exploit mitigation software.

Once again: You have no idea what you're talking about. An exploit designed to work on a Linux machine wouldn't even work on Windows...

VUPEN has written a nice blogpost that explains the exploitation process of CVE-2014-1512: http://www.vupen.com/blog/20140520.Advanced_Exploitation_Firefox_UaF_Pwn2Own_2014.php

Great.
You can always test MBAE yourself using msf, custom POC code or actual samples used ITW. But make sure that you confirm beforehand that exploit code is able to run on your testing machine.

BTW: Other people have already demonstrated that MBAE is able to defend against a large number of exploits:
- http://static-cdn.malwarebytes.org/assets/datasheets/2015-02-06/MBAETest.pdf
"In order to prove Malwarebytes Anti-Exploit has the ability to block exploit drops, we went ahead and put it to the test against the most common (...) exploit kits currently found in the wild."
"Defeated: ALL OF THE MOST COMMONLY SEEN EXPLOITS"

- http://static-cdn.malwarebytes.org/assets/datasheets/2015-02-06/RCEMitigations.pdf
"Most of the exploits are setup on Metasploit and some come from private sources."
SUMMARY: Malwarebytes Anti-Exploit: "Score: 93.103"

Once again: You have no idea what you're talking about. as far as I know the HMPA Exploit Test Tool only simulates exploitation techniques and does not use actual exploits.

( As to all the statements I made: If you have any evidence that I made a mistake i will admit that I misunderstood something and I will happily change my opinion )

 

After latest Flash Player Update 16.0.0.305 on latest Firefox, MBAE was quiet all days on this page http://www.speedtest.net/
But today in the morning again it's stopping Exploits.

 

So you're saying that with the HMPA test tool, you can't really test the protection capability of other anti-exploit tools?

What do you mean with this, is the site infected?

 

Oh, I forgot to say that exactly that's what I want to know, whether the site is infected or not, I may ask.

 

I tried the site after I saw your posting. It was OK as far as I could determine.

 

Since the post is about our test tool, I thought I'd chime in and make a few comments.

Each test in the test tool should trigger a specific mitigation. In case of heapspray it should trigger heapspray mitigation. It does not use a stackpivot because it is not meant to trigger the stackpivot mitigation, but only the heapspray mitigation (as you know we have a specific stackpivot test to test stackpivot mitigation).
If every test would do a stack pivot then it would not reveal the many mitigation layers of exploit mitigation software. Its like putting the EICAR signature in every malware sample!

Also I disagree that every heapspray needs a stack pivot. On XP the heap is already executable so you can jump straight into your sprayed heap. Another thing an attacker can do is place its ROP chain on the real stack (I admit, must be a small ROP chain, but still). And he/she can also unpivot the stack before calling a critical function. See page 15 in this paper that does just that: https://bromiumlabs.files.wordpress.com/2014/02/bypassing-emet-4-1.pdf

Hence the reason why the heapspray tests do not use a stackpivot.

Hope this helps.

 

Glad you brought up that report. Reviewed it a while back.

Before I get into specifics, I would like to see MalwareBytes do the same testing with a mainstream AV lab. VB seems the logical choice since they have done recent exploit testing for Chinese security firms.

As far as the PCSL test goes, I have some real issues with it. It was done using WIN XP SP3, an unsupported OS and unpatched since 4/2014, and IE8, a 8 year old browser. They used EMET 4.1 in their testing. In spite of this, EMET still had the third highest ranking. Lets have a certified lab test with WIN 7 SP1 x64 and IE10 or 11 using EMET 5.1 against MBAE.

 

- Not every heap spray needs a stack pivot, but I have never seen an exploit ITW that lands on the heap and that didn't use a stack pivot. So at least they don't occur very often. (Google described a way on their blog: "An interesting and useful feature of the Flash JIT is that if the arguments to a method invocation can be determined to be simple native types, then they will actually be pushed onto the native stack (as in a normal, native function call). This means that by overwriting the function pointer for a function with a lot of uint parameters, we can control a large block of the native stack when that function is called, letting us ROP directly on the legitimate program stack." - http://googleprojectzero.blogspot.it/2015/02/exploitingscve-2015-0318sinsflash.html)

- afaik MS introduced DEP in WinXP SP2 (https://technet.microsoft.com/en-us/library/bb457155.aspx) and also several exploits targeting 2013-3893, 2013-3897, 2014-0502, 2014-1815 used VirtualProtect/VirtualAlloc to mark memory as executable when launched on WinXP. But I can give it a try.

- Placing your payload on the stack when you have 'control' over the heap is a bit hard I guess. Might be possible using special objects that allocate data on the stack.

EMET 5 only introduced EAF+ and ASR.
EAF+ is only effective when you're dealing with an info leak where an attacker tries to read the PE headers of certain dll's. It's almost impossible to bypass, because all the PE headers of protected dll's will be obfuscated in a strange way (Haven't tried to figure out how this works)
Testing MBAE/EMET on Win 7/8 would only result in more exploits failing to execute even without mitigation software installed due to the addition of ASLR.

 

It gives you an idea of the individual mitigations present in mitigation software (as mentioned by Erik), but 'real' exploits often consist of a number of actions combined. And none of the tests simulates a *full* attack.
I will explain how certain exploits use Flash Player to infect a pc and which of these actions can/will be blocked using MBAE/EMET/HMPA.
This knowledge is based on analysing code used to exploit vulnerabilities like 2013-3163/2014-0322/2014-1776 (IE), 2013-0634/2014-0497/etc. (Flash Player) and blogposts/papers published by FireEye, HP, etc.

The following example will require some knowledge of exploits that use Flash Player for the exploitation process.
An exploit using an info leak created using Flash Player could perform the following actions:

1) Spray the heap with Vector.<uint> objects.
2) Corrupt the size of some Vector.<uint> objects to create an info leak
3) Locate the PE header of the Flash ocx library in memory, extract all necessary offsets and locate critical functions like VirtualProtect.
4) Corrupt the vtable pointer of a random object like a Sound object to get RCE.
5) Perform a stack pivot and mark the shellcode (stored on the heap) as executable using a ROP chain and VirtualProtect.
6) return to the shellcode.
7) Shellcode might extract additional functions like WinExec, UrlDownloadToFile, etc.
8. Main body of shellcode will be executed and a payload will be downloaded to disk / loaded into memory.
9) payload gets executed by the shellcode.

MBAE, EMET and HMPA are all able to stop such an attack at different levels.
The following list contains an incomplete overview of mitigations that can/will be triggered in such an attack (Yes, you may criticize me ):

1) Heap pre-allocation - Prevents landing on certain spots in memory like 0c0c0c0c and it might cause an exploit to crash when it tries to read unallocated memory in an attempt to find certain objects in memory (Present in MBAE/EMET/HMPA)
2) EAF+ / IAT Filtering - Prevents reading certain dll headers (EAF+ makes EMET 5 *very* slow and IAT Filtering is present in HMPA)
3) Stack pivot - Prevents certain critical functions like VirtualProtect/WinExec/etc. from being called when ESP is outside of the stack boundaries defined in the TEB. (Present in MBAE/EMET/HMPA)
4) EAF - Prevents shellcode from locating certain critical functions like WinExec/CreateProcess/etc. (sort of) (Present in EMET)
5) Caller Check and related mitigations - Prevents shellcode from calling critical functions like WinExec (Present in MBAE/EMET/HMPA using different implementations)
6) Application lockdown and related mitigations - Prevents downloaded executables from being executed (Present in MBAE/HMPA using different implementations)

MBAE, EMET and HMPA also contain additional mitigations that can be triggered under other circumstances.

( I might update this post with additional information/improvements )

 

Hi Regenpijp.
I would like additional informations for the point (6) of your list:

6) Application lockdown and related mitigations - Prevents downloaded executables from being executed (Present in MBAE/HMPA using different implementations)

TH.

P.S. EMET passes the IAT test (EAF) of HPA3.
(My tests with EMET 4.1U1 on XP)

 

How does exactly MBAE premium prevent downloaded executables from being executed in the first place?
The same question for HMPA...

 

I can't answer this question.
That's why I asked Regenpijp.

 

I did not reverse engineer MBAE and HMPA, but you can find the hash of a file that is being downloaded and executed in the MBAE log file after it has been blocked. I primarily perform testing by looking at actions that would trigger an alert and which actions would not trigger an alert.

Here are some of the actions that are being blocked by the Application Lockdown feature in MBAE and HMPA:
VBS Macro's:
MBAE and HMPA:
- Both prevent executables from being downloaded and executed using a VBS macro.
- Accessing PowerShell is not allowed.
(I assume that more restrictions exist)

Java applet:
NB:
- I am not aware of any new Java vulnerabilities being exploited in the wild in the last 1.5 year.

MBAE:
- Prevents executables from being downloaded and executed using a Java applet.
- Accessing cmd.exe and powershell.exe is not allowed.
(I assume that more restrictions exist)

HMPA:
- Really aggressive filtering that prevents almost *all* executables from being executed.


With regard to similar lockdown features:
MBAE contains mitigations like:
- "Layer0 'Application Hardening' protections"
- Other "application behavior mitigations"
Source: https://forums.malwarebytes.org/index.php?/topic/161643-malwarebytes-anti-exploit-10511016/

HMPA also contains Network Lockdown.

NB:
- Please note that I am not able to test/discover all implemented mitigations. The internal working of protection mechanisms present in MBAE/HMPA/EMET is not documented and I don't have unlimited time, samples and poc's.
- I haven't (yet) tested Application lockdown using samples/code that targets logic flaws in IE/MS Office like CVE-2014-6332 and CVE-2014-4114.
- I do not perform testing using a high number of different samples/POC's. Other people have already tested MBAE/EMET/HMPA using a large number of different exploits, I primarily use customized POC code of a small number of vulnerabilities. MBAE/EMET/HMPA do not rely on reactive protection rules (like AV), but detect general exploitation techniques, so pretty much all traditional exploits will be blocked anyway. ( Yes, you may criticize this way of testing, but I do not have the time test/analyze 1001 exploits that all use a different vulnerability but roughly the same exploitation technique. These will all be blocked when VirtualProtect is called from the heap or when WinExec/etc. is called from RWX memory on the stack )

 

@ ZeroVulnLabs

I'm running MBAE Premium right now, about the GUI, perhaps an idea to make it remember column-size, and to make it easier to see when anti-exploit is turned off for some app, by marking it with a red color perhaps. I've also tried to add a shield for Media Player Classic, but now it immediately crashes.

Thanks for the extensive reply, I understand it better now.

 

@ ZeroVulnLabs

BTW, what is the purpose of the two "conhost.exe" processes? So far I seem to have no problems with Firefox and PDF-XChange Viewer. MBAE also does not seem to interfere with Sandboxie, probably because it can't inject code into sandboxed processes.