EMET (Enhanced Mitigation Experience Toolkit)

New research by Duo Security: Bypassing EMET using the WoW64 compatibility layer provided in 64-bit Windows editions

Edit: Ok, guess I'm too late... https://www.wilderssecurity.com/threads/latest-emet-bypass-targets-wow64-windows-subsystem.381168/

 

EMET settings and Registry Key enforcing same policies

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel\

field name MitigationOptions, a QWORD field type (64-bits) with a complex value structure, e.g. See this official link

This registry key seems to be used for a lot more mitigation as unoffical sources mention see this unofficial link (scroll to line 1133 and down)

0x000000000000F = DEP
0x00000000000F0 = SEHOP
0xF000000000000 = UNTRUSTED FONTS

F = opt-in (1), opt-out (2), all-ways on (5), disabled (6)

I have put in: 5000000000055 (so skip first 0x)

 

Great, thanks. But this works only on W10?

 

As far as I know, yes https://support.microsoft.com/en-us/kb/3053676

 

thanks for this info, sadly that field name breaks things and I cannot comment more now until microsoft make a fix. Feel free to PM me for info, I did make a thread on here but asked the mods to hide it.

 

@Windows_Security When Google Chrome processes are running within AppContainer, EMET does not seem to be able to inject those particular processes. Have you noticed this as well? Should we be concerned, or is AppContainer pretty solid?

 

I don't secure Chrome with third party software, but every man for himself to decide.

The Chrome sandbox has new features: App_Container and Win32k_lockdown, you can enable them with about flags.

Chrome also uses heap partitioning extensively (objects in a partition can't touch objects in another partition), see flash example.

Although intended for speed and not for security the V8 javascript engine uses hidden classes to generate optimised machine code in stead of libraries/fixed offset data structures used by javascript compilers. This obfuscates (hence hidden) the code being reused (in stead of shared it in a reusable library) making it harder to exploit javascript.

Also end of Q4 of 2015 first releases of site-isolation were pushed through Canary builds. Enabling site-isolation in about flags is a little premature. Site isolation protects against these threats It is possible to enable site-isolation in about flags, but then it is enabled for it is not advisable to use a new experimental features on HTTPS websites (like online banking). You can test site isolation with the following command switch --isolate-sites-for-testing=http://* This way only un-encrypted(less secure) HTTP websites are isolated in their own sandbox.

Chrome protects its user configuration (User Data) with ACL's. I added a DENY ACL for Everyone on my download folder. See pic

 

EMET 5.5 Final
Link: https://www.microsoft.com/en-us/download/details.aspx?id=50766


EMET 5.5 release includes new functionality and updates, including:

• Windows 10 compatibility
• Improved configuration of various mitigations via GPO
• Improved writing of the mitigations to the registry, making it easier to leverage existing tools to manage EMET mitigations via GPO
• EAF/EAF+ perf improvements
• Untrusted font mitigation for Windows 10​

 

EMET 5.5 Final build number is: 5.5.5871.31892

As with the previous 5.5 Beta, they have the Microsoft EMET Service set to Automatic (Delayed Start). So if you want the EMET tray icon to show up sooner like previous versions of EMET, simply switch the service to Automatic.

I have noticed that when using Chromium with the AppContainer sandboxed processes flag, the EMET GUI does not show a check mark for EMET protection of those particular AppContainer protected processes. However, when viewing those processes in Process Explorer, it does show EMET64.dll injected properly into those processes. So it seems that they may very well still be protected, yet the EMET GUI is not reporting that correctly.

 

Back when the Duqu malware used a TrueType font kernel exploit, before Microsoft released a patch, they released a FixIt (50792).
This FixIt would deny access to t2embed.dll to stop the exploit. Does anyone know how this would compare to the Untrusted Fonts feature in Windows 10?

 

Enhanced Mitigation Experience Toolkit (EMET) version 5.5 is now available
http://blogs.technet.com/b/srd/arch...oolkit-emet-version-5-5-is-now-available.aspx

 

I will test 5.5 to see if they fixed the nasty DEP/SEHOP bug.

 

I tried it last night in Windows 7 Ultimate and had to go back to 5.2. It would give me a dialog that "bit locker needs to be suspended" before it would change DEP settings. It gave me the option to change settings anyway but didn't do it and gave me another dialog saying it wasn't allowed. I don't have bit locker active and the service wasn't running. I will see how it does in Windows 10.

 

EMET 5.5 User Guide: https://www.microsoft.com/en-us/download/details.aspx?id=50802

Some important excerpts (including some changes between 5.5 Beta and 5.5 Final):

Powershell Converter Script for 5.5: https://www.microsoft.com/en-us/download/details.aspx?id=50801

 

CVE-2015-2545 ITW EMET Evasion

 

With Windows 10 we have implemented many features and mitigations that can make EMET unnecessary on devices running Windows 10.

----------------------------
Microsoft: Windows 10, Edge so secure they don't need our EMET anti zero-day shield
http://www.zdnet.com/article/micros...they-dont-need-our-emet-anti-zero-day-shield/

 

Interesting.
This list P.B. Also includes other examples:

http://peter.sh/experiments/chromium-command-line-switches/#isolate-sites-for-testing

Have you noticed problems?
TH

 

@Sampei Nihira

When you look at the threatmodel information in the site-per-process/site-isolation documentation, the most important benefits of site isolation are to protect HTTPS sessions. That is probably the reason the sample mentions HxxPS//* explicitly.

Because HTTPS sites are important to me (banking, government, SAAS/cloud solutions, online purchases) I am using this new feature on unsecure websites only. I have not ran into problems yet with this chrome switch (--isolates-sites-for-testing=HxxP://*).

This (importance of encrypted/safe websites) is also the reason I don't use uBlockOrigin. In stead I use Script Blocker for Chrome, which has the option to block scripts/iframes/plug-ins of third party (by allowing same domain). When I use my PC for business, it is easy to check whether Script Blocker for Chrome is switched OFF (see pic)

 

I do a test.
Chrome (64-bit) + 2 command line (on S.U.A.)

--isolate-sites-for-testing=http://* --no-referrers

TH.

 

i ditched no referrers because that provides a problem with a cloud service

 

TH.
I do not use a cloud service.
Problems also insert messages on some forum:

 

anyone who has installed emet 5.5 on win 8/8.1/10 please do this simple test for me?

Change DEP to either opt-in or opt-out in the EMET gui.
Reboot.

In a elevated command prompt run bcdedit.

Look at that the nx line says please and see if it is correct by tests.

emet 5.2 and older broke dep optin and optout modes.

 

You mean this issue I pointed out almost a year ago?
https://www.wilderssecurity.com/thre...xperience-toolkit.344631/page-45#post-2474882

 

ahh so you noticed as well, yep same exact issue.

I reported it to microsoft a month or so ago, I even kindly on their request got my thread on here hidden, but they never got back to me after their first reply and since released 5.5. But I cannot be bothered to install it now I am using your product

Thats an insane bug for them to not notice.

 

"US-CERT is aware of a vulnerability in Microsoft Enhanced Mitigation Experience Toolkit (EMET) versions prior to 5.5. Exploitation of this vulnerability may allow a remote attacker to bypass or disable EMET to take control of an affected system.

US-CERT recommends users and administrators visit the Microsoft Security TechCenter (link is external) and upgrade to EMET version 5.5."