http://0xdabbad00.com/2010/09/12/how-emet-works/
I’m interested in how easily EMET
is able to turn DEP, ASLR and other security features on in
executables, so I decided to take a look. I chose an executable, turned
on ProcMon
from Sysinternals, and used EMET to turn on the security on that
executable. I checked the executable afterward to ensure it’s actually
the same as before (so they’re not bit fiddling). I then looked through
ProcMon’s output, and found that it adds a registry key to HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Custom\
with the name of the
file, and with REG_QWORD values that are always the same. For example, I
have:
HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Custom\firefox.exe\{e1c810aa-f7cc-4aaf-ada1-181863075f9b}.sdb
= "8c 05 84 fb f0 4e cb 01"
HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Custom\firefox.exe\{f8c4cc07-6dc4-418f-b72b-304fcdb64052}.sdb
= "8c 05 84 fb f0 4e cb 01"
Those GUID’s then correlate back to keys at HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\InstalledSDB\
which identify
files at the following locations:
C:\WINDOWS\AppPatch\Custom\Custom64\{e1c810aa-f7cc-4aaf-ada1-181863075f9b}.sdb
C:\WINDOWS\AppPatch\Custom\{f8c4cc07-6dc4-418f-b72b-304fcdb64052}.sdb
I then googled for info on .sdb files, and came to the page for a
tool called sdb2xml.
When I ran that on the .sdb file, I got an XML file showing each of
the processes I had turned EMET on for, but I’ll just show the portion
relevant to firefox, along with the rest of the info:
01 |
<? xml version = "1.0" encoding = "IBM437" standalone = "yes" ?> |
05 |
< INDEX_TAG type = "xs:short" >28676</ INDEX_TAG > |
06 |
< INDEX_KEY type = "xs:short" >24577</ INDEX_KEY > |
07 |
< INDEX_BITS type = "xs:base64Binary" /> |
10 |
< INDEX_TAG type = "xs:short" >28691</ INDEX_TAG > |
11 |
< INDEX_KEY type = "xs:short" >24577</ INDEX_KEY > |
12 |
< INDEX_BITS type = "xs:base64Binary" /> |
15 |
< INDEX_TAG type = "xs:short" >28679</ INDEX_TAG > |
16 |
< INDEX_KEY type = "xs:short" >24577</ INDEX_KEY > |
17 |
< INDEXFLAGS type = "xs:int" >1</ INDEXFLAGS > |
18 |
< INDEX_BITS type = "xs:base64Binary" /> |
22 |
< OS_PLATFORM type = "xs:int" >1</ OS_PLATFORM > |
23 |
< NAME type = "xs:string" >EMET Database</ NAME > |
24 |
< DATABASE_ID_x0028_GUID_x0029_ type = "xs:string" baseType = "xs:base64Binary" >{f8c4cc07-6dc4-418f-b72b-304fcdb64052}</ DATABASE_ID_x0028_GUID_x0029_ > |
27 |
< NAME type = "xs:string" >EnableDEP</ NAME > |
28 |
< FLAGS_PROCESSPARAM type = "xs:long" >131072</ FLAGS_PROCESSPARAM > |
31 |
< NAME type = "xs:string" >EMET Shim</ NAME > |
32 |
< DLLFILE type = "xs:string" >EMET.dll</ DLLFILE > |
35 |
< MODULE type = "xs:string" >*</ MODULE > |
40 |
< NAME type = "xs:string" >firefox.exe</ NAME > |
41 |
< APP_NAME type = "xs:string" >EMET
Apps</ APP_NAME > |
42 |
< EXE_ID_x0028_GUID_x0029_
type = "xs:string" baseType = "xs:base64Binary" >{7e589b34-a304-44ef-b715-bb037cb5221f}</ EXE_ID_x0028_GUID_x0029_ > |
44 |
< NAME type = "xs:string" >*</ NAME > |
47 |
< NAME type = "xs:string" >EMET Shim</ NAME > |
48 |
< SHIM_TAGID type = "xs:int" >236</ SHIM_TAGID > |
51 |
< NAME type = "xs:string" >EnableDEP</ NAME > |
52 |
< FLAG_TAGID type = "xs:int" >214</ FLAG_TAGID > |
57 |
< STRTAB_ITEM type = "xs:string" >EMET Database</ STRTAB_ITEM > |
58 |
< STRTAB_ITEM type = "xs:string" >EnableDEP</ STRTAB_ITEM > |
59 |
< STRTAB_ITEM type = "xs:string" >EMET Shim</ STRTAB_ITEM > |
60 |
< STRTAB_ITEM type = "xs:string" >EMET.dll</ STRTAB_ITEM > |
61 |
< STRTAB_ITEM type = "xs:string" >*</ STRTAB_ITEM > |
62 |
< STRTAB_ITEM type = "xs:string" >EMET Apps</ STRTAB_ITEM > |
63 |
< STRTAB_ITEM type = "xs:string" >firefox.exe</ STRTAB_ITEM > |
This suggests that when an executable with the name “firefox.exe”
gets run, the DLL “EMET.dll” gets loaded. This file is at C:\WINDOWS\AppPatch\EMET.dll
,
and running it through IDA we see a call to an internal function
labeled “aSetprocessdepp” which calls GetModuleHandle()/GetProcAddress()
on “kernel32.dll”/”SetProcessDEPPolicy”. I didn’t know such a function
existed, but we can check it out in the MSDN at SetProcessDEPPolicy
Function and see that it just turns DEP on or off (duh!). Just for
fun, continuing to read the MSDN article, we can see that a process can
also have it’s DEP setting changed by use of the function UpdateProcThreadAttribute
or when creating the process in the call to CreateProcess
you can specify that same attribute list in the STARTUPINFOEX
structure.
Although EMET keys off of the name of the file, you can also use
“file size, checksum, version, and date” according to the MSDN article
on the Application
Compatibility Database.
Also, I found it odd that the .pdb file listed inside the EMET.dll is
“c:\\src\\redteam\\src\\tools\\defense\\emet\\src\\razzle\\shimdll\\objfre\\i386\\EMET.pdb”
when the EMET tool is produced by the BlueHat team. What color
are you!?!
I couldn’t figure out how EMET is enabling the other security
features (like ASLR). I guess it’s trickier then just making an API
call.