公司小兄弟发给我一个py样本，是今日捕获的某weblogic 0day，咱们来分析一下。

使用我的javaSerializationTools工具，来分析这个样本。结果如图

jdk7u21调试一下

当然，weblogic 12已经不支持在jdk版本低于1.8的jdk下运行。

我们可以很明显的看到，这个是反序列化gadgets中7u21的变种。唯一不同的是com.sun.org.apache.xalan.internal.xsltc.trax被用java.rmi.MarshalledObject代替。要了解这个为什么可以绕过weblogic黑名单，我们要了解一下weblogic 反序列化的黑名单究竟是什么

在java反序列化的过程中，会层层解析所需要的类，而weblogic就是控制解析反序列化的类，如果碰到可能触发恶意操作的类的名称，则直接打断反序列化流程。

而weblogic在处理jdk 7u21这条反序列化gadgets中，为了平衡拦截的效果与不影响业务，选择拦截com.sun.org.apache.xalan.internal.xsltc.trax这个类。而这个类恰恰也是绝大多数java反序列化中最为关键的一环。

所以，如果我们想要绕过weblogic针对7u21的反序列化拦截的黑名单，则需要找到com.sun.org.apache.xalan.internal.xsltc.trax的替代。

我在这里简单分析一下7u21中AnnotationInvocationHandler到com.sun.org.apache.xalan.internal.xsltc.trax的过程。因为在poc中只有这里改变了。

Templates类的newTransformer方法，会将属性_bytecodes，通过调用java的defineClass去生成一个类，并将其实例化，也就是调用静态代码块的代码。

而AnnotationInvocationHandler，创建一个Templates的jdk动态代理，在hashmap出现哈希碰撞的时候，在hashmap中会调用AnnotationInvocationHandler的equal方法，equal方法会调用自身的equalImpl方法。最终会调用被代理对象的每个方法，去生成结果，相关代码如下

private Boolean equalsImpl(Object var1) {
// 判断var1是否为AnnotationInvocationHandle,var1是templates，pass
if(var1 == this) {
returntrue;
// 构造限制点，type属性限制了var1必须为this.type的类实例
} elseif(!this.type.isInstance(var1)) {
returnfalse;
} else{
//这里获取了当前成员的方法
Method[] var2 = this.getMemberMethods();
int var3 = var2.length;

for(int var4 = 0; var4 < var3; ++var4) {
Method var5 = var2[var4]; //遍历获取方法
String var6 = var5.getName(); //获取方法名字
Object var7 = this.memberValues.get(var6);//获取memberValues中的值
Object var8 = null;
// Proxy.isProxyClass(var1.getClass()
// 判断varl是不是代理类,显然不是，pass
AnnotationInvocationHandler var9 = this.asOneOfUs(var1);
if(var9 != null) {
var8 = var9.memberValues.get(var6);
} else{
try {
// 这里直接进行了方法的调用核心。
// var5是方法名,var1是可控的类
// var1.var5()
var8 = var5.invoke(var1);

private Method[] getMemberMethods() {
if(this.memberMethods == null) {
this.memberMethods = (Method[])AccessController.doPrivileged(new PrivilegedAction<Method[]>() {
public Method[] run() {
Method[] var1 = AnnotationInvocationHandler.this.type.getDeclaredMethods();
AccessibleObject.setAccessible(var1, true);
returnvar1;
}
});
}

returnthis.memberMethods;
}

因为newTransformer方法恰好为Templates的第一个方法，如果是第二个方法的话，会导致执行第一个方法的时候出错而中断整个反序列化链。

而poc中，使用了java.rmi.MarshalledObject这个类，我们来分析一下。

在java.rmi.MarshalledObject中，getMemberMethods方法返回的一个方法是get。get代码如下

public T get() throws IOException, ClassNotFoundException {
if(objBytes == null)   // must have been a null object
returnnull;

ByteArrayInputStream bin = new ByteArrayInputStream(objBytes);
// locBytes is null ifno annotations
ByteArrayInputStream lin =
(locBytes == null ? null : new ByteArrayInputStream(locBytes));
MarshalledObjectInputStream in=
new MarshalledObjectInputStream(bin, lin);
@SuppressWarnings("unchecked")
T obj = (T) in.readObject();
in.close();
returnobj;

一看就懂了，将objBytes属性作为反序列化的流，从中解析对象。我们知道，weblogic中，必须要调用FilteredObjectInputStream，才可以在反序列化过程中使用反序列化的黑名单。如果类中私自调用ObjectInputStream，则不会应用weblogic反序列化的黑名单。从而绕过

剩下的流程就与7u21的触发流程就一样了，只需要把objBytes随心所欲的替换为你喜欢的反序列化就可以，在这里无视weblogic黑名单。

当然，我拿到的样本，只是一个简单的回显代码，并没有太复杂的操作。

解决方案

1. 这个反序列化漏洞并不只是影响jdk7u21，因为我们知道8u21是7u21的变种，理论上将jdk 8u21以下的jdk都受到此反序列化gadget的影响。
2. 直接关闭iiop/t3这两个协议