Java审计之CMS中的那些反序列化漏洞
0x00 前言
过年这段时间比较无聊，找了一套源码审计了一下，发现几个有意思的点拿出来给分享一下。
0x01 XStream 反序列化漏洞
下载源码下来发现并不是源代码，而是一个的文件夹，里面都已经是编译过的一个个class文件。
在一个微信回调的路由位置里面找到通过搜索类名 Serialize关键字找到了一个工具类，并且参数是可控的。
这里调用xstream.fromXML(xml)进行反序列化。
而下面这个看了一下lib文件夹下面的组件其实是有着cc cb等组件，并且这个组件的反序列化漏洞是在版本范围内。
找到路由位置，发现访问页面的时候显示API 什么的错误。POC打过去没有任何响应。这个点弄了比较久没弄出来，暂且留着。
0x02 Shiro反序列化漏洞
上次的点没弄出来后，开始转换思路。再次从web.xml入手
发现这里加载了一下配置文件，从中还发现了shiro的配置文件，前面还真没注意到。
并且在lib的组件找到了这个shiro组件，但是发现这个是1.3版本的。而shiro 550漏洞的版本是在1.2.4，但是问题就来了，不在漏洞版本内就是不能打了嘛？其实不是的。
Shiro 1.2.4及之前的版本中，AES加密的密钥默认硬编码在代码里（SHIRO-550），Shiro 1.2.4以上版本官方移除了代码中的默认密钥，要求开发者自己设置，如果开发者没有设置，则默认动态生成，降低了固定密钥泄漏的风险。
回头再来看看上次分析的shiro550的细节
这里key是定义在代码里面的，定义死的。
但是只要能找到他配置的密钥就能伪造Shiro的加密流程发送gadget进行反序列化，从而达到命令执行。
这里找到web.xml加载的这个配置文件翻找了一下还真找到了密钥。这里密钥配置的不是随机密钥。
那么这里还需要找的一点是漏洞地址在哪里，也就是shiro作用于哪个地方，一般使用shiro都是将这些东西托管给shiro做权限控制，而在做权限控制的时候同时也需要配置到一些后台的登录地址，这里是从配置文件上方找到了这个地址。
配置对应的key值拿到工具里面跑一下
以上是xml文件的配置方式的审计方法，当然部分cms也会采用一个config类来进行配置。同理还是找到配置类然后看密钥
这里Config配置Shiro的本地没环境，找了一个网上的图。
漏洞修复
其实修复起来也很简单，只需要使用随机密钥就好了。
<bean id="rememberMeManager" class="org.apache.shiro.web.mgt.CookieRememberMeManager">
<property name="cipherKey" value="#{T(com.nova.framework.modules.sys.security.GenerateCipherKey).generateNewKey()}"></property>
</bean>
0x03 结尾
整体的其实还是比较简单，但是在XStream这个洞里面远程调试的环境不知道为啥一直搭不好，不知道是环境问题还是啥，断点停不下来。总的来说其实还是有源代码审起来舒服，环境只要一搭建好就能本地调试下断点。