Uncertainty And The Cost Of Failed Exploitation

A lot of what people have realized in computer security is that keeping attackers at bay is largely about making targets too expensive. By adding a sandbox we ensure an attacker needs to either monetize the sandbox or make use of an exploit that bypasses it – that second exploit is going to be costly.

Sandboxing is one of the most popular and effective methods for raising the cost but it’s by no means perfect.

I think another cost we should focus on is the cost of failed exploitation. While sandboxing raises the cost of a monetizing the system an attacker can still come up with a reliable way of breaking through it, dispatch the exploit, and make their money.

What I would like to see is a method of raising the cost of exploitation through uncertainty. ASLR randomizes a processes address space and when implemented properly an attacker is often forced to use less reliable means of attack, bruteforcing through an address space for example or repeatedly forking and attempting the exploit. With multiprocess browsers this type of attack seems much more likely to occur in the future.

Attackers need reliability because if they send their brand new 0day out there and it’s not working, or doesn’t work reliably, they’re making way less money and the company responsible for that vulnerable software is going to patch it up before it can be monetized properly. As soon as they release their 0day it’s out there for the world to discover and defend against – they need it to work quickly, they typically have 24-72 hours before a patch is released.

If an attacker has a 1 in 8 chance of successfully exploiting the target but they can constantly fork processes (their attempt to exploit crashes it, the process restarts automatically – the attacker isn’t doing it, just to clarify) and attempt over and over they’ll eventually get a successful hit. The key point here is that the time it takes for this unreliable attack to bruteforce its way to success is far lower than the time it takes for either an administrator to notice the attack or a patch for the vulnerability to come about.

Bruteforce Exploit Prevention, which is built into Grsecurity, is the type of mitigation that takes advantage of unreliable attacks. By detecting the attack, crashing the UID responsible, and waiting before reloading those vulnerable services Grsecurity makes  unreliable attacks far too costly. An attacker who attempts to exploit a service will have released their 0day and gained nothing, and all the would-be victim has to do is report the attack and their 0day will soon be patched. Attackers need to hit fast and hard and across the spectrum or they start pulling in way less and the value of their 0day (in terms of sales) goes way down.

These types of techniques are going to become much more important as systems implement proper ASLR (Windows 8 has made serious improvements) because attackers will have to rely on other methods. Multiprocess browsers are also the type of attack surface where an unreliable exploit can be bruteforced over and over again and as more browsers move to this model we will likely see these attacks used.

EMET v3.0 – What’s New and How To Set It Up

Microsoft has released version 3.0 of EMET (Enhanced Mitigation Experience Toolkit), a must-have security tool for Windows. To summarize my previous post on EMET, it is a lightweight exploit mitigation tookit that forces programs to make use of modern security techniques – simply put it makes programs more secure. This guide will show you how to set EMET up to secure your Windows system without infringing on your program compatibility. I highly recommend you follow this guide and set EMET up accordingly. I’ve included screenshots to make this guide as clear as possible – setup for 3.0 is just a few minutes.

The major changes in EMET 3.0 are the new pre-made profiles, which make setup easier, and the notifier. EMET will now give a notification when it detects an exploit and you can read about the new pre-made profiles later down the page. You can disable the notifier through msconfig.exe or exit it by clicking the EMET icon in your system tray. I suggest you keep it on unless you’re running on a very old system.

EMET has two main interfaces: one to deal with system wide settings and one to deal with application specific settings.

System Settings:

When you open up EMET you’ll see:

Click “Configure System” and you’ll be brought here: (Your settings will look different)

My suggested configuration is:

DEP: Always On

SEHOP: Always On

ASLR: Opt In

What this means is that all programs will be forced to use DEP and SEHOP and programs have the ability to opt into using ASLR. If you are noticing instability you can change the DEP setting to “Opt-Out” or back to “Opt-In” but I strongly recommend you try Always On first. SEHOP can only be set to “Opt-Out” on Windows 7.

That’s all it takes to set EMET up system wide. (And a system reboot, which you can do after following the rest of this guide.)

Note: ATI Drivers 12.6+ are now ASLR compatible. You may want to give ASLR Always On a try!

Application Specific Settings:

EMET 3.0 makes securing individual programs incredibly easy. Click the “Configure Apps” button on the bottom right of the EMET GUI.

You’ll see this:

Go to File -> Import and navigate to /Program Files(86)/EMET/Deployment/Protection Profiles/all.xml and open it through EMET.

This will add a large list of programs, already configured, to your EMET list. You can change this up if you like but right away your system is much more secure. The default settings seem to cover the most important areas.

If you want to add another program just click “Add” and navigate to the .exe.

The highlight of the preconfigured .xml is that all Java executable files as well as your browser and browser plugins are configured to use EMET. These are the most commonly exploited programs and hardening them is a critical step in securing your system.

You may receive a notification from the EMET Notifier. A new feature to 3.0 that lets you know which security mitigation was just used to prevent an exploit.

 

 

 

That’s all there is to setting up EMET. This should take just a few minutes (including time to download) and it’s the first step to securing Windows. I hope this guide helped.

Tip: If you notice an EMET’d program acting out try disabling EAF. It can cause issues.

You can download EMET from:

https://blogs.technet.com/b/srd/archive/2012/05/15/introducing-emet-v3.aspx?Redirected=true

Note:

It is worth stating that just because you use EMET does not mean you can forego patching. While EMET is an incredible tool for securing Windows it is not a silver bullet, you must keep your system up to date.

Sources:

http://blogs.technet.com/b/srd/archive/2012/05/15/introducing-emet-v3.aspx