Sometimes, we all need someone to have our back. Applications, believe it or not, are the same way, and sometimes applications don’t always behave as we expect them to. While Windows has some built in protections for program misbehavior and exploitation, it can sometimes be difficult to tell if those protections are active and what exactly they are defending. Enter the EMET.
What is EMET?
The Enhanced Mitigation Experience Toolkit, or EMET, is basically a shield or a shell that runs over Windows application and forces them, regardless of how those applications have actually been coded by their developer, to take advantage of security defenses that are built into the Windows operating system. EMET is a wrapper that enables and enforces a set of protections that, when used together, really enhance the security posture of a machine and greatly reduces the chance that exploits can run against your machine and cause any harm—most will simply fail to execute completely. It is particularly helpful in protecting against exploits that have not yet been patched by a software developer, making it a key tool that should be in your security arsenal.
EMET relies on four main defenses to offer its protection, and these are based on the following security technologies:
- Data execution prevention. Data execution protection, or DEP, was introduced in Windows XP Service Pack 2 and has remained in Windows ever since. Essentially, DEP checks applications that are loaded in memory, and identifies pages in memory that are explicitly marked as executable. If a piece of code attempts to run from a place within memory that is not explicitly designated as application space, on systems with compatible CPUs (all modern CPUs from 2005 onward support this feature) Windows will disable the code from running. While DEP is always enabled on 64-bit versions of Windows and for 64-bit applications themselves, so there’s nothing to configure and no added benefit from EMET, 32-bit applications running on either a 32-bit or 64-bit version of Windows have the potential to misbehave that DEP combined with EMET can help prevent that nefarious behavior.
- Address space layout randomization. Address space layout randomization, or ASLR, is a technique primarily designed to prevent the old buffer overflow attack vector. ASLR basically scrambles up the locations of an application’s base executable, the stack, heap, and associated application libraries, across all of the address space available to the operating system. The hope of ASLR—and this has borne out to be a valuable protection in production—is that if an exploit is actually loaded into memory, a cracker cannot avail himself or herself of it by simply overflowing from one buffer and jumping into the next space. The attacker basically has to guess where the vulnerable code is living in memory, and it is different each time the application is loaded. In addition, the application usually is not written to handle the guessing and will crash, further thwarting the attacker’s exploit.
- Structured exception handler overwrite protection. Structured exception handler overwrite protection, or SEHOP, is a protection scheme that defends against exploits that overwrite a return address on a thread’s stack to point to bogus code that does bad things. This happens, among other times, with buffer overflows: the software’s exception handling will perform some functions that can let an attacker point the exception dispatcher to an address that will run malware. SEHOP makes sure that the list of exception handlers is valid before an application can call them. SEHOP works in conjunction with the aforementioned ASLR technology to basically prevent structured exception handling overwrites. (This is a pretty detailed developer-oriented technology, and I have tried to simplify it here but still explain the overall attack and what is done to defend against it. For a great technical explanation of SEHOP if you have the chops, look at http://blogs.technet.com/b/srd/archive/2009/02/02/preventing-the-exploitation-of-seh-overwrites-with-sehop.aspx.
- Certificate trust. Sometimes called “pinning,” certificate trust is new to this version of the EMET. Basically, EMET’s certificate trust lets you create pinning rules that specify the certificates and root certificate authorities that your systems should trust. By doing this, you can prevent funny business with certificates: from man in the middle attacks that use untrusted certificates to impersonate legitimate services, to preventing illegitimate certificates issued improperly by trusted certification authorities that have experienced a breach or a misexecuted protocol. For example, Comodo, a certification authority, in March 2011 issued nine fraudulent digital certificates. In November 2011, a Malaysian certificate authority issued 22 certificates with a very weak 512-bit key that is fairly easy to break. EMET’s certificate pinning feature lets you take matters more fully into your own hands and decide specifically what certificates and which issuers you trust. Unfortunately, it is only useful if you primarily use Internet Explorer, as you cannot pin certificates from sites in Firefox, Google Chrome, or any other Internet browser.
As it happens, the weaknesses in each of these technologies offset one another—where DEP is weak, ASLR is not, and vice versa, and so on. DEP acts as a kind of front door on attacks, making it harder to get them to execute, and ASLR backstops it by making a scrambled mess (from the point of view of the exploiter) out of the memory space a vulnerable application uses so that the attacker has a harder time carrying out their malfeasance. SEHOP works with ASLR to prevent random code from executing in specific address spaces the attacker wants. (Certificate pinning is a new feature not really related to the other technologies, but it still offers a posture improvement over plain vanilla Windows.)
EMET’s current version, version 4.0, enables a pre-configured wrapper of protection for some default applications with known deficiencies and vulnerabilities, like Adobe Acrobat and the Java runtime, as well as common Microsoft applications like Office and Internet Explorer. This preconfigured protection is optional and you can configure custom protection on your own if you like, but the new defaults are a quick way to deploy some defenses sooner rather than later while you ramp up your custom deployment of the tool.
EMET is supported on Windows XP Service Pack 3 and later, Windows Vista Service Pack 1 and later, all levels of Windows 7, and Windows 8 on the client side. From the server operating system perspective, EMET is supported on Windows Server 2003 Service Pack 1 and later, all levels of Windows Server 2008, all levels of Windows Server 2008 R2, and Windows Server 2012 and Windows Server 2012 R2.
Setting Up EMET
The latest version of EMET is 4.0, and you can download it from the Microsoft website here [link: http://www.microsoft.com/en-us/download/confirmation.aspx?id=41138 ]. Once you have downloaded the tool and run the simple MSI installation, just like any other Windows application, load the program. You will see a window much like Figure 1.
Figure 1: the main screen from EMET
In the System Status area, you can see whether the overall protections of DEP, ASLR, SEHOP, and certificate trusts are enabled and active or not. The first step to actively protecting your system is to click the Configure System button, which displays the System Configuration window, as shown in Figure 2.
Figure 2: the System Configuration window in EMET
Within this window, you can choose from various profiles that are already set up. Since you are just starting out, go ahead and choose the Maximum Security Settings profile so you can get a sense of the defenses. Once you select this, you will be prompted for a reboot; do not yet.
Instead, open an command prompt with administrative privileges and let’s activate the default profiles.
- From the command prompt, type: cd “C:\Program Files (x86)\EMET 4.0”
- Type the following command:
EMET_Conf.exe –-import “Deployment\Protection Profiles\Recommended Software.xml
You will see confirmation messages like the following:
EMET is importing configuration, please wait…
Processed 86 entries
The changes you have made may require restarting one or more applications
That is your signal the profiles are installed and are working.
Now, you need to tell EMET what applications you typically use. You do this through the EMET graphical user interface, although as we just imported some default profiles through the command line, there will already be some existing entries in the interface. To continue setting up and adding applications:
- Open the EMET GUI from the Start menu.
- In the ribbon, within the Configuration section, click Apps.
- The Application Configuration screen appears. In the ribbon, within the Add/Remove section, click Add Application.
- A standard browse box appears. Browse to the location of the program you want to add and then click Open.
- The application will be added to the list on the Application Configuration screen. Each of the columns represents the defense technology and protection that should be applied to that particular executable: DEP, SEHOP, and so on. Start out with all of the protections enabled when you add executables.
- Launch the program. You may need to restart your computer first if this is the initial load of EMET on that particular system.
Fine Tuning with EMET
Since EMET acts as a shell around an application, said application’s creator could not anticipate some of the methods EMET uses to affect an application running. This means that you will likely run into some compatibility issues as you start rolling out EMET across your organization. Some observations:
- Begin with Internet facing applications. These applications are the ones most likely to contain exploits and those most likely to cause damage by spreading. Also, your users probably spend a lot of time in these applications. You will get the most “protection” bang for your buck here, and as a bonus, you can weed out terribly programmed Internet apps. Conversely, your custom line of business applications and software you wrote for your business in house is unlikely to be exploited and little value would be derived from trying to make it work with EMET if it does not by default, so I would not advise wasting your time.
- Understand ahead of time which applications are not likely to work well with EMET. Google Chrome is one that comes to mind immediately—I have had little success in running EMET with Chrome unless the Export Address Table Access Filtering defense (EAF, the fifth column from the left in the Application Configuration section of the EMET GUI) is disabled. Skype, which I used to use on a daily basis, is another application that needs EAF turned off. But essentially, as everyone uses a different set of programs with different risk profiles, you will need to play around and test to figure out exactly which security postures work for your organization. Start by disabling different threat protectors within the tool for programs that are acting wonky; only disable EMET for that particular application as a last resort.
- Deploy EMET and manage it using Group Policy. Look inside the EMET folder after it is installed, copy out the EMET.ADMX and EMET.ADML files, and copy them into the \Windows\PolicyDefinitions and \Windows\PolicyDefinitions\en-US folders on a domain-joined system—but NOT a domain controller. This will add settings to control the EMET tool to the Group Policy central store, so all you have to do is roll out the MSI to your workstations and let Group Policy handle the configuration for you.
The Last Word
The Microsoft Enhanced Mitigation Experience Toolkit is a complex but useful tool to protect the integrity of your desktop and laptop machines—computers that would traditionally be used by employees. I recommend it in that context. It has the potential to cause more trouble than the protection it offers is worth in server contexts and on computers where IT pros and power users who are less likely to download and activate malware are the primary users, so proceed with caution in those scenarios, but overall the EMET provides an effective additional layer of defense against potentially enterprise crippling malware. You should evaluate it today.
This article originally appeared, with edits, at Computerworld.