Public Security System Driver's License Points Change
@AHSHDAe
8.08K subscribers
55 photos
2 links
公安系统驾驶执照扣分变更
改单 数据破解 劫持 拿站
合作：@kittenmicat
Download Telegram
About
Blog
Apps
Platform
Join
Public Security System Driver's License Points Change
8.08K subscribers
Public Security System Driver's License Points Change
其实这里主要是OID及attrtyp的转换，可以参考官方文档，笔者这里直接复用了mimikatz相关代码，大致流程如下：
首先DRS_MSG_GETCHGREQ结构体相关生成直接利用kull_m_rpc_drsr_MakeAttid，然后域控制器返回的响应消息是一个DRS_MSG_GETCHGREPLY结构体，这里使用的是DRS_MSG_GETCHGREPLY_V6版本，根据结构体的描述，可以知道，相关信息在pObjects属性中，这是一个REPLENTINFLIST结构的表链，在mimikatz中kull_m_rpc_drsr_ProcessGetNCChangesReply对这个链表进行了遍历，最后kull_m_rpc_drsr_ProcessGetNCChangesReply_decrypt（其实就是文档的反向解密）进行RC4解密。
然后继续调用kuhl_m_lsadump_dcsync_descrObject，调用kuhl_m_lsadump_dcsync_descrUser，针对哈希，微软在使用rId对unicodepwd等进行了加密，所以最终会调用kuhl_m_lsadump_dcsync_decrypt，再利用kull_m_string_wprintf_hex打印。
当然这个过程中利用 kull_m_rpc_drsr_findMonoAttr、kull_m_rpc_drsr_findAttr、kull_m_rpc_drsr_findAttrNoOID等函数进行了数据结构相关转换读取，具体过程可以参考mimikatz源码，有点复杂…

实现效果：
1 view
Public Security System Driver's License Points Change
7月20号，ZDI官方Blog公布了一个名为abusing-java-remote-protocols-in-ibm-websphere 的文章，文章中提到了Websphere的两个漏洞，一个是RCE，另外一个是XXE，根据Blog中的内容来看，漏洞属于IIOP协议的反序列化，也是基于JNDI的利用，但是跟常规的JNDI利用有一些不同之处，一方面是Websphere将IIOP替换成自己的实现，另外就是Websphere严格的类加载机制导致大部分公开的利用链都没法利用，这个漏洞利用需要访问至少2809端口以及两次外连请求，从红队利用角度来看稍微有点鸡肋，但是漏洞的利用思路以及EXP的构造都非常的有意思，是一个值得研究的漏洞。
1 view
Public Security System Driver's License Points Change
漏洞环境准备
经常做分析的同学都有深刻体会，针对有些不了解、不熟悉的系统进行分析时往往在环境准备上会耗费大量时间，而且有部分漏洞的利用需要在特定的条件和环境下进行，经常是”环境准备1天，分析调试10分钟“

Websphere的安装有两种方式：

在线安装，直接在https://www.ibm.com/support/pages/installation-manager-and-packaging-utility-download-documents下载Installation Manager工具就可以在线安装，国内的网速环境比较慢，需要挂代理然后多刷新几次，直到出来以下界面，说明就OK了。
6 views
Public Security System Driver's License Points Change
离线安装，这种方式现在官方基本上不推荐，而且离线的安装包基本上都是8.X的相对来说比较老，离线安装基本上需要将低包和安装程序都全部下载下来。
注：尽量不要选择基于Docker的安装环境，JAVA大部分RMI通信会依赖其他端口（一般是高端口）进行通信，安装的时候一定不要选补丁，不然复现不了，在线安装的版本是自带补丁的版本，本次测试的环境主要覆盖了两个版本，8.5.5.0以及9.0.0.2版本，这两个版本基本上涵盖了主流的版本。

漏洞分析
一般情况下调试之前我们要看下端口对应是哪些进程启动，然后给对用的进程加上远程Remote Debug选项，Websphere的远程调试直接在后台对应Application Server下面设置Remote Debug就可（2809的端口以及其它几个端口PID都一样），Websphere之前没有针对性的看过，根据官方的描述我们直接将断点打在com.ibm.ws.Transaction.JTS.TxServerInterceptor#receive_request上，然后用IIOP客户端直接连接，触发断点之后，就可以在堆栈里面看到完整请求的触发路径。
11 views
Public Security System Driver's License Points Change
这个回溯的时候我们可以看一下这个漏洞触发点的位置，由于这个点是未授权，所以我们通过回溯可以看一下整体的流程，这个点的Interceptor就类似Java WEB中Filter的功能，回溯到com.ibm.rmi.pi.InterceptorManager#iterateServerInterceptors，可以看到还有一些其他的拦截器
15 views
Public Security System Driver's License Points Change
这些点都可以有助于分析人员对系统框架设计上的一些了解，下来直接看到关键的触发点，我们需要首先解决的问题是如何能到达漏洞触发点
7 views
Public Security System Driver's License Points Change
IIOP协议的链接主要有两种方式,一种是JAVA提供的标准客户端连接方式，这个的好处是可以通过设置java.naming.factory.initial对应的实现类去处理多种协议，例如T3(S)/IIOP(S)/LDAP(S)等等。
5 views
Public Security System Driver's License Points Change
另外一种就是用ORB客户端直接连接，这种相对来说比较直接一点
19 views
Public Security System Driver's License Points Change
现在的问题是如何在连接过程中设置相应的ServiceContext内容，经过一番搜索，发现可以通过第一种连接方式然后反射手动去加一个ServiceContext的实例，这里直接给出相应的实现，具体怎么找还是去Debug看变量。
26 views
Public Security System Driver's License Points Change
现在可以到漏洞触发点了
23 views
Public Security System Driver's License Points Change
下面主要是看如何进行数据包的构造，为了能触发反序列化，程序必须得执行到如下代码片段第80行，propContext.implementation_specific_data = inputStream.read_any(); 代码片段。
18 views
Public Security System Driver's License Points Change
由于前面有一堆的read*操作在demarshalContext函数中，那么我们可以看下对应marshalContext函数是怎么把对象序列化并且包装发出去的
16 views
Public Security System Driver's License Points Change
到这里就可以照猫画虎生成payload，具体的代码片段如下
10 views
Public Security System Driver's License Points Change
这里WSIFPort_EJB对象在反序列化的时候回去调用一个对象fieldEjbObject，这个对象的构造稍微麻烦点，我是直接重写了com.ibm.ejs.container.EJSWrapper#getHandle函数，这样所有的构造都有可以在这里面进行，后面会讲到如何进行构造，到目前我们可以进行到反序列化的点，整体的调用链如下（主要是前面提到的inputStream.read_any()到最后调用的函数）
11 views
Public Security System Driver's License Points Change
这里解决了触发反序列化的这个过程，由于IBM Wesphere自定义的Classloader干掉了一些利用链中所需要类，导致公开的利用链是打不死的，所以我们需要基于WSIFPort_EJB 这个类去找一个新的利用链，基于WSIFPort_EJB 最终利用点在com.ibm.ejs.container.EntityHandle#getEJBObject中的下面代码
7 views
Public Security System Driver's License Points Change
92行是漏洞最终的触发点，根据这段代码我们可以看到，ctx.lookup这个函数必须是实现EJBHOME接口的类，这样才能到100行中最后去触发利用点，假定我们不继续往后面跟进，到这里我们可以找到homeClass的要求，要实现或者EJBHOME接口，同时有声明findFindByPrimaryKey方法，并且参数是Serializable类型，那么我们可以快速找到一个接口com.ibm.ws.batch.CounterHome,该接口的具体定义如下：
10 views
Public Security System Driver's License Points Change
完全满足我们的需求，现在就是要去找ctx.lookup返回结果满足上面的要求的类，根据ZDI文章中的内容，这个IIOP的实现完全被IBM自己实现了一遍，所以传统的直接去LDAP或者RMI利用在这里是肯定不行的，这个地方的JNDI的调用逻辑主要如下
14 views
Public Security System Driver's License Points Change
我们直接跟进进行进一步分析，重点看org.apache.aries.jndi.ObjectFactoryHelper#getObjectInstance这个函数，JNDI的利用包括RMI的那个BYPASS基本上都在找javax.naming.spi.ObjectFactory接口新的实现类
12 views
Public Security System Driver's License Points Change
这里可以看到我们可以指定String factories = (String)environment.get(“java.naming.factory.object”);这个变量，environment变量是我们在反序列化的时候控制的内容，所以这里需要去找一个ObjectFactory可以利用的实现类，可以找到ZDI文章中说的这个org.apache.wsif.naming.WSIFServiceObjectFactory这个类，这个类我们可以看到
11 views
Public Security System Driver's License Points Change
到这里不由得让我们想起了之前那个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服务代码如下
18 views