EMET (Enhanced Mitigation Experience Toolkit)

It seems cert pinning doesn't work in EMET 5.x on Win7 64 bit Home Premium, but work in 4.x. Can anyone confirm it?

 

I can confirm it is not working on latest 5.2 build. Real nice .......... Does MS test anything these days? You going to contact them?

Also I imported my app & cert rules from my 5.1 build. Wonder if that has anything to do with it. I believe it was working OK for 5.1.

 

It seems it doesn't work on 5.1 too. After further confirmation, I'll post this on their technet forum if not yet done.

 

Ok, I think you have a point. Too bad Microsoft doesn't mention what else has been improved in 5.2.

 

I bet the pre-Mar. 16 release of 5.2 cert. pinning worked. Unfortunately, I deleted that one and can't find it anywhere on the web.

Typical MS solution here it appears. Since the IE11 problem was cert. pinning related, MS just disabled it in the quick fix.

 

Okay, thanks for report.

 

If you need the pre-Mar. 16 build of 5.2 for testing, let me know.

 

Big bugs here ......................

First when I test cert. pinning in 5.2, I did so in IE10 private browsing mode to my bank site w/invalid cert. pinning. Got no cert. alert as I mentioned previously. Remember this one.

Next, uninstalled 5.2 and scrubbed my registry of EMET traces. Then I installed ver. 5.1. Imported my previous app. and cert. rules. Tested again using both regular and private mode. Zip - no alert. WTF! Rebooted. This time I got a popup from EMET in regular mode but zip in private mode? Also when alert appeared, it did not block the connection although that was the only option I enabled. What was strange was it appeared to try to block it but the bank connection appeared to override that activity. Might have something to do with the cert. EV status?

Bottom line - try 5.2 again but reboot after your done configuring. Then test private and regular browser mode and see if it works. Please post results.

 

I did some more testing with EMET 5.1 and so far, the only web site where cert. pinning works correctly is my bank's web site. And only in IE regular browsing mode.

I tried two e-merchant SSL web sites that I have pinned and no alerts and no blocking. On the Newegg web site though strange things were going on. Such as SSL cert. would change from VeriSign to Newegg and then back.

Looks like perhaps these recent SSL updates MS did a while back broke EMET cert. processing and no one told the EMET developers?

I wonder if my DNS provider is screwing around here? I use Norton OpenConnect.

 

I just noticed something. Certificate pinning will only work on https domains that are directly accessible via DNS lookup. Take newegg.com for example. It's logon page is https://secure.newegg.com. If you try that using your browser, you are redirected to http://newegg.com.

So at this point, EMET 5.1 cert. pinning is working correctly except for the blocking and not working in IE private mode. Makes me believe there is some type of hidden add-on it is using?

Now to test EMET 5.2.

-EDIT- EMET 5.2 behavior identical to that of 5.1; doesn't block and doesn't work in IE private mode.

This is huge for me since I have been accessing my bank site always in private mode.

 

Found an answer about why EMET cert. blocking is not working. Appears to be related to WIN 7 and below, running with an admin level account, and UAC enabled. Appears to not be a problem with WIN 8. Also appears MS hasn't done didly squat to fix the problem.

https://social.technet.microsoft.co...b/emet-50-pinning-rule-doesnt-work?forum=emet

 

Finally starting to get a grip on this cert. pinning issue. Again if you're running Win 8, you should not be having any issues since that OS straightened out many issues with UAC. In WIN 7, the issue appears to be the default limited admin account and UAC.

If I start up IE as admin., cert. pinning works perfectly and is responsive as hell. Alert popup appears immediately and the web page display is blocked. Also works perfectly while inprivate browser mode. I also suspect that cert. pinning will work fine running under a standard user account. Perhaps someone can test that since I don't one set up on my PC?

So the question is now how to get around the UAC issue in cert. pinning? I don't believe you can disable UAC at EMET start-up time since the EMET GUI requires it. Open to ideas here folks.

Or, just run IE as admin when visiting your bank/financial sites and then shut down IE.

 

Found the culprit!

In IE10 on WIN 7 x64, it is EPM. Since obviously, you want that on for your Internet zone setting, the best work around to date I have found is your going to have to add your financial web sites to the Trusted zone. Then turn off EPM for that setting if you have it set on. Afterwards, all your sites with invalid certs. will be blocked.

Why the heck MS hasn't figured this one out is beyond me. Also contemplating why when running IE in admin mode, there was no issue with EPM interfering with certificate pinning. Definitely proof why you never want to run your browser with full admin privileges.

Also the https site verification checkbox has no impact on certificate pinning behavior so you can have that unchecked if you presently have http sites set up in the Trusted zone.

-EDIT- Found this gem in an old EMET 4 web posting. Appears MS still hasn't fixed the issue.

Fine-print continues: pinning only works for the standard version of IE which has 32-bit renderers. It does NOT work with 64-bit renderers used by Enhanced Protected Mode. This is a problem. EPM itself is a security feature; for example, it has additional mitigations against memory corruption vulnerabilities. Asking users to disable one defense in order to take advantage of a completely orthogonal one is dubious at best.

-ADDITION- Another plus for adding your financial web sites to the Trusted zone in IE w/EPM off. Those indirect secure web sites accessible only from vendor main web site such as the Newegg.com example I referenced previously now notify and block properly using EMET cert. pinning.

-SUMMARY- As far as I am concerned if your using WIN x64 and using the default limited admin logon, this is the best solution until MS fixes the EMET blocking issue when using IE with EPM set on

 

could you check if IE 11 processes with IL=AppContainer are lacking green flag in the running process section?
(in the ex below, AppContainer PID= 1836)

EMET 5.2, IE11 EPM on, 8.1

 

You could compare the process ID's to figure out which iexplore.exe processes are listed as protected in EMET.

 

while PE shows all IE processes as injected, EMET GUI shows injection only in IE broker (PID 2528, IL medium) and into the child process (PID 2312, IL Low) with IL different than AppContainer...

I don't know if it's the expected behaviour but it is replicable in VM.

 

I posted on TechNet EMET forum BTW the issues I found with certificate pinning.

I also posted an enhancement request for it. That is to allow for the thumbprint verification of the pinned web site to be added to the existing validation processing. This would prevent any spoofing of web site certs. You could use Steve Gibson's Shield's Up web site or any known secure PC to get the thumbprint of web site and manually add it to the EMET pinning rule.

 

I think I found a bug in EMET 5.2 (or older) that puts a security hole in your Windows 8 computer. I have not yet checked other versions of EMET but Windows 8 is related.
Update: I've been able to reproduce it with EMET 4.1 as well!

Steps to reproduce on Windows 8:

1. Install EMET
2. Set System DEP to Always On
3. Change System DEP back to Application Opt In
4. Reboot
5. Notice that all 32-bit applications have DEP disabled PERMANENTLY. Application Opt In becomes NEVER!

Note that the trick is to touch the System DEP setting by changing it to Always On and then back to Application Opt In. Though I think there might be other ways to trigger the issue. Update: yes there is.

You can use Process Hacker to verify this is true:



I was hoping someone is able to reproduce the issue I am seeing. I have tested on Windows 8.1 both 32-bit and 64-bit. Update: confirmed.

The thing with DEP being permanently disabled is that attackers have no problem to execute code on the heap because any code on the heap can be executed. Processes have no way to enable DEP as the API's return "Access Denied" due to the problem caused by EMET.

Update: EMET is making a registry setting that is invalid on Windows 8 causing DEP to be permanently disabled.

 

Even with DEP set to AlwaysOn you can just allocate RWX memory on the heap using VirtualProtect() and execute a piece of shellcode that is stored on the heap.

 

i've followed your steps on 8.1 x64 but i'm unable to confirm your finding

http://i62.tinypic.com/301fvxs.jpg


I must apologize, in the procedure it's clearly stated to check for 32bit binaries!

 

I know. But you need address of VirtualProtect() and perhaps a ROP to do it. Without DEP no need to call VirtualProtect(), just execute the code on the heap.

 

You did reboot in between?

 

yes, i followed step by step your procedure (in VM)

I'll try again

 

Apparently it can also be reproduced by setting the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel\
MitigationOptions REG_QWORD 0x00000002

This value is set by EMET. Manually setting it also triggers the issue.

NOTE: Reboot after you changed the value.

 

How did you turn DEP off? I know in WIN 7 once DEP is set to always on, you can't reset it from the Control Panel, Advanced Settings option. You have to set it off using BCDEdit command. Then you can reset it to opt in/out via Control Panel option.

http://www.thewindowsclub.com/disable-data-execution-prevention.