Mar 15 2013

Processes security: EMET configuration, enabling DEP, ASLR…

In order to control what processes are running on your clients you can use the Software Restriction Policies or tools like Applocker or Bit9. You can also increase the security of you system on the allowed processes by enabling some mitigations like DEP, ASLR, SEHOP… We will describe in this post how to use EMET: A tool provided by Microsoft which allows you to configure these features. By protecting the processes running on your computer with these features you can even be protected against some 0-day exploits.

You can setup these security settings by using a GPO, thanks to the ADMX files shipped in the EMET 3.0 package. The security settings are only effective when you install EMET on your clients, as a result you will need to deploy the package on all your clients with a software deployment tool (this is my recommendation), or via a GPO. In addition, in order to apply/renew the settings configured with the GPO you will need to launch the following command at client startup:

EMET_Conf.exe --refresh

We will configure the following emet.vbs startup script in our GPO:

Set fso = CreateObject("Scripting.FileSystemObject")
Set shl = CreateObject("WScript.Shell")
 
path="C:\Program Files (x86)\EMET\" 
exists = fso.FolderExists(path)
 
if (exists) then 
	program="EMET_Conf.exe"&chr(34)&" --refresh"
	cmd = chr(34)& path & program
	shl.Run cmd,1,True
end if
 
path2="C:\Program Files\EMET\"
exists2 = fso.FolderExists(path2)
if (exists2) then 
	program2="EMET_Conf.exe"&chr(34)&" --refresh"
	cmd2 = chr(34)& path2 & program2    
	shl.Run cmd2,1,True
end if

The ADMX files allow you to configure system wide mitigations: We enable DEP, ASLR and SEHOP in Optin mode (default mode) for all the processes. Then you can configure each process individually: We load the templates provided by Microsoft, who already tested some third party applications (Adobe Acrobat, Firefox)… Finally the result is a fat GPO which installs and configures EMET settings:

GPO-aslr-dep

Before you deploy EMET, my advice is to read carefully the EMET User’s Guide shipped in the package and, of course, to test before implementation.

In order to know if an application is compiled with these mitigations available you can use binscope. Let’s take for example the nxfinder.exe process, we launch Process Explorer on a Windows XP 32bits machine where our GPO is not applied yet:

processxpDEPdisabled

You can see that the process is digitally signed but the DEP mitigation is not enabled. We launch the binscope in order to analyze this process and check is the ASLR, DEP and SEHOP mitigations are available:

binscope

The following checks are performed:

  • SafeSEHCheck: SEHOP feature.
  • DBCheck: ASLR feature (/DYNAMICBASE check).
  • NXCheck: DEP feature (NXCOMPAT Check).

binscope1

As processes linked with the /NXCOMPAT option are opted-in to DEP by default only prior to Windows Vista, DEP is not enabled on our Windows XP 32bits machine for this process although it is totally compatible to run with DEP enabled. We will tell EMET to enable all mitigations for this process except SEHOP, because binscope tells us it is not necessary as the binary does not use exceptions. In the above fat GPO you can see the settings applied for the nxfinder.exe process. On the Windows XP 32bits machine, we can see with Process Explorer, that DEP is now enabled once the GPO has been applied:

processxpDEPenabled

Because ASLR is only available prior to Windows Vista, you can notice that we do not see this mitigation with Process Explorer under Windows XP 32bits. If we launch the same tool on a Windows 7 64bits system you can see the ASLR protection in the processes properties. In addition you can notice that DEP is always enabled (permanent) for 64-bit native programs:

windows7aslr

With Process Explorer you can also check all the mitigations applied on each individual process by EMET, right click on a process in order to display the properties tab, navigate to the environment tab and check the EMET_settings value. You can also notice that the emet.dll is present in the threads tab on each process protected by EMET:

emet_settings

Another very good mitigation could be to disable all 32bits processes, this is for two reasons: Most malwares are 32bits processes so they won’t be able to run on those machines and you know that at least DEP will be enabled for all the processes. You can only achieve this under Windows 2008R2 Core. As EMET is a 32bits application, we will not apply the GPO on the Windows Core machines where 32bits processes are disabled (security group SRV-32bits-DISABLED):

deny-32bits-emet

Before disabling ServerCore-WoW64, ensure that not a single 32bits process is running on your Windows server core…

This post is also available in: French

No Comments

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

*

WordPress Themes

Blossom Icon Set

Software Top Blogs