局域网监控软件WFilter ICF 鸡肋0day RCE漏洞挖掘

 

0x00关于本文

逛freebuf的时候看到了这篇文章，关于PDD员工发帖溯源联想到的相关技术与实现，其中提到了一个叫做wfilter的局域网监控软件。

这个软件官网提供了下载链接，支持10天实用，于是我就下下来研究一番。

作为一个搞安全的人，我最感兴趣的是这个软件本身是否存在缺陷，毕竟这类用于监控的安全软件自身出现漏洞是最有戏剧性的事情了

0x01不同寻常Web管理

Wfilter通过串联/旁路的方式进行部署，同时提供一个Web管理接口供管理员进行远程管理。而作为一个Web狗，我自然把重心放在了这个Web管理接口上了。

这个Web管理接口不同寻常的第一点就是登录之后不会返回任何Cookies，而且请求接口的时候也不会带Cookies或者任何特殊的Headers

那它是怎么进行鉴别的呢？

测试了一番之后发现居然是根据IP地址来鉴别的，一旦管理者登录，wfilter就会记录下管理者的IP地址，然后允许其访问这些接口。

这么诡异的鉴别方式大概率搭配了一个诡异的后端实现，结果我用火绒剑一看，发现后台是通过CGI运行的。也就是说想要审计这个软件还得去逆向这个EXE！

算了，逆向就逆向吧，正好试试IDA7.5效果怎么样

0x01对于cgiproj.exe的逆向分析

这个Web接口的特点是通过/fcgi?cmd=【功能名】来调用，因此在IDA里面搜索相关的字符串就可以找到实现通过功能名来执行不同功能的函数了。

这个函数非常的大，以至于我需要修改IDA的hexrays支持的最大函数大小来让IDA能够成功反编译这个函数（Web狗实在是不想啃汇编了）。

经过一番猜测和实验，我发现这个调用sub_BF65E0中的参数包含了功能名字，而v266[1]中存放的则是其对应的函数。通过这些信息我可以查看具体接口是如何实现。

0x02 思路1：找到无需鉴权的功能，直接拿下服务器！

实现这个思路，简单来说就两个步骤，第一个是找到无需鉴权的功能，第二个是逆向分析然后找到有漏洞功能然后利用。

为了找到无需鉴权就能使用的功能，简单起见，我搜集了那个大函数中的所有的字符串，然后拿到接口中去fuzz，接着发现viewHelp,helpSearch,login,mobileCode,mlogin,logout,remoteLogin,viewToolTip,ExecuteNoLogin,forgetPassword,resetPassword,viewHTML这些功能对应的接口无需登录。

但是很快发现他们都无助于入侵。

比如mobileCode功能虽然调用了system()但是所有的参数都是写死的，要么写死在程序里面，要么从配置文件里面读取

而viewHTML功能虽然可以玩路径穿越读取文件，但是后缀写死了htm，我尝试了00截断和Windows路径长度截断来绕过但是均未成功

ExecuteNoLogin功能看名字很诱人，看样子似乎还可以直接给一个IP让它信任，但是我无论如何调用都显示错误，也没法直接RCE了

而其余的功能更是没法利用，因此目前看下来这条路就堵死了。

0x02 思路2：利用XSS/CSRF配合后台RCE ---XSS挖掘

实现一键日天看起来是不现实了，但是XSS/CSRF配合后台RCE并不是没有可能的。

首先我需要找一个靠谱的XSS漏洞。很快我就发现一个似乎可以利用的点，在“网页浏览”记录查看中，一旦请求带了User Agent，系统就会把User Agent放在前端

为了验证我这个猜测，我在安装了wfilter的机器上再装了个python requests库，以便于调试（简单起见，我并没有用串联/并联的方式将其接入我的网络），接着利用requests库构造一个包含XSS Payload的User-Agent，就像这样

接着再去看历史

0x03 思路2：利用XSS/CSRF配合后台RCE ---后台RCE挖掘

最开始我想的是直接搜system函数，查看引用，寻觅一波命令注入，但是并没有明显容易注入的点（主要是因为反编译出来的函数太大，而且一些不太清晰的反编译让我无法理清逻辑）。因此我采取另一种办法，即查看web界面有哪些有趣的功能，然后针对性地反编译。

在翻找了一阵子后，我发现了这个系统包含了利用插件扩展的功能。

执行插件的时候抓个包，我发现了一个叫做runDll的功能，这不明显的让我为所欲为？

到IDA上一看，发现这个runDll的逻辑是根据接收到的dll参数加载dll

接着再去获取的proc参数作为函数名，通过GetProcAddress获取函数地址。

最后再去把获取的para参数和另一个不知道干什么的v36传入到刚刚获取的函数中

分析透了这个runDll之后，我们可以发现这里有执行shell的可能性。

首先这个dll参数并没有任何过滤，这意味着我们可以穿越到任意目录中去调用任意位置的DLL，因此Windows的各种API我们都可以想办法去调用了。

接着我需要找一个API函数，它接收两个参数，第一个参数是命令，第二个参数随便什么都可以，尽管看起来要满足这个条件相当的苛刻，但是真的有一个函数可以做到，那就是WinExec

而根据微软的描述，这个函数在Kernel32.dll中

于是构造如下Payload打过去

函数成功执行，但是并没有弹出计算器，不过这个执行的过程已经被火绒剑记录了下来，这证明我们成功地执行了shell

至此，整个利用链已经清晰了，就是通过XSS让管理员执行恶意JS，从而触发一个CSRF过去让服务器执行shell

0x04 完整的利用过程展示

首先用CS生成一个powershell的payload，这样就可以做到一执行命令就弹shell，接着编写CSRF

Payload,用我写的CSRF 原理 利用 防御就可以了。

由于samesite Cookies机制，现在用POST来发CSRF包会导致Cookies不会发过去，但是现在是用IP来认证的，和Cookies无关，所以用POST来发是完全没问题的

接着用requests去插入一个带有XSS的访问记录，这个Payload的功能是去引入攻击机上面的JS来执行

再去访问历史记录查询页面，发现CS Shell弹回来了！，攻击成功！

在复现的时候发现有点坑，对于已经访问过的网站Wfilter似乎不是那么愿意再记录一次，并且有时候记录不下来，不知道原因是什么，猜测是软件自带的bug

0x04 结语

这次就懒得写EXP出来了，毕竟这个漏洞用起来应该还是相对鸡肋的，写出来也没有什么用处。这个漏洞首先要求攻击者需要能让自己的流量被记录下来（所以需要能够进入内网中），而且还要管理员点击了历史记录查询页面才会触发，而且XSS Payload的引入过程还并不是那么的稳定因为有的时候还插入不了。

因此想要成功利用这个漏洞进行攻击，需要天时（XSS 能够插入）地利（进入了内网）人和（管理员去查看历史访问记录）的配合，这个条件是相当苛刻的，在实战中也不太可能真正使用这么不稳定的攻击。

不过逆向这么一个cgi程序还是挺有意思的，玩玩IDA陶冶身心也不错，权当是一次小练习吧