DLL劫持原理及其漏洞挖掘（一）-安全客

0x0 前言

简单叙述下自己研究DLL劫持的原因。

0.学习window的库加载思想
1.为了在sangforSRC挖个洞去长沙打个卡。
2.免杀及其权限持久化维持的一个思路

0x1 DLL是什么

动态链接库(Dynamic-Link-Library,缩写dll), 是微软公司在微软视窗操作系统中实现共享函数库概念的一种实现方式。这些库函数的扩展名是.DLL、.OCX(包含ActiveX控制的库)或者.DRV(旧式的系统的驱动程序)

所谓动态链接,就是把一些经常会共享的代码(静态链接的OBJ程序库)制作成DLL档,当可执行文件调用到DLL档内的函数时，Windows操作系统才会把DLL档加载进存储器内，DLL档本身的结构就是可执行档，当程序有需求时函数才进行链接。通过动态链接方式，存储器浪费的情形将可大幅降低。静态链接库则是直接链接到可执行文件

DLL的文件格式与视窗EXE文件一样——也就是说，等同于32位视窗的可移植执行文件（PE）和16位视窗的New Executable（NE）。作为EXE格式，DLL可以包括源代码、数据&action=edit&redlink=1)和资源&action=edit&redlink=1)的多种组合。

还有更广泛的定义,这个没必要去理解了。

一些与之相关的概念:

静态库与动态库的比较

静态库被链接后直接嵌入可执行文件中

好处: 不需要外部函数支持,无环境依赖,兼容性好。

坏处: 容易浪费空间，不方便修复bug。

动态库的好处与静态库相对。

Linux下静态库名字一般是: libxxx.a window则是: *.lib、*.h

Linux下动态库名字一般是:libxxx.so window则是: .dll、.OCX(..etc)

0x2 DLL的用途

DLL动态链接库，是程序进行动态链接时加载的库函数。

故动态链接最直接的好处是磁盘和内存的消耗减少，这也是dll最初的目的。

不过，dll也有缺点，就是容易造成版本冲突,比如不同的应用程序共享同一个dll,而它们需求的是不同的版本，这就会出现矛盾,解决办法是把不同版本的dll放在不同的文件夹中。

0x3 入门DLL的使用

0x3.1 编写TestDll.dll

1.采用vs2017新建DLL项目

2.分析DLL的组成

其中dllmain.cpp代码如下

每个DLL都可以有一个入口点函数DllMain,系统会在不同时刻调用此函数。

// dllmain.cpp : 定义 DLL 应用程序的入口点。
#include "pch.h"

BOOL APIENTRY DllMain( HMODULE hModule, // 模块句柄
                       DWORD  ul_reason_for_call, // 调用原因
                       LPVOID lpReserved // 参数保留
                     )
{
    switch (ul_reason_for_call) // 根据调用原因选择不不同的加载方式
    {
    case DLL_PROCESS_ATTACH: // DLL被某个程序加载
    case DLL_THREAD_ATTACH: // DLL被某个线程加载
    case DLL_THREAD_DETACH: // DLL被某个线程卸载
    case DLL_PROCESS_DETACH: //DLL被某个程序卸载
        break;
    }
    return TRUE;
}

我们可以在该文件下引入Windows.h库,然后编写一个msg的函数。

#include <Windows.h>

void msg() {
    MessageBox(0, L"Dll-1 load  succeed!", 0, 0);
}

接下来在解决方案资源管理下的项目下打开头文件中的framework.h来导出msg函数.

#pragma once

#define WIN32_LEAN_AND_MEAN             // 从 Windows 头文件中排除极少使用的内容
// Windows 头文件
#include <windows.h>

extern "C" __declspec(dllexport) void msg(void);

然后点击生成中的重新生成解决方案编译得到TestDll.dll文件。

可以用16进制文件查看下dll的文件头，正如上面所说的一样，和exe是一样的。

0x3.2 调用dll文件

解决方案处右键新建一个项目，选择>控制台应用取名hello

修改hello.cpp的文件内容如下:

// hello.cpp : 此文件包含 "main" 函数。程序执行将在此处开始并结束。
#include <iostream>
#include <Windows.h>
using namespace std;

int main()
{
    // 定义一个函数类DLLFUNC
    typedef void(*DLLFUNC)(void);
    DLLFUNC GetDllfunc = NULL;
    // 指定动态加载dll库
    HINSTANCE hinst = LoadLibrary(L"TestDll.dll");
    if (hinst != NULL) {
        // 获取函数位置
        GetDllfunc = (DLLFUNC)GetProcAddress(hinst, "msg");
    }
    if (GetDllfunc != NULL) {
        //运行msg函数
        (*GetDllfunc)();
    }
}

然后ctrl+F5,运行调试。

可以看到成功加载了我们写的msg函数。

有关代码中更多的细节的解释可以参考: C++编写DLL文件

0x4 DLL劫持漏洞

0x4.1 原理简述

什么是DLL劫持漏洞(DLL Hijacking Vulnerability)?

如果在进程尝试加载一个DLL时没有并没有指定DLL的绝对路径，那么Windows会尝试去按照顺序搜索这些特定目录来查找这个DLL,如果攻击者能够将恶意的DLL放在优先于正常DLL所在的目录，那么就能够欺骗系统去加载恶意的DLL，形成”劫持”,CWE将其归类为UntrustedSearch Path Vulnerability,比较直译的一种解释。

0x4.2 查找DLL目录的顺序

正如动态链接库安全、动态链接库搜索顺序微软的官方文档所说,

在Windows XP SP2 之前(不包括), 默认未启用DLL搜索模式。

Windows查找DLL目录及其顺序如下:

The directory from which the application loaded.

The current directory.

The system directory. Use the GetSystemDirectory function to get the path of this directory.

The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.

The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.

The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

在Windows下, 几乎每一种文件类型都会关联一个对应的处理程序。

首先DLL会先尝试搜索启动程序所处的目录(1)，没有找到，则搜索被打开文件所在的目录(2),若还没有找到,则搜索系统目录(3),若还没有找到,则向下搜索16位系统目录，…Windows目录…Path环境变量的各个目录。

这样的加载顺序很容易导致一个系统dll被劫持，因为只要攻击者将目标文件和恶意dll放在一起即可,导致恶意dll先于系统dll加载，而系统dll是非常常见的，所以当时基于这样的加载顺序，出现了大量受影响软件。

后来为了减轻这个影响,默认情况下，从Windows XP Service Pack 2（SP2）开始启用安全DLL搜索模式。

The directory from which the application loaded.

The system directory. Use the GetSystemDirectory function to get the path of this directory.

The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.

The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.

The current directory.

The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

可以看到当前目录被放置在了后面,对系统dll起到一定的保护作用。

注:

强制关闭SafeDllSearchMode的方法:

创建注册表项:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode
值为0

不过从上面分析可以知道,系统dll应该是经常调用的,如果我们对程序安装的目录拥有替换权限，比如装在了非系统盘，那么我们同样可以利用加载顺序的(1)来劫持系统的DLL。

从Windows7 之后, 微软为了更进一步的防御系统的DLL被劫持，将一些容易被劫持的系统DLL写进了一个注册表项中，那么凡是此项下的DLL文件就会被禁止从EXE自身所在的目录下调用，而只能从系统目录即SYSTEM32目录下调用。注册表路径如下：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs

win10的键值项,如图:

这样子就进一步保护了系统dll,防止这些常用的dll被劫持加载。

但是如果开发者滥用DLL目录，依然会导致DLL劫持问题。(开发真难…orz)

0x4.3 防御思路

调用第三方DLL时,使用绝对路径
调用API SetDllDirectory(L”“)将当前目录从DLL加载顺序中移除
开发测试阶段，可以采用Process Monitor进行黑盒复测

0x5 实例演示

这里我们需要使用一个工具:Process Monitor v3.60

操作过程如动态链接库安全所说:

打开进程监视器的时候,会要求填入过滤器。

Include the following filters:
Operation is CreateFile
Operation is LoadImage
Path contains .cpl
Path contains .dll
Path contains .drv
Path contains .exe
Path contains .ocx
Path contains .scr
Path contains .sys

Exclude the following filters:
Process Name is procmon.exe
Process Name is Procmon64.exe
Process Name is System
Operation begins with IRP_MJ_
Operation begins with FASTIO_
Result is SUCCESS
Path ends with pagefile.sys

一次填好即可(通过上面的配置，我们可以过滤大量无关的信息,快速定位到DLL确实的路径)