EMET (Enhanced Mitigation Experience Toolkit)

Yeh, make rundll32 to load a malicious DLL and see if the whitelisting AE will do anything about it. =P

Speaking of EMET, since in Windows 8/8.1 the explorer.exe wants to connect to the internet (for SmartScreen I assume) does any of you guys add it to EMET's additional protection? Just wondering.

 

I'm not sure what you mean, but for example EXE Radar will monitor apps that launch rundll32, no matter if rundll32 is white-listed. Also, most white-listing tools are a lot more advanced than they used to be, just look at Bit9 and Lumension.

 

I wasn't talking specifically about EXE Radar, it was more into whitelisting-based AE in general. Most whitelisting-based AE are primitive descendants of CHIPS. Sure thing, they could be useful. But they require too much effort to maintain for such a small benefit to gain.

Right right right right right, let's drop this topic for now. I have been hammered a lot this last.

 

In my opinion every "known" and "spread" app is a possible threat for getting exploited. E.g. microsoft office, skype, browser, mail clients,..... everything that typically runs on a windows system or is installed. Especially apps which are often running in the backround (e.g. keepass).

 

I believe Keepass doesn't meet the criteria (my bolding):

 

I use mostly path-based whitelisting, which needn't require much effort to maintain.

 

But would it be sensible to add explorer.exe (and also perhaps dllhost and rundll32) to EMET?

Path-based whitelisting is different, AE software are usually using hash-based whitelisting AFAIK. Besides, path-based whitelisting is very vulnerable to process hijack.

 

If Microsoft isn't recommending it, then I wouldn't do that.

 

There is no point into protecting an app like KeePass. The only thing that it handles is the password database file.
See the link, there is a reason why MBAE has chosen to protect these apps out of the box, because they are the most exploited ones.

https://www.malwarebytes.org/antiexploit/premium/

 

I have received a mail from the EMET team (I mailed them) confirming the bug and it will be fixed in the next EMET release, as a temporary solution they have suggested to turn off the stack pivot mitigation along with EAF if you have a program which is incompatible with EAF and you have to turn off EAF for the program, this way the rest of the ROP mitigations will continue to work correctly.

 

If you browse to a site that's unknowingly serving malvertising (and there's a TON of that stuff making the rounds nowadays) and you have IE and EMET without StackPivoting and EAF, the chances of getting popped by the exploit are very high. Having EMET and turning off its mitigations only serves as a false sense of security.

 

I also said similar back in August. Mitigations like StackPivot, EAF and Caller are EMET's strongest protections against exploits. Disabling any of these severely impact EMET's usefulness.

 

I just wanted to state that myself (and probably others here as well) immensely appreciate the honesty from both of you and respect the fact that, although coming from different products and companies, you both always seem happy to put the information out there for the greater good of security for all. Thank You! Much respect.

 

Well, it can't be helped if certain mitigations are incompatible with certain programs.

 

Yes it can. It's just more work from dev finetuning and testing perspective, but those mitigations can be made compatible with those programs. At least in MBAE we use the same or similar mitigations and go the extra mile of making sure they are compatible.

 

And that is the job for the EMET developers, not the users. There's nothing the users can do other than disabling those problematic mitigations for now if they encountered issues.

 

Yes of course, you're correct. My point is that if users disable those mitigations they might as well not have EMET at all, as most modern exploits will succeed without those mitigations.

 

Yes, and that's why I said it can't be helped, on the users' side.

 

User could fallback to version 4.1 (from 5). This solves most issues.

 

So, what to do? Almost all major software I use break if I don't disable Caller, StackPivot and sometimes EAF.
I am considering to go back to 4.1 Update. I doubt Microsoft will fix the issues with 5.0.

 

Use MBAE or HMPA.

 

In your situation, I would suggest uninstalling EMET 5.0 and then install EMET 4.1 Update 1 with the default recommended settings first prior to making any changes to it. Try it out and see how your applications behave. Although I am sure that Microsoft will fix issues with the next update regarding EMET 5.0 specific issues provided that users submit detailed reports to the proper channels to make the developers aware. The only question is when will they fix it. But hopefully 4.1 Update 1 will work okay for you until that time comes. Alternatively, as ZeroVulnLabs suggests, you could also consider using MBAE or HMPA. That's the beauty of having choice when it comes to any software. I don't know why EMET 5.0 has been so flaky with your system setup (and others) unfortunately, while working perfectly fine with all mitigations enabled for my system and also many others. With EMET, do you normally use Recommended settings or Maximum?

 

Thanks for your input. I have downgraded to 4.1 Update 1, imported "Popular Software" (enabled by default: Caller, StackPivot, EAF), Deep Hooks enabled and so far everything works like a charm.
Had to disable Caller for 2 software that I rarely use anyway, that's it.
So although EAF/Caller/StackPivot exist in both EMET 4.1 and 5.0 they seem to work in different ways, on a deeper level that is?

I always use Maximum settings, although I have to disable ALSR "always on" because I'm stuck with an AMD graphic card.
It's extremely weird some people that have the same system setup like I have, W7 64bit, Chrome etc, but experience no crashes.

Until Microsoft releases EMET 5.1 I'm going to stick with 4.1. It probably gives me more protection than 5.0 did.