记一次信息泄漏引发的惨案
本次文章较为基础，作为一次项目经历中的趣事记录，有很多不足的地方，还请各位大佬轻锤。
在某项目中捞到一处目标站点，是一处某某监控系统的登录页面。登陆的页面大概长如下的样子。
看起来和找到的其他站点都一样，平平无奇。准备敲弱口令admin/123456进行测试，但是当点击用户名的时候，注意到该登录点的用户名框写着大大的三个字“请选择”，直接就无需手动输入。
看来不用先枚举一波可用的用户名了，直接有现成的了。
选择某个看上去像是测试账号的用户名后，输入密码123456，非常丝滑而又毫无悬念的登录……失败。
看着屏幕上冰冷的“用户名或密码错误”8个字，想着先对网站进行一波弱口令猜解。
但是，当我抓取登录数据包，发现网站在前端对密码使用了某种加密方式，直接添加字典进行爆破是没戏了，需要先对前端的加密方式进行绕过。
阅读源码尝试对前端的加密方式进行绕过，找到登录时对密码进行加密处理的guomi函数。
通过关键字passowrd和guomi在网址admin.js中，找到该函数，确认前端使用的SM4的加密方式。找到该加密函数，剩下的就好办了。
通过下断点的方式，找到用户在登录时对密码进行加密所调用的js脚本。通过分析，发现主要有admin.js以及sm4.js。
尝试在浏览器上直接调用该加密方式，对我们的明文字典进行加密。这种方式非常的快捷，只要我们找到登录时对密码加密的函数即可。
当无法确定后续调用的加密js时很好用，但缺点是每次更换暴破字典都需要先生成密文字典。
根据admin.js中的guomi加密函数编写密文字典生成代码，使用只有123456的密码字典进行测试，得到的密文和数据包中密文内容相同。
感觉一切欧克，就在下面的网站对手头的弱口令字典进行处理，转化为列表的格式。
https://uutool.cn/list2json/
在浏览器调试模式console中，使用js脚本，对明文的列表数据调用网站的加密函数进行加密，用得到的密文字典在burp上进行弱口令枚举即可。脚本可以参考如下进行编写：
function guomi(password) {
var s4 = new SM4Util();
s4.iv = "XXXXXX";
var md5str = s4.encryptData_CBC(password);
return md5str;
}
var list=["123456","111111"];
var newlist=[];
for(var i=0;i<list.length;i++)
{
newlist+=guomi(list[i])+"";
}
console.log(newlist);
本想前端提供的用户也不少了，有些账号看着就像简单的测试账号，应该问题不大，结果硬是没有找到弱口令账号（字典都不太行的亚子）。之后对站点进行了未授权访问测试、在JS中搜索敏感路径以及进行注入等测试，均未发现可以利用的点。
就在无聊翻开浏览burpsuite的历史记录中，准备一个一个数据包看看的时候，一个被敏感信息插件标绿的可疑数据包引起我的注意。
通过对该数据的重放发现，该数据包在登录用户选择时，会对服务器的用户信息进行查询，并将用户的敏感信息一并带出，造成敏感信息泄露。这一波操作，开发真的整了一套好活。
在json返回的数据中，发现存在passowrd的字段，后面的数值推测是加密后的登录密码。看起来比较像base64编码，但是尝试解开失败，应该还是与前端相同的SM4方式。这个好办，因为之前注意到这个网站在登录时就使用了密文密码，因此直接将数据包中泄露的登录密码拿来用即可。
使用对应管理员用户的密文密码放到登陆数据包中，成功获得登录所需要的token。
在cookie editor中对token内容进行修改，利用在js文件中找到到的后台地址，成功登录到监控系统。
进入网站后，需要对网站的各个功能点进行测试。本次运气比较好的是，在后台找到一处文件上传点，仿佛看到getshell的希望。
在测试的过程中，发现该上传点在服务器端使用了黑名单限制，在前端进行绕过失败，上传jsp以及jspx后缀文件会引起500报错。
尝试上传txt、cer、html等文件都可以，但是服务器端会对文件名进行修改。这里需要注意的是linux服务器对文件后缀大小敏感，并且tomcat中间件默认情况下是不解析大小写混写或者大写的jsp/jspx后缀文件。
在尝试了诸多文件上传绕过的方法未果后，经过大佬指点，注意到该网站使用了JFinal框架。
阅读网上参考文章，发现是该web框架通过黑名单机制对上传文件进行拦截，并且在3.8版本及之前都存在很玄学的任意文件上传。该框架在上传jsp/jspx文件时，会先上传到服务器上后，再对这些恶意文件进行删除。但是当最末行缺少分割的boundary时，会导致删除恶意文件出错，造成任意文件上传。
于是根据POC重新构造数据包，结果还是返回500的错误。啊这，是姿势不对？因为开始怀疑这个漏洞是否还存在，就下意识多点了点了Go按钮。尝试访问upload/svg/加上传日期目录下的上传文件也无果。
一筹莫展之际，对上传后的路径目录进行缩进，正好发现存在目录遍历。然后跳到upload目录下，已然造成了悲剧。
需要注意的是JFinal框架的任意文件上传漏洞，会将目标文件传递到upload目录下，而非正常的upload/svg/[date]目录下。
利用该文件上传漏洞，成功上传webshell并连接。（灰溜溜的上去先把多余的木马文件删除）
