Windows Redis DLL劫持在实战中的利用

0x02 漏洞原理

2.1 DLL劫持简介

• DLL：Windows的动态链接库，简单来说，就是一部分Windows平台下的通用代码并没有写在程序里，而是当程序需要使用时去DLL里调用。
  
• DLL劫持：当程序没有指定DLL的绝对路径时，就会按一定顺序查找DLL，从而攻击者有机会在优先级更高的目录里放置恶意DLL。

标准的DLL查找顺序：

• 1. 应用程序目录：首先，系统会在启动应用程序的目录中查找指定的DLL文件。
• 2. 系统目录：接下来，系统会在Windows系统目录中查找DLL。系统目录通常是C:WindowsSystem32。
• 3. 16位系统目录：然后，系统会在16位系统目录中查找，通常是C:WindowsSysWOW64。这一步主要是为了兼容性，用于在64位系统上运行32位应用程序。
• 4. Windows目录：接着是Windows的根目录，通常是C:Windows。
• 5. 当前工作目录：此后，系统会在当前工作目录中查找DLL。这个目录是当前活动的目录，可能随着应用程序的运行而变化。
• 6. 系统环境变量指定的路径：最后，系统会按照在环境变量PATH中指定的顺序搜索DLL。

举例：

例如，假设有一个应用程序叫做"example.exe"，它依赖于名为"example.dll"的动态链接库。而"example.exe"在加载"example.dll"时没有使用绝对路径，而是仅仅指定了DLL的名称。攻击者可以将恶意的"example.dll"文件放置在与"example.exe"相同的目录下，当"example.exe"启动时，系统会先在当前目录中查找"example.dll"文件，如果找到，就会加载该文件并执行其中的恶意代码。

DLL劫持可以函数转发劫持也可以往完整DLL插入恶意代码，这里用的函数转发劫持，大致流程如下图所示：

https://kiwings.github.io/2019/04/04/th-DLL%E5%8A%AB%E6%8C%81/

2.2 劫持dbghelp.dll

redis-server.exe在执行bgsave时，会先在应用‍目录查找dbghelp.dll，找不到再去system32目录下找：

而不管redis的权限是Administrator还是普通用户或者Network Service，它对自己的应用目录一定有写文件的权限，我们可以通过Redis的主从复制在应用目录里写入恶意DLL。

2.3 函数转发劫持

对DLL进行函数转发劫持需要导出原本DLL的函数和地址，以保证程序通过恶意DLL调用这些函数时不影响正常功能，DLL的导出函数一般比较多，用Aheadlib之类的工具可以自动化处理。

我这里用的是DLLHijacker，它会自动处理导出表并生成一个VS2019的项目，但这个python脚本有几个bug：

https://github.com/kiwings/DLLHijacker

(1) VS项目中文乱码：

修复：几个写文件的地方添加 encoding="utf-8"。

(2) 函数导出表有匿名函数的时候，会导致以下报错

[-]Error occur: 'NoneType' object has no attribute 'decode修复：在几个for循环里添加函数名是否为空的判断可以解决这个问题。

(3) 生成C/C++代码时，没有使用目标DLL的绝对路径，只是用了DLL的名字填充LoadLibrary()，这是一个很严重的bug，会导致函数转发失败、Redis的功能受到影响从而只能劫持一次：

修复：我改成了根据输入的目标DLL路径自动填充。

如果没有使用原DLL的绝对路径，在Process Monitor可以看到，只会调用应用程序目录里的恶意DLL，并没有调用原本的system32下的dbghelp.dll：

从而redis的功能受到影响，导致redis的bgsave只能触发一次DLL调用，第二次bgsave的进程会被阻塞从而无法调用DLL，并且Redis关闭后将无法启动：

这也是网上部分师傅的文章写”不会影响redis运行 但会无法重启“的原因，因为他们也是用的DLLHijacker，并且没有发现有这个坑，这不仅会影响业务，而且只能劫持一次：

正常的DLL劫持不会影响程序的功能，可以劫持很多次，假如我第一次劫持想上线CS但是没有成功，那对面可能不出网，那我可能会再劫持打一个MSF的反向shell，都没成功我也可以继续尝试MSF盲打命令：

正常的DLL转发劫持如下，调用完应用程序目录里的恶意DLL后会调用原DLL：

0x03 漏洞利用

0x04 参考