What is EMET? EMET is a free tool provided by Microsoft, and the name stands for the Enhanced Mitigation Experience Toolkit. That's kind of a mouthful. What does that actually mean? Well essentially EMET is a bundle of compensating controls for exploitation. What that means is it's a series of protections designed to make exploitation of vulnerabilities in Windows and Windows applications much harder, and make it difficult for exploit developers to create reliable exploits. And we're going to come back to that concept of reliability a little later, it's very important.
So how does EMET accomplish this goal? Well it has a lot of different protections packaged in, and each one of these protections can be configured on an application by application basis. And that is a very important difference. So the first protection is what's called DEP, or Data Execution Prevention. Data Execution Prevention is just a mechanism that prevents non-executable memory. That is, memory that is set aside for holding data but isn't meant to hold instructions. It's meant to prevent anyone from telling a program to execute that piece of memory as a series of instructions, which was the traditional way that buffer overflows used to work. They would just load data into memory and then tell the program, "Oh, this is where the execution is now," and it would read those instructions. So DEP prevents the execution from moving into those non-executable sections of memory.
DEP has existed for many years now, but was originally only opt in due to application backwards compatibility issues and hasn't had a full permeation even in modern Windows operating systems. EMET allows you on, again, an application by application level basis to enforce DEP. To tell an application, "I know that you don't want to opt in to DEP but guess what, if you're going to run on this box, you're going to use DEP."
The next mitigation is one called ASLR, or Address Space Layout Randomization. This is another mouthful and you can start to see why we use acronyms so much. ASLR is another one that's been around pretty much since the same time as DEP, and all Address Space Layout Randomization, or ASLR, does is whenever you load libraries such as DLLs into a program they are loaded into certain places in memory. ASLR swaps around where in memory those individual modules are loaded each time the program loads. What this means is that an exploit developer can't use hard coded addresses most of the time because those addresses are going to change every time the program starts. So they're going to be different from box to box, they're going to be different every time the program crashes and is restarted or every time the machine reboots. That means that any exploit written with a hard coded address is not going to be reliable and is going to be essentially useless. Now there are ways to bypass ASLR, but it is still a good compensating control that just adds a little bit to the level of difficulty of writing an exploit.
Next is SEHOP. SEHOP is the Structured Exception Handler Over-write Protection. Structured Exception Handlers are built within Windows applications in a chain, and basically all they are is something that handles when an error occurs. So if an error occurs within an application, the first structured exception handler will see if it knows how to deal with that error. And if it doesn't, it's going to move down the line and pass it to the next structured exception handler, and pass it to the next structured exception handler, and so forth. What we do in a structured exception handler overwrite is overwrite one of those handlers so that instead of pointing to a piece of code to handle that error, we point it back to the malicious code that we have injected into memory.
What SEHOP does is it actually checks the integrity of that SEH chain by walking it from start to finish and making sure that when it starts at the first SE handler that it gets all the way to the final SE handler. And if it cannot do that, then it marks the SEH chain has been compromised and it will stop execution in that thread. So SEHOP is extremely effective. SEH overwrites have been one of the predominant means of buffer overflow memory corruption exploits for the past 10 years or so. And SEHOP pretty much stops them dead in its tracks. If it is enabled in the application and all of its loaded modules, you're not going to be able to pull an SEH overwrite. But if there's any wiggle room in that, if parts of the application have SEHOP but parts of them don't, you have windows of opportunity as an exploit dev to still abuse this. And that's why having EMET is really important because, again, it allows you on an application by application level basis to enforce SEHOP onto a system.
Next we're going to talk about ROP, or Return Oriented Programming. Some of you may have heard of this and not really be quite clear on what ROP is. I'm not going to go into a lot of detail, but suffice it to say Return Oriented Programming was an exploitation technique designed specifically to bypass Data Execution Prevention. So remembering that we could not execute code or instructions from non-executable memory, what ROP seeks to do is use instructions that are already inside the application and it jumps a piece at a time, forming a series of instructions that are already scattered throughout that application until it can call one of several Windows API routines that will then mark that section of memory as being executable, therefore bypassing DEP.
Now, EMET has a large number, actually, of different ROP mitigations, and we don't have time to get into all of them. But suffice it to say that these mitigations help make it much more difficult to use ROP as a means of bypassing DEP. ROP mitigation combined with DEP and ASLR, and of course SEHOP, all work together to really just neutralize a lot of the standard techniques that exploit devs have been using for a long time, and while it's not full-proof, it makes it much harder for an exploit to be reliable. And that is a key thing. If an exploit isn't reliable, it's not really useful. If it works on one system but not another, it's not really going to be that much of a threat.
Before we move on and recap, there is one thing that's not quite related to exploitation itself that I want to talk about, and that is the Certificate Trust System in EMET. Certificate Trust is basically a portion of the tool that allows a user to very easily configure rules for certificate pinning. Certificate pinning is part of a trust validation on SSL transport layer encryption certificates. The overall goal of this system is to prevent somebody from using something like a fake SSL cert to carry out a man in the middle attack by injecting themselves between you and whoever you're talking to, and putting up a fake SSL cert so that your system thinks that it's a secure connection when it's really not. And so Certificate Trust just allows you as a user to configure rules to help you have that level of certainty.
So what is the TL;DR here? TL;DR is that EMET should really be used by anyone on Windows. Anyone and everyone. Not every person is going to be able to configure on a case by case basis all of the different rules or understand exactly what's going on inside the deeper configuration of EMET, but even just installing it out of the box will provide some basic levels of protection and will be set to the most tolerant levels in terms of application compatibility so that it is not disruptive to a system. In my personal opinion, there is no reason for any Windows user to not install EMET as one of the first things they do when they have a new Windows machine. The level of protection it affords you, just like antivirus, while not fool-proof, adds just a little bit to your overall security posture and makes you that much harder of a target.
Thanks for listening and we'll catch you next time.
