一个0day的开端——失败的man与nday

2024-10-27 29 0

最近在审计java的CMS,跟着文章进行nday审计,找准目标newbee-mall Version1.0.0(新蜂商城系统),并跟着网上文章进行审计:

https://blog.csdn.net/m0_46317063/article/details/131538307

一个0day的开端——失败的man与nday插图

下载唯一的版本,且源码README中版本也对的上,但没想到nday全部复现失败,但在一番审计后找到了一个新的漏洞点:ssrf,且在前台可以被用户触发。

失败的man与nday:

失败的sql注入漏洞:

(此漏洞原本可以在前台与后台进行sql注入攻击)

分析文章中有两sql注入漏洞,是由于引入mybatis依赖导致,但在我下的版本中根据关键字符${找不到任何的注入点,经过与分析文章对比发现所有注入点全部由${改成了#{由此完成修复。

一个0day的开端——失败的man与nday插图1

失败的权限绕过:

(此漏洞原本可以在admin登录后台通过/;/admin/test完成权限绕过)

复现文章写到以request.getRequestURI()获取路径获取路径后再进入if判断:

一个0day的开端——失败的man与nday插图2

但我下载的版本进行了修复:将获取前端传输的路径方法改为了:getServletPath()从而完成修复。

两种方法的不同具体分析可以参考如下文章:

https://forum.butian.net/share/3730

失败的越权漏洞:

(此漏洞原本可以根据传入的id参数越权修改他人信息。)

定位到具体代码:

一个0day的开端——失败的man与nday插图3

此处代码与复现文章一样,都是先创建一个NewBeeMallUserVO对象,再通过是否为空判断信息修改是否成功。

真正修改信息的代码在updateUserInfo方法里面,于是跟进该方法实现处:

一个0day的开端——失败的man与nday插图4

一个0day的开端——失败的man与nday插图5

发现跟到了接口,于是我们继续跟进,找该接口的实现类:

一个0day的开端——失败的man与nday插图6

跟进到如下类,找到具体实现的代码块:

一个0day的开端——失败的man与nday插图7

复现文章代码在进入if判断前只有一行代码,并且代码逻辑是从前端传入的id值进行信息修改,但可以看到我下载的代码有两行:

NewBeeMallUserVO userTemp = (NewBeeMallUserVO)httpSession.getAttribute(Constants.MALL_USER_SESSION_KEY);

首先通过http.Session获取当前用户,再赋给创建的userTemp对象。

MallUser userFromDB =mallUserMapper.selectByPrimaryKey(userTemp.getUserId());

再从userTemp对象中获取id值进行信息修改,而非从前端请求中获取参数id的值,来完成漏洞修复。

0day的发现:

登录后台,点击修改或者添加商品:

一个0day的开端——失败的man与nday插图8

随意传入图片后点击保存并抓包。

一个0day的开端——失败的man与nday插图9

将POST数据包如上两个参数修改为dnslog地址,放包,在商城前台搜索该商品名称。

一个0day的开端——失败的man与nday插图10

点击访问,dns平台出现记录。

一个0day的开端——失败的man与nday插图11

漏洞代码分析:

先看看商品信息存储过程:

根据接口定位代码块:

一个0day的开端——失败的man与nday插图12

可以发现在接受参数后进行是否为空判断后进入了核心方法updateNewBeeMallGoods,跟进:

一个0day的开端——失败的man与nday插图13

跟到接口后再找到接口实现类,最后定位到更新信息代码块。

可以看到,仅仅对传入参数值进行为空判断和相同判断后,便调用set方法进行存储。

接下来再看看商品信息调用代码链。

根据触发漏洞的数据包接口定位代码块:

一个0day的开端——失败的man与nday插图14

此处代码根据传入goodsid参数,将商品渲染到前端,也就是搜索商品后,见到商品那刻触发漏洞。

对接受goodsid参数是否<1判断后进入取商品信息代码。

跟进getNewBeeMallGoodsById方法,找到方法接口后再找接口实现类,再找方法:

一个0day的开端——失败的man与nday插图15

发现goodsid参数传入selectByPrimaryKey方法。

一个0day的开端——失败的man与nday插图16

该方法通过数据访问对象(DAO)goodMapper调用,且在方法最前处由NewBeeMallGoodsMapper对其定义:

一个0day的开端——失败的man与nday插图17

全局搜索,找到对应xml文件:

一个0day的开端——失败的man与nday插图18

发现通过id参数对数据库操作,取出goodsCoverImg与goodsCarousel参数。

回到最先前的类:

一个0day的开端——失败的man与nday插图19

此时goods对象已经获取商品相关参数值。

再进入if判断商品是否上架,上架则进入下一轮代码,将商品信息封装为视图模型,找到NewBeeMallGoodsDetailVO类,发现只接受了goodsCoverImg参数,也就是先前抓包修改处只用修改该参数即可:

一个0day的开端——失败的man与nday插图20

最后返回视图名称"mall/detail",表示渲染商品详情页面:

一个0day的开端——失败的man与nday插图21

由于存储时未做任何过滤,进行视图层渲染时直接拿出goodsCoverImg参数放到前端,导致用户一旦访问商品便触发该漏洞。


4A评测 - 免责申明

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

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

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

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

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

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

相关文章

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

发布评论