Weblogic反序列化漏洞分析
重点在 oracle.eclipselink.coherence.integrated.internal.querying.FilterExtractor 这个类，其中有 readExternal 方法，可以对 attributeAccessor 就进行赋值：
这个 AttributeAccessor 类我们很熟悉了，就是之前的 CVE-2020-14841 就已经用到了。接着，跟进到 SerializationHelper.readAttributeAccessor,重新组建 AttributeAccessor 类：
这里有个坑，就是没有调用到 setIsWriteOnly 方法，所以之后的执行到 MethodAttributeAccessor.initializeAttributes 会有点小问题，这之后会提到。
在看到 FilterExtractor 的 extract 方法：
先执行 attributeAccessor.initializeAttributes(obj.getClass()):
这里就是上面的坑点，由于 MethodAttributeAccessor 是通过反序列化重构的，不像 CVE-2020-14841 通过反射直接插入，所以无法修改 IsWriteOnly 的值。所以这里就必须进入 if,且 GetMethod 和 SetMethod 必须有关联.这里的关联是获取 GetMethod 方法的返回类型，然后传入 SetMethod 方法参数中，所以这里直接套用 CVE-2020-14841 的利用方式是不行的：
最后执行到 this.attributeAccessor.getAttributeValueFromObject(obj),就是单纯的无参方法反射执行了：
其实可以看出，后半段的执行方法和 CVE-2020-14841 几乎一样，除了坑点那里稍做修改，可以利用 setConnection 和 connect 方法绕一下。
再来看前半段，有调用到 extract 方法，可以直接用到 CVE-2020-14756 的前半段的方式，这个之前分析过，就不再多说了。
还有最后一点，因为最新的补丁在 T3 反序列化上是用了白名单，所以走 T3 协议不会成功：
只能走 IIOP：
总结一下，这个漏洞其实是多个先前漏洞的组合利用，找到了替代之前黑名单的类，关键还是在 MethodAttributeAccessor 的调用，可以找找其他类中有调用 MethodAttributeAccessor 的地方。