DLL植入漏洞分类与微软安全响应指南

DLL植入漏洞的分类 | MSRC博客

本文章翻译自Security Research & Defense博客《Triaging a DLL planting vulnerability》（2018年4月4日美国时间发布）。

动态链接库（DLL）植入（二进制植入/劫持/预加载）问题往往每隔几年就会重新出现，而微软对此类报告的应对方式可能不够明确。本文旨在阐明DLL植入问题分类时的考量因素。

当应用程序未指定完整路径名而动态加载DLL时，Windows会按照《动态链接库搜索顺序》中描述的特定顺序，在明确定义的目录集合中查找DLL位置。默认SafeDllSearchMode使用的搜索顺序如下：

1. 应用程序加载位置的目录
2. 系统目录（通过GetSystemDirectory函数获取路径）
3. 16位系统目录（无专用函数获取路径但仍会被搜索）
4. Windows目录（通过GetWindowsDirectory函数获取路径）
5. 当前工作目录（CWD）
6. PATH环境变量列出的目录（但不包含App Paths注册表键指定的应用专属路径，该键在运行时不会用于DLL搜索）

默认DLL搜索顺序可通过多种选项修改，如先前博客《安全加载库》所述。

应用程序加载DLL时，若攻击者能将恶意DLL植入搜索顺序中的任一目录，且被植入的DLL未出现在攻击者无权限访问的更高优先级目录中，则构成DLL植入漏洞。例如，若加载foo.dll的应用程序在其目录、系统目录或Windows目录中均未找到该DLL，攻击者只需在当前工作目录植入foo.dll即可实现劫持。DLL植入漏洞对攻击者而言便捷且工作量小，由于DllMain()在加载时立即执行，代码执行极为容易。若应用程序允许加载未签名二进制，攻击者甚至无需绕过缓解措施。

根据恶意DLL植入位置的不同，漏洞主要分为三类：

• 应用程序目录中的DLL植入
• 当前工作目录（CWD）中的DLL植入
• PATH目录中的DLL植入

这些分类决定了我们的响应方式。以下详细分析各类别的处理逻辑。

应用程序目录中的DLL植入

应用程序目录是应用程序存放非系统DLL依赖并视其为可信的位置。安装目录中的文件被推定为无恶意且可信，通常通过目录ACL进行安全控制。能替换安装目录二进制文件的用户被视为具备文件写入或覆盖权限。应用程序目录被视为代码目录，存储与应用程序代码相关的文件。若无权访问该目录的攻击者能在此覆盖DLL，则问题远不止简单的DLL替换/植入。

场景1：可信应用程序目录中的恶意二进制植入
正确安装的应用程序通常通过ACL保护其目录，此场景中修改目录内容需提升权限（通常是管理员权限）。例如，Microsoft Word安装于C:\Program Files (x86)\Microsoft Office\root\Office16，修改该目录需管理员权限。拥有管理员权限的受害者可能被诱导或将恶意DLL置于可信位置，但此类情况下攻击者可能进一步诱导受害者执行更危险操作。

场景2：不可信应用程序目录中的恶意二进制植入
此类场景包括：通过XCOPY等非安装器方式安装的应用程序、共享文件夹中的应用程序、从互联网下载的应用程序，或位于无ACL控制目录的独立可执行文件。例如，从互联网下载并在默认“下载”文件夹中运行的安装程序（含可再发行包、ClickOnce生成的setup.exe、IExpress生成的自解压存档等）。从不可信位置启动应用程序本身具有风险，受害者易被诱导在這些位置植入DLL。

应用程序目录的DLL植入问题被视为纵深防御问题，更新仅考虑未来版本。鉴于此类攻击所需的社交工程量及本质符合设计规范，MSRC将此类报告归类为“vNext（下一产品版本）”问题。受害者需被诱导将恶意DLL（恶意软件）存于可执行位置，且执行不良操作（如在恶意软件同目录运行安装程序）。未安装的应用程序无“可信安全目录/二进制”参考点（除非自建目录）。理想情况下，安装程序应创建具随机名称的临时目录（防止进一步DLL植入），展开二进制文件并安装应用程序。攻击者可能通过驱动式下载在受害者系统（如“下载”文件夹）放置恶意软件，但攻击本质仍是社交工程。

Windows 10 Creators Update新增了进程缓解措施“PreferSystem32”，可切换DLL搜索顺序中应用程序目录与system32的优先级，防止应用程序目录中恶意系统二进制被劫持。此措施适用于进程创建可控的场景。

当前工作目录（CWD）中的DLL植入

应用程序通常将启动源目录视为CWD，基于默认文件关联启动时亦然。例如，点击共享文件夹中的D:\temp\file.abc文件时，D:\temp会成为.abc文件关联应用程序的CWD。

托管于远程共享文件夹（尤其是WebDAV共享）的场景更易受CWD的DLL植入攻击。攻击者可将恶意DLL与文件共存，通过社交工程诱导受害者打开文件，使恶意DLL被目标应用程序加载。

场景3：CWD中的恶意二进制植入
若前三个可信位置未找到DLL，应用程序会从不可信CWD搜索该DLL。例如，受害者尝试从\\server1\share2\打开.doc文件启动Microsoft Word时，若Word无法从可信位置找到依赖的DLL（如oart.dll），则会从CWD（即\\server1\share2\）加载该文件。该共享文件夹为不可信位置，攻击者可轻易植入恶意oart.dll。

触发点：\\server1\share2\openme.doc
应用程序：C:\Program Files (x86)\Microsoft Office\root\Office16\Winword.exe
应用程序目录：C:\Program Files (x86)\Microsoft Office\root\Office16\
CWD：\\server1\share2\
恶意DLL：\\server1\share2\OART.DLL

CWD的DLL植入问题被视为严重级问题，微软会发布安全更新。以往修复的大部分DLL植入问题属此类，部分列于安全公告2269637。有人可能疑问：为何微软应用程序会加载不存在于其目录、系统目录或Windows目录的DLL？原因包括可选组件、不同OS版本、多架构附带不同二进制集合，且应用程序有时无法在加载前有效检查/验证。

PATH目录中的DLL植入

DLL搜索顺序的最后位置是PATH目录。PATH目录是各类应用程序为提升用户体验而添加的目录集合。

PATH环境变量中的目录始终受管理员权限控制，普通用户无法修改其内容。若PATH包含任意用户可写目录，则属严重问题（远超单一DLL加载实例），我们会按严重级处理。但若仅涉及DLL植入，由于无法借此突破安全边界，被视为低安全性问题。因此，PATH目录的DLL植入问题标记为“无需修复”。

结论

以上说明应能澄清微软如何对报告的DLL植入问题分类，以及何种情况需发布安全更新。以下简指南列出通过安全发布（降级修复）修复与不修复的内容：

微软作为安全修复处理的内容

• CWD场景：关联应用程序从不可信CWD加载DLL。

微软考虑在下一产品发布时处理的内容

• 应用程序目录场景：基于产品开发组对显式/隐式加载的判断。显式加载可调整，隐式加载（依赖DLL）因路径不可控而完全符合设计规范。

微软不处理的内容（非漏洞）

• PATH目录场景：PATH中所有目录均需管理员权限，故无法被利用。

—–
Antonio Galvan, MSRC
Swamy Shivaganga Nagaraju, MSRC漏洞与缓解措施团队
更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）
公众号二维码