挖掘白加黑DLL劫持漏洞
Tips:
白程序+黑DLL
黑DLL需要优先正常DLL目录,并且DLL不在WIndows KnowDLLs列表中
1 | reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs" |
DLL劫持分为两种:
1.劫持不存在的DLL
2.劫持已存在的DLL
准备测试DLL
准备一个弹计算器的DLL 运行库MT编译x64和x86版本
1 |
|
劫持不存在的DLL
这种是最简单的情况
劫持程序uc.exe
利用Process Monitor工具 首先添加filter
1 | Process name uc.exe |
返回结果中找到iconv.dll
其stack调用了LoadLibrary函数
LoadLibrary
和LoadLibraryEx
一个是本地加载,一个是远程加载,如果DLL不在调用的同一目录下,就可以使用LoadLibrary(L"DLL绝对路径")
加载。但是如果DLL内部又调用一个DLL,就需要使用LoadLibraryEx
进行远程加载
在iconv.dll同级目录下都是x64位的,所以替换的也是x64位dll
替换后启动uc.exe,成功弹出计算器
劫持已存在的DLL
还是利用Process Monitor添加filter
1 | Process name uc.exe |
这里可以采用DLL转发方式,可以利用工具AheadLib+,但是这个工具内联了__asm在VS2022x64下不支持,只能用来生成x86的dll
在github上找到了个好用的工具:
https://github.com/strivexjun/AheadLib-x86-x64
点击Makefile后生成2个文件
VS新建DLL项目导入这两个文件
.asm文件需要设置属性
1 | 把 .asm 文件添加到工程一次 |
之后运行库改MT,开始修改代码新增弹计算器的代码
老哥在生成的代码里加了新建线程执行,避免了白加黑CS的死锁问题
之后又改了转发文件的代码转发到同目录的zlib1Org.dll
因为找不到shlwapi.h文件一些API找不到标识符
在framework.h中添加#include <shlwapi.h>
可以正常编译了,直接编译DLL
将编译好的DLL改名zlib1.dll原来的DLL改名zlib1Org.dll
启动uc.exe 成功弹出计算器
__END__