当前位置: 首页 > 技术干货 > 记录一次CMS的代码审计

记录一次CMS的代码审计

发表于:2024-06-26 16:11 作者: 1q1ng 阅读数(867人)

本次代码审计使用了白加黑的手法,用黑盒的视角测试功能点,用白盒的方式作为验证。

0x1 XSS

guestbook处,可以看到有一个留言板

idea搜索guestbook。发现代码如下,其中的getModel是获取数据的方法。Guestbook.class就是具体要获取的数据。

跟进Guestbook.class查看,发现GuestBook继承自BaseGuestbook

继续跟进BaseGuestbook可以发现http请求的数据,没有发现有过滤函数。

然后使用管理员登录后台查看留言,发现确实如我所想,存在xss漏洞。

ps:审计小技巧,开启sql日志然后一边打payload一边看记事本是否漏掉过滤哪些字符。这里是完全没有过滤,所以在出库的时候如果没有防护,基本上就是实锤xss了。

0x2 SQL注入

在产品中心发现有一个搜索框

看到源码,没有发现有过滤字符,这里采用之前开启的mysql日志,通过日志文件的sql语句判断是否有过滤。

直接输入单引号发现该cms返回500报错,很有可能存在sql注入。

于是使用两个单引号''使得系统不抛出异常,然后查看日志文件中发现sql语句没有过滤单引号,说明注入确实存在。

or 1 结果

or 0结果 注入确实存在

0x3 文件下载

/common/down路由中的file方法,直接获取http请求中的filekey参数,并且没有过滤../等关键字符。fileKey的值和PathKit.getWebRootPath()函数的返回值拼接。然后fileKey其实就是http中的参数。

ps:该路由不在前台,只能通过白盒的方式去进行,但是后续通过github上的fuzz字典发现也可以fuzz得到但是fuzz发包数量巨大不作为参考。但是日后如果实在挖不出洞,可以考虑多fuzz一下,也许就出货了也说不准。这里用的字典较大,其实可以考虑小一些的字典,算是个人的一些挖洞经验吧。

参数的fuzz

0x4 csrf

在系统管理-> 系统用户 -> 添加用户处,抓包然后使用burp生成csrf poc

保存至html后,点击submit request

可以看到用户被成功添加了

0x5 组合拳+sql备份getshell未果(条件较为苛刻)

这里是想getshell来着,毕竟都白盒了,当然能getshell就getshell,不能getshell就想办法getshell了。这里是发现后台上传接口,过滤了jsp,jspx文件名。

发现公司管理->基础内容->公司信息有上传图片

上传jsp文件,jspx文件均被拦截。

然后发现系统管理->数据库管理处发现可以进行数据库备份还原操作。在数据库还原抓包,发现是一个sql文件名字。这里想到之前的任意文件下载,那么岂不是可以通过上传一个sql文件,然后通过备份这个sql文件进行数据库备份getshell。

首先去下载备份好的sql文件,路径在static/back/文件名

然后添加getshell的payload

然后上传该sql文件,注意需要改后缀名为png

然后sql备份处填写上文件名,使用../让系统跨目录读取png图片

然后查看payload上的1.jsp是否成功生成。

访问的时候失败了,无法解析jsp,jspx等文件,但是服务器确实有写入了jsp文件

得到了两个前置条件

  1. 需要知道系统的绝对路径

  2. 系统下得开启其他能够解析的应用(如另外一个java系统在其他端口上,但是能够解析jsp,就可以通过该cms的漏洞在其他系统上写webshell,也算是一个任意文件写入,做到了"隔山打牛")

0x6 默认密码

一个比较容易忽略的点,通常admin的默认密码管理员基本都会在部署网站之后马上修改,但是如果类似有几个账户的情况下,管理员可能会忽略掉其他用户的默认密码。这里可以直接看sql文件。在其sql文件下发现有两个默认账号一个是admin,一个是read。

read登录成功

0x7 总结

本次代码审计强化学习了白+黑的方式,更加简单的找出了漏洞,有些地方还欠缺一些思路,比如0x5rce那一块,想着是不是可以写一个class文件达到rce的效果。或者覆盖掉原本的xml文件之类的操作,不允许上传jsp,jspx文件是否可以通过上传war包来进行getshell。总之觉得还有诸多不足,篇幅关系记录到这。