深入解析 DLL 劫持漏洞
原创
作者：刘科
0x01. DLL劫持漏洞介绍
1.1 漏洞简介
如果在进程尝试加载一个DLL时没有指定DLL的绝对路径，那么Windows会尝试去指定的目录下查找这个DLL；如果攻击者能够控制其中的某一个目录，并且放一个恶意的DLL文件到这个目录下，这个恶意的DLL便会被进程所加载，从而造成代码执行。这就是所谓的DLL劫持。
在Windows XP SP2之前，Windows查找DLL的目录以及对应的顺序如下：
- 进程对应的应用程序所在目录；
- 当前目录（Current Directory）；
- 系统目录（通过 GetSystemDirectory 获取）；
- 16位系统目录；
- Windows目录（通过 GetWindowsDirectory 获取）；
- 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搜索顺序如下：
- 进程对应的应用程序所在目录；
- 系统目录（通过 GetSystemDirectory 获取）；
- 16位系统目录；
- Windows目录（通过 GetWindowsDirectory 获取）；
- 当前目录；
- 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劫持漏洞，只需要设置几个过滤参数即可。
- ProcessName 目标进程的名字；
- Path 文件路径，可以设置为 begins with 当前目录所在路径；
- Result 结果，设置为 NAME NOT FOUND；0x02. 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-2016-0947），该漏洞由Acrobat.exe进程加载不存在的updaternotifications.dll所引起。此外，去CVE漏洞库搜索 DLL Hijacking 或者 Untrusted Search Path 也能找到很多案例。
2.3 针对安装程序的DLL劫持
许多应用程序的安装包程序也存在有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的源文件。
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
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 RtlLookupAtomInAtomTable + 0x35a
22 ntdll.dll RtlUlonglongByteSwap + 0x671
23 KernelBase.dll LoadLibraryExW + 0x243
24 KernelBase.dll LoadLibraryExA + 0x26
25 kernel32.dll LoadLibraryA + 0x312.4 Microsoft Edge与Google Chrome的自动下载漏洞
通过 iframe 可以触发 Microsoft Edge 和 Google Chrome 的自动下载功能，这一特性被 @HaifeiLi 认为是一个安全漏洞，其在Twitter上发表了很多关于该漏洞的推文，甚至抱怨Chrome和Edge团队忽视这个漏洞的存在。在HaifefiLi的长期呼吁下，Chrome最终在48.0.2564.82版本中修复了这个漏洞，而截至笔者撰文时Edge似乎仍然没有修复该漏洞。
Edge浏览器的默认下载目录为 C:\Users\<Username>\Downloads，通过Edge下载的文件默认都会保存在这个目录下。可以利用Edge的自动下载漏洞下载一个恶意的DLL文件（如Version.dll）到这个目录下，然后利用页面超时自动跳转功能让Edge跳转到正常页面来诱导用户下载一个正常的安装文件，当用户运行安装程序时恶意的DLL文件便会被进程加载。
测试浏览器自动下载漏洞的HTML测试代码如下所示：
<html>
<head>
<title>Windows Update</title>
</head>
<body>
<iframe src="evil.dll"></iframe>
<script>
setTimeout( function () {
window.location = "https://get.adobe.com/reader"
}, 5000);
</script>
</body>
</html>在Windows 10下使用Edge打开这个HTML页面，可以看到DLL文件被自动下载到了本地的下载目录中。不过由于DLL没有有效的数字签名，所以Edge会提示这个文件可能存在风险。
如果DLL文件具有有效的数字签名，那么Edge就不会这样提示了。在最新版本的Google Chrome（48.0.2564.116 m）上测试发现，不管DLL是否具有有效的数字签名，DLL文件下载之后都需要用户手工确认才会保存，否则会被删除。Chrome和Edge的测试结果汇总如下：
浏览器的自动下载漏洞还是十分危险的，攻击者甚至只需要诱导用户下载一个恶意的DLL，以后用户在下载目录中执行各种程序时都有可能加载这个DLL。此外，安装程序一般都会请求管理员权限，对于恶意的DLL来说管理员权限似乎是与生俱来的。
0x03. 非典型漏洞CVE-2016-0041分析
微软安全公告MS16-014中的描述表明其修复了一个CVE-ID为CVE-2016-0041的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 文件的介绍，只有 @tombkeeper 在 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.10240.16384 版本的 URLMON.dll 时找到的反汇编代码如下所示：
- 下面的代码位于 BuildUserAgentStringMobileHelper 中：
.text:1A4636A1 loc_1A4636A1:
.text:1A4636A1 mov eax, pfnQueryPhoneInformation
.text:1A4636A6 mov [ebp+pszValue], 0
.text:1A4636AD mov [ebp+szSrc], eax
.text:1A4636B3 test eax, eax ; 判断eax寄存器的值是否为0
.text:1A4636B5 jnz loc_1A48FC97 ; 如果不为0则跳转
.text:1A4636BB push eax ; dwFlags = 0
.text:1A4636BC push eax ; hFile = 0
.text:1A4636BD push offset aPhoneinfo_dll ; "phoneinfo.dll"
.text:1A4636C2 call ds:__imp__LoadLibraryExW@12 ; LoadLibraryExW(x,x,x)
.text:1A4636C8 test eax, eax
.text:1A4636CA jnz loc_1A48FC78- 下面的代码位于 _QueryPhoneInformationA 中：
.text:1A461B93 mov edi, pfnQueryPhoneInformation
.text:1A461B99 mov byte ptr [ebx], 0
.text:1A461B9C test edi, edi
.text:1A461B9E jnz loc_1A48EE56
.text:1A461BA4 push edi ; dwFlags
.text:1A461BA5 push edi ; hFile
.text:1A461BA6 push offset aPhoneinfo_dll ; "phoneinfo.dll"
.text:1A461BAB call ds:__imp__LoadLibraryExW@12 ; LoadLibraryExW(x,x,x)
.text:1A461BB1 test eax, eax
.text:1A461BB3 jnz 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 文件，对应的调用栈如下所示：
......
16 KernelBase.dll LoadLibraryExW + 0x124
17 urlmon.dll Ordinal523 + 0x6f1
18 urlmon.dll Ordinal492 + 0x941
19 urlmon.dll Ordinal492 + 0x165
20 urlmon.dll Ordinal445 + 0x2e0
21 urlmon.dll RegisterFormatEnumerator + 0xe2
22 urlmon.dll UrlMkGetSessionOption + 0xcf
23 FoxitReader.exe CertFreeCertificateChainEngine + 0x72fbef
24 FoxitReader.exe CertFreeCertificateChainEngine + 0x70bbc2
25 FoxitReader.exe CertFreeCertificateChainEngine + 0x70f61e
26 FoxitReader.exe CertFreeCertificateChainEngine + 0x6f9f9c
27 user32.dll Ordinal2535 + 0x83
28 user32.dll GetScrollInfo + 0x1e8
29 user32.dll DispatchMessageW + 0x28d
30 user32.dll DispatchMessageW + 0x10
31 FoxitReader.exe FoxitReader.exe + 0x2d1f1b
32 FoxitReader.exe FoxitReader.exe + 0x2da62d
33 FoxitReader.exe FoxitReader.exe + 0x882a36
34 FoxitReader.exe FoxitReader.exe + 0x1866d1
35 FoxitReader.exe FoxitReader.exe + 0x173286
36 FoxitReader.exe FoxitReader.exe + 0x173563
37 FoxitReader.exe FoxitReader.exe + 0x21483f
38 FoxitReader.exe FoxitReader.exe + 0x217726
39 FoxitReader.exe FoxitReader.exe + 0x1e4922
40 FoxitReader.exe FoxitReader.exe + 0x1f4aba
41 FoxitReader.exe FoxitReader.exe + 0x1e8d6a
42 FoxitReader.exe FoxitReader.exe + 0x1eb562
43 FoxitReader.exe CertFreeCertificateChainEngine + 0x91e56c
44 FoxitReader.exe FoxitReader.exe + 0x46cd8e
45 kernel32.dll BaseThreadInitThunk + 0x24
46 ntdll.dll RtlInitializeCriticalSectionAndSpinCount + 0x29e
47 ntdll.dll RtlInitializeCriticalSectionAndSpinCount + 0x26d结合IDA或者Windbg进行分析，可以知道这里的调用路径为：
UrlMkGetSessionOption
└--> GetUserAgentString
└--> GetUserAgentStringForMode
└--> InitUserAgentGlobals
└--> BuildUserAgentStringMobileHelper
└-->LoadLibraryExW即Foxit Reader因为调用了URLMON.dll中的UrlMkGetSessionOption函数，导致其受到DLL劫持漏洞的影响。在IDA中使用交叉引用功能进行回溯，可以找到其他能够触发该漏洞的路径，Greg Linares 给出了另外两个路径：
- 路径1
┌─────────────────────────────────────────────────────┐
│ CINetHttpEdge::SetOptionUserAgent │
│ CINetHttp::SetOptionUserAgent │
│ CIEBrowserModeFilter::collectCacheEntryInfoCallback │
└─────────────────────────────────────────────────────┘
└--> MapBrowserEmulationStateToUserAgent (Ordinal 445)
└--> InitUserAgentGlobals (Ordinal 492)
└--> BuildUserAgentStringMobileHelper- 路径2
┌─────────────────────────────────────┐
│ ObtainUserAgentString (Ordinal 211) │
│ GetUserAgentString │
└─────────────────────────────────────┘
└--> InitUserAgentGlobals (Ordinal 492)
└--> BuildUserAgentStringMobileHelperGreg Linares 同时也指出了他们发现的其他受该漏洞影响的软件：
- Internet Explorer 没有命令行参数的情况下（例如双击并打开IE）；
- Skype 启动的时候；
- OneDrive 同步以及更新的时候（无需用户交互）；
- Visual Studio 2015 微软账户更新或者同步的时候；3.2 补丁分析
更新后的URLMON.dll文件在调用 LoadLibraryEx 加载 phoneinfo.dll 时将 dwFlags 参数值指定为 0x800，即 LOAD_LIBRARY_SEARCH_SYSTEM32，表示只搜索 System32 目录。对应的代码为LoadLibraryExW(L"phoneinfo.dll", NULL, LOAD_LIBRARY_SEARCH_SYSTEM32)，反汇编代码如下：
.text:1A46386B push 800h ; dwFlags
.text:1A463870 push eax ; hFile
.text:1A463871 push offset aPhoneinfo_dll ; "phoneinfo.dll"
.text:1A463876 call ds:__imp__LoadLibraryExW@12 ; LoadLibraryExW(x,x,x)0x04. DLL劫持漏洞缓解措施
DLL劫持漏洞在未来可能仍然会影响着许多软件或者操作系统组件，亦或是与其他漏洞相结合以衍生出新的攻击方法。尽管目前没有一个完美的方法（No Silver Bullet）可以防止软件受到DLL劫持漏洞的影响，但是开发人员仍然可以采取各种措施来缓解DLL劫持漏洞带来的影响。
4.1 基本缓解措施
- 在加载DLL时尽量使用DLL的绝对路径；
- 调用
SetDllDirectory(L"")把 当前目录 从DLL搜索目录中排除； - 使用 LoadLibraryEx 加载DLL时，指定 LOADLIBRARY_SEARCH 系列标志； 此外，进程也可以尝试去验证DLL的合法性，例如是否具有自家的合法数字签名、是否是合法的系统DLL文件等。
4.2 Windows Edge缓解措施
最新版本的Edge提供了一种对抗DLL劫持（注入）的缓解措施：只有拥有微软签名以及WHQL（Windows Hardware Quality Lab）签名的DLL模块才会被Edge加载，而且这套机制是在操作系统内核中实现的。
关于这一缓解措施的细节分析，可以阅读 Paul Rascagneres 的文章 MICROSOFT EDGE BINARY INJECTION MITIGATION OVERVIEW。
0x05. Acknowledges
- 感谢 TK 在行文思路上的建议；同时，在本文的写作过程中参考了以下资料，在此亦表示感谢。
- MSDN，Dynamic-Link Library Security
- MSDN，Dynamic-Link Library Search Order
- Microsoft，安全通报 (2269637)
- CWE，CWE-426: Untrusted Search Path
- CWE，CWE-427: Uncontrolled Search Path Element
- Yonsm，AheadLib 2.2.150 - 自动生成一个特洛伊 DLL 分析代码的工具
- HaifeiLi，Watch your Downloads: the risk of the “auto-download” feature on Microsoft Edge and Google Chrome
- Microsoft，安全公告 MS16-014
- tombkeeper，Sexrets of LoadLibrary
- Greg Linares，SRT-VR-24DEC2015
- Wins0n，CVE-2016-0041 Windows 10 PhoneInfo.dll Hijacking Vulnerability
- Microsoft Edge Dev Blog，Protecting Microsoft Edge against binary injection
- Paul Rascagneres，MICROSOFT EDGE BINARY INJECTION MITIGATION OVERVIEW
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。