标题 | 简介 | 类型 | 公开时间 | ||||||||||
|
|||||||||||||
|
|||||||||||||
详情 | |||||||||||||
[SAFE-ID: JIWO-2024-2850] 作者: 大猪 发表于: [2021-03-19]
本文共 [395] 位读者顶过
0x0 前言简单叙述下自己研究DLL劫持的原因。 [出自:jiwo.org]
0x1 DLL是什么动态链接库(Dynamic-Link-Library,缩写dll), 是微软公司在微软视窗操作系统中实现共享函数库概念的一种实现方式。这些库函数的扩展名是.DLL、.OCX(包含ActiveX控制的库)或者.DRV(旧式的系统的驱动程序)
一些与之相关的概念:
0x2 DLL的用途DLL动态链接库,是程序进行动态链接时加载的库函数。 故动态链接最直接的好处是磁盘和内存的消耗减少,这也是dll最初的目的。 不过,dll也有缺点,就是容易造成版本冲突,比如不同的应用程序共享同一个dll,而它们需求的是不同的版本,这就会出现矛盾,解决办法是把不同版本的dll放在不同的文件夹中。
0x3 入门DLL的使用0x3.1 编写TestDll.dll1.采用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)?
0x4.2 查找DLL目录的顺序正如动态链接库安全 、动态链接库搜索顺序微软的官方文档所说, 在Windows XP SP2 之前(不包括), 默认未启用DLL搜索模式。 Windows查找DLL目录及其顺序如下:
在Windows下, 几乎每一种文件类型都会关联一个对应的处理程序。 首先DLL会先尝试搜索启动程序所处的目录(1),没有找到,则搜索被打开文件所在的目录(2),若还没有找到,则搜索系统目录(3),若还没有找到,则向下搜索16位系统目录,…Windows目录…Path环境变量的各个目录。 这样的加载顺序很容易导致一个系统dll被劫持,因为只要攻击者将目标文件和恶意dll放在一起即可,导致恶意dll先于系统dll加载,而系统dll是非常常见的,所以当时基于这样的加载顺序,出现了大量受影响软件。 后来为了减轻这个影响,默认情况下,从Windows XP Service Pack 2(SP2)开始启用安全DLL搜索模式。
可以看到当前目录被放置在了后面,对系统dll起到一定的保护作用。 注:
不过从上面分析可以知道,系统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 防御思路
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确实的路径) 然后我们随便打开一个程序,这里我使用的是深x服的EasyConnectInstaller: 可以看到这里最终会去尝试加载当前目录的一些dll,这里可以尝试进行替换rattler中的payload.dll名字即可,点击执行就可以弹出calc了。
0x6 自动化挖掘0x6.1 Ratter1.下载地址:https://github.com/sensepost/rattler/releases/ 2.使用 Rattler_x64.exe NDP461-KB3102438-Web.exe 1 结果发现这个并没有检测出来,可能是calc.exe启动失败的原因,个人感觉这个工具并不是很准确。 0x6.2 ChkDllHijack1.下载地址:[https://github.com/anhkgg/anhkgg-tools] 2.使用windbg导出module 然后打开chkDllHijack,粘贴处要验证的DLL内容 然后让他自己跑完即可,如果成功下面就会出现结果。 否则就是失败:
0x7 总结综合来说,我个人还是比较推荐采用Process monitor作为辅助工具,然后自己手工验证这种挖掘思路的,不过自动化的确挺好的,可以尝试自己重新定制下检测判断规则。本文依然倾向于入门的萌新选手,后面可能会回归DLL代码细节和免杀利用方面来展开(这个过程就比较需要耗时间Orz,慢慢填坑吧)。
0x8 参考链接 |