来源：蜘蛛抓取(WebSpider)
时间：2017-08-12 10:04
标签：
event base dispatch
1208人阅读
当使用64位debugger调试wow64进程时，cpu context默认为64位，这是查看wow64进程调用栈时，会发现只有64位调用栈，而没有32位调用栈，例如查看32位notepad进程在64位Windows上的主线程调用栈：
fffff880` fffff800`03eea992: nt!KiSwapContext+0x7a
fffff880` fffff800`03ee9eaa: nt!KiCommitThreadWait+0x1d2
fffff880` fffff800`041dbccf: nt!KeWaitForMultipleObjects+0x272
fffff880`0382bbd0 fffff800`0420a08d: nt!ObpWaitForMultipleObjects+0x294
fffff880` fffff800`03ee48d3: nt!NtWaitForMultipleObjects32+0xec
fffff880` cf2e09: nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`)
4dd18 cf283e: wow64cpu!CpupSyscallStub+0x9
4dd20 d6d07e: wow64cpu!WaitForMultipleObjects32+0x3b
4dde0 d68a40: wow64!RunCpuSimulation+0xa
4de30 d3a154: wow64!Wow64KiUserCallbackDispatcher+0x204
4e180 e1225: wow64win!whcbClientWaitMessageExMPH+0x58
4eb30 cf2e09: ntdll!KiUserCallbackDispatcherContinue (TrapFrame @ 4e9f8)
4eb98 cf2dbf: wow64cpu!CpupSyscallStub+0x9
4eba0 d6d07e: wow64cpu!Thunk0Arg+0x5
4ec60 d6c549: wow64!RunCpuSimulation+0xa
4ecb0 d4956: wow64!Wow64LdrpInitialize+0x429
4f200 d1a17: ntdll!LdrpInitializeProcess+0x17e4
4f6f0 bc32e: ntdll! ?? ::FNODOBFM::`string'+0x29220
4f760 00000: ntdll!LdrInitializeThunk+0xe
为了看到32位调用栈，我们必须采用以下步骤：
1. load the wow64exts.dll debugger extension (.load wow64exts)
kd& .load wow64exts
2. 检查当前cpu context是否为64位，若不是，切换至64位 (.effmach amd64)
kd:x86& .effmach amd64
Effective machine: x64 (AMD64)
3. 执行.thread /r /p /w fffffa800a69a910 命令
kd& .thread /r /p /w fffffa800a69a910
Loading User Symbols.....
Loading Wow64 Symbols.........................
x86 context set
4. 查看线程栈 (执行k命令)
ChildEBP RetAddr
f07ebd USER32!NtUserGetMessage+0x15
b7148a USER32!GetMessageW+0x33
b716ec notepad!WinMain+0xe6
db3677 notepad!__mainCRTStartup+0x140
199d72 kernel32!BaseThreadInitThunk+0xe
199d45 ntdll_!__RtlUserThreadStart+0x70
00000 ntdll_!_RtlUserThreadStart+0x1b
kd:x86& .effmach amd64
Effective machine: x64 (AMD64)
kd& $ Notice the 32-bit ntdll.dll is loaded into the WOW64 process address space
kd& lmv m ntdll_
Image path: C:\Windows\SysWOW64\ntdll.dll
1. .thread /w command to set the current thread context and load the WOW64 symbols.
2. .thread command needs to be run from the 64-bit thread context in the debugger for it to successfully decode the WOW64 symbols
3. if you ever have to use a 64-bit user-mode debugger to debug a WOW64 process, you can use that command to switch the CPU context as needed so that you can view the 32-bit user-mode stack.

&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：166700次
积分：2968
积分：2968
排名：第11735名
原创：106篇
转载：59篇
译文：19篇
评论：19条
(1)(7)(3)(3)(4)(11)(9)(2)(5)(10)(4)(2)(1)(1)(2)(4)(2)(1)(2)(5)(3)(5)(2)(3)(5)(5)(2)(5)(3)(1)(3)(3)(1)(3)(1)(7)(3)(2)(1)(1)(1)(2)(4)(7)(7)(2)(3)(6)(1)(1)(1)(1)(1)(1)(3)(2)(3)& 深入解析DLL劫持漏洞
深入解析DLL劫持漏洞
0×00. 导读
DLL劫持是一种古老的技术了，本文是《》的延伸，介绍了DLL劫持的漏洞原理、漏洞挖掘方法、漏洞利用场景等，同时引入了HaifeiLi关于Chrome/Edge自动下载漏洞的介绍，以及最新版本Edge对DLL注入的缓解措施。本文已在外部发表于，特别感谢在行文思路上的建议。
0×01. DLL劫持漏洞介绍
1.1 漏洞简介
如果在进程尝试加载一个DLL时没有指定DLL的绝对路径，那么Windows会尝试去指定的目录下查找这个DLL；如果攻击者能够控制其中的某一个目录，并且放一个恶意的DLL文件到这个目录下，这个恶意的DLL便会被进程所加载，从而造成代码执行。这就是所谓的DLL劫持。
在Windows XP SP2之前，Windows查找DLL的目录以及对应的顺序如下：
1. 进程对应的应用程序所在目录；
2. 当前目录（Current Directory）；
3. 系统目录（通过 GetSystemDirectory 获取）；
4. 16位系统目录；
5. Windows目录（通过 GetWindowsDirectory 获取）；
6. PATH环境变量中的各个目录；
在Windows下，几乎每一种文件类型都会关联一个对应的处理程序，当我们在资源管理器中打开某种特定类型的文件时，与之相关联的处理程序便会被执行，也就是会新建一个进程，进程默认的 Current Directory （当前目录）就是被打开文件所在的目录。在Windows搜索DLL的这些目录中，攻击者最容易控制的当然是 Current Directory 。攻击者可以把恶意的DLL文件和目标文件（如WORD文档）打包在一起，如果受害者进行解压操作，恶意DLL和目标文件就会位于同一个目录，攻击者可以十分方便的实施DLL劫持。
由于早期Windows查找DLL文件的顺序并不合理，可以想象DLL劫持漏洞伴随着Windows存在了相当长的时间。然而，在相当长的一段时间里DLL劫持漏洞并没有受到大家的关注，直到2010年8月，微软发布安全通报2269637，同时网上公布了大量受影响软件的名字，DLL劫持漏洞才开始进入大家的视野。
1.2 漏洞归类
DLL劫持漏洞翻译成英文叫做 DLL Hijacking Vulnerability，CWE将其归类为 Untrusted Search Path Vulnerability。如果想要去CVE数据库中搜索DLL劫持漏洞案例，搜索这两个关键词即可。
1.3 缓解措施
从Windows XP SP2开始，SafeDllSearchMode 默认会被开启。SafeDllSearchMode的开启与否主要影响 Current Directory（当前目录） 在搜索顺序中的位置。开启SafeDllSearchMode后的DLL搜索顺序如下：
1. 进程对应的应用程序所在目录；
2. 系统目录（通过 GetSystemDirectory 获取）；
3. 16位系统目录；
4. Windows目录（通过 GetWindowsDirectory 获取）；
5. 当前目录；
6. PATH环境变量中的各个目录；
启用SafeDllSearchMode之后可以防范大部分DLL劫持，如系统DLL劫持。不过，如果进程尝试加载的DLL并不存在，那么进程仍然会尝试去当前目录加载这个DLL，这是SafeDllSearchMode所无法防范的。不过微软引入了 SetDllDirectory 这个API，给这个API传递一个空字符串就可以将当前目录从DLL搜索顺序中排除掉。
BOOL WINAPI SetDllDirectory(
_In_opt_ LPCTSTR lpPathName
If the lpPathName parameter is an empty string (&&),
the call removes the current directory from the default DLL search order.
1.4 漏洞检查
使用Sysinternals工具包中的 Process Monitor（ProcMon）可以十分方便的检测DLL劫持漏洞，只需要设置几个过滤参数即可。
1. ProcessName 目标进程的名字；
2. Path 文件路径，可以设置为 begins with 当前目录所在路径；
3. Result 结果，设置为 NAME NOT FOUND；
0×02. DLL劫持漏洞利用场景
2.1 针对应用程序安装目录的DLL劫持
不管SafeDllSearchMode是否开启，在查找DLL时应用程序本身所在的目录都是最先被搜索的。因此如果能够放一个恶意的DLL文件到程序的安装目录，就可以利用DLL劫持漏洞来执行代码。
这种利用场景的要求相对较高，因为大部分程序默认安装到 %ProgramFiles% 或者是 %ProgramFiles(x86)%。这两个目录都需要管理员权限才可以进行写入操作，也就是说在进行DLL劫持之前，要求已经具有代码执行权限。基于这一原因，软件厂商一般不予处理此类问题。
这种场景多被一些恶意代码所使用，对常用软件进行DLL劫持可以在一定程度替代自启动功能，同时，利用 白加黑 方式还能逃避安全软件的检测。此外，一些外挂或者破解程序也会采用这种方式进行DLL劫持，例如QQ的一些显IP插件就是通过劫持 msimg32.dll 来实现功能的。
2.2 针对文件关联的DLL劫持
在Windows下，我们平时使用的各种文件（如MP3音乐、DOC文档、PDF文档、MKV视频等）都有一个与之关联的默认处理软件。当在资源管理器中打开某种特定类型的文件时，操作系统会自动创建一个进程来处理这个文件，进程对应的程序就是该文件类型关联的默认处理程序，进程的 当前目录 就是被打开文件所在的目录。
例如，如果Adobe Acrobat DC关联了.PDF文件类型，那么打开PDF文件时就会自动创建一个Acrobat.exe进程，进程的当前目录（Current Directory）就是PDF文件所在的目录。如果进程尝试加载一个不存在的DLL，根据默认的DLL搜索顺序，进程最终会搜索到PDF文件所在目录（即当前目录），如果该目录下恰好就存在有一个同名的DLL，那么这个DLL就会被进程所加载。这就是所谓的 文件关联型DLL劫持 。
相对于 针对应用程序安装目录的DLL劫持，针对文件关联的DLL劫持 的利用条件十分简单，只要放一个恶意的DLL就行了。由于实施这种DLL劫持不需要其他先决条件，许多厂商关注并承认该利用场景下的DLL劫持漏洞。
许多流行软件可能仍然存在有这种DLL劫持漏洞：笔者在2015年给12月给Adobe报告了Adobe Acrobat DC 15.009.20077中存在的一个DLL劫持漏洞（CVE-），该漏洞由Acrobat.exe进程加载不存在的updaternotifications.dll所引起。此外，去CVE漏洞库搜索 DLL Hijacking 或者 Untrusted Search Path 也能找到很多案例。
2.3 针对安装程序的DLL劫持
许多应用程序的安装包程序也存在有漏洞，这种场景与 针对应用程序安装目录的DLL劫持 比较类似，本来也没有什么特殊之处，不过结合后文提到的浏览器自动下载漏洞，其利用条件又变得相对简单了。
这里以Notepad++最新的安装包npp.6.9.Installer.exe为例来进行讲解。启动 ProcMon 并设置好过滤器，可以看到npp.6.9.Installer.exe运行后尝试加载了许多DLL，这些都是第一次加载时没有加载成功的。
仔细观察进程尝试加载这些DLL时产生的调用栈，会发现有的调用栈中存在有 LoadLibrary(Ex)，而有的调用栈中却没有。这里选取 Version.dll 和 SHFOLDER.dll 来进行对比说明。
npp.6.9.Installer.exe在尝试加载 Version.dll 时产生的调用栈中并没有 LoadLibrary(Ex)，这是因为DLL并不是被进程动态加载的，而是因为应用程序的导入表直接或者间接导入了这个DLL。在这种利用场景下，伪造DLL的导出表最好与被伪造DLL的导出表完全一致，否则DLL可能无法被进程成功加载（会弹出错误提示消息框）。有一个叫做 AheadLib 的工具可以十分方便的生成此类DLL的源文件。
fltmgr.sys
FltAcquirePushLockShared + 0x907
fltmgr.sys
FltIsCallbackDataDirty + 0x1f3d
fltmgr.sys
FltDeletePushLock + 0x64f
ntoskrnl.exe
MmCreateSection + 0x25b1
ntoskrnl.exe
SeQueryInformationToken + 0xe3e
ntoskrnl.exe
ObOpenObjectByName + 0x306
ntoskrnl.exe
NtOpenProcessTokenEx + 0x326
ntoskrnl.exe
KeSynchronizeExecution + 0x3a23
ZwQueryAttributesFile + 0xa
Wow64EmulateAtlThunk + 0xd2b1
Wow64SystemServiceEx + 0xd7
wow64cpu.dll
TurboDispatchJumpAddressEnd + 0x2d
Wow64SystemServiceEx + 0x1ce
Wow64LdrpInitialize + 0x42a
RtlUniform + 0x6e6
EtwEventSetInformation + 0x186f8
LdrInitializeThunk + 0xe
ZwQueryAttributesFile + 0x12
aullrem + 0x1f1
aullrem + 0x6cb
aullrem + 0x565
RtlEncodeSystemPointer + 0x404
RtlSetBits + 0xf0
RtlSetBits + 0x16b
RtlSetBits + 0x60
RtlSetThreadPoolStartFunc + 0x3a1
RtlSetUnhandledExceptionFilter + 0x50
LdrInitializeThunk + 0x10
npp.6.9.Installer.exe在尝试加载 SHFOLDER.dll 时产生的调用栈中存在有 LoadLibrary(Ex)，说明这个DLL是被进程所动态加载的。在这种利用场景下，伪造的DLL文件不需要存在任何导出函数即可被成功加载，即使加载后进程内部出错，也是在DLL被成功加载之后的事情。
fltmgr.sys
FltAcquirePushLockShared + 0x907
fltmgr.sys
FltIsCallbackDataDirty + 0x1f3d
fltmgr.sys
FltDeletePushLock + 0x64f
ntoskrnl.exe
MmCreateSection + 0x25b1
ntoskrnl.exe
SeQueryInformationToken + 0xe3e
ntoskrnl.exe
ObOpenObjectByName + 0x306
ntoskrnl.exe
NtOpenProcessTokenEx + 0x326
ntoskrnl.exe
KeSynchronizeExecution + 0x3a23
ZwQueryAttributesFile + 0xa
Wow64EmulateAtlThunk + 0xd2b1
Wow64SystemServiceEx + 0xd7
wow64cpu.dll
TurboDispatchJumpAddressEnd + 0x2d
Wow64SystemServiceEx + 0x1ce
Wow64LdrpInitialize + 0x42a
RtlUniform + 0x6e6
EtwEventSetInformation + 0x186f8
LdrInitializeThunk + 0xe
ZwQueryAttributesFile + 0x12
aullrem + 0x1f1
aullrem + 0x6cb
aullrem + 0x565
RtlLookupAtomInAtomTable + 0x35a
RtlUlonglongByteSwap + 0x671
KernelBase.dll
LoadLibraryExW + 0x243
KernelBase.dll
LoadLibraryExA + 0x26
kernel32.dll
LoadLibraryA + 0x31
2.4 Microsoft Edge与Google Chrome的自动下载漏洞
通过 iframe 可以触发 Microsoft Edge 和 Google Chrome 的自动下载功能，这一特性被
认为是一个安全漏洞，其在Twitter上发表了很多关于该漏洞的推文，甚至抱怨Chrome和Edge团队忽视这个漏洞的存在。在HaifefiLi的长期呼吁下，Chrome最终在48.0.2564.82版本中修复了这个漏洞，而截至笔者撰文时Edge似乎仍然没有修复该漏洞。
Edge浏览器的默认下载目录为 C:\Users\Username\Downloads，通过Edge下载的文件默认都会保存在这个目录下。可以利用Edge的自动下载漏洞下载一个恶意的DLL文件（如Version.dll）到这个目录下，然后利用页面超时自动跳转功能让Edge跳转到正常页面来诱导用户下载一个正常的安装文件，当用户运行安装程序时恶意的DLL文件便会被进程加载。
测试浏览器自动下载漏洞的HTML测试代码如下所示：
&title&Windows Update&/title&
&iframe src=&evil.dll&&&/iframe&
setTimeout( function () {
window.location = &/reader&
在Windows 10下使用Edge打开这个HTML页面，可以看到DLL文件被自动下载到了本地的下载目录中。不过由于DLL没有有效的数字签名，所以Edge会提示这个文件可能存在风险。
如果DLL文件具有有效的数字签名，那么Edge就不会这样提示了。在最新版本的Google Chrome（48.0. m）上测试发现，不管DLL是否具有有效的数字签名，DLL文件下载之后都需要用户手工确认才会保存，否则会被删除。Chrome和Edge的测试结果汇总如下：
浏览器的自动下载漏洞还是十分危险的，攻击者甚至只需要诱导用户下载一个恶意的DLL，以后用户在下载目录中执行各种程序时都有可能加载这个DLL。此外，安装程序一般都会请求管理员权限，对于恶意的DLL来说管理员权限似乎是与生俱来的。
0×03. 非典型漏洞CVE-分析
微软安全公告MS16-014中的描述表明其修复了一个CVE-ID为的DLL劫持漏洞。漏洞详情为：Windows 10下的 URLMON.dll 文件存在加载 phoneinfo.dll 的代码，而Windows 10本身并不携带这个 phoneinfo.dll 文件，并且在查找DLL时使用的是标准的目录搜索顺序，所以这里会导致DLL劫持漏洞。这个漏洞的独特之处在于其存在于操作系统本身，所以在Windows 10下，只要是调用了 URLMON.dll 中能够触发漏洞代码的API的软件都会受到这个漏洞的影响。笔者在2015年底也发现了也发现了这个漏洞，同时确认Foxit Reader 7.2.8.1124受到该漏洞的影响，并将其报告给了Foxit Software。
3.1 漏洞分析
在发现这个漏洞时，笔者发现网上很少有关于 phoneinfo.dll 文件的介绍，只有
在 Sexrets of LoadLibrary 中提到了这个文件。TK指出 IE11 running on Windows 10 TP 9926 会尝试加载 phoneinfo.dll，而IE的当前目录就是桌面，所以如果放一个 phoneinfo.dll 到桌面上的话，在启动IE时这个DLL便会被加载。
Greg Linares 在 SRT-VR-24DEC2015 中指出 Windows10 的 URLMON.dll 中存在两处加载 phoneinfo.dll 的地方，可能是DLL文件的版本不一样，笔者找到的代码与之存在一些细微差异。笔者在分析 11.0. 版本的 URLMON.dll 时找到的反汇编代码如下所示：
下面的代码位于 BuildUserAgentStringMobileHelper 中：
.text:1A4636A1 loc_1A4636A1:
.text:1A4636A1
eax, pfnQueryPhoneInformation
.text:1A4636A6
[ebp+pszValue], 0
.text:1A4636AD
[ebp+szSrc], eax
.text:1A4636B3
; 判断eax寄存器的值是否为0
.text:1A4636B5
loc_1A48FC97
; 如果不为0则跳转
.text:1A4636BB
; dwFlags = 0
.text:1A4636BC
.text:1A4636BD
offset aPhoneinfo_dll ; &phoneinfo.dll&
.text:1A4636C2
ds:__imp__LoadLibraryExW@12 ; LoadLibraryExW(x,x,x)
.text:1A4636C8
.text:1A4636CA
loc_1A48FC78
下面的代码位于 _QueryPhoneInformationA 中：
.text:1A461B93
edi, pfnQueryPhoneInformation
.text:1A461B99
byte ptr [ebx], 0
.text:1A461B9C
.text:1A461B9E
loc_1A48EE56
.text:1A461BA4
.text:1A461BA5
.text:1A461BA6
offset aPhoneinfo_dll ; &phoneinfo.dll&
.text:1A461BAB
ds:__imp__LoadLibraryExW@12 ; LoadLibraryExW(x,x,x)
.text:1A461BB1
.text:1A461BB3
loc_1A48EE34
这里加载 phoneinfo.dll 的代码为 LoadLibraryExW(“phoneinfo.dll”, NULL, 0)。因为这里 dwFlags 的值为0，所以使用标准的DLL搜索顺序；由于Windows 10上并不存在 phoneinfo.dll 这个文件，所以进程最终会尝试加载当前目录下的DLL。
这里简单分析一下受该漏洞影响的Foxit Reader。当在Windows 10下打开一个PDF文件时，进程 FoxitReader.exe 会加载当前目录下的 phoneinfo.dll 文件，对应的调用栈如下所示：
KernelBase.dll
LoadLibraryExW + 0x124
urlmon.dll
Ordinal523 + 0x6f1
urlmon.dll
Ordinal492 + 0x941
urlmon.dll
Ordinal492 + 0x165
urlmon.dll
Ordinal445 + 0x2e0
urlmon.dll
RegisterFormatEnumerator + 0xe2
urlmon.dll
UrlMkGetSessionOption + 0xcf
FoxitReader.exe
CertFreeCertificateChainEngine + 0x72fbef
FoxitReader.exe
CertFreeCertificateChainEngine + 0x70bbc2
FoxitReader.exe
CertFreeCertificateChainEngine + 0x70f61e
FoxitReader.exe
CertFreeCertificateChainEngine + 0x6f9f9c
user32.dll
Ordinal2535 + 0x83
user32.dll
GetScrollInfo + 0x1e8
user32.dll
DispatchMessageW + 0x28d
user32.dll
DispatchMessageW + 0x10
FoxitReader.exe
FoxitReader.exe + 0x2d1f1b
FoxitReader.exe
FoxitReader.exe + 0x2da62d
FoxitReader.exe
FoxitReader.exe + 0x882a36
FoxitReader.exe
FoxitReader.exe + 0x1866d1
FoxitReader.exe
FoxitReader.exe + 0x173286
FoxitReader.exe
FoxitReader.exe + 0x173563
FoxitReader.exe
FoxitReader.exe + 0x21483f
FoxitReader.exe
FoxitReader.exe + 0x217726
FoxitReader.exe
FoxitReader.exe + 0x1e4922
FoxitReader.exe
FoxitReader.exe + 0x1f4aba
FoxitReader.exe
FoxitReader.exe + 0x1e8d6a
FoxitReader.exe
FoxitReader.exe + 0x1eb562
FoxitReader.exe
CertFreeCertificateChainEngine + 0x91e56c
FoxitReader.exe
FoxitReader.exe + 0x46cd8e
kernel32.dll
BaseThreadInitThunk + 0x24
RtlInitializeCriticalSectionAndSpinCount + 0x29e
RtlInitializeCriticalSectionAndSpinCount + 0x26d
结合IDA或者Windbg进行分析，可以知道这里的调用路径为：
UrlMkGetSessionOption
└--& GetUserAgentString
└--& GetUserAgentStringForMode
└--& InitUserAgentGlobals
└--& BuildUserAgentStringMobileHelper
└--&LoadLibraryExW
即Foxit Reader因为调用了URLMON.dll中的UrlMkGetSessionOption函数，导致其受到DLL劫持漏洞的影响。在IDA中使用交叉引用功能进行回溯，可以找到其他能够触发该漏洞的路径，Greg Linares 给出了另外两个路径：
┌-----------------------------------------------------┐
CINetHttpEdge::SetOptionUserAgent
CINetHttp::SetOptionUserAgent
│ CIEBrowserModeFilter::collectCacheEntryInfoCallback │
└-----------------------------------------------------┘
└--& MapBrowserEmulationStateToUserAgent (Ordinal <span style="color: #)
└--& InitUserAgentGlobals (Ordinal <span style="color: #)
└--& BuildUserAgentStringMobileHelper
┌-------------------------------------┐
│ ObtainUserAgentString (Ordinal <span style="color: #) │
GetUserAgentString
└-------------------------------------┘
└--& InitUserAgentGlobals (Ordinal <span style="color: #)
└--& BuildUserAgentStringMobileHelper
Greg Linares 同时也指出了他们发现的其他受该漏洞影响的软件：
1. Internet Explorer 没有命令行参数的情况下（例如双击并打开IE）；
2. Skype 启动的时候；
3. OneDrive 同步以及更新的时候（无需用户交互）；
4. Visual Studio 2015 微软账户更新或者同步的时候；
3.2 补丁分析
更新后的URLMON.dll文件在调用 LoadLibraryEx 加载
时将 dwFlags 参数值指定为 0×800，即 LOAD_LIBRARY_SEARCH_SYSTEM32，表示只搜索 System32 目录。对应的代码为LoadLibraryExW(L”phoneinfo.dll”, NULL, LOAD_LIBRARY_SEARCH_SYSTEM32)，反汇编代码如下：
.text:1A46386B
.text:1A463870
.text:1A463871
offset aPhoneinfo_dll ; &phoneinfo.dll&
.text:1A463876
ds:__imp__LoadLibraryExW@12 ; LoadLibraryExW(x,x,x)
0×04. DLL劫持漏洞缓解措施
DLL劫持漏洞在未来可能仍然会影响着许多软件或者操作系统组件，亦或是与其他漏洞相结合以衍生出新的攻击方法。尽管目前没有一个完美的方法（No Silver Bullet）可以防止软件受到DLL劫持漏洞的影响，但是开发人员仍然可以采取各种措施来缓解DLL劫持漏洞带来的影响。
4.1 基本缓解措施
1. 在加载DLL时尽量使用DLL的绝对路径；
2. 调用SetDllDirectory(L””)把 当前目录 从DLL搜索目录中排除；
3. 使用 LoadLibraryEx 加载DLL时，指定 LOAD_LIBRARY_SEARCH_ 系列标志；
此外，进程也可以尝试去验证DLL的合法性，例如是否具有自家的合法数字签名、是否是合法的系统DLL文件等。
4.2 Windows Edge缓解措施
最新版本的Edge提供了一种对抗DLL劫持（注入）的缓解措施：只有拥有微软签名以及WHQL（Windows Hardware Quality Lab）签名的DLL模块才会被Edge加载，而且这套机制是在操作系统内核中实现的。
关于这一缓解措施的细节分析，可以阅读 Paul Rascagneres 的文章 MICROSOFT EDGE BINARY INJECTION MITIGATION OVERVIEW。
0×05. Acknowledges
在行文思路上的建议；同时，在本文的写作过程中参考了以下资料，在此亦表示感谢。
Microsoft，
HaifeiLi，
Microsoft，>
作者：代码疯子（Wins0n） 本站内容如无声明均属原创，转载请保留作者信息与原文链接，谢谢！
您可能对下面的文章也感兴趣:
（推荐使用
（关于作者 Wins0n/代码疯子）
免责声明：本站所有内容仅代表个人观点，无法保证100%准确，如有错误请联系指正，谢谢！
2017年四月 &(1)
2016年十月 &(1)
2016年三月 &(1)
2016年二月 &(1)
2016年一月 &(1)
2015年十月 &(1)
2015年六月 &(2)
2015年四月 &(1)
2015年一月 &(1)
2014年十一月 &(5)
2014年十月 &(1)
2014年九月 &(1)
2014年八月 &(2)
2014年七月 &(3)
2014年六月 &(4)
2014年四月 &(1)
2014年三月 &(2)
2014年二月 &(1)
2014年一月 &(1)
2013年十二月 &(1)
2013年十一月 &(2)
2013年十月 &(2)
2013年九月 &(3)
2013年八月 &(2)
2013年七月 &(3)
2013年六月 &(2)
2013年五月 &(1)
2013年四月 &(4)
2013年三月 &(2)
2013年二月 &(1)
2013年一月 &(2)
2012年十二月 &(5)
2012年十一月 &(3)
2012年十月 &(3)
2012年九月 &(4)
2012年八月 &(4)
2012年七月 &(3)
2012年六月 &(3)
2012年五月 &(6)
2012年四月 &(4)
2012年三月 &(6)
2012年二月 &(4)
2012年一月 &(7)
2011年十二月 &(9)
2011年十一月 &(9)
2011年十月 &(13)
2011年九月 &(18)
2011年八月 &(8)
2011年七月 &(7)
2011年六月 &(16)
2011年五月 &(13)
2011年四月 &(21)
2011年三月 &(22)
2011年二月 &(15)
2011年一月 &(7)
2010年十二月 &(23)
2010年十一月 &(33)
2010年十月 &(35)
2010年九月 &(42)深入解析DLL劫持漏洞
仔细观察进程尝试加载这些DLL时产生的调用栈，会发现有的调用栈中存在有LoadLibrary(Ex)，而有的调用栈中却没有。这里选取 Version.dll 和 SHFOLDER.dll 来进行对比说明。npp.6.9.Installer.exe在尝试加载 Version.dll 时产生的调用栈中并没有LoadLibrary(Ex)，这是因为DLL并不是被进程动态加载的，而是因为应用程序的导入表直接或者间接导入了这个DLL。在这种利用场景下，伪造DLL的导出表最好与被伪造DLL的导出表完全一致，否则DLL可能无法被进程成功加载（会弹出错误提示消息框）。有一个叫做
AheadLib的工具可以十分方便的生成此类DLL的源文件。
0&& fltmgr.sys&&&&& FltAcquirePushLockShared + 0x907
1&& fltmgr.sys&&&&& FltIsCallbackDataDirty + 0x1f3d
2&& fltmgr.sys&&&&& FltDeletePushLock + 0x64f
3&& ntoskrnl.exe&&& MmCreateSection + 0x25b1
4&& ntoskrnl.exe&&& SeQueryInformationToken + 0xe3e
5&& ntoskrnl.exe&&& ObOpenObjectByName + 0x306
6&& ntoskrnl.exe&&& NtOpenProcessTokenEx + 0x326
7&& ntoskrnl.exe&&& KeSynchronizeExecution + 0x3a23
8&& ntdll.dll&&&&&& ZwQueryAttributesFile + 0xa
9&& wow64.dll&&&&&& Wow64EmulateAtlThunk + 0xd2b1
10&& wow64.dll&&&&&& Wow64SystemServiceEx + 0xd7
11&& wow64cpu.dll&&& TurboDispatchJumpAddressEnd + 0x2d
12&& wow64.dll&&&&&& Wow64SystemServiceEx + 0x1ce
13&& wow64.dll&&&&&& Wow64LdrpInitialize + 0x42a
14&& ntdll.dll&&&&&& RtlUniform + 0x6e6
15&& ntdll.dll&&&&&& EtwEventSetInformation + 0x186f8
16&& ntdll.dll&&&&&& LdrInitializeThunk + 0xe
17&& ntdll.dll&&&&&& ZwQueryAttributesFile + 0x12
18&& ntdll.dll&&&&&& aullrem + 0x1f1
19&& ntdll.dll&&&&&& aullrem + 0x6cb
20&& ntdll.dll&&&&&& aullrem + 0x565
21&& ntdll.dll&&&&&& RtlEncodeSystemPointer + 0x404
22&& ntdll.dll&&&&&& RtlSetBits + 0xf0
23&& ntdll.dll&&&&&& RtlSetBits + 0x16b
24&& ntdll.dll&&&&&& RtlSetBits + 0x60
25&& ntdll.dll&&&&&& RtlSetThreadPoolStartFunc + 0x3a1
26&& ntdll.dll&&&&&& RtlSetUnhandledExceptionFilter + 0x50
27&& ntdll.dll&&&&&& LdrInitializeThunk + 0x10
npp.6.9.Installer.exe在尝试加载 SHFOLDER.dll 时产生的调用栈中存在有LoadLibrary(Ex)，说明这个DLL是被进程所动态加载的。在这种利用场景下，伪造的DLL文件不需要存在任何导出函数即可被成功加载，即使加载后进程内部出错，也是在DLL被成功加载之后的事情。
0&& fltmgr.sys&&&&&&&& FltAcquirePushLockShared + 0x907
1&& fltmgr.sys&&&&&&&& FltIsCallbackDataDirty + 0x1f3d
2&& fltmgr.sys&&&&&&&& FltDeletePushLock + 0x64f
3&& ntoskrnl.exe&&&&&& MmCreateSection + 0x25b1
4&& ntoskrnl.exe&&&&&& SeQueryInformationToken + 0xe3e
5&& ntoskrnl.exe&&&&&& ObOpenObjectByName + 0x306
6&& ntoskrnl.exe&&&&&& NtOpenProcessTokenEx + 0x326
7&& ntoskrnl.exe&&&&&& KeSynchronizeExecution + 0x3a23
8&& ntdll.dll&&&&&&&&& ZwQueryAttributesFile + 0xa
9&& wow64.dll&&&&&&&&& Wow64EmulateAtlThunk + 0xd2b1
10&& wow64.dll&&&&&&&&& Wow64SystemServiceEx + 0xd7
11&& wow64cpu.dll&&&&&& TurboDispatchJumpAddressEnd + 0x2d
12&& wow64.dll&&&&&&&&& Wow64SystemServiceEx + 0x1ce
13&& wow64.dll&&&&&&&&& Wow64LdrpInitialize + 0x42a
14&& ntdll.dll&&&&&&&&& RtlUniform + 0x6e6
15&& ntdll.dll&&&&&&&&& EtwEventSetInformation + 0x186f8&&&[2]&&&&&&
【声明】:黑吧安全网()登载此文出于传递更多信息之目的，并不代表本站赞同其观点和对其真实性负责，仅适于网络安全技术爱好者学习研究使用，学习中请遵循国家相关法律法规。如有问题请联系我们，联系邮箱，我们会在最短的时间内进行处理。
上一篇：【】【】
