----------------------------------------------------------------------------------
(1) Defeating IAT or export table modification AND/OR In-line function hooking [1]
----------------------------------------------------------------------------------
- recall that Import/Export table modification does :
modify the IAT or export address table of the targeted process and all
the modules (DLLs) that process/app uses
each process and module has its own IAT that contains the function
addresses of functions that process/module uses
so we replace the addresses in that IAT with addresses to our hooking fxns
but this method has to take into consideration that some functions will
be dynamically loaded, e.g. thatdll = LoadLibrary( somedll.dll ) then addy =
GetProcAddress( thatdll, SomeFunction )
- so to fully hook would require hooking GetProcAddress so that it
returns the hooked function address rather than the actual function addy
- could also modify the export address table of the desired DLLs; this
this will cause GetProcAddress(...) to return the addys we desire
So: GetProcAddress( thatdll, SomeFunction ) looks at the EAT of
thatdll for SomeFunction; if we have altered the EAT to have our fxn
address, then our fxn addy will be returned instead of the real fxn addy
- recall that inline function hooking does : overwrite start of the
hooked API function with a jmp instruction that causes execution to be
transferred to our function ('the replacement function')
DEFEATING BOTH OF THESE APPROACHES :
- manually read ntdll.dll and kernel32.dll into memory using CreateFile, ReadFile
- we'll call these manually loaded images "file images"
- the memory images of ntdll.dll and kernel32.dll are what have been modified
- iterate through the EAT of the file images of ntdll.dll and kernel32.dll
-- for each function exported, get that function's length * N
-- then compare the first N bytes of each of that function from the file image
and the memory image
-- restore each hooked function by copying the relevant bytes from the
file image to the memory image
- iterate through the IAT of the memory image of kernel32.dll
-- for each imported function from ntdll.dll, check that the address
of this function hasn't been modified
-- if it has been modified, restore the IAT entry from the file image
- obtain the function address of CreateProcessA using the file image of kernel32.dll
- execute desired EXE (app) using CreateProcessA
NB: relies on fact that only memory image of app and DLLs modified and
that the actual file on disk (e.g. ntdll.dll) is not changed
- also seems to rely on fact that disk image of our executable hasn't
been changed (i.e. had its IAT overwritten on disk)
-------------------------------------------------------------------
(2) Evading userland hooks - problems w/hooking implementations [2]
-------------------------------------------------------------------
(a) incomplete hooking : don't hook BOTH ANSI and Unicode versions of function
- ansi fxn names end in A, e.g. CreateProcessA(...)
- unicode versions end in W, e.g. CreateProcessW(...)
- ansi functions usually just wrappers which call unicode versions
- e.g. hook CreateFileA(...) so then attacker just calls
CreateFileW(...) instead
(b) not hooking deeply enough
- kernel32.dll has a lot of functions that are mostly wrappers for ntdll
functions
- so if only hook kernel32.dll functions and NOT ntdll.dll functions,
hooking can be bypassed via calling the ntdll functions directly
- e.g. GetProcAddress from kernel32.dll and LdrGetProcedureAddress from
ntdll.dll
(c) hooking function f but NOT hooking function g which f calls
- e.g. may hook WinExec(...)
- but this is what WinExec(...) call path looks like :
WinExec(...) --> CreateProcessA(...) --> CreateProcessInternalA(...)
- if just hook WinExec(...) and CreateProcessA(...) and NOT
CreateProcessInternalA(...) then attacker can just call that last
fxn and evade detection
- CreateProcessInternalA(...) is exported by kernel32.dll so attacker
could look for its addy via loading kernel32.dll and iterating
through that module's EAT
- also this refers to problem mentioned in (1) whereby say some function
f lives in DLL d but f itself calls function g which lives in DLL d'
- so we need to recursively be hooking not only our target functions
but ensuring that any functions THOSE TARGET FUNCTIONS call are
likewise hooked
(d) detecting installation of in-line function hooks
- most win32 api functions begin with a 5-byte preamble
XP : pre-SP2
55; push ebp
8bec; mov ebp, esp
...
XP : post-SP2
8bff; mov edi, edi (?) -- pg. 75 of Hoglund Rootkits book
55; push ebp
8bec; mov ebp, esp
...
- after in-line function hooking, a function preamble will look like :
e8 xx xx xx xx ; call xx xx xx xx
54 ; push esp
53 ; push ebx
56 ; push esi
57 ; push edi
or instead of call will have jmp (e9)
- so before program P (which wants to bypass hooking) calls function f,
P looks at the code at f; if it looks like a normal preamble, call f
else if the first instruction is a call or a jmp to some address, then
likely in-line function hooking is at work so don't call f or do
something else... but in any event the hooking has been detected
--> putting this into detours terminology, basically what the attacker
would do after probabilistically detecting the hook (above) is
search for the table which contains the original 5-byte preamble
--> recall that for detours we have a target function T, a detour
function (replacement function) D, and a trampoline function TR
where when T is called, instead D is called then TR is called
which calls T
--> so attacker would attempt to call TR then T -- bypassing D
since TR and T must live in the app memory somewhere
--> or instead attacker can have its own preamble (keep track of the
original preamble) then call the target function + 5 bytes, so we
jump over the "jmp xx xx xx xx" or "call xx xx xx xx" function
which is our inline function hook (hook hopping)
==> won't work if another function in the call path is also hooked,
e.g. if do hook hopping on WinExec but then WinExec calls
CreateProcess and haven't done hook hopping on CreateProcess,
then evasion fails
- so would need to call CreateProcess using stored preamble
and do hook hopping on functions called by WinExec
(e) implementations which overwrite preambles must change the write bits
on that code ... so that the preamble can be overwritten with the jmp or
call instruction; but some such implementations never reset the writable
bit on these code preambles ... so attacker can overwrite overwritten
preamble with original preamble!
(f) IAT patching
- attacker overwrites IAT before hooking mechanism does detection
- then hooking mechanism will hook desired functions and make those
functions jump to replacement functions then to the "original API
function"
-- but "the original api function" isn't really, it's the function
address already overwritten by the attacker
- so the attacker acts as first mover
- alters the api addy to X
- then when hooker comes in, it will alter api addy to Y where the
code at Y does whatever then calls X
- in particular the systems being attacked here call various ntdll.dll
functions in order to obtain memory page information so the idea is to
replace those core functions used by the attackee with functions
replaced by the attacker
- context is that attackee is doing buffer overflow protection
- and is using ntdll.dll functions for this purpose (rather than
supplying its own versions of these functions)
(g) write code which replaces functionality of functions exported by ntdll.dll
- have already discussed how most ntdll.dll functions basically :
push args
move the syscall number to eax
move pointer to userland stack to edx
int 2e
- well attacker can write code which essentially replicates the
functionality of those ntdll.dll functions
- so if hook was of all ntdll.dll functions, then attacker can bypass
that detection
+ of course this doesn't work against kernel-land hooking ... where the
actual hooking doesn't come into play until *after* int 2e is executed
* requires knowing the syscall numbers of desired kernel syscalls as well as
the method signature for each such kernel syscall
(type and number and order of arguments to that kernel syscall so as
to conform to it)
----------------------------
(3) Evading kernel hooks [3]
----------------------------
- basically kernel-level hooks (in NT/2k/XP/2003) rely on modifying the SSDT
- so this basically restores the SSDT from the disk image of ntoskrnl.exe
- the methods for doing this restoration mirror closely those which are
used to alter the SSDT in the first place
obviously assumes that kernel hooking done via overwriting memory image
of ntoskrnl.exe data structures (e.g. KiServiceTable) and that disk image
of ntoskrnl.exe is legit.
- requires some address conversion from original addys on disk image to RVAs
++++++++++++
References :
++++++++++++
(1) Anti API hooking
http://www.security.org.sg/code/antihookexec.html
(2) Evading userland hooks and Evading kernel hooks
http://www.phrack.org/phrack/62/p62-0x05_Bypassing_Win_BufferOverflow_Protection.txt
(3) Defeating native API hookers
http://www.security.org.sg/code/SIG2_DefeatingNativeAPIHookers.pdf
