Redis on Windows 出网利用探索

Exploiting Redis on Windows with Outbound Internet Access

前言

DLL劫持相关技术已经存在很久了,现在依然可以运用到权限维持和一些木马、外挂、钓鱼上。关于本文叙述的也是基于DLL劫持的方法,关于这个姿势,相信有不少师傅肯定都知道,只是出于某种原因还未公布而已,或者我没有搜索到。

本文主要讲 Redis on Windows 本身的DLL劫持利用。

前段时间因为上碰到 Redis on windows 的情况,所以就查了查资料看看最近网上有没有公布新的方法。
关于 Hunter师傅在XZ总结的 踩坑记录-Redis(Windows)的getshell 文章中。

可以看出来大概的方法有:

  • 写 Webshell
  • Startup
  • 篡改&劫持
  • mof

关于文中所说的DLL劫持被动等待上线这个问题,应该可以在这篇文章中解决。

有师傅可能会想,不是有主从复制RCE的姿势嘛?需要这么麻烦吗?
是因为主从复制后的 关键功能 MODULE LOAD 在4.0.0 之后开始支持,而我从github上找到的Windows版本最新也仅为:

过程

目标环境

OS: Windows Server 2012
Redis: 3.2.100
Role: Administrator
Port: 80,3389,6379

接下去我会讲讲整个发现过程。

常规套路

首先我看到了80端口,这应该是个好信号,因为说不定就可以直接写Webshell,并且还是IIS。那么根据IIS默认安装,发布目录应该是在C:\inetpub\wwwroot下。

通过常规操作,dbfilename 写文件,的确可以正常将asp写进去,但是因为 Windows Server 2012 安装IIS的时候,并不会主动帮助你勾选 ASP / ASP.NET 运行环境,所以即使能写ASP马,也不能解析。

3389 旁路攻击

RDP 看起来似乎除了暴破,没什么更好的方法。

如果存在 CVE-2019-0708,你也可以选择使用 0708 Bluekeep 把主机打重启使之运行启动项中的恶意文件(这是非常不好的做法)。

那么之前的文献中也提到过DLL劫持的方法,所以看看RDP在连接过程中会不会存在DLL劫持了?

本着试试的心态,我搭建了相同的环境,使用Procmon进行分析。

多说一句,如果遇到以下错误,可以下载 KB3033929进行安装。

为了保险起见,我们设置比较宽松的 Filter,只显示 Path end with为 dll的结果。

在发起RDP连接的过程中,我的确发现了 在 Windows Server 2012 中存在 mstlsapi DLL NAME NOT FOUND 的结果。

为什么说是 2012?因为后来我测试了 Windows Server 2008 / Windows 7 / Windows Server 2003 都没有出现这样结果,但不管怎么样,对于当前环境的确可以试试。

关于 mstlsapi.dll 的详细描述,我并没有找到多少,在之前文献中
Cyber Security Awareness Month - Day 9 - Port 3389/tcp (RDP)
有提到:

by default the certificate used for encryption is signed by an RSA private key, which is then stored statically in the file mstlsapi.dll

另外在之前漏洞记录中也存在过一些关于 MITM-attacks的漏洞,根据一些描述猜测应该是许可授权相关的dll。

其实对于劫持利用来说,我们这里也不必一定要了解这个dll的来龙去脉。因为关于DLL 劫持的相关利用,网上已经有很多成熟利用的文章了。

劫持利用

劫持的方式也有很多,之前试过BDF DLL注入,考虑到x64 dll还存在较多问题,所以为了快速达到效果,这里我们使用 kiwings师傅所改的 DLLHijacker 帮助我们生成劫持DLL后的工程项目,以便我们可以自由的修改Shellcode劫持该DLL,此方法利用函数转发完成,不会破坏原有功能(在测试中发现如果转发失败会直接导致无法关机等各种情况),缺点就是他需要原DLL也同时存在操作系统上。

点击收藏 | 8 关注 | 3
登录 后跟帖