反序列化漏洞分析及复现

普元Primeton EOS Platform（以下简称普元EOS）在节前被爆出存在反序列化漏洞。遂在此分析该漏洞成因，如有疏漏或错误，欢迎大佬指正包涵。
普元 EOS 框架分析
1、分析WEB应用的第一步首先看一下，web.xml文件。
在web.xml中我们可以看到其中配置了一个filter，其对应的类为“com.eos.access.http.InterceptorFilter”，拦截了所有的请求。

2、跟进该拦截器的“doFilter”方法。
可以看到InterceptorFilter创建了一个WebInterceptorChain，并将后续处理委托给了WebInterceptorChain。

3、跟进createChain方法。
可以看到WebInterceptorChain是通过获取当前请求的“servletPath”。遍历“configs”中的WebInterceptorConfig的对象。调用WebInterceptorConfig对象的“getPattern()”方法获取“Pattern”。将获取到的“Pattern”正则表达式与当前请求的“servletPath”进行正则匹配。匹配成功则从“interceptors”中获取对应的IWebInterceptor对象，添加进Chain中。

3.1 那么“configs”对象和“interceptors”对象是从哪里来的呢？
“configs”对象和“interceptors”对象有多种来源并且会在应用程序启动时配置完成。
在WebInterceptorManager中我们可以看到WebInterceptorConfig对象部分是通过读取“handler-web.xml”文件生成。

除此之外“configs”对象和“interceptors”对象还会在“handler-processor.xml”文件中进行配置，并且在RequstProcessors中读取并配置。文章篇幅有限，感兴趣的师傅可以自行分析一下。

类似的配置文件还有“contribution.eosinf”（下文会用到，这里提一嘴）。

普元 EOS 鉴权
分析完框架之后我们接下来分析一下，普元EOS的鉴权部分代码。
普元EOS的鉴权代码主要位于“UserLoginWebInterceptor”和“UserLoginCheckedFilter”中。这两个“interceptor”分别在“contribution.eosinf”和“handler-web.xml”中进行配置。 跟进UserLoginCheckedFilter的“doIntercept()”方法。首先判断是否处于登录状态，如果处于登录状态则直接放行。如果未登录则判断是否为“白名单”路径，如果是白名单路径则放行。再判断是否为“黑名单“路径，如果为黑名单路径则抛出异常。最后既不在”白名单“也不在”黑名单“也放行。 “UserLoginWebInterceptor”的代码逻辑与“UserLoginCheckedFilter”相似，本文不再重复分析。

黑白名单中的路径在”user-config.xml“中进行配置。

普元EOS JMX 反序列化漏洞
接下来到了本文的重点。
根据网上曝光的相关信息可以得知该漏洞的路由方式为”.jmx“,而在”handler-processor.xml“中我们可以看到与”.jmx“相关的配置。

跟进配置文件中的”JmxServiceProcessor“类，我们可以看到在”JmxServiceProcessor“类的”process()“方法中直接从request中获取了请求体，作为参数生成了ObjectInputStream的对象，并且调用了它的”readObject()“方法，触发了反序列化漏洞。

复现
利用该漏洞我们只需要向”/default/.jmx“路径，POST 发送payload。因为普元EOS存在”commons-collections“依赖，并且版本处于可利用范围内。因此直接使用CC链即可。


CC6变种
在此和大家分享一个CC6的变种。
在ysoserial中CC6是通过反射调用 ”Runtime.getRuntime().exec()“实现命令执行，不能执行复杂的操作。我们可以通过调用JS引擎的方式实现复杂的操作，例如注入内存马等，代码如下。