博文

Packer-Fuzzer漏扫工具RCE 0day(当前已被官方修复)

图片
  0x00关于本文 今天朋友丢我一个授权测试的站,那个站用vue写的前端,因此前端js包含了所有的接口。 而另一方面整个前端就一个登录框堵在那儿,因此翻js几乎成了唯一的思路。 翻着翻着,我烦了,于是估摸着网上已经有前辈们写出了专门针对webpack的扫描工具,一搜就搜到了Packer-Fuzzer( https://github.com/rtcatc/Packer-Fuzzer ) 当我浏览这个工具的介绍的时候,我注意到了这句话 “本工具将会通过PyExecJS运行原生NodeJS代码,故我们推荐您安装NodeJS环境” 看到这句话我一下就警觉起来,毕竟nodejs是可以执行命令的,而相关的安全问题已经让蚁剑翻过车了( https://xz.aliyun.com/t/8167 ),于是一瞬改变目标开始研究这个工具,并且挖掘出了RCE 当前漏洞已经被官方修复,并且奖励800(由于我Twitter上提前公开了漏洞导致高危->中危) 本文将会从分析者的角度分析漏洞 0x01定位js执行点 简单搜索execjs就可以找到执行点,位置在Recoversplit.py的57行 0x02 防护绕过 作者在写这个代码的时候也意识到了被反打的可能性(“防止黑吃黑被命令执行”),所以当js出现了exec和spawn的时候就不会执行,但是这样的简单的防护几乎是没有用的。 且不说nodejs沙箱逃逸已经被师傅们玩出花来了,单是这里eval没有过滤掉就可以通过字符串拼接或者url编码的方式绕过这个限制 比如说这里就用了url编码了能弹出计算器的payload,解码并eval之后就能弹出计算器 0x03 调用分析 那么这个执行点是怎么被调用到的呢 看了下代码,发现执行点在RecoverSplit类的jsCodeCompile里,这个函数被同一个类的checkCodeSpilting调用,而checkCodeSpilting又被这个类的recoverStart调用,recoverStart被Project类的parseStart调用,而parseStart,而再往前追溯就是命令参数处理之类乱七八糟的地方了 知道了这些东西之后,我们就可以根据它的调用一步一步走,一点一点写出RCE的POC了 0x04 如何进入recoverStart函数?让程序相信这个网站使用了webpack 我们看到这

局域网监控软件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,forget

360ARP防火墙“智能追踪”原理探究

图片
  0x00关于本文 很早就知道360有个ARP防火墙,中学的微机课上还装个攻击程序来让老师电脑上的360报警,现在课上做ARP实验装了个靶机,忽然就想拿下来调戏一番,结果一调戏就发现一些问题了。 0x01360 ARP防火墙的功能 这个ARP防护功能在360的流量防火墙中的局域网防护中 一旦捕获到了攻击还能“智能追踪” MAC地址懒得打码了 0x01360 智能追踪功能实现原理 最开始,我的猜想是,这个追踪功能靠的是ARP包里面所声称的地址来实现的,因为欺骗者总是想要自己声称自己的MAC地址对应网关的地址,以此来欺骗受害者。 但是测了一下发现并不是这样。 用scapy命令send(ARP(op=1,hwsrc='11:45:14:19:19:81',hwdst='00:0C:29:AC:46:B5',psrc='192.168.1.1',pdst='192.168.1.235')) 构造一个非攻击者的地址发过去,但还是被360找到了真实的地址 这是怎么回事呢?那只能抓包看看了。 一看wireshark就找到问题了,原来以太帧里面就会有这个MAC地址 那么要是把以太帧上的源地址换掉会怎么样呢? 通过scapy可以轻易伪造源地址 sendp(Ether(src='11:45:14:19:38:6F')/ARP(op=1,hwsrc='11:45:14:19:19:81',hwdst='00:0C:29:AC:46:B5',psrc='192.168.1.1',pdst='192.168.1.235')) 结果360就只能看到错误的地址了 而360的“追踪”是怎么回事呢,抓包发现360是执行了一次局域网内的ARP扫描,尝试找到攻击者的MAC地址对应的IP地址 通过这个简单的测试,我们已经知道了360ARP防火墙智能追踪功能的实现原理: 收到异常ARP包的时候,从以太帧中提取攻击者的真实MAC地址,然后执行ARP扫描,找到这个MAC地址对应的IP,从而实现追踪 0x02 点评 360 ARP防火墙只能根据以太帧中的MAC地址来做“追踪”,因此攻击者可以随时改掉包中的地址来借刀别的机器或者让360追踪不出来,当然这并不是360技术有

通达OA11.6 preauth RCE 0day分析

图片
  0x00关于本文 这漏洞我7.4挖出来交给先知,6号审核通过 但是迟迟不发奖金,再留言就又是审核中,一直审核到现在 (怀疑是因为厂商7.5的新版本就不收影响了,阿里觉得亏了?) 护网听说这玩意爆出来了,群里面看知道创宇都有漏洞详情了,感觉吧这个烂在我手上显得没价值,倒不如在EXP流传的到处都是之前,放出来找找乐子 exp放在了 https://github.com/TomAPU/poc_and_exp/blob/master/rce.py 需要者自取( 注意,该EXP不是无损EXP,会删除auth.inc.php让OA无法正常工作 ) 这个漏洞结合了任意文件删除漏洞以及文件上传漏洞,需要两个漏洞配合才可以实现preauth rce 复现需要的11.6安装我传到Google上面了:https://drive.google.com/file/d/1L3wG58EQpCufwqoTRP3lFq7IY6PYYqZ-/view?usp=sharing 需要者自取 0x01貌似鸡肋的任意文件删除漏洞 首先漏洞是在/module/appbuilder/assets/print.php里面 一眼看过去,就是把get里面的guid传过去然后删除掉 但是任意文件删除漏洞除了搞破坏有什么卵用呢,反正一眼看过去是没什么卵用的 0x02化腐朽为神奇的身份绕过 尽管删文件看似只能做破坏,但在某些时候也能绕过一些认证!这是怎么做到的呢? 我们来看看通达OA里常用来做身份校验的代码 这里呢,简单来讲就是把auth.inc.php给包含进来,如果没有对应session的话,auth.inc.php就会作为“拦路虎”,让用户去登陆,但是删掉会怎么样? 这里就要看php里面include和require的区别了 这两个东西看起来很相似,都是包含嘛,但是稍稍学过洋文的都知道,include的意思指的是包含,而require却有要求的意思,在这里就可以看出点区别了。 如果要包含的文件找不着,include就索性跳过去了,而require是要求,感觉更加强烈一些,找不着文件就撒泼打滚fatal error停止不前了。 而恰巧通达OA里面用的都是include,于是如果发现auth.inc.php失踪了,就会直接跳过去! 因此我们只需要利用前面的漏洞,删掉auth.inc.php,即可跳过通达OA里面大部分