记一次信息泄漏引发的惨案

admin 2022年4月15日09:53:06评论108 views字数 2273阅读7分34秒阅读模式

本次文章较为基础,作为一次项目经历中的趣事记录,有很多不足的地方,还请各位大佬轻锤。

在某项目中捞到一处目标站点,是一处某某监控系统的登录页面。登陆的页面大概长如下的样子。

记一次信息泄漏引发的惨案

看起来和找到的其他站点都一样,平平无奇。准备敲弱口令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])+"n";}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并连接。(灰溜溜的上去先把多余的木马文件删除)

记一次信息泄漏引发的惨案

原文始发于微信公众号(雁行安全团队):记一次信息泄漏引发的惨案

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年4月15日09:53:06
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   记一次信息泄漏引发的惨案http://cn-sec.com/archives/814705.html

发表评论

匿名网友 填写信息