rmi 反序列化漏洞_Dubbo反序列化漏洞复现分析(二)

604993d97d1e49639373fdebeae8b765.png

成功弹出计算机

c0a396c08449f1f564baa86ed5c161c0.png

5.漏洞分析

我们从idea里的报错栈可以看到入口应该是javax.servlet.http.HttpServlet.service

9ac64cfd63dae74bb6536cc53fc1fe24.png

我们在this.service处下个断点

73eb19418a0bcd7132cd5aca67366fab.png

我们用postman发个包,然后跟进去,发现它会用handler函数处理request,response

93af37ca21db0670d131075971a75d9f.png

随后发现其进入org.apache.dubbo.rpc.protocol.heep.HttpProtocol中的handle

5d429a68d294ecefc94da7e691c0880a.png

当跟进去后handleRequest,F8后发现直接弹出了计算机,所以可以判断漏洞出发点就在红框中,因此选择跟进

9ce9cc2540b50f29ee66d37eff49337c.png

42e5c2ac3512d3f0b32c6b149239aae7.png

继续进一步跟踪,最后在

org.springframework.remoting.rmi.RemoteInvocationSerializingExporter的

doReadRemoteInvocation发现了反序列化入口 

该ois对象来源为报文中post data部分,对于传入的ois并没有做任何安全检查,直接就执行read0bjec方法导致REC产生。

43828437c1591dbec194a1b177ddc77d.png

6.坑点

我一开始发包是采用burp进行发包的,但是一直没有达成效果。

f714ea9ae075853f098addea609e8625.png

就连错误栈里都没看到commonsollection4的执行调用。

d99053c8497251ad69a6a74a44e74901.png

我当时打开断点判断时,发现会进入read0bject的,但是就是没成功。

b951dda83594bb5d9436eb999f8f119c.png

我估计是因为编码问题吧,直接从payload.ser文件中粘贴序列化代码,导致代码发生了变化,所以传进去后反序列化就不行了。

参考链接

https://zhzhdoai.github.io/2020/08/26/Dubbo%E5%8E%86%E5%8F%B2%E6%BC%8F%E6%B4%9 E%E4%B9%8BCVE-2019-17564/

https://www.cnblogs.com/wh4am1/p/12307848.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值