Recently, there have been several zero-day vulnerabilities affecting a variety of popular applications. Some of these vulnerabilities, including CVE-2010-1297 in Adobe products and CVE-2009-2719 in Java Web Start, are actively being used to launch attacks.
Mitigation technologies can play a vital role in enterprise defences and can certainly help manage risks.
These can be effective attack methods, as regular perimeter defences such as antivirus, antimalware and intrusion detection systems have no signature with which to trap them. It's therefore important to incorporate the security-by-obscurity approach into your network defences in order to provide some form of zero-day protection.
Security-by-obscurity is based on the assumption that enterprise applications will never be completely bug free. Therefore, an organisation must use whatever tools and technologies it can to make exploiting any bugs and automating an attack as difficult as possible. Technologies that make it more difficult for an attacker to exploit vulnerabilities in a software application are known as mitigation technologies. Microsoft has added several mitigations to Vista and Windows 7, such as Address Space Layout Randomisation (ASLR) and Data Execution Prevention (DEP).
However, even though a new Windows server may support these technologies, they're only effective if they are incorporated into an application by developers. A recent report by vulnerability clearinghouse Secunia ApS (.pdf) revealed that many popular software applications either don't yet support these tools or are improperly implemented so the systems are still at risk. Additionally, many organisations still run earlier versions of Windows that don't incorporate these security controls.
This is why Microsoft's Enhanced Mitigation Experience Toolkit (EMET) is such an important tool in the battle to defeat zero-day exploits. This set of free Windows security tools works by retroactively applying various security mitigation technologies to selected applications in order to block common attack vectors such as buffer overflows and memory corruption.
The recently released version 2.0 adds two new mitigations, Mandatory Address Space Layout Randomisation (Mandatory ASLR) and Export Address Table Access Filtering (EATAF), to the following tools, which were already supported since EMET 1.02 was released in October 2009: Structure Exception Handler Overwrite Protection, Dynamic Data Execution Prevention, Heapspray Allocations and Null Page Allocations*.
ASLR was introduced in Windows Vista and combats attacks by loading modules into a different area of memory each time, but it only works for applications that explicitly enable it when they are compiled. Mandatory ASLR, however, can force the operating system to load a dynamic link library written before ASLR was available to a random location, regardless of the flags it was compiled with. EATAF blocks a common technique that malware uses to locate Windows APIs from which to launch an attack and is designed to break most shell code when it tries to lookup the APIs needed for its payload.
One of the big advantages of using Microsoft EMET is that in-house software need not be recompiled to set the various flags in order to enable DEP and ASLR. It isn't even necessary to have access to the source code for an application. EMET allows you to opt-in applications and apply mitigations on a per-process basis. This is useful when a process within a suite of applications is not compatible with a particular mitigation technology -- you simply turn that mitigation off for that process.
Version 2 of EMET also features a new graphical user interface that makes it easier to configure mitigations and see the status of the different system mitigations, including whether any of the running processes have been opted-in to EMET. System-wide mitigations can be configured either by selecting the Maximum Security Settings profile or the Recommended Security Settings profile. (Note that for the selected configuration to become active, the newly configured applications will need to be restarted.)
It is possible, of course, to set the mitigation configuration individually, and it's essential to test any changes made using EMET before rolling them out to production systems. Some security settings may break certain applications or change their behaviour. For example, applying DEP can change a boot option, which for systems with BitLocker enabled will force the user to enter his or her recovery key the next time he or she boots up.
EMET 2.0 supports the following operating systems and service pack levels:
- Windows XP service pack 3 and above
- Windows Vista service pack 1 and above
- Windows 7 all service packs
- Windows Server 2003 service pack 1 and above
- Windows Server 2008 all service packs
- Windows Server 2008 R2 all service packs
Microsoft's intention is to add new mitigation technologies to EMET as they become available, so it is worth keeping an eye on future releases. The toolkit already includes several pseudo-mitigation technologies aimed at disrupting current exploit techniques. (These pseudo mitigations are not sufficient to stop future exploit techniques, but can help prevent users from being compromised by many of the exploits currently in use.)
Mitigation technologies can play a vital role in enterprise defences and can certainly help manage risks while you're migrating away from legacy software by making it harder for hackers to exploit any vulnerabilities older software may have. I recommend checking out the EMET training video, which looks at many of the mitigations in some depth, and see how this free tool can provide additional protection to a number of IT systems.
* Structure Exception Handler Overwrite Protection protects against common techniques for exploiting stack overflows.
Dynamic Data Execution Prevention marks the stack and heap as non-executable and denies any attempt to execute malicious code from these regions at the processor level. Heapspray Allocations prevent exploits that rely on placing copies of their shellcode at as many memory locations as possible.
Null Page Allocation is designed to prevent potential null dereference issues.
About the author:
Michael Cobb CISSP-ISSAP, CLAS, is a renowned security author with more than 15 years of experience in the IT industry. He is the founder and managing director of Cobweb Applications, a consultancy that provides data security services delivering ISO 27001 solutions. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications.
This was first published in January 2011