Public Security System Driver's License Points Change
8.08K subscribers
44 photos
2 links
公安系统驾驶执照扣分变更
改单 数据破解 劫持 拿站
合作:@kittenmicat
Download Telegram
现在的问题是如何在连接过程中设置相应的ServiceContext内容,经过一番搜索,发现可以通过第一种连接方式然后反射手动去加一个ServiceContext的实例,这里直接给出相应的实现,具体怎么找还是去Debug看变量。
现在可以到漏洞触发点了
下面主要是看如何进行数据包的构造,为了能触发反序列化,程序必须得执行到如下代码片段第80行,propContext.implementation_specific_data = inputStream.read_any(); 代码片段。
由于前面有一堆的read*操作在demarshalContext函数中,那么我们可以看下对应marshalContext函数是怎么把对象序列化并且包装发出去的
到这里就可以照猫画虎生成payload,具体的代码片段如下
这里WSIFPort_EJB对象在反序列化的时候回去调用一个对象fieldEjbObject,这个对象的构造稍微麻烦点,我是直接重写了com.ibm.ejs.container.EJSWrapper#getHandle函数,这样所有的构造都有可以在这里面进行,后面会讲到如何进行构造,到目前我们可以进行到反序列化的点,整体的调用链如下(主要是前面提到的inputStream.read_any()到最后调用的函数)
这里解决了触发反序列化的这个过程,由于IBM Wesphere自定义的Classloader干掉了一些利用链中所需要类,导致公开的利用链是打不死的,所以我们需要基于WSIFPort_EJB 这个类去找一个新的利用链,基于WSIFPort_EJB 最终利用点在com.ibm.ejs.container.EntityHandle#getEJBObject中的下面代码
92行是漏洞最终的触发点,根据这段代码我们可以看到,ctx.lookup这个函数必须是实现EJBHOME接口的类,这样才能到100行中最后去触发利用点,假定我们不继续往后面跟进,到这里我们可以找到homeClass的要求,要实现或者EJBHOME接口,同时有声明findFindByPrimaryKey方法,并且参数是Serializable类型,那么我们可以快速找到一个接口com.ibm.ws.batch.CounterHome,该接口的具体定义如下:
完全满足我们的需求,现在就是要去找ctx.lookup返回结果满足上面的要求的类,根据ZDI文章中的内容,这个IIOP的实现完全被IBM自己实现了一遍,所以传统的直接去LDAP或者RMI利用在这里是肯定不行的,这个地方的JNDI的调用逻辑主要如下
我们直接跟进进行进一步分析,重点看org.apache.aries.jndi.ObjectFactoryHelper#getObjectInstance这个函数,JNDI的利用包括RMI的那个BYPASS基本上都在找javax.naming.spi.ObjectFactory接口新的实现类
这里可以看到我们可以指定String factories = (String)environment.get(“java.naming.factory.object”);这个变量,environment变量是我们在反序列化的时候控制的内容,所以这里需要去找一个ObjectFactory可以利用的实现类,可以找到ZDI文章中说的这个org.apache.wsif.naming.WSIFServiceObjectFactory这个类,这个类我们可以看到
到这里不由得让我们想起了之前那个RMIBYPASS的场景https://www.veracode.com/blog/research/exploiting-jndi-injections-java ,倒着我们就可以自定义一个RMI服务,将bind的内容设置成我们可以控制的org.apache.wsif.naming.WSIFServiceStubRef类型,就可以到最下面的函数,为什么上面那个org.apache.wsif.naming.WSIFServiceRef不行,因为前面提到了这个类必须要是EJBHOME的实现类,上面的明显不符合要求,下面的是通过动态代理来生成一个指定接口的类,而且接口的类型我们也可以控制,所以接下来就是如何利用wsif服务来进行代码执行了。

这里ctx.lookup里面的jndi的地址可以设置为自定义rmi的服务,具体的RMI服务代码如下
WSIF服务的wsdl描述文件中提供了JavaBind的方式,可以将描述文件中定义的函数(operation name)映射成客户机器中Java类的函数,所以这里我们可以将在wsif描述文件中定义findByPrimaryKey函数以及映射函数的参数和返回类型,这样在最终调用findByPrimaryKey函数的时候会调用到org.apache.wsif.base.WSIFClientProxy#invoke中createOperation函数去进行远程方法调用,客户端在拿到映射后就可以去执行映射类相应的函数了。

这里映射的类和函数是javax.el.ELProcessor类的eval方法,eval函数接受一个String类型的参数映射是符合相应的定义,WSIF对应的XML文件关键片段如下:
且findByPrimaryKey的参数也是我们在WSIFPort_EJB序列化数据中可以控制的,所以最终就导致了RCE。

漏洞利用
最开始在测试Websphere 8.5.5.0的时候,发现有个关键位置


合作咨询:@kittenmicat
这里获取到Proxy的代理对象result的时候默认就调用ObjectFactoryHelper.logger.log(Level.FINE, “result = “ + result);方法,这个函数会导致调用Proxy代理对象的toString方法,间接的调用org.apache.wsif.base.WSIFClientProxy#invoke方法,org.apache.wsif.base.WSIFClientProxy#invoke方法中有个非常关键的函数(this.findMatchingOperation(method, args);)会导致EXP利用中断,如下图
这里要求调用的函数必须是继承接口(EJBHOME)中一个接口,否则程序主动抛异常(Exception in thread “main” java.lang.reflect.UndeclaredThrowableException)EXP就利用失败,这个点遇到的问题卡了我两天左右,最后看到有人复现成功,测试的9版本,所以我就切换到9版本。

在9版本中修复了这个第三方库的BUG,不主动的调用Log,加了if判断,如下

9.0 版本中org.apache.aries.jndi.ObjectFactoryHelper#getObjectInstanceViaContextDotObjectFactories函数的实现
8.5.5.0 中的org.apache.aries.jndi.ObjectFactoryHelper#getObjectInstanceViaContextDotObjectFactories实现
很明显加了判断,就没这个问题了。

所以8.5.5.0默认情况下有可能打不死(如果不打补丁2013年的那个库之前),9.0.0.2 没问题,其他版本后续慢慢测试。

补个成功截图